Architecture Overview

An overview of how the system’s components interact to form a modular, general-purpose sequencing stack that applications can integrate seamlessly.

Stack Overview

zkCoprocessor

Role: Executes Verified Off-chain Application Logic within the Risc Zero zkVM. Due to its design it can generate pre-confirms on blockchain state.

• Application specific logic is coded within the Risc Zero zkVM

• Pre-confirms can be customized, by requiring different confirmation levels within the on-chain components.

  • Example levels

    • Execution based on rollup state with customizable block confirmations

    • Execution based on L1 inclusion

    • Execution based on L1 finality

• Expects on-chain inputs for verified UserOps. Input consists of:

  • On-chain transactions with specified orders

  • Optionally it could handle order-flow fully off-chain by accepting off-chain signatures from users

Proof-Based On-Chain Execution Environment - Solidity

• zkVerifier.sol — Custom Execution based on application needs

  • RiscZeroVerifierRouter.sol — Used for verifying the submitted proofs

• BatchSubmitter.sol — Executes transactions in order, in case of failed transaction it has a partial success state, which executes up until the first failed transaction

• Application Specific Logic Example — Lending Protocol

  • Proof-based cross-chain state updates

  • Adjustments on final state calculations to account for multichain state

    • Calculation on all global liquidity existing within the protocol, instead of relying on BalanceOf contract calls

Application Specific Multichain Sequencer

Main Components:

• reth node per network — Not hard requirement, we currently integrated these due to size and simplicity

• sequencer_database — Manages all orchestration based on a database built for application logic

  • batch_manager — Sequences transactions into batches within a 15 second window

  • lane_manager — Volume based reorg protection service

• prover_service — Interfaces with Bonsai and Boundless (offchain flow) to request proofs

Crosschain Sequencing Flow

1. User Submits Operation

   An end-user initiates an action (e.g., deposit, position update, repayment).

   This transaction is initiated on one of the source chains where the app is deployed.

2. Full Nodes Monitor Source Chains

   The Sequencer Client runs full nodes (via reth) for each integrated chain.

   These nodes continuously monitor on-chain events and detect incoming user operations.

3. Sequencer Collects and Orders Transactions

   The Sequencer Module aggregates incoming transactions, orders them deterministically, and groups them into a batch.

4. Prover Module Requests zk-Proof

   The Prover Module takes the batch and sends a proof request to the Boundless / Bonsai prover network, verifying the correctness of the ordered operations against the source-chain state.

5. zk-Proof Returned

   The prover network generates a valid zk-proof and returns it to the Sequencer.

6. Proof Verified On-Chain

   The Sequencer submits the proven batch to the destination chain, where the proof is verified by the on-chain verifier contract.

7. Transactions Executed

   Once verification passes, the Execution Module (BatchSubmitter.sol) executes the transactions on the destination chain, in the predetermined order.

8. State Updates Reflected to End-User

   After execution, the user sees the updated cross-chain state — e.g., assets delivered, collateral credited, position updated, etc.