When we set out to build NexusForge's cross-chain execution layer, we faced a fundamental question: how do you let an autonomous agent operate across multiple blockchains while preserving the same verifiability guarantees that make single-chain execution trustworthy? Bridges solve the problem of moving assets. We needed to solve the problem of moving verified computation.
This post is a technical deep-dive into the architecture we built, the tradeoffs we made, and the benchmarks we are seeing in production. If you are building cross-chain applications or evaluating interoperability solutions, this should give you a clear picture of how NexusForge differs from traditional bridging approaches.
The Problem: State Verification Across Chains
The core challenge of cross-chain agent execution is state verification. When an agent on Ethereum needs to take an action on Arbitrum based on a condition it observed on Solana, three things need to happen: the agent must read Solana's state reliably, it must prove that it read the correct state, and it must submit that proof to Arbitrum in a form that Arbitrum can verify. Each step introduces potential failure modes -- stale state, forged proofs, and verification incompatibilities.
Traditional bridges handle this by running a set of validators or relayers that attest to cross-chain state. This works for asset transfers, but it introduces a trust assumption: you are trusting the bridge's validator set. For an agent that is supposed to be verifiable, delegating trust to a third-party validator set defeats the purpose.
Our Approach: Proof-Native Messaging
NexusForge takes a different approach. Instead of relying on external validators, we use the proof system itself as the messaging layer. When an agent reads state from a source chain, it generates a proof that includes the state root of the source chain at a specific block height, the Merkle path to the specific storage slot it read, and the computation it performed on that data. This proof is then submitted to the target chain's NexusForge verifier contract, which checks all three components atomically.
The key insight is that ZK proofs are inherently portable. A valid proof is valid regardless of which chain verifies it, as long as the verifier contract on the target chain knows the verification key. We deploy verifier contracts on every supported chain, and our relay network handles the transport of proofs between chains. The relay network is untrusted -- it can delay proofs but cannot forge them, because the cryptographic verification happens on-chain at the destination.
Supported Chains and Message Format
As of v2.4, NexusForge supports cross-chain execution across 15 networks:
- EVM chains: Ethereum, Arbitrum, Optimism, Base, Polygon, Avalanche, BNB Chain, Linea, Scroll, zkSync Era
- Non-EVM chains: Solana, Sui, Aptos, Cosmos (via IBC), Starknet
Cross-chain messages follow the NexusForge Cross-Chain Message (NXCM) format, a compact binary encoding that includes the source chain ID, the destination chain ID, the agent ID, a nonce for replay protection, the payload (typically an encoded function call or state assertion), the proof bytes, and a timestamp bound that defines the validity window of the message. The total overhead of the NXCM envelope is 148 bytes, which adds negligible cost to the underlying payload.
Latency Benchmarks
Cross-chain latency depends on two factors: proof generation time and relay transport time. With v2.4's Plonky3 prover, proof generation adds approximately 380ms. Relay transport varies by chain pair, but our relay network maintains the following median latencies:
- EVM to EVM (L2 to L2): 1.2 seconds end-to-end
- Ethereum to Solana: 3.8 seconds end-to-end
- Solana to EVM: 4.1 seconds end-to-end
- EVM to Cosmos: 5.6 seconds end-to-end
These numbers include proof generation, relay transport, and on-chain verification. For comparison, most bridge-based approaches require waiting for block finality on the source chain, which alone can take 12-15 minutes on Ethereum L1. NexusForge agents can operate against pending state with optimistic execution and retroactive proof verification, cutting effective latency dramatically for use cases that tolerate bounded optimism.
How This Differs from Bridges
It is worth being explicit about what NexusForge's interop layer is not. It is not a general-purpose bridge. We do not move tokens or assets between chains -- that is the domain of protocols like Wormhole, LayerZero, and Axelar. What we move is verified computation state. An agent can prove that it observed a specific price on Uniswap (Ethereum), computed a rebalancing action, and executed that action on Raydium (Solana), all as a single verifiable trace.
This means NexusForge is complementary to bridges, not competitive with them. In fact, several of our most active agents use bridge protocols for asset movement and NexusForge for the decision-making and verification layer that wraps those movements. The bridge moves the money; NexusForge proves why the money was moved.
What We're Building Next
The next milestone for the interop layer is proof aggregation across chains. Today, each cross-chain message carries its own proof. In Q2 2026, we will introduce a recursive aggregation service that collects proofs from multiple agents operating across multiple chains and compresses them into a single aggregated proof that can be verified once on any chain. This will reduce the on-chain verification cost for high-volume cross-chain agents by up to 90%, making it economically viable to run verified agents at the scale that institutional DeFi demands.
We will publish the full technical specification for cross-chain proof aggregation in a follow-up post. In the meantime, the NXCM format specification and cross-chain SDK documentation are available in our developer portal.