Summary Value Secured Activity Onchain costs Data posted Liveness Milestones & Incidents Risk summary Risk analysis Stage Data availability State validation Upgrades & Governance Updates Operator Withdrawals Permissions Smart contracts

ADI Chain

Badges

About

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

Total Value SecuredTVS

$12.03 M1.03%

Past day UOPSDaily UOPS

0.2325.2%

Stage

Gas token

ADI

Type

ZK Rollup

Purpose

Universal

Chain ID

36900

Tokens breakdown

Value secured breakdown

62.5% with additional trust assumptions

View TVS breakdown

Sequencer failureState validationData availabilityExit windowProposer failure

Explore more in Discovery UI

Badges

About

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

Value Secured View TVS breakdown

Exclude restricted RWA tokens

Total

Canonically BridgedCanonically Bridged ValueCanonical

Natively MintedNatively Minted TokensNative

Externally BridgedExternally Bridged ValueExternal

ETH & derivatives

Stablecoins

BTC & derivatives

Other

View TVS breakdown

Activity

2025 Nov 25 — 2026 Aug 19

Past Day UOPS

0.2325.2%

Past Day Ops count

19.92 K

Total Ops

1.66 M

since 2025 Nov 25

Max. UOPS

1.12

2026 Jul 09

Past day UOPS/TPS Ratio

<1.01

Onchain costs

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

2025 Nov 25 — 2026 Aug 19

Total cost

$53.92 K

Avg cost per L2 UOP

$0.032757

Avg cost per day

$201.95

Data posted

This section shows how much data the project publishes to its data-availability (DA) layer over time. The project currently posts data toEthereum.

2026 Jan 20 — Aug 19

Data posted

4.65 GiB

Avg size per day

22.46 MiB

Avg size per L2 UOP

2.96 KiB

Liveness

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

2026 Jul 20 — Aug 20

Avg. proof subs. interval

44 minutes

Avg. state updates interval

44 minutes

Past 30 days anomalies

100% normal uptime

Last 30 day anomalies

All liveness anomalies detected for this project in the last 30 days, helping you review recent downtime and availability issues.

No State updates were performed for 4d 1h (from 2026 Apr 04, 11:42 UTC until 2026 Apr 08, 12:50 UTC). These typically occur every 33m 8s on average.

No Proof submissions were performed for 4d 1h (from 2026 Apr 04, 11:41 UTC until 2026 Apr 08, 12:49 UTC). These typically occur every 34m 58s on average.

No State updates were performed for 3d 3h (from 2026 Mar 28, 17:46 UTC until 2026 Mar 31, 21:27 UTC). These typically occur every 33m 8s on average.

No Proof submissions were performed for 3d 3h (from 2026 Mar 28, 17:46 UTC until 2026 Mar 31, 21:26 UTC). These typically occur every 34m 58s on average.

Milestones & Incidents

ADI chain mainnet launch

2025 Dec 9th

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

Learn more

Risk summary

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

The central operator can censor withdrawal transactions by implementing a TransactionFilterer with no delay.

There is no window for users to exit in case of an unwanted upgrade since contracts are instantly upgradable.

Proposer failure

Cannot withdraw

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

Stage

ADI Chain is a

Stage 0

ZK Rollup.

The requirement for available node software is under review

Learn more about Stages

Please keep in mind that these stages do not reflect project security, this is an opinionated assessment of project 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.

Data availability

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

State validation

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

Airbender

Trusted Setups

Onchain verifier

ZKsyncOSVerifierPlonk

Used in

Onchain verifier

ZKsyncOSVerifierPlonk

Used in

Upgrades & Governance

Upgrades are managed by a Governance smart contract on L1. The owner of smart contract (ADI Multisig 2) 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.

Past upgrades

The metrics include upgrades on the currently used proxy contracts. Historical proxy contracts and changes of such are not included.

Count of upgrades

Last upgrade

4mo 12d ago

Avg upgrade interval

2mo 29d

Updates

2026 June 04, 15:16 UTC

6changes

Owner of L1NativeTokenVault and L1Nullifier changed from an EOA to a multisig.

	contract L1NativeTokenVault (eth:0x0A0F8912162Ff83A036883dbaDA42efF647a3065) [shared-zk-stack/L1NativeTokenVault] {
	+++ description: Canonical central asset escrow for all ZK stack chains.
	values.owner:
-	"eth:0x59Be28DE6eFb1f78802E96188d2b7907059Be59f"
+	"eth:0xdE4781a08Cc75D4E1b07fb3909840AE685960711"
	}

	EOA (eth:0x59Be28DE6eFb1f78802E96188d2b7907059Be59f) {
	+++ description: None
	receivedPermissions:
-	[{"permission":"interact","from":"eth:0x0A0F8912162Ff83A036883dbaDA42efF647a3065","description":"pause / unpause the bridge.","role":".owner"}]
	}

	contract L1Nullifier (eth:0x5E5a72077dFB354Dfe61200b8f31fa491F9B9Cea) [shared-zk-stack/L1Nullifier] {
	+++ description: Contract responsible for bookkeeping L1 bridging transactions. Used to finalize withdrawals and reclaim failed deposits. Does not escrow funds.
	values.owner:
-	"eth:0xb63320480218fbC7Cc31c3f92C254D4732528985"
+	"eth:0xdE4781a08Cc75D4E1b07fb3909840AE685960711"
	}

+	Status: CREATED
	contract Safe (eth:0xdE4781a08Cc75D4E1b07fb3909840AE685960711) [GnosisSafe]
	+++ description: None

2026 April 10, 08:25 UTC

8changes

Upgraded executor facet on ADI Diamond to a new version, then upgraded back. Upgrade params stay the same, the only diff in the contracts is MAINNET COMMIT TIMESTAMP NOT OLDER change from 3 days to 10 days: https://disco.l2beat.com/diff/eth:0x56767eB2E3197A1dfa030faaD4A65cF38E807c81/eth:0x8991bF7Ed45ad2B8352efbaB83aD6e00c056a61c. Probably they did that to post old batches ( 3 days) from when the chain was down.

Upgraded executor facet on ADI Diamond to a new version, then upgraded back. Upgrade params stay the same, the only diff in the contracts is MAINNET_COMMIT_TIMESTAMP_NOT_OLDER change from 3 days to 10 days: https://disco.l2beat.com/diff/eth:0x56767eB2E3197A1dfa030faaD4A65cF38E807c81/eth:0x8991bF7Ed45ad2B8352efbaB83aD6e00c056a61c.

Probably they did that to post old batches (>3 days) from when the chain was down.

	contract Diamond (eth:0x0583Ef2B6416cb7B287406438B940E4d99680C5B) {
	+++ description: 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.
	values.$pastUpgrades.5:
+	["2026-04-08T18:36:47.000Z","0x4428eb3c0a1be76b850c3a1cd744087320aa49dfa2304311ed0579c10ec1e568",["eth:0xf9DD56364E3878056654C756cEBA692e577f8466","eth:0xB0D33d94aD4048070f510eF0086F12d20595dd07","eth:0xFA565846c217Bc0bA0f75027D4eECccdD68a9708","eth:0x8991bF7Ed45ad2B8352efbaB83aD6e00c056a61c"]]
	values.$pastUpgrades.6:
+	["2026-04-09T13:05:35.000Z","0x08471063fd03e8dacd215a9c030f4c54a0f002c778a9a8283bc5161efae20e39",["eth:0xf9DD56364E3878056654C756cEBA692e577f8466","eth:0xB0D33d94aD4048070f510eF0086F12d20595dd07","eth:0xFA565846c217Bc0bA0f75027D4eECccdD68a9708","eth:0x56767eB2E3197A1dfa030faaD4A65cF38E807c81"]]
	values.$upgradeCount:
-	5
+	7
	}

	contract Governance (eth:0x8253F33026c49A430963FE3991441c02175bda95) {
	+++ description: Allows scheduling transparent and shadow proposals, 'securityCouncil' role can execute without delay.
	+++ description: Number of executed proposals
	values.executedCount:
-	8
+	10
	+++ description: Number of scheduled transparent proposals
	values.scheduledTransparentCount:
-	8
+	10
	}

2026 March 20, 15:54 UTC

5changes

Plonk verifier is verified on etherscan.

New and verified contracts

	contract ADI PlonkVerifier (eth:0x08513A4646d1Bc8c348C67A3680bb19626E7F13F) {
	+++ description: None
	unverified:
-	true
	values.verificationKeyHash:
+	"0x124ebcd537a1e1c152774dd18f67660e35625bba0b669bf3b4836d636b105337"
	implementationNames.eth:0x08513A4646d1Bc8c348C67A3680bb19626E7F13F:
-	""
+	"ZKsyncOSVerifierPlonk"
	sourceHashes:
+	["0x99ad2513d609d837d3fb8bd7fa2df0a4f37aea1065e9036c5796772f248f8d30"]
	}

2026 March 06, 11:06 UTC

High severity

18changes

Verified DualVerifier and FflonkVerifier smart contracts.

New and verified contracts

	contract ZKsyncOSDualVerifier (eth:0x5E7cF1C310F9E0BF8DbFe70D5cC8021a2109D0AE) {
	+++ description: A router contract for verifiers. Routes verification requests to THE PLONK VERIFIER ONLY depending on the supplied proof version.
	name:
-	"ADI DialVerifier"
+	"ZKsyncOSDualVerifier"
	unverified:
-	true
	+++ description: Fflonk verifier with version 0. Verifiers are read from mapping so they are not displayed in an array.
	+++ severity: HIGH
	values.fflonkVerifier0:
+	"eth:0xF6b3708BE4192CE4526c2F87D4c3eABA79230E6A"
	+++ description: Fflonk verifier with version 1. !MUST BE ZERO, IF NON-ZERO THEN ADD fflonkVerifier2 IN CONFIG! Verifiers are read from mapping so they are not displayed in an array. This value serves as an indicator of a new verifier.
	+++ severity: HIGH
	values.fflonkVerifier1:
+	"eth:0x0000000000000000000000000000000000000000"
	values.owner:
+	"eth:0x8253F33026c49A430963FE3991441c02175bda95"
	values.pendingOwner:
+	"eth:0x0000000000000000000000000000000000000000"
	+++ description: Plonk verifier with version 0. Verifiers are read from mapping so they are not displayed in an array.
	+++ severity: HIGH
	values.plonkVerifier0:
+	"eth:0x08513A4646d1Bc8c348C67A3680bb19626E7F13F"
	+++ description: Plonk verifier with version 1. This value serves as an indicator of a new verifier. !MUST BE ZERO, IF NON-ZERO THEN ADD plonkVerifier2 IN CONFIG! Verifiers are read from mapping so they are not displayed in an array.
	+++ severity: HIGH
	values.plonkVerifier1:
+	"eth:0x0000000000000000000000000000000000000000"
	+++ description: Verification key hash for the PLONK verifier ONLY (backwards compatibility).
	values.verificationKeyHash:
+	"0x124ebcd537a1e1c152774dd18f67660e35625bba0b669bf3b4836d636b105337"
	implementationNames.eth:0x5E7cF1C310F9E0BF8DbFe70D5cC8021a2109D0AE:
-	""
+	"ZKsyncOSDualVerifier"
	template:
+	"adi/ZKsyncOSDualVerifier_post_v30"
	sourceHashes:
+	["0x611d6c62506d4eb15d6b10346b737f49651ba4c3ee1231744069ece1b5ce7443"]
	description:
+	"A router contract for verifiers. Routes verification requests to THE PLONK VERIFIER ONLY depending on the supplied proof version."
	fieldMeta:
+	{"verificationKeyHash":{"description":"Verification key hash for the PLONK verifier ONLY (backwards compatibility)."},"ctmOwner":{"severity":"HIGH","description":"Contract owner that can add and remove verifiers."},"fflonkVerifier0":{"severity":"HIGH","description":"Fflonk verifier with version 0. Verifiers are read from mapping so they are not displayed in an array."},"fflonkVerifier1":{"severity":"HIGH","description":"Fflonk verifier with version 1. !MUST BE ZERO, IF NON-ZERO THEN ADD fflonkVerifier2 IN CONFIG! Verifiers are read from mapping so they are not displayed in an array. This value serves as an indicator of a new verifier."},"plonkVerifier0":{"severity":"HIGH","description":"Plonk verifier with version 0. Verifiers are read from mapping so they are not displayed in an array."},"plonkVerifier1":{"severity":"HIGH","description":"Plonk verifier with version 1. This value serves as an indicator of a new verifier. !MUST BE ZERO, IF NON-ZERO THEN ADD plonkVerifier2 IN CONFIG! Verifiers are read from mapping so they are not displayed in an array."}}
	}

+	Status: CREATED
	contract ADI PlonkVerifier (eth:0x08513A4646d1Bc8c348C67A3680bb19626E7F13F)
	+++ description: None

+	Status: CREATED
	contract ZKsyncOSVerifierFflonk (eth:0xF6b3708BE4192CE4526c2F87D4c3eABA79230E6A)
	+++ description: Verifies a zk-SNARK proof using an implementation of the fflonk proof system.

2026 February 06, 11:17 UTC

High severity

29changes

Updated verifier to an unverified smart contract, also updated chain creation params on ADI's chain type manager: https://tools.l2beat.com/decoder-new/?hash=0x83c8f3f7619c6bb27a46696734863f97b0824bfd8dc68d0db491c25050f4073a&data=AwA.

Updated verifier to an unverified smart contract, also updated chain creation params on ADI’s chain type manager: https://tools.l2beat.com/decoder-new/?hash=0x83c8f3f7619c6bb27a46696734863f97b0824bfd8dc68d0db491c25050f4073a&data=AwA.

	contract Diamond (eth:0x0583Ef2B6416cb7B287406438B940E4d99680C5B) {
	+++ description: 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.
	values.$pastUpgrades.4:
+	["2026-02-05T09:58:23.000Z","0x3837cd476c7e8b1131d519f1dd8aed9cb1fbd779716260b0ff79196520f81b21",["eth:0xf9DD56364E3878056654C756cEBA692e577f8466","eth:0xB0D33d94aD4048070f510eF0086F12d20595dd07","eth:0xFA565846c217Bc0bA0f75027D4eECccdD68a9708","eth:0x56767eB2E3197A1dfa030faaD4A65cF38E807c81"]]
	values.$upgradeCount:
-	4
+	5
	+++ description: Protocol version, increments with each protocol upgrade.
	+++ severity: HIGH
	values.getProtocolVersion:
-	128849018880
+	128849018881
	values.getSemverProtocolVersion.2:
-	0
+	1
	values.getVerifier:
-	"eth:0x6Fd373b9470976Ec561F54664f931733C6149852"
+	"eth:0x5E7cF1C310F9E0BF8DbFe70D5cC8021a2109D0AE"
	}

	contract ZKsyncOSChainTypeManager (eth:0x08A1D2962fC29AA46e869A1E7561112cc1026EfA) {
	+++ description: [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,30,1.
	description:
-	"[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,30,0."
+	"[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,30,1."
	values.getSemverProtocolVersion.2:
-	0
+	1
	values.initialCutHash:
-	"0x28f0af46a96ece2c72a1a7c9c9bfe937162082c4b8925da3b8621599b2869cf5"
+	"0xedf457bf18d9feac26a2fb4a43686971a5eb0f0e21d80393cc8118ecaff31e29"
	values.protocolVersion:
-	128849018880
+	128849018881
	values.storedBatchZero:
-	"0x492e189b00c1e79ab2da8e9475e345cbc4ad91b89650d086d956f2dd58ce2d89"
+	"0x18bd4bd6909643336ab04fcab99eff346bc4e74799aeeb2ed809341e3a1df6f9"
	}

	contract ChainAdminOwnable (eth:0x0a8a2473cc5731575a94f58F470851Bc6695B5B8) {
	+++ description: A governance proxy that lets eth:0xF50293Ac52f987122DcD67Eda0cFb34E9d7a0Cf9 act through it.
	+++ description: Timestamps for new protocol version upgrades can be registered here (NOT enforced)
	values.upgradeTimestamps.2:
+	{"_protocolVersion":128849018881,"_upgradeTimestamp":0}
	+++ description: Timestamps for new protocol version upgrades can be registered here (NOT enforced)
	values.upgradeTimestamps.3:
+	{"_protocolVersion":128849018881,"_upgradeTimestamp":1}
	}

-	Status: DELETED
	contract ZKsyncOSDualVerifier (eth:0x6Fd373b9470976Ec561F54664f931733C6149852)
	+++ description: A router contract for verifiers. Routes verification requests to THE PLONK VERIFIER ONLY depending on the supplied proof version.

	contract Governance (eth:0x8253F33026c49A430963FE3991441c02175bda95) {
	+++ description: Allows scheduling transparent and shadow proposals, 'securityCouncil' role can execute without delay.
	+++ description: Number of executed proposals
	values.executedCount:
-	7
+	8
	+++ description: Number of scheduled transparent proposals
	values.scheduledTransparentCount:
-	7
+	8
	}

-	Status: DELETED
	contract ZKsyncOSVerifierPlonk (eth:0x84871A20Cd4DB1Ac1Db641841Fc7d900e230F92D)
	+++ description: Verifies a zk-SNARK proof using an implementation of the PlonK proof system.

-	Status: DELETED
	contract ZKsyncOSVerifierFflonk (eth:0xF6b3708BE4192CE4526c2F87D4c3eABA79230E6A)
	+++ description: Verifies a zk-SNARK proof using an implementation of the fflonk proof system.

+	Status: CREATED
	contract ADI DialVerifier (eth:0x5E7cF1C310F9E0BF8DbFe70D5cC8021a2109D0AE)
	+++ description: None

Operator

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.

L1 - L2 interoperability - Developer's documentation

Withdrawals

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.

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.

Permissions

A dashboard to explore contracts and permissions

Go to Disco

Explore in Disco

Ethereum

Actors:

Governance0x8253…da95

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

Can upgrade with no delay
- ZKsyncOSChainTypeManager ProxyAdmin
- L1NativeTokenVault ProxyAdmin
- L1Nullifier ProxyAdmin
- L1MessageRoot ProxyAdmin
- BridgeHub ProxyAdmin
- L1ChainAssetHandler ProxyAdmin
- CTMDeploymentTracker ProxyAdmin
- ValidatorTimelock ProxyAdmin
- L1AssetRouter ProxyAdmin
Can interact with ZKsyncOSChainTypeManager
- 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 RollupDAManager
- manage allowed rollup DA pairs (allowed to be used by rollups in permanent rollup mode)
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

ADI Multisig 20xB272…3754

A Multisig with 2/3 threshold.

Can upgrade with no delay
- ServerNotifier ChainAdminOwnable → ProxyAdmin
Can interact with ZKsyncOSChainTypeManager
- set the pending admin of this contract and the ServerNotifier contract address (ZK cluster Admin role) ChainAdminOwnable
Can interact with BridgeHub
- create new zk chains (based on the current version), register tokens (ZK cluster Admin role) ChainAdminOwnable

Participants (3):

0x2e48…9Dc9 0x3740…1ecE 0x288c…66A9

ADI Multisig 10xF502…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) ChainAdminOwnable

Participants (3):

0x2e48…9Dc9 0x3740…1ecE 0x288c…66A9

Safe0xdE47…0711

A Multisig with 3/5 threshold.

Can interact with L1NativeTokenVault
- pause / unpause the bridge
Can interact with L1Nullifier
- pause, unpause and set critical escrow address references

Participants (5):

0x97B0…0Bc8 0x85A1…8ebf 0x17D2…9C3b 0x3ABc…6C14 0xA2D8…3795

4 EOAs

EOA 1 EOA 2 EOA 3 EOA 4

Can interact with ValidatorTimelock
- call the functions to commit, prove, execute and revert L2 batches through the ValidatorTimelock in the ADI Diamond contract

EOA 50x5CcF…366a

Can interact with ChainAdminOwnable
- set the conversion factor for gas token deposits

Smart contracts

A dashboard to explore contracts and permissions

Go to Disco

Explore in Disco

Ethereum

Diamond0x0583…0C5B Implementation #1 (Upgradable)Implementation #2 (Upgradable)Implementation #3 (Upgradable)Implementation #4 (Upgradable)

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

ZKsyncOSChainTypeManager0x08A1…6EfA Implementation (Upgradable)Admin

[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,30,1.

Roles:
- admin: ChainAdminOwnable, ProxyAdmin; ultimately ADI Multisig 2, Governance
- owner: Governance

Can be upgraded by:

Governance with no delay

RollupDAManager0x57B0…EdEA

Simple registry for allowed DA validators for different data availability modes. Scheme 3 is used by default RollupL1DAValidator, the commitment includes EIP-4844 blobs data. Scheme 4 is used only for ZKsyncOS, it is keccak of blob versioned hashes filled with pubdata.

Roles:
- owner: Governance

L1Nullifier0x5E5a…9Cea Implementation (Upgradable)Admin

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: Safe

Can be upgraded by:

Governance with no delay

L1MessageRoot0x783e…6d37 Implementation (Upgradable)Admin

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:

Governance with no delay

BridgeHub0x7a38…59Cb Implementation (Upgradable)Admin

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

Governance with no delay

CTMDeploymentTracker0xaCD4…EA5f Implementation (Upgradable)Admin

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:

Governance with no delay

ValidatorTimelock0xE28c…f186 Implementation (Upgradable)Admin

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 4

Can be upgraded by:

Governance with no delay

L1AssetRouter0xf252…fe7A Implementation (Upgradable)Admin

Canonical central asset router for all ZK stack chains. Routes deposits and withdrawals to the respective asset handlers (like the L1NativeTokenVault); does not escrow funds itself.