The case for Solana as a coordinator (and when it isn't)
Why Switchboard puts its coordinator program on Solana, what that costs us, and the specific scenarios where the choice is wrong.
People who pick a coordinator chain usually do not write down why. We are going to, because the question comes up in every customer call and most of the answers floating around are vibes.
Switchboard runs its coordinator program on Solana mainnet. That is a design decision with a clear set of consequences. Some of them are good. Some of them are bad. Most of them are exactly what you would predict if you sat down for half an hour and worked out the requirements.
What a coordinator actually has to do
A coordinator chain is the chain that resolves the question “did this cross-chain event happen?” Specifically, the coordinator has to:
- Receive event commits fast. Sub-second is required; the destination latency is at best the coordinator latency plus the destination chain block time.
- Provide deterministic finality. Destination chains have to agree, with no ambiguity, that a coordinator state at slot N is canonical.
- Be cheap. A coordinator pays per-message fees on every coordinated operation. If the fee is meaningful, it eats your gas savings on the destination.
- Support arbitrary state. The coordinator program is the source of truth for routes, retries, atomicity proofs, and policy. It is not just a message bus.
- Have a healthy validator economy. A coordinator chain whose validators are about to go bankrupt is a coordinator chain that will halt at the worst possible time.
When you put those five requirements next to the major options, the shortlist collapses quickly.
Evaluating the options
Ethereum mainnet. Loses on (1) and (3). Twelve-second block times kill latency, and gas fees at mainnet rates would make sub-cent coordinated operations impossible. Strong on validator economy and finality semantics.
A major Ethereum L2. Loses on (2) — sequencer-controlled soft finality requires waiting for L1 confirmation if you want true finality, which puts you back to twelve seconds. The “fast” path is sequencer-trusted, which is a worse trust model than picking an L1 directly.
Solana mainnet. Wins on (1), (3), (4) cleanly. Sub-second slot times, low fixed transaction fees, generous account model. The trade is (2) and (5): Solana finality semantics are well-specified but newer than Ethereum’s, and the validator economy has had some bumpy years.
Cosmos / a Tendermint chain. Wins on (1), (2), (3) cleanly. Trade-off is (4) — the Cosmos SDK is fine for many things but not as ergonomic as Anchor for the kind of program we wanted to write — and (5), where small Cosmos chains have validator-economy concerns of their own.
Near. Plausible alternative. Fast finality, reasonable fees, healthy economy. The reason we did not pick Near is mostly developer ecosystem: more of the team’s Rust contract experience was on Anchor, and we cared more about audit speed than picking the optimal coordinator on paper.
So Solana wins on the criteria we cared about most. We would not pretend the choice was inevitable. We will pretend it was correct.
What the Solana dependency costs us
It is worth being explicit about the cost side.
Solana halts. Solana has had a handful of halt events in its production history. Each one was a temporary, hours-not-days outage. We have a per-route policy for this: routes can declare fail-closed (pause until coordinator catches up), fail-open (use the last known coordinator state and continue, accepting some risk of inconsistency), or fallback (switch to a secondary verifier — for example, BLS quorum from the relayer pool). We default to fail-closed for new routes because that is the conservative choice. Sophisticated customers pick fallback.
Solana liveness perception. Some customers will tell us in the first call that they cannot use anything that depends on Solana for reputational reasons. We respect that. It usually translates to “our investors will be upset,” which is a real concern even if we think it is wrong on the technical merits.
Coordinator program upgrade authority. The coordinator is upgradeable through a 4-of-7 multisig held by named operators. That is a trust concentration point, period. The way we mitigate it is the small attack surface — the program is ~1,500 lines of Rust, fully audited, with the audit reports public.
Fee token exposure. Coordinated operations pay SOL for the coordinator commit. We absorb this in our managed-service pricing, but self-hosters have to think about it.
When you should not use Switchboard
There are use cases where the Solana dependency is the wrong call:
Regulated financial flows where a Solana liveness pause causes compliance issues. If you are wiring an institutional bridge that has SLA penalties for any pause, you probably want a guardian network that can keep moving under any individual chain’s halt. Wormhole or Axelar are stronger picks there.
Pure token bridging with patient users. If you are wrapping tokens for users who do not care about a 30-second wait, you have no reason to pay for the latency Switchboard sells. Use whatever bridge has the most liquidity for your route.
Cosmos-native workloads. If your entire stack is IBC-connected Cosmos chains, IBC is right there. Adding a Solana coordinator just to talk between two Cosmos zones is silly.
Workflows that benefit from a permissionless validator set. The argument here is values-based, and we do not contest it. Hyperlane and Axelar are designed for this; Switchboard is not.
When you should use Switchboard
The customers who get the most out of us:
- Perp / orderbook teams where the price discovery window is measured in hundreds of milliseconds and a slow bridge is a product-killer.
- Multi-chain game state operators where players expect actions to be visible across chains in real time.
- Auction protocols where the auction window is short and cross-chain bid latency matters.
- MEV-aware routing teams who need cross-chain message ordering to be deterministic in a tight window.
- Anyone running their own ops who wants to replace 4–6 bridge integrations with one and drop the ops headcount.
If you are in one of those buckets, the Solana dependency is the price of admission and the math works out. If you are not, we will tell you so on the first call.
A closing note on chain neutrality
The cross-chain industry has a strong preference for vendor-neutral, chain-agnostic narratives. We did not pick a chain-agnostic narrative because chain-agnostic coordinators are not actually faster — they just spread the latency around. Our value is the speed, and the speed comes from picking a fast coordinator and being honest about it. We picked Solana, we said why, and we will defend it on the merits or change it if the merits change.
That is the trade. If it does not work for you, we get it. If it does, the free tier is right there.