Architecture of ADI Network: Technical Modules, State Flows, and Airbender Proving Logic

Legacy setups remain fragmented across Africa and Asia. These opaque systems slow down public services. The ADI Chain fixes this by offering a modular Layer-2 network secured by Ethereum. It executes transactions off-chain and converts them into validity proofs. Then, the system settles the final output directly on Ethereum to maintain network security.

According to our analysts, using ZKsync’s zkOS and Airbender stacks keeps performance high. This approach provides a solid foundation for tokenized assets, healthcare data, and cross-border payments. Honestly, the system modules and verification flows are what make it work. Let us examine the exact architecture of the ADI Chain network.

Table of contents:

1. State Transition Framework and Execution Layer of the ADI Chain
2. Airbender Proving Architecture and Multi-Stage Sequence of the ADI Chain
3. Canonical Bridge Design and Cross-Chain Asset Operations of the ADI Chain
4. Layer-3 Scalability and Compliance-Optimized Rollups of the ADI Chain
5. Account Abstraction, Nodes, and Platform Parameters of the ADI Chain
6. Conclusion

State Transition Framework and Execution Layer of the ADI Chain

ADI Chain operates as a modular Layer-2 network secured directly by the Ethereum mainnet. The system employs ZKsync’s Atlas and Airbender stacks to execute transactions off-chain. This setup processes transactions, converts them into validity proofs, and settles the output on Ethereum to provide security. According to our analysts, separating execution from settlement allows for high transaction speeds.

The execution layer acts as the system-level transition function. It accepts transaction blocks and current states to output a fresh state. Interestingly, the program is written in Rust and compiles to two separate targets:

• The x86 target runs inside the sequencer under Forward Running Mode. This target uses standard operating system allocators and skips heavy checks like Merkle proof validation.
• Conversely, the RISC-V target runs inside the Airbender prover during Proving Running Mode. This environment lacks standard system services. This is why memory allocation is managed manually, and the execution flow must be completely deterministic.

The execution program is compiled for distinct targets. Three main parts coordinate within the execution program:

• First, the Bootloader initializes the system and initiates transactions.
• Second, the Execution Environment employs interpreters to process bytecode, Ergs (execution resources), and call context values. When a contract call happens, the environment spins up a fresh interpreter.
• Third, the System handles storage writes, logging events, and memory maps. It communicates with external oracles to read the initial storage slot data.

To reduce unnecessary computation and data overhead, the system separates resource tracking from traditional gas accounting. ADI Chain is EVM-equivalent, meaning it follows Ethereum’s original gas schedule for compatibility. At the same time, the execution proving process is fundamentally more complex than running code on standard hardware.

Instead of only tracking gas usage, the system must also prove how the entire state changes during execution. These state transitions cannot remain internal. They need to be verifiable on Ethereum. For this reason, both the pre-state and post-state commitments are included in the public inputs of the proof. They ensure that the transition can be independently verified.

Airbender Proving Architecture and Multi-Stage Sequence of the ADI Chain

The Airbender proof engine processes RISC-V bytecode execution traces. It runs on top of highly optimized STARK and FRI designs to deliver speed and flexibility. It:

• Uses Arithmetic Intermediate Representation constraints
• Operates over the Mersenne31 prime field
• Applies Blake2s hashes

The proof pipeline follows a strict sequence of 6 stages. This structured sequence manages GPU memory usage effectively.

Generating zero-knowledge proofs demands robust hardware. GPU acceleration remains mandatory. FRI proving times scale inversely with available GPU memory, whereas SNARK proving demands a flat 33 GB. According to our analysts, running the FRI and SNARK provers in parallel across separate GPU partitions increases transaction throughput by 15% to 20%.

Each prover setup targets an output speed of 15 to 20 transactions per second. Nevertheless, overall system throughput can be easily scaled with additional GPUs.

Canonical Bridge Design and Cross-Chain Asset Operations of the ADI Chain

The canonical bridge links Ethereum directly to the Layer-2 blockchain. This native bridge inherits Ethereum’s security directly. It avoids trusted operators and multisig systems. Users pay L2 gas fees in $ADI using the custom gas token model.

Depositing ADI base tokens is simple:

1. The user authorizes the L1 bridge to spend the ADI ERC20 tokens.
2. They call requestL2TransactionDirect on the Bridgehub proxy. Note that the transaction value must be zero.
3. The Bridgehub routes this to the L1 Asset Router, which signals the L1 Native Token Vault to lock the tokens.
4. After locking, the vault updates the chainBalance tracking.
5. The Bridgehub calls bridgehubRequestL2Transaction on the Mailbox, which emits a priority request.
6. Finally, the L2 bootloader prompts the L2 Base Token contract at address 0x800A to mint the user’s native L2 balance.

Standard ERC20 deposits follow a dual-bridge sequence:

1. The user approves both the target ERC20 token and the ADI gas token.
2. They submit the request through requestL2TransactionTwoBridges on the Bridgehub.
3. The Bridgehub locks ADI for L2 gas.
4. The Bridgehub locks the ERC20 asset in the L1 Native Token Vault.
5. The vault reads the token’s metadata, such as symbol and decimals, to prepare L2 deployment.
6. A priority transaction is then pushed to the Mailbox.
7. Once on L2, the L2 Asset Router receives the call.
8. If this is a new asset, the L2 Native Token Vault deploys a bridged token contract using CREATE2 before minting the balance to the user.

Withdrawals also use structured steps:

1. The user calls withdraw on the L2 Base Token contract, which burns the ADI on L2.
2. The contract writes a 56-byte message and passes it to the L1 Messenger at address 0x8008. This action creates an L2-to-L1 log.
3. The sequencer processes the batch, which is subsequently committed and proven on Ethereum.
4. The user then calls finalizeDeposit on the L1 Nullifier.
5. The Nullifier verifies the Merkle proof and sets isWithdrawalFinalized to true.
6. L1 Native Token Vault releases the tokens to the L1 receiver.

Bridge protection is strict. Contract addresses on L1 are aliased on L2 by adding an offset. This prevents smart contracts on Ethereum from forging L2 messages. Meanwhile, the chainBalance ledger tracks locked L1 assets, meaning one compromised chain cannot drain the vault deposits of another.

Layer-3 Scalability and Compliance-Optimized Rollups of the ADI Chain

Scale requires layered structures. Layer-3 chains are specialized rollups that settle on the ADI L2 Chain, which itself settles on Ethereum. These networks inherit security guarantees from both Layer-2 and Layer-1. This is highly useful for corporate deployments. Entities can run their own compliance-optimized domains. This allows them to stay connected to ADI Chain while managing rules for specific jurisdictions. Compliance with ADGM and FATF Travel Rules can be maintained on these separate layers.

L3 chains share the infrastructure deployed on the L2 layer. This solution allows unification of the assets bridged between the ecosystem’s chains. This guarantees no multiple versions of the same token just bridged from different L3 chains.

A single StateTransitionManager registers chains and handles upgrades, while the Bridgehub manages routing. Each L3 chain has a Diamond Proxy contract. Instead of modifying the whole contract, developers upgrade individual sub-contracts (execution, getters, admin). Validator Timelocks impose delays between block commitments and execution. This prevents fast finalization of fraudulent state updates.

Operational roles are strictly split. The Governor manages protocol upgrades, while the Admin handles validator actions. Operators commit batches and pay gas in ADI. Prove Operators submit proof files. Execute Operators finalise the state changes on L2.

Account Abstraction, Nodes, and Platform Parameters of the ADI Chain

Deploying applications on ADI Chain offers several flexibility paths. Builders can use native EVM flows or overlay ERC-4337 smart account stacks. The standard path uses Pimlico Bundlers and permissionless.js to deploy smart accounts. Note that the Bundler does not work in safe mode due to missing debug_trace support on the RPC.

The official ADI Wallet uses Zerodev’s Kernel v3.1 smart account. Note that ADI Chain does not ship default audited paymaster contracts, so teams must audit their custom templates.

Operators can run private, read-only nodes. Setting up a node requires Docker, Docker Compose, and an archive Ethereum L1 RPC. This node downloads committed proofs to verify the L2 state locally. It does not submit transactions, produce proofs, or act as a validator.

Some EVM features are not supported currently on ADI Chain. These include ERC-7702, ERC-4844, and debug_traceCall with custom tracers.

Tokenomics parameters govern the ecosystem currency. At launch, the governance framework remains dormant. It will activate after contract audits and ADGM filings. The genesis supply is 999,999,999 ADI tokens.

Conclusion

Building on the ADI Chain network requires understanding these structural layers. The platform combines a modular execution setup with the Airbender proving system. This ensures absolute correctness for every transaction. From simple asset transfers to complex Layer-3 rollups, the design keeps state transitions secure. Our data shows that separating these operations helps handle heavy enterprise workloads.

ADI Chain is finally the setup that makes decentralized networks practical for governments. As governance features activate and teams deploy specialized chains, the ADI Chain network will support many financial applications.