Protocol is across V4's ZK settlement without per-chain bridge adapters

Do not confuse Ethereum-state proof with fill validation

The common mistake is treating Across V4's ZK proof as an independent review of every relayer-funded destination fill. UMA's Optimistic Oracle provides the economic validation layer for the repayment bundle on Ethereum, using a bonded proposal and a challenge window. The proof starts only after that process has produced a confirmed message hash.

SP1 proves a narrower, equally important claim: finalized Ethereum state contains that hash at the expected HubPoolStore location. A destination verifier therefore learns what Ethereum finalized without trusting a chain-specific bridge adapter. It does not recalculate the bundle's token accounting. Two security stages remain distinct: optimistic bundle validation decides the message, and ZK state verification transports the decision.

The cost ledger shifts from adapters to shared verification

Across V4 removes recurring custom-adapter engineering, yet each settlement message still consumes proving work and destination-chain gas during execution. The fixed execution shape begins with two destination transactions: one light-client update and one message execution. Refund leaves then execute as separate calls.

The payable amount comes from four observable inputs: SP1 proof verification gas, calldata size, the destination chain's gas price, and the number of refund leaves executed. Bundle aggregation spreads proof delivery across many fills, so the architecture avoids repeating verification for every user transfer. Chain onboarding also drops the engineering and audit cycle for a bespoke canonical-bridge adapter. Teams still budget for deploying UniversalSpokePool and SP1Helios, operating the Finalizer path, and maintaining chain-specific RPC, indexing, and transaction submission across every network in the deployment set.

What does SP1Helios actually prove?

A related page handles this Across protocol checklist. SP1Helios proves that a specified HubPoolStore value exists in finalized Ethereum state, then records that proven state for destination execution. The circuit connects three evidence layers.

Finalized beacon state

The Finalizer waits for the block containing StoredCallData to reach Ethereum finality before requesting a proof. Ethereum runs 12-second slots, and 32 slots form a 6.4-minute epoch. Across documents a 12-to-15-minute finality wait for this path, matching the two-epoch rhythm plus inclusion variance. The proof consumes finalized beacon headers, so a merely proposed block is insufficient. This checkpoint adds settlement latency after the user-facing fill, while preventing the verifier from accepting a storage value that belongs only to a nonfinal branch.

Sync committee continuity

SP1 Helios verifies Ethereum sync committee transitions inside RISC-V guest code before Succinct's proving network returns a compact proof.

Ethereum's sync committee contains 512 members and stays assigned for 256 epochs. At 32 slots per epoch, that period spans 8192 slots, or about 27.3 hours. SP1 Helios verifies committee updates and the aggregate signature that supports finalized beacon state. The destination contract therefore follows Ethereum consensus through compact proofs rather than a full Ethereum node. Committee continuity matters when a settlement crosses a period boundary, because the verifier needs a valid transition from the trusted committee state to the committee signing the target header. A local preflight checks the witness before remote proving begins.

HubPoolStore inclusion

A Merkle storage proof ties the finalized header to the HubPoolStore slot containing the settlement message hash. An EVM storage word is 32 bytes, and the value must match the event-selected message. This step proves exact inclusion, not a loose association with the contract. Once accepted, SP1Helios stores the proven Ethereum view that UniversalSpokePool queries.

The two calls that make Ethereum state executable

Across V4 converts one completed proof into executable settlement through two ordered destination-chain transactions, followed by permissionless refund-leaf execution.

SP1Helios update

The first transaction calls SP1Helios.update() with the ZK proof. The Finalizer submits two destination-chain transactions: SP1Helios.update() and UniversalSpokePool.executeMessage(). The update advances the light client's proven view of Ethereum and stores the relevant state commitment. A failed update leaves the settlement message unavailable to the next call, preserving the ordering dependency. The topic is examined Across protocol rewards.

UniversalSpokePool execution

The second transaction calls UniversalSpokePool.executeMessage(), which checks that SP1Helios has accepted the referenced hash. UniversalSpokePool then handles relayRootBundle, and individual executeRelayerRefundLeaf() calls pay the listed relayers. The message destination is the repayment chain; in the V4 origin-repayment model, that corresponds to the chain where the user's deposit began. Separating update, message execution, and leaf execution lets operators retry the unfinished stage without replaying the completed proof step.

How does a new chain avoid a custom bridge adapter?

A new chain avoids a bespoke Ethereum bridge adapter by deploying the standard verifier and UniversalSpokePool pattern that Across V4 already understands. BNB Chain, chain ID 56, was the first production use of this architecture.

Universal settlement does not erase chain identity or operational configuration. Ethereum remains chain ID 1, while Base uses 8453 and Arbitrum One uses 42161; every order and transaction still points to a specific network. A workable deployment brings together:

• an SP1Helios contract compatible with the destination runtime;
• a UniversalSpokePool with correct ownership and message permissions;
• Finalizer RPC, indexing, and transaction submission;
• token mappings and expected ERC-20 contract behavior; and
• relayers willing to quote, fill, and fund the route.

Origin-chain repayment changes relayer treasury work

Across V4 repays a relayer on the intent's origin chain after that relayer funds the user's output on the destination chain. Settlement therefore closes the relayer's claim where deposited capital entered the system, while the relayer chooses how to rebalance inventory elsewhere. Centralized exchanges, native bridges, Circle CCTP, and other liquidity routes remain treasury tools rather than parts of the ZK proof. The preferred route changes with inventory, withdrawal constraints, finality, and execution cost.

Which verification path matches a chain's trust model?

The right path depends on whether the application wants Ethereum-state proofs, a native rollup bridge, issuer attestations, or configurable verification modules.

Across V4 packages finalized Ethereum state for UniversalSpokePool. Optimism Standard Bridge inherits the OP Stack's native rollup path. Circle CCTP uses attested burn-and-mint messages for USDC. LayerZero V2 lets an OApp choose Decentralized Verifier Networks, Hyperlane lets an application select an Interchain Security Module, and Wormhole uses signed Verifiable Action Approvals. These systems are not interchangeable merely because each moves data across chains.

Operational limits beyond a valid proof

Across V4 settlement remains operationally dependent on Ethereum finality, proof production, destination execution, and enough relayer capital for the route.

Finality queue

The Finalizer cannot skip the 12-to-15-minute finality checkpoint. A StoredCallData event can exist before its block is final, so proof generation remains in WaitingForFinality. User output may already be filled, but relayer settlement has not reached its executable state. The condition changes when the target header becomes finalized and eligible for proof input.

Proof lifecycle

The ZK API exposes four states: WaitingForFinality, Generating, Success, and Errored. Success means the proof artifact is ready; it does not mean both destination transactions or refund leaves have executed. An Errored job needs diagnosis and a fresh successful proof attempt before settlement advances. Operators should monitor proof state and destination receipts as separate layers.

Route capacity

ERC-20 compatibility expands what contracts can represent, while relayer economics determines what users can actually fill. A route needs destination inventory, source-chain repayment value, native gas, and a quote that covers capital time. Thin or newly deployed markets therefore gain availability only when relayers support them. This is the practical boundary between permissionless contract deployment and usable crosschain liquidity.

ERC-7683 remains above the proof system

ERC-7683 gives solvers a common way to resolve crosschain orders, while Across V4 supplies one protocol-specific method for settling those orders. ERC-7683 standardizes solver-facing order resolution while leaving settlement verification to each protocol.

The current standard represents execution through ordered steps, variables, payments, and explicit assumptions. A Call step carries a 4-byte selector, while ERC-7930 supplies interoperable address encoding for accounts beyond one address format. Across can expose an order to shared solver tooling without asking the standard to understand HubPoolStore, UMA, SP1, or refund trees. That separation keeps order portability independent from the V4 proof backend.

The V3-to-V4 shift in context

Across V3 relied on chain-specific canonical bridge adapters to transmit finalized repayment bundle roots outward from Ethereum to each chain. Across Protocol announced V4 on July 2, 2025, after using BNB Chain as the architecture's first production deployment. V4 retained UMA bundle validation and relayer-funded fills, then replaced adapter-based root transport with SP1 proofs, SP1Helios, and UniversalSpokePool. The change remains most valuable when a destination supports the verifier contracts, reliable finalization infrastructure, and relayers prepared to serve chain ID 56 or any later configured network.