Why a court needs a bridge

Kleros is a dispute resolution protocol. Jurors stake, vote, and produce a ruling. That ruling has to reach the application that requested it. When the court and the application live on different chains, the ruling has to cross a bridge.

The bridging problem for a court is unusual. A payment bridge moves value: as long as tokens arrive intact, the user can absorb small delays or reorgs. A ruling bridge moves an authenticated instruction. "Release this escrow." "Slash this bond." "Mark this claim as fraud." The message is small, but a manipulated or delayed ruling can drain arbitrary amounts of value locked in the arbitrable contract. The bridge cannot afford a compromised message, and it cannot afford censorship of a valid one.

Cross-chain bridges usually pick a point on the latency-security curve. Canonical rollup bridges (Arbitrum, Optimism, and Base) are as secure as the rollup itself but take days to finalize withdrawals. Third-party message bridges finalize in minutes, but they add a trust assumption on the bridge operator. Neither trade-off is ideal for a court.

Vea was Kleros's first answer to this problem and still handles routes where a canonical bridge exists and two days is acceptable. VeaShi covers the rest: chains outside Vea's reach and rapid courts where the latency budget is minutes.

Vea: an optimistic bridge with a canonical fallback

Vea is an optimistically-verified cross-chain message bridge. It was introduced in May 2023 in Introducing Vea, and is designed around a trust assumption borrowed from optimistic rollups: the bridge is secure as long as at least one honest participant is watching.

In the common case, messages cross in hours via an optimistic claim game. In the adversarial case, the bridge falls back to the canonical rollup bridge, which is slower but as secure as the rollup itself.

VeaInbox and the Merkle tree

On the source chain, VeaInbox maintains an incremental Merkle tree of every message sent through the bridge. Each sendMessage call appends a leaf. The tree state stays compact, and periodically the current root is snapshotted.

Snapshots are epoch-based. An epoch is a fixed time window. At the end of each epoch, the current tree root becomes that epoch's snapshot. Once an epoch has passed, its snapshot is a stable value that can be claimed on the destination chain.

Claiming a snapshot

On the destination chain, VeaOutbox accepts claims of the form "epoch N had root R." A claim can be posted for any epoch that has already passed on the inbox side. If the current epoch on VeaInbox is 10, only epoch 9 can be claimed on VeaOutbox.

The claim requires a bond. This bond gives an honest verifier something to challenge and what an incorrect claimant stands to lose.

The challenge window

Once a claim is posted, any account can challenge it by posting a matching bond. A challenge is a bet that the claimed root does not match the actual root computed from the source chain. Claims remain challengeable until the claim is verified, not just for a fixed period after posting.

Whichever party is wrong loses their bond to the party that was right. This is the game-theoretic core of the bridge: as long as one honest verifier is willing to challenge false claims, false claims are unprofitable.

Verification and the sequencer delay

Verification can begin for any posted claim, but the claim remains challengeable while verification is in progress. Only after verification completes does the claim finalize.

The reason is Arbitrum-specific. The Arbitrum sequencer can force-include user transactions submitted directly to L1 with a delay of up to 24 hours. This means the observed inbox state at a given moment could still change if a batch of backdated transactions is later published. sequencerDelayLimit is a safe window that covers this delay, so the claim only finalizes once no further backdating can invalidate the observed root. The value is set with headroom above the 24-hour maximum, on the order of 30 hours.

The delay applies at verification, not at claim time. Claims themselves can be posted as soon as the epoch has passed.

Censorship test

Optimistic bridging only works if honest challengers can get their challenge transactions on-chain. If the destination chain is under strong censorship, where block producers are reorged out or slots are missed, an honest challenger could be censored long enough for a fraudulent claim to finalize.

On Ethereum-style proof-of-stake chains, block headers carry enough slot information to detect this statistically. Blocks are produced on a fixed slot cadence, and missed slots increment the timestamp without incrementing the block number. Vea uses this to count missing slots during a claim's lifetime. If the count exceeds a configured threshold, the censorship test fails and the claim cannot be optimistically verified. Resolution falls back to the canonical bridge instead, regardless of whether a challenger appeared.

Under normal network conditions the test passes and Vea operates optimistically. During periods of degraded consensus, for example after a hardfork, the test can fail, and Vea slows down to canonical-bridge finality on its own. Reference thresholds under consideration: on Ethereum mainnet, roughly 601 missing slots in 7200 (~8%), assuming at least 10% non-censoring validators and a 1-in-a-million risk tolerance; on Gnosis Chain, roughly 3207 in 17280 (~18.5%) with the same risk tolerance and 20% non-censoring validators. Full derivation is in the Vea technical deep dive.

The router and the canonical fallback

If a claim is challenged, the bridge falls back to the canonical bridge as the source of truth. The canonical bridge carries the actual snapshot root computed at the source.

When source and destination chains share a native bridge, the canonical message goes directly to VeaOutbox. When they do not, a Router contract on an intermediary chain relays the canonical message onward. Kleros deploys a Router on Ethereum for the Arbitrum-to-Gnosis route, where Arbitrum's canonical bridge terminates on Ethereum and the Router forwards to Gnosis.

The canonical message is executed on VeaOutbox to resolve the challenge. Whichever side of the claim-challenge dispute matches the canonical root wins.

This fallback is why Vea can call itself trust-minimized: in the worst case, security degrades to the security of the underlying rollup bridge, not to the honesty of a third-party operator.

The canonical bridge is not part of the normal message flow. It is only touched when a claim is disputed. In the happy path, no canonical message is ever sent.

The one-of-n trust model

For an attacker to steal messages through Vea, they need to post an incorrect claim with a bond and ensure that no honest verifier challenges it before the window closes. The second condition is the load-bearing one. Anyone can run a verifier. As long as one honest verifier exists and is willing to lose a bond to challenge a bad claim, the attack fails.

This is why more validators strengthen the bridge. Each additional independent implementation reduces the chance that a bug or an outage takes down every verifier at once. Kleros currently operates two Vea validator implementations, with a third in active development, and hosts them.

Why we built VeaShi

Vea works, and it works well for its target case: bridging between an optimistic rollup and its parent chain, or between two rollups with shared native bridging. Three constraints pushed Kleros toward a different design for chains outside that target.

Native bridging is not always available. Vea's fallback path relies on an uncompromisable canonical bridge. Optimistic rollups have one. Gnosis Chain has one. Chains like Story do not. Without a canonical bridge to fall back on, the optimistic game has no source of truth to resolve to. Vea cannot be deployed to those chains without giving up its trust-minimization property.

Fast courts need faster bridging. Vea's happy path takes around two days, dominated by the challenge and verification windows. That is acceptable for most disputes, where the jury vote itself takes days. It is not acceptable for the fast-court patterns; Kleros is building (sometimes referred to as AI courts), where the whole point is a ruling in minutes. VeaShi's happy path is 20 to 25 minutes.

Validator diversity is bounded. Vea's security scales with the number of independent honest validators. Kleros currently runs all of them. Even with multiple independent implementations, the operator is one entity. Adding independent third-party bridges through a threshold aggregator provides a security layer that does not depend on Kleros running more nodes.

VeaShi: Vea combined with Hashi

VeaShi is Kleros's message bridge built on top of Hashi, Gnosis's EVM hash oracle aggregator. Hashi's design principle is that a message should be accepted on the destination chain only if a threshold of independent bridges agrees with it. VeaShi wires that principle up for Kleros's specific set of chains and bridges. The contracts live in the veashi-contracts workspace inside the Vea monorepo.

Yaho on the source chain

Yaho is the source-chain entry point. When Kleros wants to send a message, it calls Yaho with the message payload. Yaho computes a hash of the message and hands it to a set of registered reporters. Each reporter is responsible for transmitting that hash to the destination chain over one specific bridge.

Reporters and adapters

Each reporter has a matching adapter on the destination chain. The reporter takes Yaho's hash and pushes it into its bridge. The adapter receives whatever the bridge delivers and records the hash on-chain, tagged by the reporter it came from.

VeaShi uses four bridge oracles as reporter-adapter pairs:

• LayerZero: a widely-used general-purpose message bridge with configurable security stacks.
• Chainlink CCIP: Chainlink's cross-chain interoperability protocol, backed by its decentralized oracle networks.
• Axelar: a general-purpose message network with wide chain coverage.
• deBridge: a general-purpose message bridge that covers chains outside CCIP and Axelar's reach, including Story.

The three bridges were chosen deliberately. From a pure security-model perspective, all three fall into the same category: an off-chain set of signers is responsible for verifying and signing the message on-chain. What makes the combination secure is that the three sets of signers are independent, and the three implementations are different. Compromising the message requires compromising a threshold of them at the same time. Axelar was added because it is the cheapest of the set and covers the most chains, which matters when Kleros needs to deploy to a new chain. deBridge was added to cover chains that CCIP and Axelar do not support, notably Story.

Hashi

Once adapters have recorded hashes for a given message, Hashi is the threshold aggregator that decides when the message is valid. The threshold is included with the message itself: each message specifies how many adapters must report the same hash for it to be considered agreed. If that number of matching adapter reports has not been reached, the message is not executable through Yaru.

Yaru on the destination chain

Yaru is the destination-chain executor. Once Hashi certifies that a message hash has met the threshold, Yaru calls the target application with the message payload. Yaru only executes messages that Hashi has certified, so an application receiving a message from Yaru knows that the required threshold of independent bridges has agreed to it.

Where Vea fits inside VeaShi

VeaShi is best understood as an additional security layer on top of Vea, not as its replacement. For routes where Vea can operate (optimistic rollups and chains with native bridging), Vea sits alongside the third-party bridges as one of the reporter-adapter pairs feeding into Hashi. Even if all Vea validators were compromised, the Hashi threshold from independent third-party bridges would still have to be met before Yaru could execute a message. For routes where Vea cannot operate, such as chains without a canonical fallback, VeaShi runs with only the third-party bridges.

Vea and VeaShi side by side

What's next

VeaShi expansion. VeaShi is the default choice for new routes where Vea is not viable, particularly chains without native bridging (such as Story) and routes where fast-court latency requirements rule out Vea's two-day happy path.

Vea for L2 routes. Vea remains the design for optimistic-rollup routes where the 1-of-n trust model plus canonical fallback is sufficient. Additional L2 routes are on the list to be added.

Mainnet. Mainnet deployments are on the roadmap for Vea.

Validator implementation diversity. A third Vea validator implementation is in active development. The goal is code-path diversity: three independently written validators reduce the chance that a single bug or misconfiguration takes down the honest side of the claim game.