Problem

Cross chain protocols typically run isolated validator sets or oracle committees per route, which is expensive, slow, and does not scale. Costs grow with validator count, so verifying hundreds of operators on the EVM becomes prohibitive, while committee signatures and relayer hops add latency.

Security is fragmented because every bridge ships its own trust model and attack surface, and operators often have weak economic alignment with unclear slashing paths.

Finality differences across chains complicate safe verification, and each new chain or pair demands bespoke integrations, audits, and ongoing operations, creating vendor lock in and brittle user experience when messages are delayed or stuck.

Relay Solution

The Relay gives you one validation layer for everything: turn any cross-chain message into a money backed, stake secured attestation you can verify on any destination chain. You ship faster, spend less, and gain clearer guarantees.

Some of the Relay advantages can be found below:

• Cheaper at scale. BLS aggregation with optional ZK keeps EVM verify gas essentially flat, even with large validator sets.
• Stronger security. Attestations are backed by bonded stake with explicit slashing and configurable quorum.
• Faster to market. Lightweight client and SDK replace bespoke relayers and committees, reducing code and audits.
• Portable across chains. One attestation format, one verifier; add a chain by deploying the verifier and an adapter.
• Works with existing stacks. Thin adapters feed DVN, Hyperlane, governance, feeds, or your app logic.
• Full control. Customize validator sets, quorum thresholds, stake types and amounts, challenge windows, and slashing rules.

Figure 1 - Relay Flow for Cross-Chain Applications

How it Works

1. Observe and package. An event or message is observed on the source chain and packaged with block height, domain, nonce, and expiry.
2. Attest and aggregate. A configurable quorum of operators signs the package; signatures are aggregated with BLS and backed by bonded stake.
3. Verify on destination. The verifier contract checks quorum and weights, validates metadata, enforces replay and time bounds, and verifies the aggregate. With optional ZK, verification remains near constant in gas even as the validator set grows.
4. Settle the outcome. After verification, adapters execute the intended action: mint or burn, update a feed, trigger a bridge transfer, call governance or settlement, or hand a standard proof to DVN or Hyperlane. Each attestation emits a unique ID and events for auditability and monitoring.

Figure 2 - Relay System Architecture