One integration, not N bridges
An agent, intent-solver, or contract issues one call and it fans out to every supported chain. No bespoke bridge per corridor, no validator set to wire up per route — the coordinator does the fan-out.
build passing · 92% test coverage · MIT
One contract.
One contract.
Fifty chains.
Four hundred milliseconds.
Switchboard turns 50+ blockchains into a single state machine that autonomous agents and contracts can act on with one call. Write once, read everywhere — at trading-grade latency, with the gas math to back it up. Built on a Solana coordinator, delivered as a 2-service stack you can run yourself or consume as a managed API. One integration instead of N bridges.
Read the source MIT · 92% test coverage
- Coordination latency
- <400ms
- Chains supported
- 50+
- Ops / second
- 10,000+
- Uptime SLA
- 99.9%
$ switchboard route open \
--from ethereum \
--to solana,arbitrum,base,sui \
--payload ./order.json
[12:04:17.812] coord → solana slot 248_117_902 ✓ 0ms
[12:04:17.901] verify → arbitrum light-client ✓ 89ms
[12:04:17.943] verify → base light-client ✓ 131ms
[12:04:18.064] verify → sui bls-quorum 12/15 ✓ 252ms
[12:04:18.182] ack → ethereum receipt 0xc4f… ✓ 370ms
route 0x6a…f31 settled · p50 252ms · p99 370ms 5 chains · 1 commit p99 370ms
What is Switchboard?
Switchboard is a sub-400ms cross-chain state synchronization platform — the coordination layer autonomous agents and contracts use to act across many chains at once. It uses Solana as a high-throughput coordination clock so a single contract, service, or agent can read and write state across 50+ EVM and non-EVM chains through one integration, without bespoke bridge code per route.
It ships as a two-service stack: a Customer API gateway (auth, rate limiting, request proxy) and a Core Engine (oracle, blockchain ops, cross-chain coordination, billing). Integrate once via the TypeScript SDK or HTTPS and ship to every supported chain — one call fans out instead of N bridges. Run it yourself under MIT, or consume the managed API.
Not the Solana oracle. Cryptuon Switchboard synchronizes and coordinates cross-chain state. It is distinct from the similarly named Solana price-oracle network — Solana here is a coordination clock, not a price feed.
Problem → Solution
Agents shouldn't need a bridge per chain to act everywhere.
The 2026 problem is coordination: liquidity, state, and users are fragmented across dozens of chains, and autonomous agents need to act across many at once. N bespoke bridges don't compose and don't move at agent speed.
The old way
- ✕A bespoke bridge, validator set, and message format per corridor — N integrations to maintain.
- ✕Multi-second quorum times that rule out agents, orderbooks, and perps.
- ✕N trust assumptions and failure modes for one agent to reason about.
- ✕Full calldata cost paid on every single hop.
With Switchboard
- ✓One integration: a single call fans out to every chain.
- ✓One Solana coordinator every chain agrees to watch — atomic composability, one finality clock.
- ✓p50 ~250ms, p99 under 400ms end-to-end — agent-speed.
- ✓Batched commits, roughly 40% gas savings on busy corridors.
Integrate once
One call an agent can act on across chains.
Commit once to the coordinator; a competing relayer pool races the destination transactions inside the 400ms budget. The same call covers every supported chain — adding a chain does not add integration code. It's the primitive an agent or intent-solver needs to act everywhere at once.
app.ts · @switchboard/sdk TypeScript
import { Switchboard } from '@switchboard/sdk';
const sb = new Switchboard({ apiKey: process.env.SWITCHBOARD_API_KEY });
// Read canonical state from any chain through one call.
const liquidity = await sb.read({
chain: 'ethereum',
contract: '0xA0b8…9F21',
key: 'totalLiquidity',
});
// Commit once, ship to many — p99 under 400ms.
const receipt = await sb.write({
from: 'ethereum',
to: ['solana', 'arbitrum', 'base', 'sui'],
payload: order, // arbitrary opaque bytes
verifier: 'auto', // light-client / BLS / zk per chain
finalityPolicy: 'fail-closed',
});
console.log(receipt.routeId, receipt.p99Ms); Features
A coordination layer, not a committee.
Most cross-chain stacks invent governance per route. Switchboard collapses the problem onto a single Solana program that every chain agrees to watch — the coordination layer agents and contracts compose against. See every feature in depth →
Solana-anchored coordinator
Every supported chain shares one finality clock. No per-route governance, no bespoke validator set per corridor — one source of truth running on Solana mainnet. (This is a coordination clock, not the Solana price oracle of the same name.)
Sub-400ms end-to-end
From source commit to destination verification, the median route lands inside 400ms. That is agent-speed coordination — bridge throughput at orderbook speed.
Atomic composability across chains
Commit once to the coordinator and the write propagates to every destination inside one latency budget, with per-route finality policy and a verifiable receipt. Cross-chain state becomes a single call instead of an orchestration problem.
2-service architecture
A Customer API gateway (auth, rate limiting, proxy) and a Core Engine (oracle, chain ops, billing, coordination) — nothing else. MongoDB or PostgreSQL behind it. You can read the whole topology on a napkin.
Pluggable verifiers
Each chain uses the strongest available proof: light-client receipt where possible, BLS threshold signature otherwise, zk-proof for chains that ship them.
40% gas savings via batching
The coordinator commits messages in batches, so destination chains amortize calldata costs across the bundle instead of paying per-route.
Bring-your-own signers
Enterprise teams can plug their own threshold-signing nodes into the relayer pool, keeping signing material under their own custody.
2-service stack
You could draw it on a napkin.
Customer API handles auth, API gateway, rate limiting, security, request proxy. Core Engine runs the oracle service, blockchain ops, billing logic, and cross-chain coordination. That is the whole topology. MongoDB or PostgreSQL behind it — pick with one env var.
- 01Auth + proxy layer (port 3000)
- 02Oracle + chain ops (port 3001)
- 03Pluggable persistence
- 04Solana coordinator program
┌──────────────────┐ ┌──────────────────┐
client ──▶│ Customer API │────────▶│ Core Engine │
│ :3000 │ │ :3001 │
│ auth · rate │ │ oracle · chain │
│ proxy · keys │ │ billing · coord │
└──────────────────┘ └──────────────────┘
│
▼
┌──────────────────────────────┐
│ Solana coordinator program │
│ state-oracle + coordinator │
└──────────────────────────────┘
│
┌──────────────────────┼──────────────────────┐
▼ ▼ ▼
ethereum arbitrum sui
light-client light-client bls-quorum Honest comparisons
How Switchboard stacks up.
We do not pretend competitors do not exist. We picked a position on the curve — speed and simplicity — and these pages are the receipts. See all comparisons →
vs read →
LayerZero
A messaging fabric with chain-paired DVN/Executor security. Wide chain support, configurable security stack.
vs read →
Wormhole
A 19-guardian message-passing network with a strong ecosystem footprint and battle-tested ops.
vs read →
Axelar
A Cosmos-style PoS network of validators acting as a general message-passing layer.
vs read →
Chainlink CCIP
Chainlink Labs message-passing with strong institutional governance and risk management framework.
vs read →
Hyperlane
Permissionless interchain messaging with modular ISMs (Interchain Security Modules).
FAQ
The questions we get.
Mostly from infra teams about to wire us into a perp DEX or a real-time game state engine.
How does Switchboard hit sub-400ms across so many chains?
+
Source events get committed to the Solana coordinator in the next slot (~400ms). The Core Engine watches the coordinator, packages the destination payload, and a competing relayer pool races to land it on the destination — usually within the same wall-clock budget.
Is the core actually open source?
+
Yes — MIT-licensed. The monorepo contains the Solana programs, the Customer API, the Core Engine, the SDK, and a demo app. The managed service adds relayer ops, signing infrastructure, and observability.
What happens if Solana halts or has a slow slot?
+
Each route declares a finality policy: fail-open (use the last confirmed coordinator state and continue), fail-closed (pause until the coordinator catches up), or fallback (switch to a secondary verifier). Defaults are conservative.
Can I self-host Switchboard?
+
Yes. `npm run docker:up` brings up both services with Postgres or Mongo. You still need to run relayers and configure signers, which is what most teams end up paying us for.
How is message security enforced?
+
Switchboard ships a verifier per destination: light-client proof where the chain supports it, BLS threshold signature from the relayer pool otherwise, and zk-proof receipts on chains that natively verify them. You can mix and match per route.
What about chains you do not list?
+
New chains land roughly monthly. If you have a specific chain blocking adoption, Enterprise customers can sponsor a chain integration with a 6-week ETA.
Does Switchboard handle arbitrary call data, or only token transfers?
+
Arbitrary opaque payloads. Adapters handle on-chain encoding. The protocol does not assume a token model.
What database does Switchboard use?
+
Either MongoDB or PostgreSQL — both are first-class. MongoDB is the default in docker-compose; switch with DATABASE_TYPE=postgresql. The Core Engine abstracts the persistence layer so you pick whichever your ops team already runs.
Is this the same as the Solana "Switchboard" oracle?
+
No. Cryptuon Switchboard is a cross-chain state-synchronization and coordination platform — it uses Solana as a coordination clock so one contract or agent can act across 50+ chains. It is unrelated to, and distinct from, the well-known Solana "Switchboard" oracle network. We do not serve price feeds; we synchronize and coordinate state across chains.
How does Switchboard help autonomous agents act across many chains?
+
An agent making agentic payments or executing intents integrates once and issues a single call that fans out to every target chain through the Solana coordinator, sub-400ms end-to-end, with a verifiable receipt per destination. That replaces N bespoke bridge integrations — each with its own trust model and failure mode — with one coordination layer the agent reasons about as a single finality clock.
What do you mean by "atomic composability" across chains?
+
A write commits once to the coordinator and propagates to every destination inside one latency budget, each with a per-route finality policy (fail-open, fail-closed, or fallback) and a verifiable receipt. Instead of orchestrating a sequence of independent bridge calls that can partially fail in hard-to-reason-about ways, cross-chain state becomes a single composable action against one finality clock. Where destination chains allow it, batched commits carry all-or-nothing semantics.
Why one integration instead of N bridges?
+
Every extra bridge is another validator set, message format, quorum time, and on-call rotation. Switchboard collapses that onto one Solana coordinator every chain agrees to watch, so adding a destination chain does not add integration code on your side — the coordinator and per-chain adapters absorb the fan-out. You maintain one SDK surface, not one per corridor.
Explore
Everything, one click deep.
The whole site, mapped. Start with a use case, read an honest comparison, or go straight to the internals.
Use cases
Agent cross-chain coordination
Give an autonomous agent one call to act across many chains.
Cross-chain orderbook
Match on one chain, settle on many — inside a latency budget.
Omnichain state read
Read canonical state from 50+ chains through one call.
Multi-chain governance
Vote once, enact everywhere, with an auditable trail.
Unified liquidity routing
Route against liquidity everywhere as if it were one pool.
Learn
referenceread →
FAQ
Latency, open source, Solana liveness, self-hosting, and how message security is enforced.
referenceread →
Glossary
Coordinator, finality clock, verifier, relayer pool, calldata batching, and the rest of the vocabulary.
writingread →
Blog
Technical deep dives and honest competitor comparisons — latency benchmarks, gas math, finality models.
internalsread →
Architecture
The 2-service topology, message lifecycle, pluggable verifiers, and how gas batching works.
get startedread →
Quickstart
Install the SDK, authenticate, and run your first cross-chain read and write in an afternoon.
companyread →
About
The team, the mission, and why the coordinator runs on Solana.
Wire it up in an afternoon.
git clone, npm run docker:up, and the Customer API is live on :3000 with the Core Engine on :3001. MongoDB by default, PostgreSQL with one env var. Open-source MIT, 92% test coverage, no signup wall.