Search

Search for projects by name

ADI Chain logo
ADI Chain

Badges

About

ADI Chain is a zk rollup built for scale and policy alignment.


  • Total Value SecuredTVS
    $1.34 K37.2%
  • Past day UOPSDaily UOPS
    0.0040.0%
  • Stage
  • Gas token
    ADI

  • Type
    ZK Rollup
  • Purpose
    Universal
  • Chain ID
    36900

  • Tokens breakdown

    Value secured breakdown

    View TVS breakdown
    Sequencer failureState validationData availabilityExit windowProposer failure

    Badges

    About

    ADI Chain is a zk rollup built for scale and policy alignment.


    Total
    Canonically BridgedCanonically Bridged ValueCanonical
    Natively MintedNatively Minted TokensNative
    Externally BridgedExternally Bridged ValueExternal

    ETH & derivatives
    Stablecoins
    BTC & derivatives
    Other

    2025 Nov 25 — Dec 18

    Past Day UOPS
    <0.01
    Past Day Ops count
    12
    Max. UOPS
    <0.01
    2025 Nov 27
    Past day UOPS/TPS Ratio
    1.09

    The section shows the operating costs that L2s pay to Ethereum.


    2025 Nov 25 — Dec 18


    Total cost
    $682.92
    Avg cost per L2 UOP
    $0.960512
    Avg cost per day
    $29.69

    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.

    No ongoing anomalies detected

    Avg. proof subs. interval
    Avg. state updates interval
    Past 30 days anomalies

    ADI chain mainnet launch

    2025 Dec 9th

    ADI mainnet is live as a ZK stack L2 secured by the Airbender prover.

    Learn more
    Sequencer failureState validationData availabilityExit windowProposer failure
    Sequencer failure
    Enqueue via L1

    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.

    State validation
    Validity proofs (ST, SN)

    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.

    Data availability
    Onchain (SD)

    All of the data (SD = state diffs) needed for proof construction is published onchain.

    Exit window
    None

    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.

    Proposer failure
    Cannot withdraw

    Only the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen.

    ADI Chain
    ADI Chain is a
    Stage 0
    ZK Rollup.
    The requirement for available node software is under review

    Learn more about Rollup stages
    Please keep in mind that these stages do not reflect rollup security, this is an opinionated assessment of rollup maturity based on subjective criteria, created with a goal of incentivizing projects to push toward better decentralization. Each team may have taken different paths to achieve this goal.

    All data required for proofs is published on chain

    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.

    Learn more about the DA layer here: Ethereum logoEthereum

    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.


    Prover Architecture

    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.

    PROVER

    Trusted Setups

    Used in

    Verifiers

    1

    Used in

    Verifiers

    1

    Used in

    Verifiers

    1

    Used in

    Verifiers

    1

    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.

    The system has a centralized operator

    The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.

    • MEV can be extracted if the operator exploits their centralized position and frontruns user transactions.

    Users can force any transaction via L1

    If a user is censored by the L2 Sequencer, they can try to force their transaction via an L1 queue. Right now there is no mechanism that forces L2 Sequencer to include transactions from the queue in an L2 block. The operator can implement a TransactionFilterer that censors forced 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.

    1. L1 - L2 interoperability - Developer's documentation

    Regular messaging

    The user initiates L2->L1 messages by submitting a regular transaction on this chain. When the block containing that transaction is settled, the message becomes available for processing on L1. ZK proofs are required to settle blocks.

    1. Withdrawing funds - ZKsync documentation

    Forced messaging

    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.

    A dashboard to explore contracts and permissions
    Go to Disco
    Disco UI Banner

    Ethereum

    Actors:

    Governance 0x8253…da95

    Allows scheduling transparent and shadow proposals, ‘securityCouncil’ role can execute without delay.

    • Can upgrade with no delay
      • ChainTypeManager
      • L1NativeTokenVault
      • L1Nullifier
      • L1MessageRoot
      • BridgeHub
      • L1ChainAssetHandler
      • CTMDeploymentTracker
      • ValidatorTimelock
      • L1AssetRouter
    • Can interact with ChainTypeManager
      • manage the shared ValidatorTimelock contract address and the admin role, register and execute upgrades (and set their deadlines), freeze, revert batches and set permissioned validators and fee params for all connected chains
    • Can interact with BridgeHub
      • set critical contract addresses for the shared cluster, register settlement layers, pause and unpause migrations and the bridge and manage zk chain registration
    • Can interact with RollupDAManager
      • manage allowed rollup DA pairs (allowed to be used by rollups in permanent rollup mode)
    ADI Multisig 2 0xB272…3754

    A Multisig with 2/3 threshold.

    • Can upgrade with no delay
      • ServerNotifier
    • Can interact with ChainTypeManager
      • revert batches for any connected chain (ZK cluster Admin role)
    • Can interact with BridgeHub
      • create new zk chains (based on the current version), register tokens (ZK cluster Admin role)
    ADI Multisig 1 0xF502…0Cf9

    A Multisig with 2/3 threshold.

    • Can interact with Diamond
      • administrate operator roles for this chain in the ValidatorTimelock, manage fees, apply predefined upgrades, manage censorship through a TransactionFilterer, set DA mode, migrate the chain to whitelisted settlement layers (Chain Admin role)
    • Can interact with ValidatorTimelock
      • call the functions to commit, prove, execute and revert L2 batches through the ValidatorTimelock in the ADI Diamond contract
    • Can interact with L1Nullifier
      • pause, unpause and set critical escrow address references
    • Can interact with ChainAdminOwnable
      • set the conversion factor for gas token deposits
    • Can interact with L1NativeTokenVault
    A dashboard to explore contracts and permissions
    Go to Disco
    Disco UI Banner

    Ethereum

    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.

    • Roles:
      • getAdmin: ChainAdminOwnable; ultimately ADI Multisig 1

    [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.

    • Roles:
      • admin: ChainAdminOwnable, ProxyAdmin; ultimately ADI Multisig 2, Governance
      • owner: Governance
    Can be upgraded by:
    RollupL1DAValidator 0x45D5…DDA7

    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.

    • Roles:
      • admin: ProxyAdmin; ultimately Governance
      • owner: EOA 4
    Can be upgraded by:

    Aggregates remote bridge message roots from all ZK stack chains. To be used with the Gateway when deployed.

    • Roles:
      • admin: ProxyAdmin; ultimately Governance
    Can be upgraded by:

    [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.

    • Roles:
      • admin: ChainAdminOwnable, ProxyAdmin; ultimately ADI Multisig 2, Governance
      • owner: Governance
    Can be upgraded by:
    RollupDAManager 0x96A4…787e

    Simple registry for allowed DA address pairs for the ‘rollupdata 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.

    • Roles:
      • owner: Governance

    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.

    • Roles:
      • admin: ProxyAdmin; ultimately Governance
    Can be upgraded by:

    Intermediary contract between the Validators and the central diamond contract that delays block execution (ie withdrawals and other L2 --> L1 messages) by 0s.

    • Roles:
      • admin: ProxyAdmin; ultimately Governance
      • validatorVTL: EOA 1, EOA 2, EOA 3, EOA 5
    Can be upgraded by:
    ChainAdminOwnable 0x0a8a…B5B8

    A governance proxy that lets ADI Multisig 1 act through it.

    • Roles:
      • owner: ADI Multisig 1
      • tokenMultiplierSetter: EOA 6
    ChainAdminOwnable 0x2d6E…2Ca7

    A governance proxy that lets ADI Multisig 2 act through it.

    • Roles:
      • owner: ADI Multisig 2
    L1ERC20Bridge 0xfA8B…C3B8

    Legacy bridge for depositing ERC20 tokens to ADI Chain.

    Canonical central asset escrow for all ZK stack chains.

    • Roles:
      • admin: ProxyAdmin; ultimately Governance
      • owner: EOA 7
    • This contract can store any token.
    Can be upgraded by:
    DualVerifier 0x28E3…C529

    A router contract for verifiers. Routes verification requests to the corresponding fflonk or plonk verifiers depending on the supplied proof type and version.

    ProxyAdmin 0x34f5…C90C
    • Roles:
      • owner: ChainAdminOwnable
    L1VerifierFflonk 0x60aD…6208

    Verifies a zk-SNARK proof using an implementation of the fflonk proof system.

    ProxyAdmin 0x8140…3217
    • Roles:
      • owner: Governance
    L1VerifierPlonk 0x8F87…c4Ba

    Verifies a zk-SNARK proof using an implementation of the PlonK proof system.

    Specialized contract for managing chain assets, i.e. chain migrations.

    • Roles:
      • admin: ProxyAdmin; ultimately Governance
    Can be upgraded by:

    A simple contract that can be called by the ChainAdmin to emit notifications about chain migrations.

    • Roles:
      • admin: ProxyAdmin; ultimately ADI Multisig 2
    Can be upgraded by:

    Value Secured is calculated based on these smart contracts and tokens:

    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).