How Do ADI Chain L3 Compliant Chains Work? Deployment Models and Settlement Flow

ADI Chain L3 compliant chains are Layer 3 zero-knowledge Rollups that settle on ADI Chain (L2), while L2 itself settles on Ethereum mainnet (L1). Institutions can run independent chains by jurisdiction or business line and set compliance policies accordingly. Consistent with the dual-layer security model described in the ADI Chain overview, L3 inherits cryptographic guarantees from both L2 and L1 while isolating execution environments and compliance domains from the shared L2 state.

For governments, banks, and industry consortia, L3 enables "one ecosystem, different rules": regulated assets circulate on dedicated chains, open applications run on another L3 or on L2, and all layers interconnect through L2 bridging.

Where Does L3 Sit in the ADI Chain Layered Architecture?

ADI Chain uses an L3→L2→L1 three-tier settlement hierarchy. L3 chains execute transactions locally and maintain independent state; L2 (ADI Chain) verifies L3 batch validity proofs and stores L3 state roots; L1 (Ethereum) verifies L2 batch proofs and finalizes global state. Each layer passes security upward through zero-knowledge validity proofs, so invalid state transitions cannot be accepted by a higher layer.

Unlike deploying dApps directly on L2, L3 provides physical-level execution isolation: each L3 has its own Sequencer, Prover, and Diamond Proxy contract, with states that do not interfere. Multiple L3s can deploy within the same ecosystem, sharing infrastructure contracts such as Bridgehub (chain registry) and StateTransitionManager (STM). ADI L2 throughput is roughly 2,000–10,000 TPS; adding multiple L3s can further scale capacity by application or jurisdiction.

The table shows that L3 is not a standalone public chain but a customizable execution domain nested on ADI L2 and Ethereum L1. ADI L2, as a zkRollup, inherits Ethereum economic security; L3 adds another institutional compliance layer on top.

Figure 1. Position of ADI Chain L3 compliant chains in the L3→L2→L1 layered architecture and the relationship among core components.

What Are the Core Components of the L3 Ecosystem?

The L3 ecosystem deploys shared infrastructure on the L2 settlement layer and chain-specific contracts and operational nodes on each L3. Bridgehub acts as a central registry, maintaining chain ID to contract address mappings, cross-chain message routing, and ecosystem-level configuration. StateTransitionManager handles new chain registration, protocol upgrades, and shared verification parameter management. Each L3 chain is equipped with a Diamond Proxy contract using the Facet pattern for modular upgrades, handling batch submission and verification, state root storage, and validator management.

On the L3 operations side, each chain runs a Sequencer, Prover, and an Operator wallet set (responsible for Commit, Prove, and Execute respectively). On L2, the L2 Prover aggregates L2-native transactions and L3 settlements into proofs submitted to L1. Validator Timelock enforces a delay between Commit and Execute, leaving a window for anomaly detection.

The Diamond Proxy Facet design allows execution, query, and management logic to be upgraded independently. The combination of shared registration infrastructure on L2 with isolated execution state on each L3 is a defining feature of ADI Chain compared with the general L2 "single chain, many apps" model; in the ADI Chain vs Arbitrum and Base comparison, native L3 support and the Bridgehub ecosystem model are among the key differentiators.

What Are the Three Deployment Models for L3 Chains?

ADI Chain L3 supports ADI-managed, client-operated, and hybrid infrastructure models, covering institutional needs from zero-ops to full self-control.

Contract deployment uses role-based access control: Governor handles protocol upgrades, Admin handles emergency actions, Operator executes batch Commit, Prove Operator submits proofs, and Execute Operator executes verified batches. Ownership can transfer fully to a customer multisig or hand over in phased stages. The L3 ecosystem follows a "deploy once, add chains incrementally" pattern: Bridgehub and STM deploy once at the ecosystem layer, and new L3 chains join as independent contracts.

In client-operated mode, the Prover requires NVIDIA H100 or H200 GPUs (70–140 GB VRAM) and system memory of 64 GB or more; the Sequencer requires at least 8 CPU cores, 32 GB RAM, and a public transaction endpoint. Operator wallets must hold $ADI tokens as L2 gas for on-chain operations across Commit, Prove, and Execute.

How Does the Commit-Prove-Execute Settlement Flow Work?

When L3 batches settle to L2, they pass through Commit, Prove, and Execute. The Sequencer packages L3 transactions into batches; the Operator submits a Commit transaction to L2 carrying state diffs (storage slot changes), contract deployment information, and L2→L3 message hashes—not full state snapshots—to reduce data cost.

In the Prove phase, the Prover generates a validity proof using the Airbender proving system (FRI/STARK → FFLONK SNARK pipeline), cryptographically guaranteeing that state transitions comply with L3 execution rules. In the Execute phase, triggered after L2 verifies the proof, the new L3 state root is written to the Diamond Proxy chain contract and the batch is marked finalized.

A full settlement cycle consumes roughly 747,000 Gas total (Commit ~136,000, Prove ~494,000, Execute ~117,000), with each phase paid in $ADI from Operator wallets. In production, FRI and SNARK Provers can run in parallel on separate GPU partitions, improving batch throughput by roughly 15%–20%; a single Prover in the target configuration supports about 15–20 TPS.

Figure 2. Flow from transaction batching through Commit, Prove, and Execute settlement on L2 for an L3 batch.

The recommended Prover configuration is NVIDIA H200 (140 GB VRAM), with 2 parallel FRI Provers and 1 dedicated SNARK Prover (~33 GB VRAM). Institutions in client-operated mode should plan GPU clusters and low-latency L2 RPC connections in advance to maintain batch submission cadence.

How Does Finality Propagate from L3 to Ethereum?

L3 transaction confirmation types upgrade along L3→L2→L1 as settlement progresses. After the L3 Sequencer includes a transaction in a block, users receive second-level soft confirmation and can immediately use transferred assets; soft confirmation relies on Sequencer honesty and does not yet carry cryptographic finality.

After an L3 batch is Committed to L2, it enters the L2 confirmation stage (typically minutes). Once Prove and Execute complete on L2, the L3 state root is written to the L2 chain contract and cannot be rolled back. The L2 Prover then proves L2 state—including L3 settlements—to Ethereum L1; after L1 verifier contracts confirm, the full settlement chain reaches L1 finality (typically hours).

Large settlements or cross-chain withdrawals should wait for L2 or L1 finality; everyday interactions can rely on soft confirmation. Validator Timelock introduces a configurable delay between Commit and Execute, reserving time for anomaly detection.

What Use Cases Suit L3 Compliant Chains?

L3 fits a "rule isolation, shared security" logic: banks run sovereign stablecoin rails, asset managers deploy RWA contracts with KYC-gated access, and governments can tokenize data by jurisdiction. Client-operated deployments carry responsibility for GPU clusters and RPC whitelists; ADI-managed deployments shift operations to ADI.

Summary

ADI Chain L3 compliant chains use an L3→L2→L1 three-layer ZK Rollup architecture so institutions inherit Ethereum-grade security while gaining independent execution domains with compliance rules tailored by jurisdiction. Bridgehub and StateTransitionManager provide shared registration and upgrade infrastructure; each L3 maintains state isolation through Diamond Proxy, an independent Sequencer, and Prover. Batches settle on L2 through Commit, Prove, and Execute; the Airbender proving system and GPU infrastructure (H100/H200) support validity proof generation; finality propagates from L3 soft confirmation to L2 and L1 cryptographic finality. Three deployment models cover different operational and governance needs, suited to sovereign stablecoins, RWAs, cross-border payments, and government data tokenization.

FAQ

What is an L3 on ADI Chain?

An L3 is a Layer 3 ZK Rollup that settles on ADI Chain (L2), allowing institutions, governments, or industry consortia to run independent chains by jurisdiction with custom compliance policies. Each L3 has its own Sequencer, Prover, and Diamond Proxy contract, inherits dual-layer security through L2 and Ethereum, and shares Bridgehub registration infrastructure with other L3s in the ecosystem.

What is the relationship between ADI Chain and Ethereum?

ADI Chain runs as an L2 zkRollup on Ethereum; L2 batch state transitions require L1 verifier contracts to validate ZK proofs before finalization. L3 chains further settle on ADI L2, forming an L3→L2→L1 three-layer validity-proof chain. Assets can move among L1, L2, and L3 via bridges, with the security model inheriting Ethereum economic security at each level.

Is ADI Chain secure?

ADI Chain uses ZK validity proofs, so invalid state cannot be accepted on L1; L3 batches must also pass L2 verification before finalization. The Sequencer provides second-level soft confirmation; cryptographic finality requires proof verification on L2 and L1. Users and institutions should still account for residual risks around bridge contracts, operational key management, L3 self-operated GPU infrastructure, and the window between soft confirmation and L1 finality.

What deployment models are available for L3 chains?

ADI Chain L3 supports three models: ADI-managed (ADI runs Sequencer, Prover, and contract operations), client-operated (the institution runs nodes and GPU proving infrastructure and holds keys), and hybrid (governance stays with the customer while Sequencer and Prover can be flexibly assigned). The choice depends on how an institution balances operational burden, control sovereignty, and compliance flexibility.

What is the Commit-Prove-Execute flow for L3 batches?

The L3 Sequencer packages transactions into batches; the Operator Commits state diffs to L2; the Prover generates a ZK validity proof via the Airbender system and submits a Prove transaction; after L2 verification, the Execute Operator triggers execution, writing the L3 state root to the chain contract and finalizing the batch. The three phases consume roughly 747,000 Gas total, paid in $ADI.

What hardware is required to run an L3 Prover?

Production environments require NVIDIA H100 or H200 GPUs with at least 70 GB VRAM (140 GB recommended), 64 GB or more system memory, and NVMe SSD storage for witness data. The recommended setup includes 2 parallel FRI Provers and 1 dedicated SNARK Prover (~33 GB VRAM), targeting roughly 15–20 TPS. The Sequencer requires at least 8 CPU cores, 32 GB RAM, and a public transaction endpoint.