Vea Bridge

Overview

Vea is a cross-chain message bridge built by Kleros for fast and secure interoperability with optimistic rollups. It solves a specific problem: bridging authenticated data across chains, where no third party can “supply liquidity” the way token bridges do. In the Kleros protocol, Vea handles two message types:

Dispute creation from foreign chains to Kleros Court on Arbitrum (Foreign to Home)
Ruling relay from Kleros Court back to arbitrable contracts on foreign chains (Home to Foreign)

Vea connects the Foreign Gateway and Home Gateway contracts.

For the full Vea protocol documentation including technical deep-dive, SDK reference, and validator guide, see docs.vea.ninja.

Security Properties

Vea differs from most cross-chain bridges in several ways:

1-of-N security: Only one honest participant is needed to force correct bridge execution. The protocol is permissionless, so anyone can be that participant.
Immutable contracts: No governance, no multisig, no upgradability risk.
No tokens, no fees, no rent-seeking: Vea is a public good primitive.
Falls back to native bridges: In the unhappy path, the native rollup bridge (operated by the rollup provider) serves as the source of truth.

Bridge Types

Vea uses different bridge primitives depending on the message direction and security requirements:

Bridge Type	Direction	Mechanism
Simple Bridge	Foreign to Home (dispute creation)	Direct relay via gateways. No fraud-proof game needed because a malicious dispute only wastes the attacker’s gas.
Fast Bridge	Home to Foreign (ruling relay)	Trust-minimized bridge with deposit-backed claims and a challenge period. Falls back to native bridge only when challenged.
Safe Bridge	Fallback	Thin wrapper around the native rollup bridge (e.g., Arbitrum to Ethereum). Used when Fast Bridge claims are challenged.

Fast Bridge Flow

Happy Path

Messages are optimistically verified. Bridging takes hours to a couple of days depending on the source and destination chain. No native bridge is involved. Gas is paid on the destination chain only.

Unhappy Path

If a claim is challenged, the message is sent over the canonical bridge. This can take 7-8 days when sent from optimistic rollups. The dishonest party (either Bridger or Challenger) loses their deposit. Half is burned, half goes to the winning party. The mandatory burn prevents a zero-cost delay-grief attack where Bridger and Challenger are the same entity.

Participants

Role	Description
Bridger	Makes deposit-backed claims on the receiving chain about the state of messages on the sending chain. Competes for first claim per message.
Challenger	Monitors claims. Submits a challenge deposit when a dishonest claim is observed. Does not propose a correct answer; the native bridge provides ground truth.
Relayer	Waits until the challenge period passes, then calls `verifyAndRelay()` to deliver the message to its recipient.

Supported Routes

Route	Direction	Bridge Type
Arbitrum to Ethereum	Home to Foreign	Fast Bridge
Ethereum to Arbitrum	Foreign to Home	Simple Bridge
Arbitrum to Gnosis Chain	Home to Foreign	Fast Bridge (multi-hop via Ethereum in unhappy path)
Base ↔ Ethereum	Both	Added June 2026
Base ↔ Arbitrum	Both	Added June 2026
Arbitrum ↔ Story	Both	Deployed and tested January 2026

Bridge dependencies were upgraded to the latest LayerZero and Chainlink CCIP versions (March 2026).

Vea does not rely on a direct native bridge between Arbitrum and Gnosis Chain. In the unhappy path, challenged claims are resolved using two Safe Bridges: Arbitrum to Ethereum Mainnet, then Ethereum Mainnet to Gnosis Chain.

Contract Components

For each sending-receiving chain pair, there is a separate set of Vea contract deployments with exactly one contract per chain.

VeaInbox (Sending Chain)

Manages the state of all messages sent through Vea. Messages are inserted into an append-only merkle tree (merkle mountain range). Deployed on the home chain (Arbitrum).

function sendMessage(address _to, bytes4 _fnSelector, bytes memory _data) external;

Router (Intermediary Chain, if applicable)

Routes native bridge messages between chains that don’t have a direct native bridge.

VeaOutbox (Receiving Chain)

Manages the optimistic game over inbox state on the receiving chain. Receives claims from bridgers and manages the challenge period.

function claim(bytes32 _messageHash) external payable;
function challenge(bytes32 _messageHash) external payable;
function verifyAndRelay(bytes memory _message) external;

Epoch System

Time is partitioned into epochs defined by an epochPeriod. Epochs mark the period between potential bridging events and define the highest frequency of bridge operation. A claim delay of roughly one epochPeriod is introduced after a snapshot to ensure challengers know the L2 state before claims can be made.

Bridge Protocols

Vea supports multiple underlying bridge protocols:

deBridge was added as a second bridge protocol alongside LayerZero (February 2026). The DeBridgeReporter contract was deployed and tested, with a full end-to-end message tested on the Story-to-Arbitrum route (February 2026).
A three-oracle approach for VeaShi was approved (June 2026): LayerZero and Chainlink CCIP as the two primary oracles, with deBridge or Wormhole as a third slot.
Mainnet deployments were completed on Base and Ethereum with three DVNs in LayerZero (June 2026).

VeaShi

The VeaShi package packages Hashi and Vea contracts for consumption by Kleros V2 (March 2026).
veashi-sdk was published to npm as @kleros/veashi-sdk v0.0.2 (May 2026).
LayerZero contracts were moved under an adapter layout for consistency (May 2026).
The Hashi executor was decoupled from the relayer - splitting message indexing from execution and introducing state-file logic for pending messages that don’t yet meet the Hashi threshold (May 2026).
The Hashi executor was made chain-agnostic (January 2026).

Validator Infrastructure

A second validator became operational (February 2026).
A validator RPC fallback shipped - a degraded primary RPC no longer takes the validator down (June 2026).
The relayer error-handling was refactored - listener setup moved out of the per-network loop, with error-per-chain logging (May 2026).
An RPC provider wrapper handles errors and fallback URLs in both the validator and the relayer (May 2026).

Indexing

The Envio HyperIndex indexer was integrated into the VeaShi scanner, with the existing subgraph kept as a fallback (June 2026).
The VeaShi scanner was moved into the Vea monorepo (June 2026).

VeaScan

VeaScan is the block explorer for Vea bridge transactions. It displays pending claims, challenge status, and relay history.

Resources

Full Vea Documentation

Complete protocol docs: technical deep-dive, SDK, validator guide

Vea GitHub

Bridge contract source code

VeaScan Explorer

Bridge transaction explorer

L2 Integration Guide

Integrate from a foreign chain

Getting Started

V2 Architecture

Arbitrable Apps

Products

Cross-chain

Examples

Subgraph & Data

Overview

Security Properties

Bridge Types

Fast Bridge Flow

Happy Path

Unhappy Path

Participants

Supported Routes

Contract Components

VeaInbox (Sending Chain)

Router (Intermediary Chain, if applicable)

VeaOutbox (Receiving Chain)

Epoch System

Bridge Protocols

VeaShi

Validator Infrastructure

Indexing

VeaScan

Resources

Full Vea Documentation

Vea GitHub

VeaScan Explorer

L2 Integration Guide

​Overview

​Security Properties

​Bridge Types

​Fast Bridge Flow

​Happy Path

​Unhappy Path

​Participants

​Supported Routes

​Contract Components

​VeaInbox (Sending Chain)

​Router (Intermediary Chain, if applicable)

​VeaOutbox (Receiving Chain)

​Epoch System

​Bridge Protocols

​VeaShi

​Validator Infrastructure

​Indexing

​VeaScan

​Resources

Full Vea Documentation

Vea GitHub

VeaScan Explorer

L2 Integration Guide

Overview

Security Properties

Bridge Types

Fast Bridge Flow

Happy Path

Unhappy Path

Participants

Supported Routes

Contract Components

VeaInbox (Sending Chain)

Router (Intermediary Chain, if applicable)

VeaOutbox (Receiving Chain)

Epoch System

Bridge Protocols

VeaShi

Validator Infrastructure

Indexing

VeaScan

Resources