Cross-chain integration engineering: routes, adapters, and failure handling

The short answer

Cross-chain applications break at the edges: one leg executes and another does not. Cryptuon starts from the exact chain pairs you need and a written failure model for each route. We then choose the protocol for each route, build the adapters, and prove the failure handling with injected faults on forks and testnets before any mainnet value moves.

Two questions are often treated as one, and they should not be. “How fast is the message?” is about coordination. “When is the workflow settled, and what happens if it is not?” is about settlement. We sell answers to both.

Decision criteria

The questions that decide cost and approach:

Which exact chain pairs, assets, and values?

“Multi-chain” is not a scope. “USDC from Arbitrum to Base, up to $250k per transfer, 400 transfers a day” is. Each chain pair has its own protocol coverage, finality, gas profile, and liquidity. A route that a protocol supports in its documentation still has to be tested end to end for your asset and contract.

What happens when one leg fails?

For each route we list the failure cases and the terminal state each one must reach:

• Destination revert: slippage, a paused contract, insufficient liquidity, or a changed allowance.
• Delivery without execution: the message arrives, but the executor runs out of gas or a stored payload waits for a retry.
• Destination stalls: a sequencer is down or congested past the workflow’s deadline.
• Source reorg: the message was sent on a soft confirmation that later reorganised.
• Relayer or verifier outage: no one submits the next leg.
• Rate limit hit: a token-transfer limit pauses the route mid-flow.
• Deadline race: a resolution lands on one chain after refunds have opened on another.

Each case ends in one of three states: completed, refunded, or queued for a named person to act on. It also needs an alert. “It probably won’t happen” is not a state.

Is coordination latency the number you need?

Vendor latency figures usually measure coordination, not settlement. Switchboard’s design target is sub-400 ms to commit on its Solana coordinator. Tesseract’s swap groups use a configurable 5 to 300 second coordination window, with 30 seconds as the default. As our own atomicity write-up notes, Tesseract operates at L2 sequencer confirmation, not at L1 finality. Ethereum finality takes about 13 minutes, and native withdrawals from optimistic rollups wait out a challenge period of about seven days. We measure every route against the settlement point your application relies on.

Messaging, intents, or atomic settlement?

• Messaging (LayerZero, Wormhole, CCIP, Hyperlane) delivers a payload. If the destination fails, compensation is your application’s job.
• Intent bridges (Across) let a relayer front the funds on the destination and take the finality risk. This is fast for supported assets, but it is a transfer, not a multi-leg transaction.
• Atomic groups (Tesseract) make every leg resolve or become refundable. They cover only supported EVM rollups and add gas for the extra phases.

Who operates it after launch?

Relayers, executor gas wallets, pause authority, verifier configuration, and alerting all need owners. The operational surface often costs more over a year than the integration itself.

Implementation options

Approach	How it works	Strength	Tradeoff	Maturity
Tesseract (Cryptuon)	Vyper contracts on each EVM rollup plus a Rust relayer; commit, reveal, then resolve every leg of a swap group or make each refundable after its deadline	Native assets, no wrapped tokens, all-or-nothing intent at the contract layer	EVM rollups only; adds a coordination window; resolution relies on an authorised resolver role and sequencer-level confirmation	Open source, 135-test suite, testnet-deployable; no third-party audit published
Switchboard (Cryptuon)	A Solana program acts as coordinator; two services relay to destinations, with a verifier and a fail-open, fail-closed, or fallback finality policy for each route	One integration surface for many chains	Adds Solana liveness as a dependency; coverage must be verified for each chain pair	Declared: source on GitHub; latency figures are design targets
LayerZero	Immutable endpoints; the application configures verifier networks (DVNs) and an executor for each path	Broad chain coverage; OFT standard for omnichain tokens	Security is whatever you configure; failure handling at the destination is the application’s job	Established, widely used on mainnet
Wormhole	A 19-member guardian set signs messages (VAAs) that destination contracts verify	Broad EVM and non-EVM coverage, including Solana	Trust in the guardian set; its 2022 exploit still shapes many risk reviews	Established, widely used on mainnet
Chainlink CCIP	Chainlink oracle networks carry messages and tokens, with an additional risk-management layer and rate limits on token transfers	Defence in depth; managed service	Coverage and timing are set by Chainlink, and waiting for source finality makes some routes slow	Established, on mainnet
Hyperlane	Permissionless deployment; each application chooses an Interchain Security Module	Can reach chains others do not cover	You design the security module and often run relayers	Established, on mainnet
Across	Intent-based: relayers fill on the destination from their own capital and are repaid after optimistic verification	Fast fills for supported assets	Asset transfers on supported routes; not general multi-leg atomicity	Established, on mainnet

Most production designs are mixed by route. An established messaging protocol carries governance or configuration messages, an intent bridge handles user transfers, and atomic settlement is used only where a partly executed workflow would be expensive.

The delivery sequence

1. Route inventory. Chain pairs, assets, value bands, volumes, and finality assumptions.
2. Failure matrix. Every failure case for every route, with its terminal state, detection time, and owner.
3. Protocol selection. The protocol for each route, chosen against the matrix, with verifier configuration and rate limits.
4. Adapters. Contracts and client code, with replay protection, pause controls, and idempotent handlers.
5. Failure injection. Automated tests on local forks and testnets that stall, revert, and replay each leg.
6. Measurement. p50 and p95 latency on testnet for each route, measured to the agreed settlement point.
7. Operations. Monitoring, stranded-value alerts, runbooks, and an audit-readiness pack.

The route manifest is the contract between design and tests. An illustrative example:

# Illustrative route manifest: one entry per chain pair and flow.
routes:
  - id: arb-to-base-usdc-rebalance
    source: arbitrum-one
    destination: base
    asset: USDC
    max_value_usd: 250000
    protocol: tesseract-swap-group   # candidate; testnet only until audited
    settlement_point: l2-sequencer-confirmation
    deadline_seconds: 30
    on_failure:
      destination_revert: refund_all
      destination_stalled: refund_all
      relayer_offline: refund_all
      source_reorg: page_oncall
    alerts:
      stranded_value_after_seconds: 60
  - id: eth-to-solana-governance
    source: ethereum
    destination: solana
    payload: governance-config
    protocol: wormhole
    settlement_point: source-finality
    on_failure:
      destination_revert: retry_then_page_oncall
      delivery_without_execution: retry_with_backoff

Each on_failure entry becomes a test. Here the destination leg stalls past its deadline, and both legs must end refundable with nothing stranded:

// Failure-injection acceptance test. `openSwapGroup`, `refundAll`, and
// `tokenBalances` are the project's own harness (illustrative names);
// the chains are two local Anvil forks.
import { createTestClient, http, parseUnits } from "viem";
import { foundry } from "viem/chains";
import { expect, it } from "vitest";
import { openSwapGroup, refundAll, tokenBalances } from "./harness";

const arb = createTestClient({ chain: foundry, mode: "anvil", transport: http("http://127.0.0.1:8545") });
const base = createTestClient({ chain: foundry, mode: "anvil", transport: http("http://127.0.0.1:8546") });

it("refunds every leg when the Base leg misses its deadline", async () => {
  const before = await tokenBalances(["arbitrum", "base"]);
  const group = await openSwapGroup({
    legs: [
      { chain: "arbitrum", sell: "USDC", amount: parseUnits("1000", 6) },
      { chain: "base", buy: "WETH", minOut: parseUnits("0.25", 18) },
    ],
    deadlineSeconds: 30,
  });

  await base.setAutomine(false); // simulate a stalled sequencer
  await arb.increaseTime({ seconds: 31 });
  await base.increaseTime({ seconds: 31 });
  await arb.mine({ blocks: 1 });
  await base.setAutomine(true);
  await base.mine({ blocks: 1 });

  expect(await group.status()).toBe("refundable");
  await refundAll(group);
  expect(await tokenBalances(["arbitrum", "base"])).toEqual(before);
});

Evidence

• Tesseract’s commit, reveal, and resolve lifecycle, the resolver role, and the relayer topology are documented in how it works and the Tesseract documentation. The quickstart runs the 135-test suite and deploys to a testnet.
• Tesseract’s comparisons with LayerZero and Across set out where each approach fits.
• Switchboard’s two-service architecture, verifiers for each destination, and finality policies are described on its architecture page and in the Switchboard documentation. It also has a comparison with Chainlink CCIP.
• Gas overhead estimates for each phase and Tesseract’s limitations, including its sequencer-level finality assumption, are in the cross-chain atomicity problem. Where state sync fits relative to bridges, messaging, and intents is covered in cross-chain state sync for the agent economy.
• Tesseract builds on the paper Towards Universal Atomic Composability, listed on /research.
• Not yet evidenced: neither project has a published third-party audit. Switchboard’s sub-400 ms latency and its chain counts are design targets with no independently reproduced benchmark. In the maturity register, Tesseract is at “reproduced” and Switchboard at “declared”, and neither has been accepted in a paying delivery.

What drives the cost

• Number of chain pairs and protocols. Each route adds adapters, test fixtures, and monitoring.
• Failure cases that need automated tests. Stalls, reverts, reorgs, and replays each need harness support.
• Non-EVM chains. Solana, Cosmos, or Bitcoin-adjacent legs need different tooling and test environments.
• Value at risk. Higher values justify stricter verifier configuration, lower rate limits, and longer settlement waits.
• Operations. Relayer and executor gas management, alerting, and on-call cover after launch.
• Audit scope. Custom contracts on any route need an independent audit before they hold mainnet value.

Limitations and what we won’t do

• We do not operate bridges, hold pooled liquidity, or take custody of funds.
• We do not guarantee the security or uptime of third-party protocols. We design for their failure.
• Tesseract covers supported EVM rollups only and has not been audited. We will not put it on a mainnet route without an independent audit.
• Switchboard’s figures are design targets. Any chain pair that relies on it is tested before it is proposed.
• If one chain, or one well-established protocol, solves your problem, the assessment will say so.

Next step

Send us the chain pairs, assets or message types, rough values and volumes, and any incident you have already had. The specialist assessment returns a route inventory, a failure-mode matrix, a protocol recommendation for each route, and a costed implementation plan.