ADI (ADI)

ADI Token Explained: The Gas Asset for an Institutional Ethereum Layer 2

ADI is designed as the operating token for ADI Chain, a zkSync-based Layer 2 focused on regulated payments, tokenized assets, and jurisdiction-specific enterprise networks. Its practical importance depends on network usage, governance activation, contract permissions, and the delivery of the system described in project documentation.

What ADI Chain is trying to build

ADI Chain is presented as an Ethereum Layer 2 for institutional finance rather than as a general-purpose consumer chain. The project describes use cases including payments, digital identity, registries, logistics, stablecoins, and real-world asset tokenization. Its proposed enterprise model also includes separate Layer 3 domains that can be tailored to particular institutions or jurisdictions. These are stated project objectives; the documentation does not, by itself, establish the scale of live usage or the completion of every listed use case.

The architecture is built around the zkSync stack, including Airbender for proof generation and a modular execution layer based on zkSync OS. ADI’s technical documentation says the execution program is written in Rust and compiled for two environments: x86 for sequencing and RISC-V for producing a validity proof. In a rollup configuration, state commitments and proofs are intended to be checked on Ethereum. The documentation also says the network can support rollup and validium modes, so data-availability assumptions may differ by deployment.

How the Layer 2 mechanism works

In the documented rollup model, transactions are executed on ADI Chain, grouped into batches, and represented by a zero-knowledge proof. The proof is submitted to Ethereum, where a verifier contract checks whether the state transition is valid before the new state is accepted. This design separates execution from settlement: ADI Chain handles application activity, while Ethereum is intended to provide the settlement reference point.

ADI’s execution design also tracks more than ordinary EVM gas. The documentation describes double resource accounting, combining an EVM-equivalent gas measure with a separate computational resource intended to reflect proving costs. That distinction matters for developers because a transaction that is inexpensive from an execution perspective may still consume meaningful proving or data resources. The project documentation explicitly says ADI Network and zkSync OS remain under active development, so implementation details may change.

What the ADI token does

ADI is specified as the native gas token for ADI Chain and associated Layer 3 domains. The project says users need ADI for transfers, smart-contract execution, and decentralized application interactions, using zkStack’s custom gas-token capability rather than paying network fees directly in ETH. The token is also described as a medium of exchange between users, enterprises, developers, validators, and ecosystem services. These functions create a direct link between token utility and actual network activity, but they do not demonstrate that demand is currently sufficient to support a particular valuation.

The documentation additionally describes ADI staking into a treasury-backed pool that pays rewards without minting new tokens. That mechanism should be assessed through the terms of the staking contracts, the source of rewards, withdrawal conditions, and the identity and control of the treasury. The reviewed materials describe the intended model but do not independently establish its economic sustainability or the extent of live participation.

Supply design and contract control

ADI’s tokenomics documentation lists a genesis supply of 999,999,999 tokens. It allocates 35% to a community fund, 25% to treasury reserves, 12% to private investors, 10% to partnerships, 10% to the team, 4% to a token-incentivization pool, and 4% to liquidity. Several allocations unlock over 72 or 108 months, while private investors, partnerships, and the team have 12-month cliffs. The page says first-year unlocks occur monthly on the ninth day of each month.

The public ADI token repository describes an upgradeable ERC-20 implementation with role-based permissions. Its stated roles include an administrator able to mint and rescue tokens, a burner role, and an upgrader role able to change the implementation. Etherscan identifies the Ethereum contract as an ERC-1967 proxy and reports that the source code is verified, but it also shows that no contract security audit had been submitted on the page reviewed. The existence of a stated genesis supply therefore should not be treated as proof that all future supply-changing or upgrade permissions are technically impossible.

Governance and operational dependencies

ADI Chain’s documentation says tokenholder governance is not active at launch. A governance framework is described as dormant until an Activation Resolution follows deployment and audit of the relevant governance contracts, publication of detailed specifications, and updated filings with the ADGM Registrar. This means holding ADI does not, based on the reviewed documentation, currently guarantee voting power over upgrades, treasury decisions, validators, or network parameters.

The network also depends on several specialized components: sequencers, provers, settlement contracts, bridges, data-availability validators, and administrative controls. The mainnet contract page lists separate addresses for the base token, verifier, governance, chain administration, proxy administration, validator timelock, and data-availability validators. These dependencies are normal for a modular Layer 2, but they create several points where operational security, upgrade policy, and availability can affect users even when Ethereum settlement remains part of the design.

Who may use it and what remains unproven

The intended users are institutions, developers, governments, payment providers, and applications that need Ethereum-compatible infrastructure with configurable compliance or jurisdictional controls. ADI’s documentation specifically discusses compliance-oriented Layer 3 operators and says custodians, exchanges, and transfer agents operating in the ecosystem must meet applicable FATF Travel Rule and ADGM requirements. This makes the network’s adoption path dependent not only on technical performance but also on licensing, custody, identity, and regulatory integrations outside the base token itself.

The central open question is execution. ADI’s public materials describe an ambitious settlement platform and list ecosystem categories such as payments, tokenization, identity, and infrastructure, but project claims about partnerships or future applications should be separated from independently measurable production activity. Readers should verify the live chain, bridge route, contract permissions, governance status, and the terms of any staking or enterprise service before treating the token’s proposed utility as established usage.

Key takeaways

• ADI is intended to pay gas and support settlement across ADI Chain and associated Layer 3 domains.
• The network uses zkSync-derived execution and proof components, with Ethereum serving as the intended settlement layer in rollup deployments.
• The tokenomics page lists a 999,999,999-token genesis supply and long unlock schedules for major allocations.
• Tokenholder governance is documented as inactive at launch and dependent on a later activation process.
• The token contract is upgradeable and includes documented administrative minting, burning, rescue, and upgrade roles.
• The project’s practical success depends on live institutional usage, bridge operations, proving infrastructure, compliance integrations, and delivery of the documented architecture.

Risks and open questions

• Contract-control risk: the public repository describes administrator-controlled minting and an upgradeable proxy, so supply and behavior depend partly on privileged roles and upgrade procedures.
• Governance risk: tokenholder governance is not active at launch, meaning token ownership may not currently provide direct control over network decisions.
• Execution risk: the documentation says ADI Network and zkSync OS remain under active development, and the proposed architecture may change before all components mature.
• Adoption risk: payments, tokenization, government, and institutional use cases are project targets; the reviewed sources do not independently establish their scale or recurring production demand.
• Technical and infrastructure risk: sequencers, provers, bridges, verifiers, data-availability services, and administrative contracts are all material dependencies.
• Regulatory and access risk: compliant Layer 3 deployments may require separate licensing, custody, identity, and Travel Rule arrangements, which can vary by jurisdiction.