Search for projects by name
X Layer is a Layer 2 by OKX with seamless integration with OKX products. It is powered by the Agglayer CDK.
X Layer is a Layer 2 by OKX with seamless integration with OKX products. It is powered by the Agglayer CDK.
Consequence: projects without a proper proof system fully rely on single entities to safely update the state. A malicious proposer can finalize an invalid state, which can cause loss of funds.
Learn more about the recategorisation here.
2024 Dec 10 — 2025 Dec 10
The section shows the operating costs that L2s pay to Ethereum.
2025 Oct 27 — Dec 10
This section shows how much data the project publishes to its data-availability (DA) layer over time. The project currently posts data to
Ethereum.
2025 Oct 27 — Dec 10
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.
Currently the system permits invalid state roots. ‘Pessimistic’ proofs only validate the bridge accounting.
All of the data needed for proof construction is published on Ethereum L1.
There is no window for users to exit in case of an unwanted regular upgrade since contracts are instantly upgradable.
Only the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen.

The regular upgrade process for shared system contracts and L2-specific validium contracts starts at the PolygonAdminMultisig. For the shared contracts, they schedule a transaction that targets the ProxyAdmin via the Timelock, wait for 3d and then execute the upgrade. An upgrade of the Layer 2 specific validium contract requires first adding a new rollupType through the Timelock and the AgglayerManager (defining the new implementation and verifier contracts). Now that the rollupType is created, either the local admin or the PolygonAdminMultisig can immediately upgrade the local system contracts to it. Chains using pessimistic proofs often have completely sovereign upgrade paths from the ones described here, but the shared contracts still remain relevant to them because they use them as escrow.
The PolygonSecurityCouncil can expedite the upgrade process by declaring an emergency state. This state pauses both the shared bridge and the AgglayerManager and allows for instant upgrades through the timelock. Accordingly, instant upgrades for all system contracts are possible with the cooperation of the SecurityCouncil. The emergency state has been activated 1 time(s) since inception.
Furthermore, the PolygonAdminMultisig is permissioned to manage the shared trusted aggregator (proposer and prover) for all participating Layer 2s, deactivate the emergency state, obsolete rollupTypes and manage operational parameters and fees in the AgglayerManager directly. The local admin of a specific Aggchain can manage their chain by choosing the trusted sequencer, manage forced batches and set the data availability config. For sovereign chains using pessimistic proofs they can manage any proof logic that might be used on top of the minimal pessimistic one. Creating new Layer 2s (of existing rollupType) is outsourced to the PolygonCreateRollupMultisig but can also be done by the PolygonAdminMultisig. Custom non-shared bridge escrows have their custom upgrade admins listed in the permissions section.
Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly.
Polygon Agglayer uses a shared bridge escrow for Rollups, Validiums and external chains that opt in to participate in interoperability. Each participating chain needs to provide zk proofs to access any assets in the shared bridge. In addition to the full execution proofs that are used for the state validation of Rollups and Validiums, accounting proofs over the bridges state (Polygon calls them ‘Pessimistic Proofs’) are used by external chains (‘cdk-sovereign’). Using the SP1 zkVM by Succinct, projects without a full proof system on Ethereum are able to share the bridge with the zkEVM Agglayer projects.
Funds can be lost if the accounting proof system for the bridge (pessimistic proofs, SP1) is implemented incorrectly.
Funds can be stolen if the operator manipulates the L2 state, which is not validated on Ethereum (CRITICAL).

Allowed to challenge or delete state roots proposed by a Proposer.
Allowed to post new state roots of the current layer to the host chain.
Allowed to commit transactions from the current layer to the host chain.
Permissioned to post new state roots and global exit roots accompanied by ZK proofs.
A Multisig with 5/9 threshold.
Participants (9):
0xcAB3…62f90xAb35…235E0xED7c…B5a20xdFEd…56Da0xffbf…32380xeD44…dB370x516e…46B70xA0B0…f2270xEad7…9dB2A Multisig with 6/8 threshold.
Participants (8):
0xFe45…2e4b0xaF46…261D0xBDc2…FEFf0x4c16…88910x3ab9…D6220x49c1…0E860x9F7d…86A00x2188…1C28A Multisig with 3/7 threshold.


System contract defining the X Layer Aggchain logic. It only enforces bridge accounting (pessimistic) proofs to protect the shared bridge while the Aggchain state transitions are not proven. They must instead be signed by 1 aggchainSigner(s).
The dispute game factory allows the creation of dispute games, used to propose state roots and eventually challenge them.
A verifier gateway for pessimistic proofs. Manages a map of chains and their verifier keys and is used to route proofs based on the first 4 bytes of proofBytes data in a proof submission. The SP1 verifier is used for all proofs.
The shared bridge contract, escrowing user funds sent to Agglayer chains. It is usually mirrored on each chain and can be used to transfer both ERC20 assets and arbitrary messages.
The central shared managing contract for Polygon Agglayer chains. This contract coordinates chain deployments and proof validation. All connected Layer 2s can be globally paused by activating the ‘Emergency State’. This can be done by the PolygonSecurityCouncil or by anyone after 1 week of inactive verifiers.
A merkle tree storage contract aggregating state roots of each participating Layer 2, thus creating a single global merkle root representing the global state of the Agglayer, the ‘global exit root’. The global exit root is synchronized to all connected Layer 2s to help with their interoperability.
A timelock with access control. In the case of an activated emergency state in the AgglayerManager, all transactions through this timelock are immediately executable. The current minimum delay is 3d.
Sends messages from host chain to this chain, and relays messages back onto host chain. In the event that a message sent from host chain to this chain is rejected for exceeding this chain’s epoch gas limit, it can be resubmitted via this contract’s replay function.
Contains the latest confirmed state root that can be used as a starting point in a dispute game. It specifies which game type can be used for withdrawals, which currently is the PermissionedDisputeGame.
Contract designed to hold the bonded ETH for each game. It is designed as a wrapper around WETH to allow an owner to function as a backstop if a game would incorrectly distribute funds.
The PreimageOracle contract is used to load the required data from L1 for a dispute game.
The MIPS contract is used to execute the final step of the dispute game which objectively determines the winner of the dispute.
A helper contract that generates OptimismMintableERC20 contracts on the network it’s deployed to. OptimismMintableERC20 is a standard extension of the base ERC20 token contract designed to allow the L1StandardBridge contracts to mint and burn tokens. This makes it possible to use an OptimismMintableERC20 as this chain’s representation of a token on the host chain, or vice-versa.
Used to bridge ERC-721 tokens from host chain to this chain.
This OP stack bridge contract has been modified to disallow ETH and ERC-20 bridging.
Extension contract of the AgglayerBridge for asset metadata…
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).
Funds can be stolen if the source code of unverified contracts contains malicious code (CRITICAL).