Skip to content
Switchboard
How it works

Two services, one finality clock.

Switchboard is deliberately small. A Customer API gateway handles auth, rate limiting, and request proxying. A Core Engine runs the oracle, blockchain operations, billing, and cross-chain coordination. Behind them sits MongoDB or PostgreSQL, and above them a Solana program that every chain agrees to watch. That is the whole topology.

2-service stack

Customer API ↔ Core Engine ↔ chains.

Requests enter through the gateway, get coordinated on Solana, and fan out to destination chains through the relayer pool. Nothing else is in the hot path.

  • :3000Customer API — auth, rate limit, proxy
  • :3001Core Engine — oracle, chain ops, billing, coord
  • dbMongoDB (default) or PostgreSQL
  • solSolana coordinator program
             ┌──────────────────┐         ┌──────────────────┐
   client ──▶│  Customer API    │────────▶│   Core Engine    │
             │   :3000          │         │     :3001        │
             │   auth · rate    │         │  oracle · chain  │
             │   proxy · keys   │         │  billing · coord │
             └──────────────────┘         └───────┬──────────┘
                                                  │
                                     ┌────────────┴───────────┐
                                     ▼                        ▼
                          ┌────────────────────┐     MongoDB / PostgreSQL
                          │  Solana coordinator│
                          │  state-oracle +    │
                          │  coordinator prog. │
                          └─────────┬──────────┘
                                    │  (relayer pool)
                   ┌────────────────┼────────────────┐
                   ▼                ▼                 ▼
              ethereum          arbitrum             sui
              light-client      light-client         bls-quorum
Message lifecycle

From source commit to destination verify.

Every route follows the same three-stage path, and the whole thing is designed to finish inside a 400ms budget.

  1. stage 01

    Source commit

    Your source-chain event (a state write, an order, a governance outcome) is observed by the Core Engine and committed to the Solana coordinator program in the next slot — roughly 400ms.

  2. stage 02

    Coordinator batch

    The coordinator normalizes state and packages destination payloads. Messages headed for the same chain are batched so calldata cost is amortized across the bundle rather than paid per route.

  3. stage 03

    Destination verify

    A competing relayer pool races the destination transaction. On arrival, the per-chain verifier proves the message — light-client receipt, BLS threshold signature, or zk-proof — and an acknowledgement returns to the source.

Pluggable verifiers

The strongest proof each chain can support.

Security is a per-route decision, not a global compromise. You mix and match verifiers by destination.

Verifier When it applies Notes
Light-client proof Chains that can run a compact client of the source chain. Strongest trust model; preferred wherever the destination supports it.
BLS threshold signature Chains where a light client is impractical. A threshold of relayer-pool signers jointly attest to the message.
zk-proof receipt Chains that natively verify zero-knowledge proofs. Succinct receipts verified on-chain without trusting a signer set.
Gas batching

Amortize calldata across the bundle.

Rather than paying fixed calldata overhead once per route, the coordinator commits messages in batches. Destination chains amortize that cost across the whole bundle, which works out to roughly 40% gas savings versus naive per-chain dispatch. Batch cadence is tunable against your latency budget.

Try it in the quickstart Read the FAQ

Finality policy — what happens if Solana lags

  • fail-open — continue on the last confirmed coordinator state.
  • fail-closed — pause the route until the coordinator catches up.
  • fallback — switch to a secondary verifier for the route.

Defaults are conservative. See the glossary for finality-clock and verifier definitions.