Search for projects by name
ADI Chain is a zk rollup built for scale and policy alignment.
ADI Chain is a zk rollup built for scale and policy alignment.
2025 Nov 25 — Dec 18
The section shows the operating costs that L2s pay to Ethereum.
2025 Nov 25 — Dec 18
This section shows how "live" the project's operators are by displaying how frequently they submit transactions of the selected type. It also highlights anomalies - significant deviations from their typical schedule.
Users can submit transactions to an L1 queue, but can’t force them. The sequencers cannot selectively skip transactions but can stop processing the queue entirely. In other words, if the sequencers censor or are down, they are so for everyone.
STARKs and SNARKs are zero knowledge proofs that ensure state correctness. STARKs proofs are wrapped in SNARKs proofs for efficiency. SNARKs require a trusted setup.
All of the data (SD = state diffs) needed for proof construction is published onchain.
There is no window for users to exit in case of an unwanted standard upgrade because the central operator can censor withdrawal transactions by implementing a TransactionFilterer with no delay. The standard upgrade delay is 0s.
Only the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen.
All the data that is used to construct the system state is published on chain in the form of cheap blobs or calldata. This ensures that it will be available for enough time.
Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.
MatterLabs proof system Airbender can be found here and contains essential tools like the Prover, the Verifier, and other backend components. The docs about the system can be found here.
Funds can be lost if the proof system is implemented incorrectly.
Upgrades are managed by a Governance smart contract on L1. The owner of smart contract (eth:0xB272B188855128c10a933Edb62CC64c22B1f3754) can schedule either transparent or shadow proposals. Transparent proposals have full upgrade data onchain when scheduled. Shadow proposals post only the hash of the upgrade data onchain when proposed, and the full upgrade data during execution.
Scheduled proposals must wait a minimal delay before being executed (currently 0s). Governance supports a ‘securityCouncil’ role (eth:0x59Be28DE6eFb1f78802E96188d2b7907059Be59f) that can execute proposals without any delay.
Currently, the governance process does not involve ADI token holders. See this link for more info: https://docs.adi.foundation/appendix/appendix-b-governance.
MEV can be extracted if the operator exploits their centralized position and frontruns user transactions.
Users can be censored if the operator refuses to include their transactions.
Users can be censored if the operator implements a TransactionFilterer, which is possible without delay.
If the user experiences censorship from the operator with regular L2->L1 messaging they can submit their messages directly on L1. The system is then obliged to service this request or halt all messages from L1, including all forced withdrawals and deposits. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.

Allows scheduling transparent and shadow proposals, ‘securityCouncil’ role can execute without delay.
A Multisig with 2/3 threshold.
A Multisig with 2/3 threshold.

The main contract defining the Layer 2. Operator actions like commiting blocks, providing ZK proofs and executing batches ultimately target this contract which then processes transactions. During batch execution it processes L1 --> L2 and L2 --> L1 transactions.
[FORK] This contract is not the standard hub contract from the Elastic network but a local fork for ADI chain. Defines L2 diamond contract versions, creation and upgrade data and the proof system for all ZK stack chains connected to it. ZK chains are children of this central contract and can only upgrade to versions that were previously registered here. The current protocol version is 0,29,0.
Contract that verifies the data availability of ethereum calldata and blobs. Can be used by ZK stack rollups as the L1 part of a DAValidator pair.
Contract responsible for bookkeeping L1 bridging transactions. Used to finalize withdrawals and reclaim failed deposits. Does not escrow funds.
Aggregates remote bridge message roots from all ZK stack chains. To be used with the Gateway when deployed.
[FORK] This contract is not the standard hub contract from the Elastic network but a local fork for ADI chain. The main registry (hub) for chain contracts (supports more than ADI chain) and central entrypoint for bridge transactions. Stores important mappings like from chainId to diamond address, from chainId to parent CTM, from chainId to base token etc. A clone of Bridgehub is also deployed on each L2 chain, but this clone is only used on settlement layers.
Simple registry for allowed DA address pairs for the ‘rollup’ data availability mode (can be permanently enforced with isPermanentRollup=true). Rollup DA address pairs (especially the L1 part) usually point to contracts that validate if data was made available on Ethereum.
Asset deployment tracker where the ‘asset’ is a ChainTypeManager. The registering of asset IDs for ChainTypeManagers is necessary to be able to migrate them to a given settlement layer, for example the Gateway.
Intermediary contract between the Validators and the central diamond contract that delays block execution (ie withdrawals and other L2 --> L1 messages) by 0s.
A governance proxy that lets ADI Multisig 1 act through it.
A governance proxy that lets ADI Multisig 2 act through it.
Legacy bridge for depositing ERC20 tokens to ADI Chain.
Canonical central asset escrow for all ZK stack chains.
A router contract for verifiers. Routes verification requests to the corresponding fflonk or plonk verifiers depending on the supplied proof type and version.
Verifies a zk-SNARK proof using an implementation of the fflonk proof system.
Verifies a zk-SNARK proof using an implementation of the PlonK proof system.
Specialized contract for managing chain assets, i.e. chain migrations.
A simple contract that can be called by the ChainAdmin to emit notifications about chain migrations.
Main escrow contract of ADI chain.
The current deployment carries some associated risks:
Funds can be stolen if a contract receives a malicious code upgrade. There is no delay on code upgrades (CRITICAL).