From Bridges to Intents: Cross-Chain State Sync for the AI Agent Economy

Q: What are intents in crypto?

An intent is a signed declaration of a desired outcome rather than a script of steps. Instead of "bridge X, then swap Y, then deposit Z," you declare "I want 100 USDC on Base for at most 0.03 ETH on Arbitrum, by this deadline," and a competitive set of solvers finds and executes the path, getting paid for delivering the result. Intents are powerful for agents because they collapse brittle multi-step logic into one declarative statement and push execution risk onto specialized solvers. Across is a well-known production example of an intents-based bridge. The open question intents raise is atomicity — which is where Tesseract comes in.

Autonomous agents do not operate on one chain; they hold positions, route payments, and hunt for yield across dozens of them simultaneously, which means the primitive they need is not a token bridge but a way to read and write shared state across chains as if it were one machine. Bridges move assets, messaging protocols deliver payloads, but neither gives an agent a coherent, low-latency view of state across the chains it acts on. Switchboard closes that gap: it is a sub-400ms cross-chain state synchronization platform that uses Solana as a coordination layer, so a single contract can read and write state across 50+ EVM and non-EVM chains without bespoke bridge code — and when those reads and writes must be all-or-nothing, atomic intents (settled by protocols like Tesseract) complete the picture.

TL;DR

Agents are multi-chain by default. An agent managing a treasury, arbitraging a spread, or paying for services touches many chains in a single logical action. It needs one execution surface, not N disconnected ones.
Bridges and messaging are the wrong abstraction for this. Bridges move tokens. Messaging protocols (LayerZero, Wormhole) deliver a payload. Neither lets a contract read and write shared state across chains, and neither guarantees the agent’s higher-level outcome.
Switchboard provides cross-chain state synchronization in under 400ms, using Solana as a coordination layer. One contract, one SDK, 50+ chains, no per-chain bridge glue. It is MIT-licensed and open source.
Intents express outcomes, not steps. Instead of scripting “bridge, then swap, then deposit,” an agent declares the end state it wants and lets solvers find the path. When those intents must settle atomically across rollups, Tesseract enforces all-or-nothing execution with commit-reveal MEV protection.
The ROI is fewer integrations and no stranded funds. One SDK replaces a matrix of bridge integrations; atomic settlement removes the partial-execution risk that makes autonomous multi-chain execution unsafe today.
This builds on our atomicity research. For the formal proof and the Buffer/Resolve/Execute protocol, see the companion post on the cross-chain atomicity problem. This article is about the layer above it: coordinating state for agents. See /solutions for the full stack, or /contact to talk through an integration.

Why the Agent Economy Breaks the Single-Chain Model

For a decade, the mental model for on-chain software has been implicitly single-chain. You deploy a contract to a chain, users interact with that chain, and if you need liquidity or data from somewhere else you bridge it in. The chain is the boundary of your world.

Autonomous agents shatter that model. An agent is not a user clicking one button on one dApp. It is a continuously running process that observes state, forms a plan, and executes across whatever venues offer the best outcome. Consider what a single “reduce portfolio risk” instruction actually entails for an agent:

Read collateral ratios on a lending market on Arbitrum.
Read a perp position’s funding rate on Base.
Read spot prices from AMMs on three different chains.
Decide to unwind part of the perp, move the freed collateral, and top up the lending position — all before the state it read goes stale.

Every one of those reads is on a different chain. Every write the agent wants to make lands on a different chain. And the whole plan is only valid if the state it read is still true when it acts. This is the core difficulty of the agent economy: agents reason over a global state, but the infrastructure they inherited exposes only local state, one chain at a time, stitched together by bridges that were designed to move tokens for humans who could tolerate multi-minute finality.

The result is that agents today are forced into one of two bad patterns. Either they run a bespoke integration per chain — a maintenance nightmare that grows quadratically as you add venues — or they collapse their strategy down to a single chain and leave opportunity and safety on the table. Neither scales to an economy where agents transact autonomously, continuously, and across the entire multi-chain surface.

The state-staleness problem

There is a subtler issue than integration count: time. An agent’s plan is computed against a snapshot of state. If reading that state across five chains takes thirty seconds, the snapshot is already wrong by the time the agent acts. Prices moved. Someone else took the arbitrage. The collateral ratio the agent optimized for no longer holds.

This is why latency is not a nice-to-have for agent infrastructure — it is load-bearing. A coordination layer that synchronizes cross-chain state in under 400ms keeps the agent’s world-view coherent long enough to act on it. A coordination layer that takes minutes hands the agent a plan built on fiction.

Four Abstractions, Precisely Distinguished

The cross-chain space is a graveyard of conflated terminology. “Bridge,” “messaging,” “interop,” and “intents” get used interchangeably, which makes it impossible to reason about what an agent actually needs. Let’s define them exactly, because the differences determine what you can and cannot build.

Bridges: move tokens

A bridge answers one question: how do I get an asset from chain A to chain B? Mechanically, a lock-and-mint bridge locks (or burns) the asset on the source chain and mints (or releases) a representation on the destination chain. Liquidity-network bridges instead pay out from a pool on the destination and rebalance later.

A bridge is an asset-transfer primitive. It has no concept of your higher-level goal. If you bridged USDC to Optimism because you intended to open a position there, and the position-opening transaction reverts, the bridge does not know or care — your USDC is sitting on Optimism, and the intent that motivated the transfer has silently failed. Bridges also typically operate on the timescale of source-chain finality, which for optimistic rollups can be minutes to hours in the pessimistic case.

Messaging: deliver a payload

Messaging protocols — LayerZero, Wormhole, and similar — generalize bridges. Instead of moving only tokens, they let a contract on chain A send an arbitrary payload to a contract on chain B, with some security model (a set of oracles, guardians, or DVNs) attesting that the message is authentic.

This is strictly more powerful than a bridge, and it is the right tool for many jobs. But note what messaging does not give you. A message is fire-and-forget from the sender’s perspective: chain A emits a message, and eventually chain B receives and acts on it. There is no guarantee the action on B succeeds, and no built-in mechanism to undo the action on A if B fails. Messaging gives you delivery, not coordination, and certainly not atomicity. It is honest to describe LayerZero and Wormhole as excellent message-passing rails — and equally honest to say that message-passing is not the same as a shared, readable, writable state surface.

State synchronization: read and write shared state

State synchronization is the abstraction agents are actually missing. The question it answers is: how does a contract read the current state of many chains, and write to them, as if they were one coherent system?

This is what Switchboard provides. Rather than emitting a message and hoping, a contract using Switchboard can query the synchronized state of 50+ chains and issue writes against them, coordinated through Solana as a fast, high-throughput settlement and sequencing layer. Solana’s role here is specific and deliberate: it is a globally-ordered, low-latency ledger that can act as the coordination point where cross-chain state is reconciled, so that reads reflect a consistent snapshot and writes are sequenced coherently. The sub-400ms target is what makes this usable for agents — it keeps the synchronized view fresh enough to plan against.

Crucially, state sync removes the per-chain integration tax. You write against one SDK and one logical state surface. Adding a chain is Switchboard’s problem, not yours.

Intents: express an outcome, let solvers execute

Intents are the highest-level abstraction. An intent does not say how — it says what. “I want 100 USDC on Base in exchange for at most 0.03 ETH on Arbitrum, settled atomically.” The user (or agent) signs that declaration and hands it to a competitive set of solvers, who figure out the concrete path — which liquidity, which venues, which order — and get paid for delivering the outcome.

Intents matter for agents for two reasons. First, they collapse a brittle multi-step script into a single declarative statement, which is far easier for an agent to generate and reason about. Second, they shift execution risk onto solvers who specialize in it. Across is a good example of a production intents-based bridge: the user expresses a cross-chain transfer outcome and relayers fill it, taking on the inventory and finality risk.

But intents raise the atomicity question in its sharpest form. If an agent’s intent spans two rollups and only one leg settles, the agent is worse off than if nothing had happened — funds are stranded and the strategy is broken. This is exactly the problem our atomicity research formalizes, and exactly what Tesseract enforces at settlement time.

Putting It Together: Read, Decide, Act

Here is the shape of a real agent loop built on this stack. The agent uses Switchboard to read coherent cross-chain state, forms an intent, and settles atomically. Let’s walk through it in code.

Switchboard resources: switchboard.cryptuon.com · Documentation · Source on GitHub

Reading and writing cross-chain state

With Switchboard, an agent points at one client and queries many chains through a single synchronized surface. The key property is that the reads come back reflecting a consistent, recent snapshot — coordinated through Solana — rather than N independent RPC calls that drift out of sync.

from switchboard import Switchboard, Chain

# One client, coordinated through Solana, spans 50+ chains.
sb = Switchboard(coordinator="mainnet")

# Read state from several chains as one coherent snapshot.
snapshot = sb.read_state([
    (Chain.ARBITRUM,  "0xLendingMarket", "collateralRatio(address)", agent_addr),
    (Chain.BASE,      "0xPerpVenue",     "fundingRate(bytes32)",     market_id),
    (Chain.OPTIMISM,  "0xAmmPool",       "spotPrice(address)",       eth_addr),
])

# snapshot.block_age is bounded by the sync window (<400ms target),
# so the values are fresh enough to plan against.
assert snapshot.block_age_ms < 400

collateral = snapshot[Chain.ARBITRUM]["collateralRatio"]
funding    = snapshot[Chain.BASE]["fundingRate"]
spot       = snapshot[Chain.OPTIMISM]["spotPrice"]

# Write back across chains through the same surface — no per-chain bridge code.
if collateral < TARGET_RATIO:
    sb.write_state([
        (Chain.BASE,     "0xPerpVenue",     "reducePosition(bytes32,uint256)", (market_id, unwind_amt)),
        (Chain.ARBITRUM, "0xLendingMarket", "addCollateral(address,uint256)",  (agent_addr, topup_amt)),
    ])

The single-SDK ergonomics are the point. There is no LayerZero endpoint per chain, no Wormhole guardian wiring, no bespoke relayer per venue. The agent reasons over one state object and issues writes against one interface.

Expressing the same action as an intent

For value-moving actions where the agent cares about the outcome rather than the path, the same logic becomes an intent. The agent declares the end state and constraints; solvers compete to deliver it.

/// An intent is a signed declaration of a desired outcome,
/// not a script of steps. Solvers race to fill it.
struct Intent {
    // What the agent gives up, and where.
    input:  Asset,        // e.g. 0.03 ETH on Arbitrum
    // What the agent must receive, and where.
    output: Asset,        // e.g. 100 USDC on Base
    // Hard constraints the fill must respect.
    max_slippage_bps: u16,
    deadline:         u64, // unix seconds
    // Settlement mode: does this leg have to be atomic with others?
    atomic_group:     Option<GroupId>,
    // Signature over the canonical encoding, from the agent's key.
    signature:        [u8; 65],
}

/// Solver flow (simplified): observe, plan, fill, get paid.
fn solve(intent: &Intent, book: &SolverBook) -> Result<Fill> {
    // 1. Find a path that satisfies the outcome within constraints.
    let route = book.best_route(intent.input, intent.output)?;
    route.check_slippage(intent.max_slippage_bps)?;

    // 2. If this intent is part of an atomic group, it cannot be
    //    filled in isolation — settlement must be all-or-nothing.
    match intent.atomic_group {
        Some(group) => settle_atomic(group, route),   // via Tesseract
        None        => settle_direct(route),
    }
}

The atomic_group field is where state sync and atomicity meet. An agent that wants two legs — say, closing a position on one rollup only if it can open the hedge on another — tags both intents with the same group. Solvers may fill each independently, but settlement is gated on the whole group, so the agent never ends up half-hedged.

Enforcing all-or-nothing settlement with Tesseract

When an intent group must be atomic across rollups, Tesseract’s three-phase protocol settles it. We covered the formal guarantees in the companion atomicity post; here is the settlement call from the intent solver’s perspective.

from tesseract import AtomicGroup, Chain

# Solver has found fills for both legs; now settle them atomically.
group = AtomicGroup(coordination_window=30)  # seconds; configurable 5-300

group.add_leg(
    chain=Chain.OPTIMISM,
    action="closePosition",
    params={"market": market_id, "size": size},
)
group.add_leg(
    chain=Chain.BASE,
    action="openHedge",
    params={"market": hedge_id, "size": size},
)

# Buffer -> Resolve -> Execute. Either both legs execute or neither does.
# Commit-reveal ordering protects the reveal from front-running.
receipt = group.settle()
assert receipt.status in ("EXECUTED_ALL", "ABORTED_ALL")   # never partial

Tesseract does this without bridges or wrapped assets, using Vyper contracts and a Rust relayer, and enforces the all-or-nothing property through its Buffer/Resolve/Execute phases. The EXECUTED_ALL / ABORTED_ALL invariant is the whole reason an agent can act on a multi-chain plan without risking a stranded, half-completed state.

Fair ordering with commit-reveal

The reveal step in an atomic settlement is a juicy target for MEV: if a searcher can see the reveal before it lands, they can front-run it. Cryptuon’s commit-reveal primitive addresses this with a simple, auditable scheme — commit to a hash first, reveal the preimage later, so ordering is decided before anyone learns the payload.

from commit_reveal import commit, reveal, verify
import os

# Phase 1: commit. Publish only a hash of (action || nonce).
nonce  = os.urandom(32)
action = encode_settlement(group)           # canonical bytes
c      = commit(action, nonce)              # H(action || nonce)
publish_commitment(c)                        # ordering is fixed on this hash

# ... coordination window elapses; ordering is now settled ...

# Phase 2: reveal. Now disclose the preimage.
r = reveal(action, nonce)
assert verify(c, r)                          # anyone can check H(action||nonce)==c

# Optional: a Schnorr ZK proof on secp256k1 can attest knowledge of the
# preimage without revealing it early, for stronger fairness guarantees.

Because ordering is committed before the payload is known, a searcher cannot selectively reorder based on content. The optional Schnorr proofs on secp256k1 let a party prove they hold a valid preimage without disclosing it, which is useful when you want to lock ordering even earlier in the pipeline. This is the same fairness primitive Tesseract uses for its MEV protection.

How the Approaches Compare

No single protocol is best at everything, and it would be dishonest to claim otherwise. Bridges, messaging, state sync, atomic swaps, and interop each occupy a distinct point in the design space. The table below is an honest map of the trade-offs, with an explicit column for how well each fits an autonomous agent’s needs.

Approach	What it does	Atomic?	Latency	Trust model	Agent-fit
Switchboard (state sync)	Read/write shared state across 50+ chains via one contract	Coordinated writes; pair with Tesseract for hard atomicity	Sub-400ms sync target	Solana coordination layer + source-chain security	High — gives agents one coherent, fresh state surface
Tesseract (atomic swaps)	All-or-nothing cross-rollup settlement, no bridges/wrapped assets	Yes — Buffer/Resolve/Execute enforces all-or-nothing	Configurable 5–300s window (default 30s)	Coordinator + commit-reveal; no trusted custodian	High — removes partial-execution risk at settlement
LayerZero	Deliver arbitrary messages between chains	No — delivery only, no cross-chain revert	Depends on DVN/config; often seconds to minutes	Configurable DVN/oracle+relayer set	Medium — good rail, but agent must build coordination on top
Wormhole	Deliver arbitrary messages/attestations	No — delivery only	Guardian finality, typically seconds+	Guardian multisig set	Medium — same as above; messaging, not state
Across	Intents-based bridge; solvers fill transfers	Per-transfer fill, not multi-leg atomic	Fast fills (seconds) for supported routes	Relayers + optimistic verification	Medium-High — great for single transfers, not multi-chain plans
Optimism Interop	Low-friction cross-L2 composability in the Superchain	Aims for atomic cross-L2 within Superchain	Low, intra-Superchain (as reported, rolling out ~early 2026)	Shared Superchain security	High within its scope — bounded to Superchain chains

A few honest notes on this table. Optimism Interop is, as reported and rolling out around early 2026, a genuinely exciting step: the goal is to make cross-L2 transactions feel like switching browser tabs rather than bridging, with atomic composability across the Superchain. If your agent lives entirely inside the Superchain, that may be all the coordination you need. The distinction is scope: Interop is Superchain-native, while Switchboard’s purpose is to span 50+ EVM and non-EVM chains, including ecosystems no single Superchain will encompass. LayerZero and Wormhole are best understood as messaging rails — powerful, widely integrated, and correctly described as delivery layers rather than state or atomicity layers. Across is an excellent intents-based bridge for single transfers; it is not designed to be a multi-leg atomic settlement engine.

The Business Case: Fewer Integrations, No Stranded Funds

The engineering economics here are stark, and they compound as the number of chains grows.

Integration count collapses from a matrix to a line

Without state sync, supporting an agent across N chains means building and maintaining N bridge/messaging integrations, each with its own endpoint configuration, security assumptions, upgrade cadence, and failure modes. Add a chain and you add another integration, another audit surface, another on-call rotation. The cost is superlinear because the interactions between integrations also have to be tested.

With Switchboard, the agent codes against one SDK and one state surface. Onboarding a new chain is Switchboard’s responsibility. The team’s integration cost goes from “one per chain, forever” to “one, total.” For a team shipping an agent product, that is the difference between a dedicated cross-chain infra team and a single dependency.

Partial-execution risk goes to zero

The scarier cost is not engineering hours — it is stranded capital. An autonomous agent that can strand funds mid-plan is an agent you cannot let run unattended, which defeats the entire premise of autonomy. Every partial execution is a manual cleanup, a reconciliation headache, and a potential loss. Atomic settlement via Tesseract makes the outcome binary: the multi-chain action either fully happens or fully doesn’t. That is what lets an operator actually delegate execution to the agent and walk away.

The same principle underpins how agents pay for things across chains — atomic, verifiable settlement is what makes machine-to-machine payments trustworthy. We explore that adjacent problem in the post on agentic payments and on-chain settlement.

Time-to-market and opportunity capture

Freshness has direct P&L consequences for agents that trade or rebalance. A sub-400ms synchronized state view means the agent acts on a world that is still roughly true, capturing spreads and rebalancing at ratios that still hold. Slow, stitched-together RPC views hand that edge to faster competitors. For a yield or arbitrage agent, latency is revenue.

Limitations

Cryptuon publishes limitations because balanced infrastructure claims are the only ones worth trusting. Here is where this stack stands today and where it is going.

Current limitations

Coordination latency is a floor, not zero. Switchboard targets sub-400ms synchronization, which is excellent for cross-chain coordination, but it is not the sub-millisecond world of a single-chain read. Agents whose strategy depends on truly instantaneous cross-chain state must design around this window. Atomic settlement via Tesseract adds a further, deliberate coordination window (default 30 seconds, configurable 5–300s) — the price of the all-or-nothing guarantee.
Liveness assumptions. State synchronization coordinated through Solana inherits a dependency on the coordination layer’s liveness, and atomic settlement inherits a dependency on the relayer/coordinator being available during the window. These are honest liveness assumptions; they do not compromise safety (funds are not at risk), but a coordinator outage delays coordination.
Chain coverage is broad but not universal. “50+ EVM and non-EVM chains” is a large surface, but it is not every chain in existence. A long-tail chain your agent needs may not yet be supported, and adding one is real work even if it is Switchboard’s work rather than yours.
Atomicity requires opt-in. State sync coordinates reads and writes; it does not by itself make a multi-leg action atomic. You get hard all-or-nothing guarantees by routing the settlement through Tesseract’s atomic group. Teams that skip that step get coordinated-but-not-atomic behavior, which is fine for many reads and idempotent writes but not for value-moving multi-leg plans.

Roadmap items

Tighter state-sync-to-settlement integration, so that an agent’s read snapshot and its atomic settlement share a single freshness guarantee end to end.
Wider non-EVM coverage, extending the coherent state surface to more ecosystems beyond the current set.
Solver marketplace maturation for intents, so that competitive fill quality improves and atomic-group intents become a first-class, well-tooled path rather than a manual assembly.
Formal verification of the coordination path, extending the rigor of the “Towards Universal Atomic Composability” research (recognized by a16z Crypto Startup School) further up the stack into the state-sync layer.

For where these pieces fit in the broader Cryptuon stack, see /solutions and the research index.

Frequently Asked Questions

Why do AI agents need cross-chain infrastructure?

Because agents act across many chains at once, not one. A single agent instruction — rebalance a portfolio, capture an arbitrage, pay for a service — typically requires reading state from several chains and writing to several others, all within the window before that state goes stale. Single-chain infrastructure forces the agent to either maintain a brittle integration per chain or artificially restrict itself to one chain. Cross-chain state synchronization gives the agent one coherent execution surface so it can reason globally and act coherently, which is the precondition for genuine autonomy.

What’s the difference between a bridge and cross-chain state sync?

A bridge moves an asset from one chain to another; it is an asset-transfer primitive with no awareness of your higher-level goal. Cross-chain state synchronization lets a contract read and write shared state across many chains as if they were one system. The bridge answers “how do I move these tokens?”; state sync answers “what is the current state across all these chains, and how do I coherently change it?” An agent needs the latter, because its plans depend on a consistent, fresh view of state it does not own, on chains it does not live on. Switchboard provides that view across 50+ chains with a sub-400ms sync target.

What are intents in crypto?

An intent is a signed declaration of a desired outcome rather than a script of steps. Instead of “bridge X, then swap Y, then deposit Z,” you declare “I want 100 USDC on Base for at most 0.03 ETH on Arbitrum, by this deadline,” and a competitive set of solvers finds and executes the path, getting paid for delivering the result. Intents are powerful for agents because they collapse brittle multi-step logic into one declarative statement and push execution risk onto specialized solvers. Across is a well-known production example of an intents-based bridge. The open question intents raise is atomicity — which is where Tesseract comes in.

How does Switchboard keep cross-chain state consistent?

It uses Solana as a coordination layer — a fast, globally-ordered, high-throughput ledger — to reconcile and sequence cross-chain reads and writes, so that a contract sees a consistent recent snapshot rather than N independently-drifting RPC views. The sub-400ms synchronization target keeps that snapshot fresh enough to plan against. A single contract can then read and write across 50+ EVM and non-EVM chains through one SDK, without writing per-chain bridge code. Switchboard is MIT-licensed and open source at github.com/cryptuon/switchboard.

When do I need Tesseract on top of Switchboard?

Whenever a multi-leg, value-moving action must be all-or-nothing across chains. Switchboard coordinates reads and writes, but it does not by itself guarantee that two writes on two different rollups either both succeed or both fail. When your agent’s plan has that requirement — close a position on one chain only if the hedge opens on another — you route the settlement through a Tesseract atomic group, whose Buffer/Resolve/Execute protocol enforces the all-or-nothing property with commit-reveal MEV protection and no bridges or wrapped assets. The formal treatment is in the cross-chain atomicity problem.

How is this different from LayerZero, Wormhole, or Optimism Interop?

LayerZero and Wormhole are messaging protocols: they reliably deliver a payload from one chain to another under some security model, but delivery is not the same as a shared readable/writable state surface, and it does not provide cross-chain atomicity. Optimism Interop (rolling out around early 2026, as reported) aims to make cross-L2 transactions inside the Superchain feel like switching browser tabs, with atomic composability — genuinely powerful, but scoped to the Superchain. Switchboard’s distinct role is to give agents one coherent state surface across 50+ EVM and non-EVM chains, including ecosystems no single Superchain encompasses, and to pair with Tesseract when hard atomicity is required. If you want to discuss which layer your agent needs, get in touch.

Is Switchboard production-ready and open source?

Switchboard is a cross-chain state synchronization platform that targets sub-400ms coordination across 50+ chains, is MIT-licensed, and is open source at github.com/cryptuon/switchboard with documentation at docs.cryptuon.com/switchboard. As with any coordination infrastructure, evaluate it against your own liveness and coverage requirements — see the Limitations section above for an honest accounting, and reach out via /contact to talk through your specific multi-chain agent architecture.