What is Across V4?

This is a technical deep dive where we will walk through the entire V4 flow, defining each actor in the system and the specific function they perform to allow Across Protocol to expand to more chains, faster.

Across Protocol now uses zero-knowledge proofs (ZKPs) with Succinct to expand to more chains, faster. Across V4 allows us to decouple the trust model from destination-chain adapters, enabling permissionless expansion to new chains without custom verification logic.

V4 is already powering our BNB Smart Chain bridge in production.

We will break down the execution flow into several parts and the core differences between V3 and V4 in detail.

Fundamentals for Learning Across V4

Across traditionally required some form of “canonical bridge” or adapters for destination chains to verify messages from Ethereum’s HubPool. This was fine for chains like Arbitrum or Optimism, which expose Ethereum-finalized state natively.

But for chains like BSC, this breaks down. There's no trusted or canonical way to verify Ethereum state. Historically, this meant either building custom adapters or skipping support entirely.

Across operates on a powerful three-step system for processing user intents:

1. A request-for-quote mechanism houses users' cross-chain requests.

2. A competitive network of relayers bids on and fulfills these requests.

3. A settlement layer verifies intent fulfillment and ensures relayers are repaid.

With Across Protocol V4, the first two steps (requesting and filling) remain identical to V3 for the best user experience. Our innovation focuses squarely on Step 3, the settlement layer. We are integrating zero-knowledge (ZK) technology with Succinct’s help to transform how we verify intent fulfillment on various destination chains.

This enhancement creates a single, universal system for repaying relayers on any chain, allowing across to expand to more chains, faster.

Across Protocol V4 Architecture

Across Protocol V4 uses a modular architecture where each component has a distinct role. Together, they enable fast, secure, and universal cross-chain settlement.

• UMA's Optimistic Oracle: Verifies relayer repayment bundles off-chain before the settlement process begins.

• HubPoolStore Contract on Ethereum: An L1 contract that stores message hashes, acting as the universal source of truth.

• Finalizer: An off-chain service that listens for L1 events and orchestrates the proof and settlement process.

• ZK API: An off-chain service that generates the ZK proof needed to verify an L1 message on any destination chain.

• SP1Helios: A destination chain contract that acts as a ZK light client of Ethereum, verifying proofs and storing proven L1 state.

• UniversalSpokePool: A destination chain contract that executes the final message after confirming its validity with SP1Helios.

Now that we have seen the architecture at a glance, let's dive in!

Anchoring the Intent on Ethereum L1

The entire process begins on Ethereum, our root of trust. Here, two key actors set the stage:

1. UMA's Optimistic Oracle Function: Verify Repayment Bundles The flow starts after a group of relayers have successfully fronted liquidity to users on various destination chains. A bundle of these fills is submitted to UMA's Optimistic Oracle. This oracle assumes the bundle is valid unless challenged within a specific window, providing a fast and economically secure method to confirm that the proposed repayments are legitimate

2. HubPoolStore Contract on Ethereum Function: Persist and Announce Intents Once a repayment bundle is confirmed by the oracle, the HubPoolStore contract is called. Its job is to take the hash of each root bundle (repayment messages) and write it to a specific storage slot within its contract state. Crucially, every time it stores a hash, it emits a StoredCallData event. This event contains the message hash and the slot where it was stored. So the data now stored in the HubPoolStore along with the event emitted becomes the anchor for ZK verification.

The Off-Chain Proof Generation Engine

With the intent anchored on L1, the action moves to our off-chain infrastructure. This is where ZK is incorporated, orchestrated by two primary services:

1. The Finalizer Function: Listen and Initiate The Finalizer is a service that constantly monitors the HubPoolStore for StoredCallData events. When a new event is emitted, it initiates a process to prove that the message hash was indeed written to Ethereum. It starts by requesting the ZK API for the proof of storage slot on Ethereum. However, the ZK API cannot act immediately. It must first wait for the Ethereum block containing the event to be finalized (approximately 12-15 minutes). A proof cannot be generated for a non-finalized state.

2. The ZK API Function: Manage and Generate Proofs Once finality is achieved, the Finalizer requests a proof from the ZK API. The ZK API is a stateful service that manages the entire proof lifecycle, using Redis to track requests through four statuses: ::WaitingForFinality, ::Generating, ::Success, or ::Errored. The proof generation process is as follows:

   1. Gather proof_inputs: The API gathers all the necessary data: the finalized beacon headers, the collective signature from Ethereum's sync committee (a group of 512 validators that attest to block finality), and the Merkle proof demonstrating that the specific storage slot in the HubPoolStore contains the message hash from the event. (Note: there are more input fields, these are just the ones we are focusing on for now)

   2. The Pre-Flight Check: Generating a ZK proof is computationally intensive. To avoid wasting resources on a proof that is destined to fail, the sp1-sdk we use performs a critical pre-flight check. It spins up a local RISC-V Virtual Machine (VM), loads the proof_program, and runs it with the collected proof_inputs. This is not just a type-check; it is a full, local execution of the proof logic. If it succeeds, we have high confidence the final proof will generate correctly.

   3. Generate the Proof: With a successful pre-flight, the API sends the job to our proving partner (Succinct's SP1 network) to generate the final, verifiable ZK proof.

   

Universal Verification on the Destination Chain

The final act takes place on the destination chain, where a generic set of contracts can universally verify the state on Ethereum. This is the approach that allows Across Protocol to expand to more chains, faster:

1. The Finalizer (Step 1) Function: Deliver and Verify the Proof The process begins with a transaction that calls the .update() function on the Sp1Helios contract, providing the ZK proof and its public outputs (which includes the Merkle root of the repayment bundle). Sp1Helios then verifies the proof. Upon success, it saves the root bundle hash to its state, creating a trusted record of the L1 event on the destination chain.

2. The Finalizer (Step 2) Function: Execute the Proven Message Once the first transaction is confirmed, a second, separate transaction is sent to the UniversalSpokePool contract to call .executeMessage(msg). This function's primary role is to relay the now-verified root bundle (SpokePool.relayRootBundle). Before doing so, it queries Sp1Helios to confirm the root hash is present in its state. Since the first transaction was successful, the check passes, and the UniversalSpokePool executes the message, officially settling the bundle on the destination chain.

3. Universal Spokepool Function: Process Final Repayments on the Origin Chain Relaying the root bundle is the crucial step that enables final repayments, but it does not trigger them directly. Individual relayer refunds are then processed through separate calls to functions like .executeRelayerRefundLeaf().

V4 is for Everyone

Whether you're a user, builder, relayer, or chain team, V4 offers something that makes your life easier and your onchain experience better. Here's what that means:

• Users get more supported chains, more bridge routes, and faster availability of new tokens.

• Builders integrate Across once, and tap into a growing universe of L1s and L2s without waiting for audits or custom deployments.

• Relayers are no longer bound to protocol-defined repayment flows. Repayments now happen on the origin chain, and you can rebalance however you want (via CEXs, other bridges, or your own systems).

• Chains can integrate quickly and easily. If your ecosystem needs a bridge and there’s a clear user demand, Across can now launch support with almost zero friction.

V4 is designed to make bridging easier for everyone.

Next Steps

Get start with building your crosschain apps using Across V4 today:

1. Check the Bridge Integration Guide: For a step-by-step walkthrough of how to build a bridging experience in your application using our SDK.

   • Read the Bridge Integration Guide

2. Review the API & SDK: The best way to start is with our high-level tools. They are V4-compatible and abstract away the protocol's complexity.

   • API Reference: For direct HTTP integration to get quotes and check transaction status.

   • App-SDK Guide: For deeper integrations within a TypeScript or JavaScript application.

3. Join the Community: Have a technical question or want to connect with the team and other developers? Our Discord and telegram are the best places to get support.

   • Join the Community