Question 1

What is Quasar and the TUWA Ecosystem?

Accepted Answer

Quasar is the headless API engine powering the TUWA Ecosystem. It serves as the central synchronization hub for transaction indexing (via Pulsar), cross-device state sync, and authenticated webhook delivery. Quasar is available as a managed cloud service and as the open-source, self-hosted Community Edition (Apache-2.0), so you choose who operates the infrastructure and where your transaction data lives.

Question 2

Is Quasar open source? Can I self-host it?

Accepted Answer

Yes. Quasar Community Edition is the open-source, self-hosted distribution of the Quasar engine, published under the Apache-2.0 license at github.com/TuwaIO/quasar-community. It runs on your own VPS or bare-metal server with Docker Compose and includes the same transaction engine as Quasar Cloud: two-phase lifecycle tracking for EVM and Solana, partitioned PostgreSQL 16 storage, BullMQ workers, and SSRF-protected, HMAC-signed webhooks. The node is managed through a Payload admin panel secured with email, password, and TOTP two-factor authentication.

Question 3

What is the difference between Quasar Cloud and the Community Edition?

Accepted Answer

Both run the same transaction indexing engine. Quasar Cloud is the managed, multi-tenant service: TUWA operates the infrastructure, and you get the developer dashboard with team access, SIWX wallet sign-in, passkeys and email notifications. Quasar Cloud is in public beta and free of charge: every organization gets 1,000 free quota units, paid quota is not available yet, and Quasar Cloud reads your transactions through your own RPC provider. The Community Edition is single-tenant and self-operated: you run it on your own servers, manage it through the Payload admin panel, and pay only for your hardware and RPC providers. It has no billing, and its quota and RPS limits are set effectively unlimited. SIWX sign-in, passkeys, transactional email, and the customer portal are available only in Quasar Cloud.

Question 4

Does the same SDK work with a self-hosted node?

Accepted Answer

Yes. @tuwaio/quasar-sdk talks to the same Engine API in both editions. Set the baseUrl option to your node (for example, https://api.your-domain.com) and use a secret key created in your node's admin panel; Pulsar sync, transaction history, and webhooks work the same way. To move an organization from Quasar Cloud, an owner exports it on its organization page and the node's admin panel imports the encrypted file: the apps keep their API keys and the webhooks their signing secrets, the transaction history comes along, and your apps only change baseUrl.

Question 5

What do I need to run a Quasar Community node?

Accepted Answer

A Linux server with Docker Engine and Docker Compose v2. The minimal profile starts PostgreSQL 16, Redis, the Payload admin panel, and the NestJS engine with a single command. The production profile adds PostgreSQL high availability with PgBouncer, WAL-G backups, Traefik ingress with TLS, an optional Cloudflare Tunnel, and Prometheus, Loki, and Grafana monitoring. You also need your own RPC and provider keys (such as Alchemy, QuickNode, Pimlico, or Gelato), configured per app in the admin panel. The repository ships a GitHub Actions pipeline that builds, scans, signs, and deploys the images to your server. Step-by-step guides are in docs/QUICKSTART_LOCAL.md and docs/PRODUCTION_DEPLOY.md.

Question 6

How do I get started with the API?

Accepted Answer

Create an organization in the Quasar Dashboard, then an app in it, as a live or a test app. The app gets a secret key (sk_live_… or sk_test_…) for your server and a read-only public key. In Quasar Cloud, add your RPC provider to the app (an RPC endpoint, an Alchemy key or a QuickNode key): Quasar Cloud reads transactions only through it. Call the API at api.tuwa.io with @tuwaio/quasar-sdk, which sends the secret key for you; the Quasar docs at docs.tuwa.io/quasar walk through it.

Question 7

How is the Quasar API protected?

Accepted Answer

Quasar has two layers. The Management Layer (quasar.tuwa.io) serves the dashboard and sign-in behind a Next.js proxy, and the Performance Layer (api.tuwa.io) serves the engine behind a NestJS guard. The guard resolves the API key, checks the domain and IP allowlists of the app, and enforces the requests-per-second limit of the organization. Secret keys are stored encrypted and looked up by their SHA-256 hash.

Question 8

How does the Quota and Billing system work?

Accepted Answer

Quasar Cloud is in public beta and free of charge. Every organization receives 1,000 free quota units, and quota cannot be bought during the beta. A sync of a live-app transaction uses 10 units (5 on a test app), each first webhook delivery uses 1 unit, and history reads are free. During the beta, features, limits and the free units may change.

Question 9

How does Quasar prevent quota discrepancies or double-charging?

Accepted Answer

We use a "Swap-and-Sync" strategy. API consumption is buffered in Redis using organization-scoped locks. Background cron jobs then reconcile these counts to PostgreSQL, guaranteeing atomic quota deductions even during system restarts or crashes.

Question 10

Which networks are supported?

Accepted Answer

Quasar is multi-chain by design. We support all major EVM-compatible networks (including Ethereum, Polygon, BSC, and Base) as well as high-performance Solana indexing. Support for new chains is continuously added via the Pulsar Sync engine.

Question 11

Can I use my own RPC endpoints with Quasar?

Accepted Answer

Yes, and in Quasar Cloud it is required: Quasar Cloud reads the transactions of your apps only through your own RPC provider, an RPC endpoint for each chain, an Alchemy key or a QuickNode key in the settings of the app. Without one, a synced transaction is refused with an explanation. A Community Edition node can also fall back to keys set by its operator and to public endpoints.

Persistence & Sync for Web3 Transactions