8fa3d100 (main)
and
6f787946 (PR)
+2 -2
+2 -2
{
"architectureImage": "agglayer-validium",
"exitMechanisms": [
{
"name": "Regular messaging",
"description": "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.",
"risks": [],
"references": [
{
"title": "AgglayerBridge.sol - source code, claimAsset function",
"url": "https://etherscan.io/address/0x66E0120e3c965552a89AcC37b03f762624baC5Ad#code"
}
]
}
],
"forceTransactions": {
"name": "Users can't force any transaction",
"description": "There is no general mechanism to force the sequencer to include the transaction.",
"risks": [
{
"category": "Users can be censored if",
"text": "the operator refuses to include their transactions."
}
],
"references": [
{
"title": "Validium.sol - source code, forceBatchAddress address",
"url": "https://etherscan.io/address/0x10D296e8aDd0535be71639E5D1d1c30ae1C6bD4C#code"
}
]
},
"operator": {
"name": "The system has a centralized sequencer",
"description": "Only a trusted sequencer is allowed to submit transaction batches.",
"risks": [
{
"category": "MEV can be extracted if",
"text": "the operator exploits their centralized position and frontruns user transactions."
},
{
"category": "Funds can be frozen if",
"text": "the sequencer refuses to include an exit transaction.",
"isCritical": true
}
],
"references": [
{
"title": "Validium.sol - source code, onlyTrustedSequencer modifier",
"url": "https://etherscan.io/address/0x10D296e8aDd0535be71639E5D1d1c30ae1C6bD4C#code"
}
]
},
"otherConsiderations": [
{
"name": "Shared bridge and Pessimistic Proofs",
"description": "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.",
"risks": [
{
"category": "Funds can be lost if",
"text": "the accounting proof system for the bridge (pessimistic proofs, SP1) is implemented incorrectly."
}
],
"references": [
{
"title": "Pessimistic Proof - Polygon Knowledge Layer",
"url": "https://docs.polygon.technology/cdk/concepts/pessimistic-proofs"
},
{
"title": "Etherscan: AgglayerManager.sol - verifyPessimisticTrustedAggregator() function",
"url": "https://etherscan.io/address/0x15cAF18dEd768e3620E0f656221Bf6B400ad2618#code#F1#L1300"
}
]
}
],
"stateDerivation": {
"nodeSoftware": "Node software can be found [here](https://github.com/0xPolygonHermez/zkevm-node) and [here](https://github.com/0xPolygonHermez/cdk-erigon). The cdk-erigon node is the more recent implementation.",
"compressionScheme": "No compression scheme is used.",
"genesisState": "The genesis state, whose corresponding root is accessible as Batch 0 root in the `_legacyBatchNumToStateRoot` variable of AgglayerManager, is available [here](https://github.com/agglayer/agglayer-contracts/blob/0d0e69a6f299e273343461f6350343cf4b048269/deployment/genesis.json).",
"dataFormat": "The trusted sequencer batches transactions according to the specifications documented [here](https://docs.polygon.technology/zkEVM/architecture/protocol/transaction-life-cycle/transaction-batching/). Only /signed hashes of batches are posted to the Validium contract."
},
"stateValidation": {
"description": "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.",
"categories": [
{
"title": "Prover Architecture",
"description": "Polygon zkEVM proof system PIL-STARK can be found [here](https://github.com/0xPolygonHermez/pil-stark)."
},
{
"title": "ZK Circuits",
"description": "Polygon zkEVM circuits are built from PIL (polynomial identity language) and are designed to replicate the behavior of the EVM. The source code can be found [here](https://github.com/0xPolygonHermez/zkevm-rom).",
"risks": [
{
"category": "Funds can be lost if",
"text": "the proof system is implemented incorrectly."
}
]
},
{
"title": "Verification Keys Generation",
"description": "SNARK verification keys can be generated and checked against the Ethereum verifier contract using [this guide](https://github.com/0xPolygonHermez/zkevm-contracts/blob/main/verifyMainnetDeployment/verifyMainnetProofVerifier.md). The system requires a trusted setup."
},
{
"title": "Pessimistic Proofs",
"description": "The pessimistic proofs that are used to prove correct accounting in the Agglayer shared bridge are using the [SP1 zkVM by Succinct](https://github.com/succinctlabs/sp1)."
},
{
"title": "Validity proofs",
"description": "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.",
"risks": [],
"references": [
{
"title": "AgglayerManager.sol - source code, _verifyAndRewardBatches function",
"url": "https://etherscan.io/address/0x15cAF18dEd768e3620E0f656221Bf6B400ad2618#code"
}
]
}
]
},
"upgradesAndGovernance": "\nThe 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.\n\nThe 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.\n\nFurthermore, 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 Validium 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.",
"upgradesAndGovernanceImage": "polygoncdk"
"upgradesAndGovernance": "\nThe 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.\n\nThe 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.\n\nFurthermore, 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.",
"upgradesAndGovernanceImage": "agglayer"
}+5 -0
+5 -0
{
"daLayer": "ethereum",
"name": "Enshrined Bridge",
"risks": {
"daBridge": {
"value": "Enshrined",
"sentiment": "good",
"description": "Rollup users have access to all the data, as it is posted onchain on the consensus layer. On the execution layer, the rollup relies on blob data commitment (versioned hashes), which are accessible through the BLOBHASH opcode. \nThe rollup smart contracts can use these blob commitments during state transition validation to reference blobs during proof verification, without requiring direct access to the raw blob data.\n "
},
"callout": "Unlike non-enshrined DA bridges, it does not place any honesty\n assumption on an external committee that provides data availability\n attestations to the DA bridge. From the rollup perspective,\n Ethereum's canonical chain cannot contain unavailable data\n commitments as full nodes self-verify the data availability of each\n block, discarding blocks with unavailable data. The rollup state\n validating bridge has access to all the data, as it is posted on chain."
},
"technology": {
"description": "\n ## Enshrined Bridge\n The DA bridge on Ethereum is enshrined, meaning that blob data is directly accessible on the consensus layer, with data availability guaranteed by the network's inherent consensus rules. \n If a block contains unavailable data, full nodes will reject it, causing the chain to fork away from that block. This ensures data availability without requiring additional trust assumptions. \n In contrast, external DA providers must rely on data availability attestations from the external validator set, introducing an extra layer of trust on the majority of validators.\n "
},
"usedIn": [
{
"id": "abstract",
"name": "Abstract",
"slug": "abstract"
},
{
"id": "arbitrum",
"name": "Arbitrum One",
"slug": "arbitrum"
},
{
"id": "arenaz",
"name": "Arena-Z",
"slug": "arenaz"
},
{
"id": "base",
"name": "Base Chain",
"slug": "base"
},
{
"id": "blast",
"name": "Blast",
"slug": "blast"
},
{
"id": "bob",
"name": "BOB",
"slug": "bob"
},
{
"id": "bobanetwork",
"name": "Boba Network",
"slug": "bobanetwork"
},
{
"id": "cartesi-prt-honeypot-v2",
"name": "Cartesi PRT Honeypot v2",
"slug": "cartesi-prt-honeypot-v2"
},
{
"id": "dbk",
"name": "DeBank Chain",
"slug": "dbk"
},
{
"id": "deri",
"name": "Deri",
"slug": "deri"
},
{
"id": "ethernity",
"name": "Epic Chain",
"slug": "epicchain"
},
{
"id": "facet",
"name": "Facet v1",
"slug": "facet"
},
{
"id": "forknet",
"name": "Forknet",
"slug": "forknet"
},
{
"id": "hashkey",
"name": "HashKey Chain",
"slug": "hashkey"
},
{
"id": "hemi",
"name": "Hemi",
"slug": "hemi"
},
{
"id": "ink",
"name": "Ink",
"slug": "ink"
},
{
"id": "jovay",
"name": "Jovay",
"slug": "jovay"
},
{
"id": "karak",
"name": "K2",
"slug": "k2"
},
{
"id": "katana",
"name": "Katana",
"slug": "katana"
},
{
"id": "lighter",
"name": "Lighter",
"slug": "lighter"
},
{
"id": "linea",
"name": "Linea",
"slug": "linea"
},
{
"id": "lisk",
"name": "Lisk",
"slug": "lisk"
},
{
"id": "loopring",
"name": "Loopring",
"slug": "loopring"
},
{
"id": "metal",
"name": "Metal",
"slug": "metal"
},
{
"id": "metis",
"name": "Metis Andromeda",
"slug": "metis"
},
{
"id": "mint",
"name": "Mint",
"slug": "mint"
},
{
"id": "mode",
"name": "Mode Network",
"slug": "mode"
},
{
"id": "morph",
"name": "Morph",
"slug": "morph"
},
{
"id": "optimism",
"name": "OP Mainnet",
"slug": "op-mainnet"
},
{
"id": "optopia",
"name": "Optopia",
"slug": "optopia"
},
{
"id": "paradex",
"name": "Paradex",
"slug": "paradex"
},
{
"id": "phala",
"name": "Phala",
"slug": "phala"
},
{
"id": "polynomial",
"name": "Polynomial",
"slug": "polynomial"
},
{
"id": "r0ar",
"name": "R0ar",
"slug": "r0ar"
},
{
"id": "race",
"name": "Race Network",
"slug": "race"
},
{
"id": "scroll",
"name": "Scroll",
"slug": "scroll"
},
{
"id": "settlus",
"name": "Settlus",
"slug": "settlus"
},
{
"id": "shape",
"name": "Shape",
"slug": "shape"
},
{
"id": "soneium",
"name": "Soneium",
"slug": "soneium"
},
{
"id": "sxt",
"name": "Space and Time",
"slug": "sxt"
},
{
"id": "starknet",
"name": "Starknet",
"slug": "starknet"
},
{
"id": "superseed",
"name": "Superseed",
"slug": "superseed"
},
{
"id": "swan",
"name": "Swan Chain",
"slug": "swan"
},
{
"id": "swell",
"name": "Swellchain",
"slug": "swell"
},
{
"id": "syndicateframe",
"name": "Syndicate Frame Chain",
"slug": "syndicateframe"
},
{
"id": "taiko",
"name": "Taiko Alethia",
"slug": "taiko"
},
{
"id": "unichain",
"name": "Unichain",
"slug": "unichain"
},
{
"id": "worldchain",
"name": "World Chain",
"slug": "world"
},
{
"id": "xlayer",
"name": "X Layer",
"slug": "xlayer"
},
{
"id": "zeronetwork",
"name": "ZERO Network",
"slug": "zeronetwork"
},
{
"id": "zircuit",
"name": "Zircuit",
"slug": "zircuit"
},
{
"id": "aztec",
"name": "Zk.Money v1 (Aztec v1)",
"slug": "aztecv1"
},
{
"id": "zksync2",
"name": "ZKsync Era",
"slug": "zksync-era"
},
{
"id": "zksync",
"name": "ZKsync Lite",
"slug": "zksync-lite"
},
{
"id": "zora",
"name": "Zora",
"slug": "zora"
}
]
}+2 -2
+2 -2
{
"architectureImage": "agglayer-validium",
"exitMechanisms": [
{
"name": "Regular messaging",
"description": "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.",
"risks": [],
"references": [
{
"title": "AgglayerBridge.sol - source code, claimAsset function",
"url": "https://etherscan.io/address/0x66E0120e3c965552a89AcC37b03f762624baC5Ad#code"
}
]
}
],
"forceTransactions": {
"name": "Users can't force any transaction",
"description": "There is no general mechanism to force the sequencer to include the transaction.",
"risks": [
{
"category": "Users can be censored if",
"text": "the operator refuses to include their transactions."
}
],
"references": [
{
"title": "Validium.sol - source code, forceBatchAddress address",
"url": "https://etherscan.io/address/0x10D296e8aDd0535be71639E5D1d1c30ae1C6bD4C#code"
}
]
},
"operator": {
"name": "The system has a centralized sequencer",
"description": "Only a trusted sequencer is allowed to submit transaction batches.",
"risks": [
{
"category": "MEV can be extracted if",
"text": "the operator exploits their centralized position and frontruns user transactions."
},
{
"category": "Funds can be frozen if",
"text": "the sequencer refuses to include an exit transaction.",
"isCritical": true
}
],
"references": [
{
"title": "Validium.sol - source code, onlyTrustedSequencer modifier",
"url": "https://etherscan.io/address/0x10D296e8aDd0535be71639E5D1d1c30ae1C6bD4C#code"
}
]
},
"otherConsiderations": [
{
"name": "Shared bridge and Pessimistic Proofs",
"description": "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.",
"risks": [
{
"category": "Funds can be lost if",
"text": "the accounting proof system for the bridge (pessimistic proofs, SP1) is implemented incorrectly."
}
],
"references": [
{
"title": "Pessimistic Proof - Polygon Knowledge Layer",
"url": "https://docs.polygon.technology/cdk/concepts/pessimistic-proofs"
},
{
"title": "Etherscan: AgglayerManager.sol - verifyPessimisticTrustedAggregator() function",
"url": "https://etherscan.io/address/0x15cAF18dEd768e3620E0f656221Bf6B400ad2618#code#F1#L1300"
}
]
}
],
"stateDerivation": {
"nodeSoftware": "Node software can be found [here](https://github.com/0xPolygon/cdk-validium-node).",
"compressionScheme": "No compression scheme yet.",
"genesisState": "The genesis state, whose corresponding root is accessible as Batch 0 root in the `getRollupBatchNumToStateRoot(5,0)` method of AgglayerManager, is available [here](https://github.com/0xPolygonHermez/zkevm-contracts/blob/1ad7089d04910c319a257ff4f3674ffd6fc6e64e/tools/addRollupType/genesis.json).",
"dataFormat": "The trusted sequencer request signatures from DAC members off-chain, and posts hashed batches with signatures to the GptProtocolValidium contract."
},
"stateValidation": {
"description": "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.",
"categories": [
{
"title": "Prover Architecture",
"description": "Polygon zkEVM proof system PIL-STARK can be found [here](https://github.com/0xPolygonHermez/pil-stark)."
},
{
"title": "ZK Circuits",
"description": "Polygon zkEVM circuits are built from PIL (polynomial identity language) and are designed to replicate the behavior of the EVM. The source code can be found [here](https://github.com/0xPolygonHermez/zkevm-rom).",
"risks": [
{
"category": "Funds can be lost if",
"text": "the proof system is implemented incorrectly."
}
]
},
{
"title": "Verification Keys Generation",
"description": "SNARK verification keys can be generated and checked against the Ethereum verifier contract using [this guide](https://github.com/0xPolygonHermez/zkevm-contracts/blob/main/verifyMainnetDeployment/verifyMainnetProofVerifier.md). The system requires a trusted setup."
},
{
"title": "Pessimistic Proofs",
"description": "The pessimistic proofs that are used to prove correct accounting in the Agglayer shared bridge are using the [SP1 zkVM by Succinct](https://github.com/succinctlabs/sp1)."
},
{
"title": "Validity proofs",
"description": "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.",
"risks": [],
"references": [
{
"title": "AgglayerManager.sol - source code, _verifyAndRewardBatches function",
"url": "https://etherscan.io/address/0x15cAF18dEd768e3620E0f656221Bf6B400ad2618#code"
}
]
}
]
},
"upgradesAndGovernance": "\nThe 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.\n\nThe 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.\n\nFurthermore, 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 Validium 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.",
"upgradesAndGovernanceImage": "polygoncdk"
"upgradesAndGovernance": "\nThe 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.\n\nThe 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.\n\nFurthermore, 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.",
"upgradesAndGovernanceImage": "agglayer"
}+1 -1
+1 -1
{
"architectureImage": "agglayer-pessimistic",
"dataAvailability": [
{
"name": "Data is not stored on chain",
"description": "Transaction data is kept off-chain. Bridge accounting is protected by pessimistic proofs while L2 state transitions are not proven on Ethereum.",
"risks": [],
"references": []
}
],
"exitMechanisms": [
{
"name": "Regular messaging",
"description": "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.",
"risks": [],
"references": [
{
"title": "AgglayerBridge.sol - source code, claimAsset function",
"url": "https://etherscan.io/address/0x66E0120e3c965552a89AcC37b03f762624baC5Ad#code"
}
]
}
],
"forceTransactions": {
"name": "Users can't force any transaction",
"description": "There is no general mechanism to force the sequencer to include the transaction.",
"risks": [
{
"category": "Users can be censored if",
"text": "the operator refuses to include their transactions."
}
],
"references": []
},
"otherConsiderations": [
{
"name": "Shared bridge and Pessimistic Proofs",
"description": "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.",
"risks": [
{
"category": "Funds can be lost if",
"text": "the accounting proof system for the bridge (pessimistic proofs, SP1) is implemented incorrectly."
},
{
"category": "Funds can be stolen if",
"text": "the operator manipulates the L2 state, which is not validated on Ethereum.",
"isCritical": true
}
],
"references": [
{
"title": "Pessimistic Proof - Polygon Knowledge Layer",
"url": "https://docs.polygon.technology/cdk/concepts/pessimistic-proofs"
},
{
"title": "Etherscan: AgglayerManager.sol - verifyPessimisticTrustedAggregator() function",
"url": "https://etherscan.io/address/0x15cAF18dEd768e3620E0f656221Bf6B400ad2618#code#F1#L1300"
}
]
}
],
"upgradesAndGovernance": "\nThe 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.\n\nThe 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.\n\nFurthermore, 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.",
"upgradesAndGovernanceImage": "polygoncdk"
"upgradesAndGovernanceImage": "agglayer"
}+1 -1
+1 -1
{
"dataAvailability": [
{
"name": "All data required for proofs is published on chain",
"description": "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.",
"risks": [],
"references": [
{
"url": "https://etherscan.io/address/0x000d4411cdeb152378626B5C5E33fd5D6808939a",
"title": "batchInbox - Etherscan address"
}
]
}
],
"exitMechanisms": [
{
"name": "Regular messaging",
"description": "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.",
"risks": [],
"references": []
}
],
"forceTransactions": {
"name": "Users can't force any transaction",
"description": "The mechanism for allowing users to submit their own transactions is currently disabled.",
"risks": [
{
"category": "Users can be censored if",
"text": "the operator refuses to include their transactions."
}
],
"references": [
{
"url": "https://etherscan.io/address/0x51c852eC17062FB229A117Cb8abCBc7Eb171D5Bc#code#F1#L578",
"title": "_depositTransaction() in OptimismPortal2 - Etherscan source code"
}
]
},
"operator": {
"name": "The system has a centralized operator",
"description": "Only a trusted sequencer is allowed to submit transaction batches. A mechanism for users to submit their own batches is currently disabled. Only a trusted proposer can propose and prove new state roots.",
"risks": [
{
"category": "Funds can be frozen if",
"text": "the permissioned proposer fails to publish state roots to the L1."
},
{
"category": "Funds can be frozen if",
"text": "the permissioned sequencer fails to publish transaction data to the L1."
}
],
"references": [
{
"url": "https://etherscan.io/address/0xb6e1f8B589A14B79DDD3aD7F0589AB548c70C174#readProxyContract#F13",
"title": "batcherHash - Etherscan address"
}
]
},
"otherConsiderations": [
{
"name": "Shared bridge and Pessimistic Proofs",
"description": "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' and aggchains). Using the SP1 zkVM by Succinct, projects without a full proof system on Ethereum or custom proof systems are able to share the bridge with the zkEVM Agglayer projects.",
"risks": [
{
"category": "Funds can be lost if",
"text": "the accounting proof system for the bridge (pessimistic proofs, SP1) is implemented incorrectly."
}
],
"references": [
{
"title": "Pessimistic Proof - Polygon Knowledge Layer",
"url": "https://docs.polygon.technology/learn/agglayer/pessimistic_proof"
},
{
"title": "Etherscan: AgglayerManager.sol - verifyPessimisticTrustedAggregator() function",
"url": "https://etherscan.io/address/0x15cAF18dEd768e3620E0f656221Bf6B400ad2618#code#F1#L1300"
}
]
}
],
"stateValidation": {
"categories": [
{
"title": "Prover Architecture",
"description": "Katana uses the Agglayer CDK in CDK-opgeth-zkrollup configuration. This combines an OP-Succinct zk rollup base with Agglayer shared bridge interoperability. Both parts are verified in a single nested proof using the Succinct Sp1Verifier. This proof is called the pessimistic proof by Agglayer which contains 1) the bridge accounting proof proving only the secure accounting of the Agglayer shared bridge and can have 2) a reference to an 'aggchain proof', which can define additional programs to be proven. In the case of Katana, these are the op-succinct block range proofs as an aggregated proof proving the state transitions of the L2.",
"references": [
{
"url": "https://docs.agglayer.dev/cdk/cdk-opgeth/architecture/#cdk-opgeth-zkrollup-not-live-yet",
"title": "CDK-opgeth-zkrollup architecture"
}
]
},
{
"title": "Validity proofs",
"description": "Each update to the rollup 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.",
"references": [
{
"url": "https://succinctlabs.github.io/op-succinct/architecture.html",
"title": "Op-Succinct architecture"
}
],
"risks": [
{
"category": "Funds can be stolen if",
"text": "the state transition validity proof cryptography is broken or implemented incorrectly."
},
{
"category": "Funds can be stolen if",
"text": "A malicious state transition is finalized by activating the permissioned optimistic mode."
},
{
"category": "Funds can be stolen if",
"text": "the proposer routes proof verification through a malicious or faulty verifier by specifying an unsafe route id."
},
{
"category": "Funds can be frozen if",
"text": "the AggLayerGateway is unable to route proof verification to a valid verifier."
}
]
},
{
"title": "Pessimistic Proofs",
"description": "The pessimistic proofs that are used to prove correct accounting in the Agglayer shared bridge (minimum security guarantee) are using the [SP1 zkVM by Succinct](https://github.com/succinctlabs/sp1).",
"risks": [
{
"category": "Funds can be stolen if",
"text": "the pessimistic proof cryptography is broken or implemented incorrectly."
}
]
}
]
},
"upgradesAndGovernance": "\nThe regular upgrade process for all system contracts (shared and L2-specific) 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 rollup- or 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.\n\nThe 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.\n\nFurthermore, 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 Layer 2 can manage their chain by choosing the trusted sequencer, manage forced batches and set the data availability config. Creating new Layer 2s (of existing rollupType) is outsourced to the PolygonCreateRollupMultisig but can also be done by the PolygonAdminMultisig. Finally, it can manage SP1 verification keys for pessimistic proofs and aggchain proofs, which defines the affected chains' state validation. Custom non-shared bridge escrows have their custom upgrade admins listed in the permissions section.",
"upgradesAndGovernanceImage": "agglayer-algateway"
"upgradesAndGovernanceImage": "agglayer"
}+1 -1
+1 -1
{
"architectureImage": "agglayer-pessimistic",
"dataAvailability": [
{
"name": "Data is not stored on chain",
"description": "Transaction data is kept off-chain. Bridge accounting is protected by pessimistic proofs while L2 state transitions are not proven on Ethereum.",
"risks": [],
"references": []
}
],
"exitMechanisms": [
{
"name": "Regular messaging",
"description": "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.",
"risks": [],
"references": [
{
"title": "AgglayerBridge.sol - source code, claimAsset function",
"url": "https://etherscan.io/address/0x66E0120e3c965552a89AcC37b03f762624baC5Ad#code"
}
]
}
],
"forceTransactions": {
"name": "Users can't force any transaction",
"description": "There is no general mechanism to force the sequencer to include the transaction.",
"risks": [
{
"category": "Users can be censored if",
"text": "the operator refuses to include their transactions."
}
],
"references": []
},
"otherConsiderations": [
{
"name": "Shared bridge and Pessimistic Proofs",
"description": "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.",
"risks": [
{
"category": "Funds can be lost if",
"text": "the accounting proof system for the bridge (pessimistic proofs, SP1) is implemented incorrectly."
},
{
"category": "Funds can be stolen if",
"text": "the operator manipulates the L2 state, which is not validated on Ethereum.",
"isCritical": true
}
],
"references": [
{
"title": "Pessimistic Proof - Polygon Knowledge Layer",
"url": "https://docs.polygon.technology/cdk/concepts/pessimistic-proofs"
},
{
"title": "Etherscan: AgglayerManager.sol - verifyPessimisticTrustedAggregator() function",
"url": "https://etherscan.io/address/0x15cAF18dEd768e3620E0f656221Bf6B400ad2618#code#F1#L1300"
}
]
}
],
"upgradesAndGovernance": "\nThe 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.\n\nThe 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.\n\nFurthermore, 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.",
"upgradesAndGovernanceImage": "polygoncdk"
"upgradesAndGovernanceImage": "agglayer"
}+2 -2
+2 -2
{
"architectureImage": "agglayer-validium",
"exitMechanisms": [
{
"name": "Regular messaging",
"description": "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.",
"risks": [],
"references": [
{
"title": "AgglayerBridge.sol - source code, claimAsset function",
"url": "https://etherscan.io/address/0x66E0120e3c965552a89AcC37b03f762624baC5Ad#code"
}
]
}
],
"forceTransactions": {
"name": "Users can't force any transaction",
"description": "There is no general mechanism to force the sequencer to include the transaction.",
"risks": [
{
"category": "Users can be censored if",
"text": "the operator refuses to include their transactions."
}
],
"references": [
{
"title": "Validium.sol - source code, forceBatchAddress address",
"url": "https://etherscan.io/address/0x427113ae6F319BfFb4459bfF96eb8B6BDe1A127F#code"
}
]
},
"operator": {
"name": "The system has a centralized sequencer",
"description": "Only a trusted sequencer is allowed to submit transaction batches.",
"risks": [
{
"category": "MEV can be extracted if",
"text": "the operator exploits their centralized position and frontruns user transactions."
},
{
"category": "Funds can be frozen if",
"text": "the sequencer refuses to include an exit transaction.",
"isCritical": true
}
],
"references": [
{
"title": "Validium.sol - source code, onlyTrustedSequencer modifier",
"url": "https://etherscan.io/address/0x427113ae6F319BfFb4459bfF96eb8B6BDe1A127F#code"
}
]
},
"otherConsiderations": [
{
"name": "Shared bridge and Pessimistic Proofs",
"description": "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.",
"risks": [
{
"category": "Funds can be lost if",
"text": "the accounting proof system for the bridge (pessimistic proofs, SP1) is implemented incorrectly."
}
],
"references": [
{
"title": "Pessimistic Proof - Polygon Knowledge Layer",
"url": "https://docs.polygon.technology/cdk/concepts/pessimistic-proofs"
},
{
"title": "Etherscan: AgglayerManager.sol - verifyPessimisticTrustedAggregator() function",
"url": "https://etherscan.io/address/0x15cAF18dEd768e3620E0f656221Bf6B400ad2618#code#F1#L1300"
}
]
}
],
"stateDerivation": {
"nodeSoftware": "Node software can be found [here](https://github.com/0xPolygonHermez/zkevm-node) and [here](https://github.com/0xPolygonHermez/cdk-erigon). The cdk-erigon node is the more recent implementation.",
"compressionScheme": "No compression scheme is used.",
"genesisState": "The genesis state, whose corresponding root is accessible as Batch 0 root in the `_legacyBatchNumToStateRoot` variable of AgglayerManager, is available [here](https://github.com/agglayer/agglayer-contracts/blob/0d0e69a6f299e273343461f6350343cf4b048269/deployment/genesis.json).",
"dataFormat": "The trusted sequencer batches transactions according to the specifications documented [here](https://docs.polygon.technology/zkEVM/architecture/protocol/transaction-life-cycle/transaction-batching/). Only /signed hashes of batches are posted to the Validium contract."
},
"stateValidation": {
"description": "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.",
"categories": [
{
"title": "Prover Architecture",
"description": "Polygon zkEVM proof system PIL-STARK can be found [here](https://github.com/0xPolygonHermez/pil-stark)."
},
{
"title": "ZK Circuits",
"description": "Polygon zkEVM circuits are built from PIL (polynomial identity language) and are designed to replicate the behavior of the EVM. The source code can be found [here](https://github.com/0xPolygonHermez/zkevm-rom).",
"risks": [
{
"category": "Funds can be lost if",
"text": "the proof system is implemented incorrectly."
}
]
},
{
"title": "Verification Keys Generation",
"description": "SNARK verification keys can be generated and checked against the Ethereum verifier contract using [this guide](https://github.com/0xPolygonHermez/zkevm-contracts/blob/main/verifyMainnetDeployment/verifyMainnetProofVerifier.md). The system requires a trusted setup."
},
{
"title": "Pessimistic Proofs",
"description": "The pessimistic proofs that are used to prove correct accounting in the Agglayer shared bridge are using the [SP1 zkVM by Succinct](https://github.com/succinctlabs/sp1)."
},
{
"title": "Validity proofs",
"description": "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.",
"risks": [],
"references": [
{
"title": "AgglayerManager.sol - source code, _verifyAndRewardBatches function",
"url": "https://etherscan.io/address/0x15cAF18dEd768e3620E0f656221Bf6B400ad2618#code"
}
]
}
]
},
"upgradesAndGovernance": "\nThe 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.\n\nThe 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.\n\nFurthermore, 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 Validium 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.",
"upgradesAndGovernanceImage": "polygoncdk"
"upgradesAndGovernance": "\nThe 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.\n\nThe 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.\n\nFurthermore, 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.",
"upgradesAndGovernanceImage": "agglayer"
}+1 -1
+1 -1
{
"architectureImage": "agglayer-pessimistic",
"dataAvailability": [
{
"name": "Data is not stored on chain",
"description": "Transaction data is kept off-chain. Bridge accounting is protected by pessimistic proofs while L2 state transitions are not proven on Ethereum.",
"risks": [],
"references": []
}
],
"exitMechanisms": [
{
"name": "Regular messaging",
"description": "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.",
"risks": [],
"references": [
{
"title": "AgglayerBridge.sol - source code, claimAsset function",
"url": "https://etherscan.io/address/0x66E0120e3c965552a89AcC37b03f762624baC5Ad#code"
}
]
}
],
"forceTransactions": {
"name": "Users can't force any transaction",
"description": "There is no general mechanism to force the sequencer to include the transaction.",
"risks": [
{
"category": "Users can be censored if",
"text": "the operator refuses to include their transactions."
}
],
"references": []
},
"otherConsiderations": [
{
"name": "Shared bridge and Pessimistic Proofs",
"description": "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.",
"risks": [
{
"category": "Funds can be lost if",
"text": "the accounting proof system for the bridge (pessimistic proofs, SP1) is implemented incorrectly."
},
{
"category": "Funds can be stolen if",
"text": "the operator manipulates the L2 state, which is not validated on Ethereum.",
"isCritical": true
}
],
"references": [
{
"title": "Pessimistic Proof - Polygon Knowledge Layer",
"url": "https://docs.polygon.technology/cdk/concepts/pessimistic-proofs"
},
{
"title": "Etherscan: AgglayerManager.sol - verifyPessimisticTrustedAggregator() function",
"url": "https://etherscan.io/address/0x15cAF18dEd768e3620E0f656221Bf6B400ad2618#code#F1#L1300"
}
]
}
],
"upgradesAndGovernance": "\nThe 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.\n\nThe 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.\n\nFurthermore, 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.",
"upgradesAndGovernanceImage": "polygoncdk"
"upgradesAndGovernanceImage": "agglayer"
}+2 -2
+2 -2
{
"architectureImage": "agglayer-validium",
"exitMechanisms": [
{
"name": "Regular messaging",
"description": "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.",
"risks": [],
"references": [
{
"title": "AgglayerBridge.sol - source code, claimAsset function",
"url": "https://etherscan.io/address/0x66E0120e3c965552a89AcC37b03f762624baC5Ad#code"
}
]
}
],
"forceTransactions": {
"name": "Users can't force any transaction",
"description": "There is no general mechanism to force the sequencer to include the transaction.",
"risks": [
{
"category": "Users can be censored if",
"text": "the operator refuses to include their transactions."
}
],
"references": [
{
"title": "Validium.sol - source code, forceBatchAddress address",
"url": "https://etherscan.io/address/0x427113ae6F319BfFb4459bfF96eb8B6BDe1A127F#code"
}
]
},
"operator": {
"name": "The system has a centralized sequencer",
"description": "Only a trusted sequencer is allowed to submit transaction batches.",
"risks": [
{
"category": "MEV can be extracted if",
"text": "the operator exploits their centralized position and frontruns user transactions."
},
{
"category": "Funds can be frozen if",
"text": "the sequencer refuses to include an exit transaction.",
"isCritical": true
}
],
"references": [
{
"title": "Validium.sol - source code, onlyTrustedSequencer modifier",
"url": "https://etherscan.io/address/0x427113ae6F319BfFb4459bfF96eb8B6BDe1A127F#code"
}
]
},
"otherConsiderations": [
{
"name": "Shared bridge and Pessimistic Proofs",
"description": "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.",
"risks": [
{
"category": "Funds can be lost if",
"text": "the accounting proof system for the bridge (pessimistic proofs, SP1) is implemented incorrectly."
}
],
"references": [
{
"title": "Pessimistic Proof - Polygon Knowledge Layer",
"url": "https://docs.polygon.technology/cdk/concepts/pessimistic-proofs"
},
{
"title": "Etherscan: AgglayerManager.sol - verifyPessimisticTrustedAggregator() function",
"url": "https://etherscan.io/address/0x15cAF18dEd768e3620E0f656221Bf6B400ad2618#code#F1#L1300"
}
]
}
],
"stateDerivation": {
"nodeSoftware": "Node software can be found [here](https://github.com/0xPolygonHermez/zkevm-node) and [here](https://github.com/0xPolygonHermez/cdk-erigon). The cdk-erigon node is the more recent implementation.",
"compressionScheme": "No compression scheme is used.",
"genesisState": "The genesis state, whose corresponding root is accessible as Batch 0 root in the `_legacyBatchNumToStateRoot` variable of AgglayerManager, is available [here](https://github.com/agglayer/agglayer-contracts/blob/0d0e69a6f299e273343461f6350343cf4b048269/deployment/genesis.json).",
"dataFormat": "The trusted sequencer batches transactions according to the specifications documented [here](https://docs.polygon.technology/zkEVM/architecture/protocol/transaction-life-cycle/transaction-batching/). Only /signed hashes of batches are posted to the Validium contract."
},
"stateValidation": {
"description": "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.",
"categories": [
{
"title": "Prover Architecture",
"description": "Polygon zkEVM proof system PIL-STARK can be found [here](https://github.com/0xPolygonHermez/pil-stark)."
},
{
"title": "ZK Circuits",
"description": "Polygon zkEVM circuits are built from PIL (polynomial identity language) and are designed to replicate the behavior of the EVM. The source code can be found [here](https://github.com/0xPolygonHermez/zkevm-rom).",
"risks": [
{
"category": "Funds can be lost if",
"text": "the proof system is implemented incorrectly."
}
]
},
{
"title": "Verification Keys Generation",
"description": "SNARK verification keys can be generated and checked against the Ethereum verifier contract using [this guide](https://github.com/0xPolygonHermez/zkevm-contracts/blob/main/verifyMainnetDeployment/verifyMainnetProofVerifier.md). The system requires a trusted setup."
},
{
"title": "Pessimistic Proofs",
"description": "The pessimistic proofs that are used to prove correct accounting in the Agglayer shared bridge are using the [SP1 zkVM by Succinct](https://github.com/succinctlabs/sp1)."
},
{
"title": "Validity proofs",
"description": "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.",
"risks": [],
"references": [
{
"title": "AgglayerManager.sol - source code, _verifyAndRewardBatches function",
"url": "https://etherscan.io/address/0x15cAF18dEd768e3620E0f656221Bf6B400ad2618#code"
}
]
}
]
},
"upgradesAndGovernance": "\nThe 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.\n\nThe 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.\n\nFurthermore, 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 Validium 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.",
"upgradesAndGovernanceImage": "polygoncdk"
"upgradesAndGovernance": "\nThe 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.\n\nThe 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.\n\nFurthermore, 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.",
"upgradesAndGovernanceImage": "agglayer"
}+2 -2
+2 -2
{
"architectureImage": "agglayer-validium",
"exitMechanisms": [
{
"name": "Regular messaging",
"description": "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.",
"risks": [],
"references": [
{
"title": "AgglayerBridge.sol - source code, claimAsset function",
"url": "https://etherscan.io/address/0x66E0120e3c965552a89AcC37b03f762624baC5Ad#code"
}
]
}
],
"forceTransactions": {
"name": "Users can't force any transaction",
"description": "There is no general mechanism to force the sequencer to include the transaction.",
"risks": [
{
"category": "Users can be censored if",
"text": "the operator refuses to include their transactions."
}
],
"references": [
{
"title": "Validium.sol - source code, forceBatchAddress address",
"url": "https://etherscan.io/address/0x427113ae6F319BfFb4459bfF96eb8B6BDe1A127F#code"
}
]
},
"operator": {
"name": "The system has a centralized sequencer",
"description": "Only a trusted sequencer is allowed to submit transaction batches.",
"risks": [
{
"category": "MEV can be extracted if",
"text": "the operator exploits their centralized position and frontruns user transactions."
},
{
"category": "Funds can be frozen if",
"text": "the sequencer refuses to include an exit transaction.",
"isCritical": true
}
],
"references": [
{
"title": "Validium.sol - source code, onlyTrustedSequencer modifier",
"url": "https://etherscan.io/address/0x427113ae6F319BfFb4459bfF96eb8B6BDe1A127F#code"
}
]
},
"otherConsiderations": [
{
"name": "Shared bridge and Pessimistic Proofs",
"description": "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.",
"risks": [
{
"category": "Funds can be lost if",
"text": "the accounting proof system for the bridge (pessimistic proofs, SP1) is implemented incorrectly."
}
],
"references": [
{
"title": "Pessimistic Proof - Polygon Knowledge Layer",
"url": "https://docs.polygon.technology/cdk/concepts/pessimistic-proofs"
},
{
"title": "Etherscan: AgglayerManager.sol - verifyPessimisticTrustedAggregator() function",
"url": "https://etherscan.io/address/0x15cAF18dEd768e3620E0f656221Bf6B400ad2618#code#F1#L1300"
}
]
}
],
"stateDerivation": {
"nodeSoftware": "Node software can be found [here](https://github.com/0xPolygonHermez/zkevm-node) and [here](https://github.com/0xPolygonHermez/cdk-erigon). The cdk-erigon node is the more recent implementation.",
"compressionScheme": "No compression scheme is used.",
"genesisState": "The genesis state, whose corresponding root is accessible as Batch 0 root in the `_legacyBatchNumToStateRoot` variable of AgglayerManager, is available [here](https://github.com/agglayer/agglayer-contracts/blob/0d0e69a6f299e273343461f6350343cf4b048269/deployment/genesis.json).",
"dataFormat": "The trusted sequencer batches transactions according to the specifications documented [here](https://docs.polygon.technology/zkEVM/architecture/protocol/transaction-life-cycle/transaction-batching/). Only /signed hashes of batches are posted to the Validium contract."
},
"stateValidation": {
"description": "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.",
"categories": [
{
"title": "Prover Architecture",
"description": "Polygon zkEVM proof system PIL-STARK can be found [here](https://github.com/0xPolygonHermez/pil-stark)."
},
{
"title": "ZK Circuits",
"description": "Polygon zkEVM circuits are built from PIL (polynomial identity language) and are designed to replicate the behavior of the EVM. The source code can be found [here](https://github.com/0xPolygonHermez/zkevm-rom).",
"risks": [
{
"category": "Funds can be lost if",
"text": "the proof system is implemented incorrectly."
}
]
},
{
"title": "Verification Keys Generation",
"description": "SNARK verification keys can be generated and checked against the Ethereum verifier contract using [this guide](https://github.com/0xPolygonHermez/zkevm-contracts/blob/main/verifyMainnetDeployment/verifyMainnetProofVerifier.md). The system requires a trusted setup."
},
{
"title": "Pessimistic Proofs",
"description": "The pessimistic proofs that are used to prove correct accounting in the Agglayer shared bridge are using the [SP1 zkVM by Succinct](https://github.com/succinctlabs/sp1)."
},
{
"title": "Validity proofs",
"description": "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.",
"risks": [],
"references": [
{
"title": "AgglayerManager.sol - source code, _verifyAndRewardBatches function",
"url": "https://etherscan.io/address/0x15cAF18dEd768e3620E0f656221Bf6B400ad2618#code"
}
]
}
]
},
"upgradesAndGovernance": "\nThe 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.\n\nThe 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.\n\nFurthermore, 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 Validium 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.",
"upgradesAndGovernanceImage": "polygoncdk"
"upgradesAndGovernance": "\nThe 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.\n\nThe 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.\n\nFurthermore, 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.",
"upgradesAndGovernanceImage": "agglayer"
}+2 -2
+2 -2
{
"architectureImage": "agglayer-validium",
"exitMechanisms": [
{
"name": "Regular messaging",
"description": "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.",
"risks": [],
"references": [
{
"title": "AgglayerBridge.sol - source code, claimAsset function",
"url": "https://etherscan.io/address/0x66E0120e3c965552a89AcC37b03f762624baC5Ad#code"
}
]
}
],
"forceTransactions": {
"name": "Users can't force any transaction",
"description": "There is no general mechanism to force the sequencer to include the transaction.",
"risks": [
{
"category": "Users can be censored if",
"text": "the operator refuses to include their transactions."
}
],
"references": [
{
"title": "Validium.sol - source code, forceBatchAddress address",
"url": "https://etherscan.io/address/0x427113ae6F319BfFb4459bfF96eb8B6BDe1A127F#code"
}
]
},
"operator": {
"name": "The system has a centralized sequencer",
"description": "Only a trusted sequencer is allowed to submit transaction batches.",
"risks": [
{
"category": "MEV can be extracted if",
"text": "the operator exploits their centralized position and frontruns user transactions."
},
{
"category": "Funds can be frozen if",
"text": "the sequencer refuses to include an exit transaction.",
"isCritical": true
}
],
"references": [
{
"title": "Validium.sol - source code, onlyTrustedSequencer modifier",
"url": "https://etherscan.io/address/0x427113ae6F319BfFb4459bfF96eb8B6BDe1A127F#code"
}
]
},
"otherConsiderations": [
{
"name": "Shared bridge and Pessimistic Proofs",
"description": "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.",
"risks": [
{
"category": "Funds can be lost if",
"text": "the accounting proof system for the bridge (pessimistic proofs, SP1) is implemented incorrectly."
}
],
"references": [
{
"title": "Pessimistic Proof - Polygon Knowledge Layer",
"url": "https://docs.polygon.technology/cdk/concepts/pessimistic-proofs"
},
{
"title": "Etherscan: AgglayerManager.sol - verifyPessimisticTrustedAggregator() function",
"url": "https://etherscan.io/address/0x15cAF18dEd768e3620E0f656221Bf6B400ad2618#code#F1#L1300"
}
]
}
],
"stateDerivation": {
"nodeSoftware": "Node software can be found [here](https://github.com/0xPolygonHermez/zkevm-node) and [here](https://github.com/0xPolygonHermez/cdk-erigon). The cdk-erigon node is the more recent implementation.",
"compressionScheme": "No compression scheme is used.",
"genesisState": "The genesis state, whose corresponding root is accessible as Batch 0 root in the `_legacyBatchNumToStateRoot` variable of AgglayerManager, is available [here](https://github.com/agglayer/agglayer-contracts/blob/0d0e69a6f299e273343461f6350343cf4b048269/deployment/genesis.json).",
"dataFormat": "The trusted sequencer batches transactions according to the specifications documented [here](https://docs.polygon.technology/zkEVM/architecture/protocol/transaction-life-cycle/transaction-batching/). Only /signed hashes of batches are posted to the Validium contract."
},
"stateValidation": {
"description": "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.",
"categories": [
{
"title": "Prover Architecture",
"description": "Polygon zkEVM proof system PIL-STARK can be found [here](https://github.com/0xPolygonHermez/pil-stark)."
},
{
"title": "ZK Circuits",
"description": "Polygon zkEVM circuits are built from PIL (polynomial identity language) and are designed to replicate the behavior of the EVM. The source code can be found [here](https://github.com/0xPolygonHermez/zkevm-rom).",
"risks": [
{
"category": "Funds can be lost if",
"text": "the proof system is implemented incorrectly."
}
]
},
{
"title": "Verification Keys Generation",
"description": "SNARK verification keys can be generated and checked against the Ethereum verifier contract using [this guide](https://github.com/0xPolygonHermez/zkevm-contracts/blob/main/verifyMainnetDeployment/verifyMainnetProofVerifier.md). The system requires a trusted setup."
},
{
"title": "Pessimistic Proofs",
"description": "The pessimistic proofs that are used to prove correct accounting in the Agglayer shared bridge are using the [SP1 zkVM by Succinct](https://github.com/succinctlabs/sp1)."
},
{
"title": "Validity proofs",
"description": "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.",
"risks": [],
"references": [
{
"title": "AgglayerManager.sol - source code, _verifyAndRewardBatches function",
"url": "https://etherscan.io/address/0x15cAF18dEd768e3620E0f656221Bf6B400ad2618#code"
}
]
}
]
},
"upgradesAndGovernance": "\nThe 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.\n\nThe 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.\n\nFurthermore, 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 Validium 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.",
"upgradesAndGovernanceImage": "polygoncdk"
"upgradesAndGovernance": "\nThe 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.\n\nThe 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.\n\nFurthermore, 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.",
"upgradesAndGovernanceImage": "agglayer"
}+2 -2
+2 -2
{
"architectureImage": "agglayer-validium",
"exitMechanisms": [
{
"name": "Regular messaging",
"description": "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.",
"risks": [],
"references": [
{
"title": "AgglayerBridge.sol - source code, claimAsset function",
"url": "https://etherscan.io/address/0x66E0120e3c965552a89AcC37b03f762624baC5Ad#code"
}
]
}
],
"forceTransactions": {
"name": "Users can't force any transaction",
"description": "There is no general mechanism to force the sequencer to include the transaction.",
"risks": [
{
"category": "Users can be censored if",
"text": "the operator refuses to include their transactions."
}
],
"references": [
{
"title": "Validium.sol - source code, forceBatchAddress address",
"url": "https://etherscan.io/address/0x10D296e8aDd0535be71639E5D1d1c30ae1C6bD4C#code"
}
]
},
"operator": {
"name": "The system has a centralized sequencer",
"description": "Only a trusted sequencer is allowed to submit transaction batches.",
"risks": [
{
"category": "MEV can be extracted if",
"text": "the operator exploits their centralized position and frontruns user transactions."
},
{
"category": "Funds can be frozen if",
"text": "the sequencer refuses to include an exit transaction.",
"isCritical": true
}
],
"references": [
{
"title": "Validium.sol - source code, onlyTrustedSequencer modifier",
"url": "https://etherscan.io/address/0x10D296e8aDd0535be71639E5D1d1c30ae1C6bD4C#code"
}
]
},
"otherConsiderations": [
{
"name": "Shared bridge and Pessimistic Proofs",
"description": "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.",
"risks": [
{
"category": "Funds can be lost if",
"text": "the accounting proof system for the bridge (pessimistic proofs, SP1) is implemented incorrectly."
}
],
"references": [
{
"title": "Pessimistic Proof - Polygon Knowledge Layer",
"url": "https://docs.polygon.technology/cdk/concepts/pessimistic-proofs"
},
{
"title": "Etherscan: AgglayerManager.sol - verifyPessimisticTrustedAggregator() function",
"url": "https://etherscan.io/address/0x15cAF18dEd768e3620E0f656221Bf6B400ad2618#code#F1#L1300"
}
]
}
],
"stateDerivation": {
"nodeSoftware": "Node software can be found [here](https://github.com/0xPolygonHermez/zkevm-node) and [here](https://github.com/0xPolygonHermez/cdk-erigon). The cdk-erigon node is the more recent implementation.",
"compressionScheme": "No compression scheme is used.",
"genesisState": "The genesis state, whose corresponding root is accessible as Batch 0 root in the `_legacyBatchNumToStateRoot` variable of AgglayerManager, is available [here](https://github.com/agglayer/agglayer-contracts/blob/0d0e69a6f299e273343461f6350343cf4b048269/deployment/genesis.json).",
"dataFormat": "The trusted sequencer batches transactions according to the specifications documented [here](https://docs.polygon.technology/zkEVM/architecture/protocol/transaction-life-cycle/transaction-batching/). Only /signed hashes of batches are posted to the Validium contract."
},
"stateValidation": {
"description": "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.",
"categories": [
{
"title": "Prover Architecture",
"description": "Polygon zkEVM proof system PIL-STARK can be found [here](https://github.com/0xPolygonHermez/pil-stark)."
},
{
"title": "ZK Circuits",
"description": "Polygon zkEVM circuits are built from PIL (polynomial identity language) and are designed to replicate the behavior of the EVM. The source code can be found [here](https://github.com/0xPolygonHermez/zkevm-rom).",
"risks": [
{
"category": "Funds can be lost if",
"text": "the proof system is implemented incorrectly."
}
]
},
{
"title": "Verification Keys Generation",
"description": "SNARK verification keys can be generated and checked against the Ethereum verifier contract using [this guide](https://github.com/0xPolygonHermez/zkevm-contracts/blob/main/verifyMainnetDeployment/verifyMainnetProofVerifier.md). The system requires a trusted setup."
},
{
"title": "Pessimistic Proofs",
"description": "The pessimistic proofs that are used to prove correct accounting in the Agglayer shared bridge are using the [SP1 zkVM by Succinct](https://github.com/succinctlabs/sp1)."
},
{
"title": "Validity proofs",
"description": "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.",
"risks": [],
"references": [
{
"title": "AgglayerManager.sol - source code, _verifyAndRewardBatches function",
"url": "https://etherscan.io/address/0x15cAF18dEd768e3620E0f656221Bf6B400ad2618#code"
}
]
}
]
},
"upgradesAndGovernance": "\nThe 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.\n\nThe 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.\n\nFurthermore, 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 Validium 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.",
"upgradesAndGovernanceImage": "polygoncdk"
"upgradesAndGovernance": "\nThe 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.\n\nThe 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.\n\nFurthermore, 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.",
"upgradesAndGovernanceImage": "agglayer"
}+636 -52
+3 -2
{
"reviewStatus": "inReview",
"unverifiedContracts": []
"unverifiedContracts": [
"eth:0xe58C365Da30c746204022e61482bBE828cAA9091"
]
}+28 -5
{
"badges": [
{
"id": "CustomDA",
"id": "EVM",
"type": "VM",
"name": "EVM",
"description": "This project uses the Ethereum Virtual Machine to run its smart contracts and supports the Solidity programming language",
"action": {
"type": "scalingFilter",
"id": "vm",
"value": "EVM"
}
},
{
"id": "EthereumBlobs",
"type": "DA",
"name": "Custom DA solution",
"description": "This project is using a custom DA solution",
"name": "Ethereum with blobs",
"description": "This project is posting its data to Ethereum as blobs",
"action": {
"type": "selfDaHighlight"
"type": "publicDaHighlight",
"slug": "ethereum"
}
},
{
"id": "OPStack",
"type": "Stack",
"name": "Built on OP Stack",
"description": "The project is built on the OP Stack",
"action": {
"type": "scalingFilter",
"id": "stack",
"value": "OP Stack"
}
},
{
"id": "Agglayer",
"type": "Infra",
"name": "Part of the Agglayer",
"description": "The project is part of the Agglayer, meaning that it uses the shared Agglayer contracts",
"action": {
"type": "scalingFilter",
"id": "infrastructure",
"value": "Agglayer"
}
}
],
"description": "X Layer is a Layer 2 by OKX with seamless integration with OKX products. It is powered by the Polygon CDK.",
"description": "X Layer is a Layer 2 by OKX with seamless integration with OKX products. It is powered by the Agglayer CDK.",
"links": {
"websites": [
"https://okx.com/xlayer"
],
"documentation": [
"https://web3.okx.com/ua/xlayer/docs/developer/build-on-xlayer/about-xlayer"
],
"explorers": [
"https://okx.com/explorer/xlayer"
],
"socialMedia": [
"https://twitter.com/XLayerOfficial"
],
"bridges": [
"https://web3.okx.com/xlayer/bridge"
],
"repositories": [
"https://github.com/okx/xlayer-erigon"
]
}
}+4 -7
{
"capability": "universal",
"daLayer": [
"None"
"Ethereum"
],
"hostChain": {
"id": "ethereum",
"slug": "ethereum",
"name": "Ethereum"
},
"infrastructure": "Agglayer",
"layer": "layer2",
"purposes": [
"Universal"
],
"reasonsForBeingOther": [
{
"label": "No DA bridge",
"shortDescription": "There is no data availability bridge",
"description": "Projects without a data availability bridge fully rely on single entities (the sequencer) to honestly rely available data roots on Ethereum. A malicious sequencer can collude with the proposer to finalize an unavailable state, which can cause loss of funds."
},
{
"label": "No proofs",
"shortDescription": "The proof system isn't fully functional",
"description": "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."
}
],
"stacks": [
"Agglayer CDK"
],
"stage": "Not applicable",
"type": "Other",
"vm": []
"vm": [
"EVM"
]
}+9 -6
{
"self": {
"stateValidation": {
"value": "None",
"description": "Currently the system permits invalid state roots. 'Pessimistic' proofs only validate the bridge accounting.",
"sentiment": "bad",
"orderHint": null
},
"dataAvailability": {
"value": "External",
"description": "Proof construction and state derivation rely fully on data that is NOT published onchain.",
"sentiment": "bad"
"value": "Onchain",
"description": "All of the data needed for proof construction is published on Ethereum L1.",
"sentiment": "good",
"orderHint": null
},
"exitWindow": {
"value": "None",
"description": "There is no window for users to exit in case of an unwanted regular upgrade since contracts are instantly upgradable.",
"sentiment": "bad",
"orderHint": 0
},
"sequencerFailure": {
"value": "No mechanism",
"description": "There is no mechanism to have transactions be included if the sequencer is down or censoring. Although the functionality exists in the code, it is currently disabled.",
"sentiment": "bad"
"value": "Self sequence",
"description": "In the event of a sequencer failure, users can force transactions to be included in the project's chain by sending them to L1. There can be up to a 12h delay on this operation.",
"sentiment": "good",
"orderHint": 43200,
"secondLine": "12h delay"
},
"proposerFailure": {
"value": "Cannot withdraw",
"description": "Only the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen.",
"sentiment": "bad",
"orderHint": null
}
}
}+11 -8
[
{
"layer": {
"value": "None",
"sentiment": "bad",
"description": "The data is not posted to any data availability layer."
"value": "Ethereum",
"secondLine": "Blobs or Calldata",
"sentiment": "good",
"description": "The data is posted to Ethereum as calldata or blobs.",
"projectId": "ethereum"
},
"bridge": {
"value": "None",
"sentiment": "bad",
"description": "There is no bridge that can attest if the data has been made available.",
"orderHint": -2
"value": "Enshrined",
"sentiment": "good",
"description": "The validating bridge has access to all the data, as it is posted onchain.",
"projectId": "ethereum"
},
"mode": {
"value": "None"
"value": "Transaction data",
"secondLine": "Compressed"
}
}
]+7 -12
{
"architectureImage": "agglayer-pessimistic",
"architectureImage": "agglayer-opstack_closed",
"dataAvailability": [
{
"name": "Data is not stored on chain",
"description": "Transaction data is kept off-chain. Bridge accounting is protected by pessimistic proofs while L2 state transitions are not proven on Ethereum.",
"name": "Data is posted on Ethereum",
"description": "Transaction data is posted to Ethereum L1 as compressed calldata or blobs through the OP Stack batch inbox.",
"risks": [],
"references": []
}
],
"exitMechanisms": [
{
"name": "Regular messaging",
"description": "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.",
"risks": [],
"references": [
{
"title": "AgglayerBridge.sol - source code, claimAsset function",
"url": "https://etherscan.io/address/0x66E0120e3c965552a89AcC37b03f762624baC5Ad#code"
}
]
}
],
"forceTransactions": {
"name": "Users can't force any transaction",
"description": "There is no general mechanism to force the sequencer to include the transaction.",
"risks": [
{
"category": "Users can be censored if",
"text": "the operator refuses to include their transactions."
}
],
"name": "Users can force any transaction",
"description": "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.",
"risks": [],
"references": []
},
"otherConsiderations": [
{
"name": "Shared bridge and Pessimistic Proofs",
"description": "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.",
"risks": [
{
"category": "Funds can be lost if",
"text": "the accounting proof system for the bridge (pessimistic proofs, SP1) is implemented incorrectly."
},
{
"category": "Funds can be stolen if",
"text": "the operator manipulates the L2 state, which is not validated on Ethereum.",
"isCritical": true
}
],
"references": [
{
"title": "Pessimistic Proof - Polygon Knowledge Layer",
"url": "https://docs.polygon.technology/cdk/concepts/pessimistic-proofs"
},
{
"title": "Etherscan: AgglayerManager.sol - verifyPessimisticTrustedAggregator() function",
"url": "https://etherscan.io/address/0x15cAF18dEd768e3620E0f656221Bf6B400ad2618#code#F1#L1300"
}
]
}
],
"upgradesAndGovernance": "\nThe 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.\n\nThe 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.\n\nFurthermore, 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.",
"upgradesAndGovernanceImage": "polygoncdk"
"upgradesAndGovernanceImage": "agglayer"
}+1 -1
null
{}+1 -1
null
{}+48 -1
null
[
{
"projectId": "xlayer",
"sinceTimestamp": 1761304367,
"type": "liveness",
"subtype": "batchSubmissions",
"params": {
"formula": "transfer",
"from": "0xdfd6C636Dcb5a013c2431316c4A0762B84e70a5d",
"to": "0x002bdE9b0c0857AEE2cFFDea6b8723eAF5989449"
}
},
{
"projectId": "xlayer",
"sinceTimestamp": 1761304367,
"type": "l2costs",
"subtype": "batchSubmissions",
"params": {
"formula": "transfer",
"from": "0xdfd6C636Dcb5a013c2431316c4A0762B84e70a5d",
"to": "0x002bdE9b0c0857AEE2cFFDea6b8723eAF5989449"
}
},
{
"projectId": "xlayer",
"sinceTimestamp": 1761304367,
"type": "liveness",
"subtype": "stateUpdates",
"params": {
"formula": "functionCall",
"address": "0x9D4c8FAEadDdDeeE1Ed0c92dAbAD815c2484f675",
"selector": "0x82ecf2f6",
"signature": "function create(uint32 _gameType, bytes32 _rootClaim, bytes _extraData) payable returns (address proxy_)"
}
},
{
"projectId": "xlayer",
"sinceTimestamp": 1761304367,
"type": "l2costs",
"subtype": "stateUpdates",
"params": {
"formula": "functionCall",
"address": "0x9D4c8FAEadDdDeeE1Ed0c92dAbAD815c2484f675",
"selector": "0x82ecf2f6",
"signature": "function create(uint32 _gameType, bytes32 _rootClaim, bytes _extraData) payable returns (address proxy_)"
}
}
]+11 -1
null
[
{
"type": "ethereum",
"daLayer": "ethereum",
"sinceBlock": 23668700,
"inbox": "0x002bdE9b0c0857AEE2cFFDea6b8723eAF5989449",
"sequencers": [
"0xdfd6C636Dcb5a013c2431316c4A0762B84e70a5d"
]
}
]+134 -6
{
"ethereum": {
"roles": [
{
"id": "Challenger",
"name": "Challenger",
"description": "Allowed to challenge or delete state roots proposed by a Proposer.",
"accounts": [
{
"address": "eth:0x736E68Af2CbF2aB0E46E4310fE5Ae568b3642FF6",
"type": "EOA",
"isVerified": true,
"name": "EOA 8",
"url": "#EOA-8"
}
],
"chain": "ethereum",
"discoveryDrivenData": true
},
{
"id": "Proposer",
"name": "Proposer",
"description": "Allowed to post new state roots of the current layer to the host chain.",
"accounts": [
{
"address": "eth:0xE43944421681170648E10007f73816e04F74394F",
"type": "EOA",
"isVerified": true,
"name": "EOA 9",
"url": "#EOA-9"
}
],
"chain": "ethereum",
"discoveryDrivenData": true
},
{
"id": "Sequencer",
"name": "Sequencer",
"description": "Allowed to commit transactions from the current layer to the host chain.",
"accounts": [
{
"address": "eth:0xdfd6C636Dcb5a013c2431316c4A0762B84e70a5d",
"type": "EOA",
"isVerified": true,
"name": "EOA 5",
"url": "#EOA-5"
}
],
"chain": "ethereum",
"discoveryDrivenData": true
},
{
"id": "Trusted Aggregator (Proposer)",
"name": "Trusted Aggregator (Proposer)",
"description": "Permissioned to post new state roots and global exit roots accompanied by ZK proofs.",
"accounts": [
{
"address": "eth:0x20A53dCb196cD2bcc14Ece01F358f1C849aA51dE",
"type": "EOA",
"isVerified": true,
"name": "EOA 4",
"url": "#EOA-4-and-EOA-5"
"name": "EOA 6",
"url": "#EOA-6-and-EOA-7"
},
{
"address": "eth:0xD7e6c31750838Ef895fBe0c57f7Fd881a14482Fb",
"type": "EOA",
"isVerified": true,
"name": "EOA 5",
"url": "#EOA-4-and-EOA-5"
"name": "EOA 7",
"url": "#EOA-6-and-EOA-7"
}
],
"chain": "ethereum",
"discoveryDrivenData": true
}
],
"actors": [
{
"id": "PolygonAdminMultisig",
"name": "PolygonAdminMultisig",
"description": "A Multisig with 5/9 threshold. \n* Can upgrade **with 3d delay**\n * AgglayerGateway [via: Timelock with 3d delay (no delay if in emergency state) → SharedProxyAdmin]\n * AgglayerBridge [via: Timelock with 3d delay (no delay if in emergency state) → SharedProxyAdmin]\n * AgglayerManager [via: Timelock with 3d delay (no delay if in emergency state) → SharedProxyAdmin]\n * AgglayerGER [via: Timelock with 3d delay (no delay if in emergency state) → SharedProxyAdmin]\n* Can interact with AgglayerGateway\n * add new routes from proof selector to verifier / pessimisticVkey for pessimistic proofs **with 3d delay** [via: Timelock with 3d delay (no delay if in emergency state)]\n * add or update default aggchain verification keys (aggchainVkey) for any given selectors \n * change the aggchainSigners and threshold (a multisig used for permissioned state transitions) \n * freeze routes from proof selector to verifier / pessimisticVkey for pessimistic proofs \n* Can interact with AgglayerBridge\n * upgrade the implementation of wrapped tokens deployed by the bridge **with 3d delay** [via: Timelock with 3d delay (no delay if in emergency state)]\n* Can interact with AgglayerManager\n * deploy new projects that use predefined rollup types (implementations) and connect them or other Agglayer chains to the PolygonRollupManager \n * manage all access control roles, add new rollup types (which are implementation contracts that can then be upgraded to by connected projects), update any connected projects to new rollup types, migrate to pessimistic proofs and rollback batches, connect existing rollups to the PolygonRollupManager **with 3d delay** [via: Timelock with 3d delay (no delay if in emergency state)]\n * manage parameters like fees for all connected projects, set the trusted aggregator, stop the emergency state, update projects and obsolete rollup types \n* Can interact with Timelock\n * propose, cancel and execute transactions in the timelock, manage all access control roles and change the minimum delay **with 6d delay or with 3d delay** [via: Timelock with 3d delay (no delay if in emergency state) with 3d delay (no delay if in emergency state) - or - acting directly with 3d delay (no delay if in emergency state)]",
"accounts": [
{
"address": "eth:0x242daE44F5d8fb54B198D03a94dA45B5a4413e21",
"type": "Contract",
"isVerified": true,
"name": "0x242d…3e21",
"url": "https://etherscan.io/address/0x242daE44F5d8fb54B198D03a94dA45B5a4413e21"
}
],
"chain": "ethereum",
"references": [],
"participants": [
{
"address": "eth:0xcAB31b6A7b4d2eCd562A09e2BfA46535a18862f9",
"type": "EOA",
"isVerified": true,
"name": "0xcAB3…62f9",
"url": "https://etherscan.io/address/0xcAB31b6A7b4d2eCd562A09e2BfA46535a18862f9"
},
{
"address": "eth:0xAb3506507449bF1880f3337825efd19ac89E235E",
"type": "EOA",
"isVerified": true,
"name": "0xAb35…235E",
"url": "https://etherscan.io/address/0xAb3506507449bF1880f3337825efd19ac89E235E"
},
{
"address": "eth:0xED7cC82235A7757702475c8f77c7830c095FB5a2",
"type": "EOA",
"isVerified": true,
"name": "0xED7c…B5a2",
"url": "https://etherscan.io/address/0xED7cC82235A7757702475c8f77c7830c095FB5a2"
},
{
"address": "eth:0xdFEd8373695a7b3DaF268CF91e71f6a7024A56Da",
"type": "EOA",
"isVerified": true,
"name": "0xdFEd…56Da",
"url": "https://etherscan.io/address/0xdFEd8373695a7b3DaF268CF91e71f6a7024A56Da"
},
{
"address": "eth:0xffbfc0c8331C5fc912DDA3C6D4A86eEB80203238",
"type": "EOA",
"isVerified": true,
"name": "0xffbf…3238",
"url": "https://etherscan.io/address/0xffbfc0c8331C5fc912DDA3C6D4A86eEB80203238"
},
{
"address": "eth:0xeD44D1CFfB91e163CB7126bdEeA83959f175dB37",
"type": "EOA",
"isVerified": true,
"name": "0xeD44…dB37",
"url": "https://etherscan.io/address/0xeD44D1CFfB91e163CB7126bdEeA83959f175dB37"
},
{
"address": "eth:0x516eEcfb38aA308c5f1878497108c7d054fd46B7",
"type": "EOA",
"isVerified": true,
"name": "0x516e…46B7",
"url": "https://etherscan.io/address/0x516eEcfb38aA308c5f1878497108c7d054fd46B7"
},
{
"address": "eth:0xA0B02B28920812324f1cC3255bd8840867d3f227",
"type": "EOA",
"isVerified": true,
"name": "0xA0B0…f227",
"url": "https://etherscan.io/address/0xA0B02B28920812324f1cC3255bd8840867d3f227"
},
{
"address": "eth:0xEad77b01ea770839F7f576Cd1516Ff6A298d9dB2",
"type": "EOA",
"isVerified": true,
"name": "0xEad7…9dB2",
"url": "https://etherscan.io/address/0xEad77b01ea770839F7f576Cd1516Ff6A298d9dB2"
}
],
"discoveryDrivenData": true
},
{
"id": "OwnerContract",
"name": "OwnerContract",
"accounts": [
{
"address": "eth:0xe58C365Da30c746204022e61482bBE828cAA9091",
"type": "Contract",
"isVerified": false,
"name": "0xe58C…9091",
"url": "https://etherscan.io/address/0xe58C365Da30c746204022e61482bBE828cAA9091"
}
],
"chain": "ethereum",
"description": "* Can upgrade **with no delay**\n * AnchorStateRegistry [via: ProxyAdmin]\n * DelayedWETH [via: ProxyAdmin]\n * SystemConfig [via: ProxyAdmin]\n * OptimismMintableERC20Factory [via: ProxyAdmin]\n * OptimismPortal2 [via: ProxyAdmin]\n * SuperchainConfig [via: ProxyAdmin]\n * L1ERC721Bridge_neutered [via: ProxyAdmin]\n * DisputeGameFactory [via: ProxyAdmin]\n * L1StandardBridge_neutered [via: ProxyAdmin]\n * L1CrossDomainMessenger [via: ProxyAdmin]\n* Can interact with AddressManager\n * set and change address mappings [via: ProxyAdmin]",
"discoveryDrivenData": true
},
{
"id": "PolygonSecurityCouncil",
"name": "PolygonSecurityCouncil",
"description": "A Multisig with 6/8 threshold. \n* Can interact with AgglayerManager\n * activate the emergency state in the PolygonRollupManager and in the shared bridge immediately, effectively pausing all projects connected to them and making system contracts instantly upgradable ",
"accounts": [
{
"address": "eth:0x37c58Dfa7BF0A165C5AAEdDf3e2EdB475ac6Dcb6",
"type": "Contract",
"isVerified": true,
"name": "0x37c5…Dcb6",
"url": "https://etherscan.io/address/0x37c58Dfa7BF0A165C5AAEdDf3e2EdB475ac6Dcb6"
}
],
"chain": "ethereum",
"references": [],
"participants": [
{
"address": "eth:0xFe45baf0F18c207152A807c1b05926583CFE2e4b",
"type": "EOA",
"isVerified": true,
"name": "0xFe45…2e4b",
"url": "https://etherscan.io/address/0xFe45baf0F18c207152A807c1b05926583CFE2e4b"
},
{
"address": "eth:0xaF46a0ddf80DFFB49C87656625E65A37499B261D",
"type": "EOA",
"isVerified": true,
"name": "0xaF46…261D",
"url": "https://etherscan.io/address/0xaF46a0ddf80DFFB49C87656625E65A37499B261D"
},
{
"address": "eth:0xBDc235cC9d6Baa641c5ae306bc83962475A5FEFf",
"type": "EOA",
"isVerified": true,
"name": "0xBDc2…FEFf",
"url": "https://etherscan.io/address/0xBDc235cC9d6Baa641c5ae306bc83962475A5FEFf"
},
{
"address": "eth:0x4c1665d6651ecEfa59B9B3041951608468b18891",
"type": "EOA",
"isVerified": true,
"name": "0x4c16…8891",
"url": "https://etherscan.io/address/0x4c1665d6651ecEfa59B9B3041951608468b18891"
},
{
"address": "eth:0x3ab9f4b964eE665F7CDf1d65f1cEEc6196B0D622",
"type": "EOA",
"isVerified": true,
"name": "0x3ab9…D622",
"url": "https://etherscan.io/address/0x3ab9f4b964eE665F7CDf1d65f1cEEc6196B0D622"
},
{
"address": "eth:0x49c15936864690bCd6af0ecaca8E874adFF30E86",
"type": "EOA",
"isVerified": true,
"name": "0x49c1…0E86",
"url": "https://etherscan.io/address/0x49c15936864690bCd6af0ecaca8E874adFF30E86"
},
{
"address": "eth:0x9F7dfAb2222A473284205cdDF08a677726d786A0",
"type": "EOA",
"isVerified": true,
"name": "0x9F7d…86A0",
"url": "https://etherscan.io/address/0x9F7dfAb2222A473284205cdDF08a677726d786A0"
},
{
"address": "eth:0x21887c89368bf918346c62460e0c339113801C28",
"type": "EOA",
"isVerified": true,
"name": "0x2188…1C28",
"url": "https://etherscan.io/address/0x21887c89368bf918346c62460e0c339113801C28"
}
],
"discoveryDrivenData": true
},
{
"id": "PolygonCreateRollupMultisig",
"name": "PolygonCreateRollupMultisig",
"description": "A Multisig with 3/7 threshold. \n* Can interact with AgglayerManager\n * deploy new projects that use predefined rollup types (implementations) and connect them or other Agglayer chains to the PolygonRollupManager ",
"accounts": [
{
"address": "eth:0xC74eFc7fdb3BeC9c6930E91FFDF761b160dF79dB",
"type": "Contract",
"isVerified": true,
"name": "0xC74e…79dB",
"url": "https://etherscan.io/address/0xC74eFc7fdb3BeC9c6930E91FFDF761b160dF79dB"
}
],
"chain": "ethereum",
"references": [],
"participants": [
{
"address": "eth:0xAb3506507449bF1880f3337825efd19ac89E235E",
"type": "EOA",
"isVerified": true,
"name": "0xAb35…235E",
"url": "https://etherscan.io/address/0xAb3506507449bF1880f3337825efd19ac89E235E"
},
{
"address": "eth:0x3038B4DBf022E80169b2A068290d4a3A8b87D3b5",
"type": "EOA",
"isVerified": true,
"name": "0x3038…D3b5",
"url": "https://etherscan.io/address/0x3038B4DBf022E80169b2A068290d4a3A8b87D3b5"
},
{
"address": "eth:0xa43901c63f7702C407378E55E0d0EB4064a2AE31",
"type": "EOA",
"isVerified": true,
"name": "0xa439…AE31",
"url": "https://etherscan.io/address/0xa43901c63f7702C407378E55E0d0EB4064a2AE31"
},
{
"address": "eth:0xD9478f759a13Bfa1d9dAB3cDF5ff0C099d5EfCFC",
"type": "EOA",
"isVerified": true,
"name": "0xD947…fCFC",
"url": "https://etherscan.io/address/0xD9478f759a13Bfa1d9dAB3cDF5ff0C099d5EfCFC"
},
{
"address": "eth:0xCE27d8BCee45dB3E457EcF8629264Ca7893AAaAc",
"type": "EOA",
"isVerified": true,
"name": "0xCE27…AaAc",
"url": "https://etherscan.io/address/0xCE27d8BCee45dB3E457EcF8629264Ca7893AAaAc"
},
{
"address": "eth:0x0185fb2F27f2Acda3e2a6B8530b342333e9f22A6",
"type": "EOA",
"isVerified": true,
"name": "0x0185…22A6",
"url": "https://etherscan.io/address/0x0185fb2F27f2Acda3e2a6B8530b342333e9f22A6"
},
{
"address": "eth:0x7316DeD96c4Ff756c74D1D9c4178f6921Aff4496",
"type": "EOA",
"isVerified": true,
"name": "0x7316…4496",
"url": "https://etherscan.io/address/0x7316DeD96c4Ff756c74D1D9c4178f6921Aff4496"
}
],
"discoveryDrivenData": true
},
{
"id": "EOA-1",
"name": "EOA 1",
"accounts": [
{
"address": "eth:0x491619874b866c3cDB7C8553877da223525ead01",
"type": "EOA",
"isVerified": true,
"name": "0x4916…ad01",
"url": "https://etherscan.io/address/0x491619874b866c3cDB7C8553877da223525ead01"
}
],
"chain": "ethereum",
"description": "* Can interact with AggchainECDSAMultisig\n * sole address that can force batches ",
"discoveryDrivenData": true
},
{
"id": "EOA-2",
"name": "EOA 2",
"accounts": [
{
"address": "eth:0x610DE9141a2c51A9A9624278AA97fbE54b27c102",
"type": "EOA",
"isVerified": true,
"name": "0x610D…c102",
"url": "https://etherscan.io/address/0x610DE9141a2c51A9A9624278AA97fbE54b27c102"
}
],
"chain": "ethereum",
"description": "* Can interact with AggchainECDSAMultisig\n * sign state transitions (replaces state validation for this aggchain) ",
"discoveryDrivenData": true
},
{
"id": "EOA-3",
"name": "EOA 3",
"accounts": [
{
"address": "eth:0x6eE7BDa7AF04F61ccf93aB4b8DB2289aBe76C6aA",
"type": "EOA",
"isVerified": true,
"name": "0x6eE7…C6aA",
"url": "https://etherscan.io/address/0x6eE7BDa7AF04F61ccf93aB4b8DB2289aBe76C6aA"
}
],
"chain": "ethereum",
"description": "* Can interact with SystemConfig\n * it can update the preconfer address, the batch submitter (Sequencer) address and the gas configuration of the system ",
"discoveryDrivenData": true
},
{
"id": "EOA-4",
"name": "EOA 4",
"accounts": [
{
"address": "eth:0xa90B4C8B8807569980F6cC958c8905383136B5eA",
"type": "EOA",
"isVerified": true,
"name": "0xa90B…B5eA",
"url": "https://etherscan.io/address/0xa90B4C8B8807569980F6cC958c8905383136B5eA"
}
],
"chain": "ethereum",
"description": "* Can interact with AggchainECDSAMultisig\n * set the trusted sequencer address ",
"discoveryDrivenData": true
},
{
"id": "EOA-4-and-EOA-5",
"name": "EOA 4 and EOA 5",
"id": "EOA-5",
"name": "EOA 5",
"accounts": [
{
"address": "eth:0xdfd6C636Dcb5a013c2431316c4A0762B84e70a5d",
"type": "EOA",
"isVerified": true,
"name": "0xdfd6…0a5d",
"url": "https://etherscan.io/address/0xdfd6C636Dcb5a013c2431316c4A0762B84e70a5d"
}
],
"chain": "ethereum",
"description": "* A Sequencer - acting directly",
"discoveryDrivenData": true
},
{
"id": "EOA-6-and-EOA-7",
"name": "EOA 6 and EOA 7",
"accounts": [
{
"address": "eth:0x20A53dCb196cD2bcc14Ece01F358f1C849aA51dE",
"type": "EOA",
"isVerified": true,
"name": "0x20A5…51dE",
"url": "https://etherscan.io/address/0x20A53dCb196cD2bcc14Ece01F358f1C849aA51dE"
},
{
"address": "eth:0xD7e6c31750838Ef895fBe0c57f7Fd881a14482Fb",
"type": "EOA",
"isVerified": true,
"name": "0xD7e6…82Fb",
"url": "https://etherscan.io/address/0xD7e6c31750838Ef895fBe0c57f7Fd881a14482Fb"
}
],
"chain": "ethereum",
"description": "* A trusted Aggregator - acting directly",
"discoveryDrivenData": true
},
{
"id": "EOA-8",
"name": "EOA 8",
"accounts": [
{
"address": "eth:0x736E68Af2CbF2aB0E46E4310fE5Ae568b3642FF6",
"type": "EOA",
"isVerified": true,
"name": "0x736E…2FF6",
"url": "https://etherscan.io/address/0x736E68Af2CbF2aB0E46E4310fE5Ae568b3642FF6"
}
],
"chain": "ethereum",
"description": "* A Challenger - acting directly",
"discoveryDrivenData": true
},
{
"id": "EOA-9",
"name": "EOA 9",
"accounts": [
{
"address": "eth:0xE43944421681170648E10007f73816e04F74394F",
"type": "EOA",
"isVerified": true,
"name": "0xE439…394F",
"url": "https://etherscan.io/address/0xE43944421681170648E10007f73816e04F74394F"
}
],
"chain": "ethereum",
"description": "* A Proposer - acting directly",
"discoveryDrivenData": true
}
]
}
}+379 -2
{
"addresses": {
"ethereum": [
{
"name": "AggchainECDSAMultisig",
"isVerified": true,
"address": "eth:0x2B0ee28D4D51bC9aDde5E58E295873F61F4a0507",
"upgradeability": {
"proxyType": "EIP1967 proxy",
"admins": [
"eth:0x5132A183E9F3CB7C848b0AAC5Ae0c4f0491B7aB2"
],
"implementations": [
"eth:0x0D49fD0d79723e4D24AaC83f604ED2D3d5fC0f21"
]
},
"chain": "ethereum",
"pastUpgrades": [
{
"timestamp": 1711785755,
"transactionHash": "0x35215d1a6f4ad41bedfbfc481d53b9d508864a6ace025f243264978e1a755f81",
"implementations": [
"eth:0x10D296e8aDd0535be71639E5D1d1c30ae1C6bD4C"
]
},
{
"timestamp": 1736257283,
"transactionHash": "0x9d23f56225d22a2a1b82c2aa6122b1a29896686b30bb1f3def0189043699d46f",
"implementations": [
"eth:0x427113ae6F319BfFb4459bfF96eb8B6BDe1A127F"
]
},
{
"timestamp": 1754397707,
"transactionHash": "0xab579dbf426db0badfaef925504105088f3300b51f1362a4084c57d7e13c0fb1",
"implementations": [
"eth:0x18C45DD422f6587357a6d3b23307E75D42b2bc5B"
]
},
{
"timestamp": 1761747071,
"transactionHash": "0x7be3301b763f904f5076e22914b0ea13e101ed3cff6480b23a7757e7b9875939",
"implementations": [
"eth:0x0D49fD0d79723e4D24AaC83f604ED2D3d5fC0f21"
]
}
],
"description": "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).\n* Roles:\n * **admin**: EOA 3\n * **aggchainSigners**: EOA 2\n * **forceBatchAddress**: EOA 1",
"description": "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).\n* Roles:\n * **admin**: EOA 4\n * **aggchainSigners**: EOA 2\n * **forceBatchAddress**: EOA 1",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/eth:0x2B0ee28D4D51bC9aDde5E58E295873F61F4a0507#code"
},
{
"name": "SystemConfig",
"isVerified": true,
"address": "eth:0x5065809Af286321a05fBF85713B5D5De7C8f0433",
"upgradeability": {
"proxyType": "EIP1967 proxy",
"admins": [
"eth:0x313ce9Cec2070B519f13BDaFe07eabb4f215FEE6"
],
"implementations": [
"eth:0xfCA51bf5bDc5aC16B86F859d6BEe90cfdF6fEb72"
]
},
"chain": "ethereum",
"pastUpgrades": [
{
"timestamp": 1761567143,
"transactionHash": "0x548809f75e4988d16e41bd323e76519cf64ad325a7840911cdf865f67ffd284f",
"implementations": [
"eth:0xee63dC4B835b2790A171fd0149566B1D51E5ae73"
]
},
{
"timestamp": 1764577007,
"transactionHash": "0xdfa2991d716c87991504d3a2e76fd06bc0c7cd2db5d2ce83d910aaf184123487",
"implementations": [
"eth:0xfCA51bf5bDc5aC16B86F859d6BEe90cfdF6fEb72"
]
}
],
"description": "Contains configuration parameters such as the Sequencer address, gas limit on this chain and the unsafe block signer address.\n* Roles:\n * **admin**: ProxyAdmin; ultimately OwnerContract\n * **batcherHash**: EOA 5\n * **owner**: EOA 3",
"upgradableBy": [
{
"name": "OwnerContract",
"delay": "no"
}
],
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/eth:0x5065809Af286321a05fBF85713B5D5De7C8f0433#code"
},
{
"name": "OptimismPortal2",
"isVerified": true,
"address": "eth:0x64057ad1DdAc804d0D26A7275b193D9DACa19993",
"upgradeability": {
"proxyType": "EIP1967 proxy",
"admins": [
"eth:0x313ce9Cec2070B519f13BDaFe07eabb4f215FEE6"
],
"implementations": [
"eth:0xa0fEfC3A457F6A1aE2d81FC172D6dE090a9F4033"
]
},
"chain": "ethereum",
"pastUpgrades": [
{
"timestamp": 1761567143,
"transactionHash": "0x548809f75e4988d16e41bd323e76519cf64ad325a7840911cdf865f67ffd284f",
"implementations": [
"eth:0xa0fEfC3A457F6A1aE2d81FC172D6dE090a9F4033"
]
}
],
"description": "Central message and gas token (dOKB) bridge of the OP stack part of this deployment. It allows for permissioned state proposals without public challenges, and forced transactions.\n* Roles:\n * **admin**: ProxyAdmin; ultimately OwnerContract",
"upgradableBy": [
{
"name": "OwnerContract",
"delay": "no"
}
],
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/eth:0x64057ad1DdAc804d0D26A7275b193D9DACa19993#code"
},
{
"name": "DisputeGameFactory",
"isVerified": true,
"address": "eth:0x9D4c8FAEadDdDeeE1Ed0c92dAbAD815c2484f675",
"upgradeability": {
"proxyType": "EIP1967 proxy",
"admins": [
"eth:0x313ce9Cec2070B519f13BDaFe07eabb4f215FEE6"
],
"implementations": [
"eth:0x74Fac1D45B98bae058F8F566201c9A81B85C7D50"
]
},
"chain": "ethereum",
"pastUpgrades": [
{
"timestamp": 1761567143,
"transactionHash": "0x548809f75e4988d16e41bd323e76519cf64ad325a7840911cdf865f67ffd284f",
"implementations": [
"eth:0x74Fac1D45B98bae058F8F566201c9A81B85C7D50"
]
}
],
"description": "The dispute game factory allows the creation of dispute games, used to propose state roots and eventually challenge them.\n* Roles:\n * **admin**: ProxyAdmin; ultimately OwnerContract",
"upgradableBy": [
{
"name": "OwnerContract",
"delay": "no"
}
],
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/eth:0x9D4c8FAEadDdDeeE1Ed0c92dAbAD815c2484f675#code"
},
{
"name": "AgglayerGateway",
"isVerified": true,
"address": "eth:0x046Bb8bb98Db4ceCbB2929542686B74b516274b3",
"upgradeability": {
"proxyType": "EIP1967 proxy",
"admins": [
"eth:0x0F99738B2Fc14D77308337f3e2596b63aE7BCC4A"
],
"implementations": [
"eth:0xD062B7f9fbB89bdA59262E77015C34a27Dc9aB49"
]
},
"chain": "ethereum",
"pastUpgrades": [
{
"timestamp": 1750087643,
"transactionHash": "0xe7c64d567589723d0920e6104296a434fb24193d2ccd33814d0b3fd753be5db2",
"implementations": [
"eth:0x7bB0e8f1950722694929dB392abA805AAc6e9346"
]
},
{
"timestamp": 1761747071,
"transactionHash": "0x7be3301b763f904f5076e22914b0ea13e101ed3cff6480b23a7757e7b9875939",
"implementations": [
"eth:0xD062B7f9fbB89bdA59262E77015C34a27Dc9aB49"
]
}
],
"description": "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.\n* Roles:\n * **addPpRoute**: Timelock; ultimately PolygonAdminMultisig\n * **admin**: SharedProxyAdmin; ultimately PolygonAdminMultisig\n * **aggchainDefaultVKey**: PolygonAdminMultisig\n * **alMultisig**: PolygonAdminMultisig\n * **freezePpRoute**: PolygonAdminMultisig",
"upgradableBy": [
{
"name": "PolygonAdminMultisig",
"delay": "3d"
}
],
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/eth:0x046Bb8bb98Db4ceCbB2929542686B74b516274b3#code"
},
{
"name": "AgglayerBridge",
"isVerified": true,
"address": "eth:0x2a3DD3EB832aF982ec71669E178424b10Dca2EDe",
"upgradeability": {
"proxyType": "EIP1967 proxy",
"admins": [
"eth:0x0F99738B2Fc14D77308337f3e2596b63aE7BCC4A"
],
"implementations": [
"eth:0x66E0120e3c965552a89AcC37b03f762624baC5Ad"
]
},
"chain": "ethereum",
"pastUpgrades": [
{
"timestamp": 1679653127,
"transactionHash": "0x28f93532243dd8a8cc92ce630ef1920f40de15af7db2903efbf42f21fdf8152c",
"implementations": [
"eth:0x5ac4182A1dd41AeEf465E40B82fd326BF66AB82C"
]
},
{
"timestamp": 1707822059,
"transactionHash": "0xb83824c7eb1e87bd12222d98cf1cbff317b0853ba1e5beda1e3e3d8a4cfd1b24",
"implementations": [
"eth:0x0FeB850B183C57534b56b7d56520133C8f9BDB65"
]
},
{
"timestamp": 1750689983,
"transactionHash": "0xcdd772d0b4764da67b80a72af2da7230f4f70f8c810cb8c4fe3882b8c4506ff3",
"implementations": [
"eth:0x75D28BfDfF93B3e4f20184b442d2634DC01cA48b"
]
},
{
"timestamp": 1761747071,
"transactionHash": "0x7be3301b763f904f5076e22914b0ea13e101ed3cff6480b23a7757e7b9875939",
"implementations": [
"eth:0x66E0120e3c965552a89AcC37b03f762624baC5Ad"
]
}
],
"description": "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.\n* Roles:\n * **admin**: SharedProxyAdmin; ultimately PolygonAdminMultisig\n * **proxiedTokensManager**: Timelock; ultimately PolygonAdminMultisig",
"upgradableBy": [
{
"name": "PolygonAdminMultisig",
"delay": "3d"
}
],
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/eth:0x2a3DD3EB832aF982ec71669E178424b10Dca2EDe#code"
},
{
"name": "AgglayerManager",
"isVerified": true,
"address": "eth:0x5132A183E9F3CB7C848b0AAC5Ae0c4f0491B7aB2",
"upgradeability": {
"proxyType": "EIP1967 proxy",
"admins": [
"eth:0x0F99738B2Fc14D77308337f3e2596b63aE7BCC4A"
],
"implementations": [
"eth:0x15cAF18dEd768e3620E0f656221Bf6B400ad2618"
]
},
"chain": "ethereum",
"pastUpgrades": [
{
"timestamp": 1679653163,
"transactionHash": "0xe34243804e1f7257acb09c97d0d6f023663200c39ee85a1e6927b0b391710bbb",
"implementations": [
"eth:0xe262Ea2782e2e8dbFe354048c3B5d6DE9603EfEF"
]
},
{
"timestamp": 1695198635,
"transactionHash": "0x25c342d7c5b4137b5439c16fd5fa1577c116277859202b2c68fcd9f73b3fc2ac",
"implementations": [
"eth:0x301442aA888701c8B86727d42F3C55Fb0dd9eF7F"
]
},
{
"timestamp": 1699521779,
"transactionHash": "0x1db1400138d6778d303b9a13e816432d11f8dfca00ef6ec6ffcb6698cb447a31",
"implementations": [
"eth:0xb1585916487AcEdD99952086f2950763D253b923"
]
},
{
"timestamp": 1707822059,
"transactionHash": "0xb83824c7eb1e87bd12222d98cf1cbff317b0853ba1e5beda1e3e3d8a4cfd1b24",
"implementations": [
"eth:0x3b82Da772c825283d85d5d6717A77C6Ff582053b"
]
},
{
"timestamp": 1730286719,
"transactionHash": "0x8c1be5b5d844d6e04b2c224cd810cda091d70e6d5c2e5e0464993f7df1ab8403",
"implementations": [
"eth:0x103388f5661d224F4aFb555C7E4a8FB52d0b752d"
]
},
{
"timestamp": 1738594559,
"transactionHash": "0xb499c5a8f315d72886e44eabcbf6428fb9672f3ea8eb55adcbfda0ae0612233e",
"implementations": [
"eth:0xA33619940bceb9be7c9679Dd80FA2918C2476382"
]
},
{
"timestamp": 1750689983,
"transactionHash": "0xcdd772d0b4764da67b80a72af2da7230f4f70f8c810cb8c4fe3882b8c4506ff3",
"implementations": [
"eth:0x9ab2cB2107d3E737f7977B2E5042C58dE98326ab"
]
},
{
"timestamp": 1753882523,
"transactionHash": "0x289865ea6d92cdf5be21123b6ce61447f500ba14c229f02153113f8419af1695",
"implementations": [
"eth:0x42B9fF0644741e3353162678596e7D6aA6a13240"
]
},
{
"timestamp": 1761747071,
"transactionHash": "0x7be3301b763f904f5076e22914b0ea13e101ed3cff6480b23a7757e7b9875939",
"implementations": [
"eth:0x15cAF18dEd768e3620E0f656221Bf6B400ad2618"
]
}
],
"description": "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.\n* Roles:\n * **admin**: SharedProxyAdmin; ultimately PolygonAdminMultisig\n * **createRollup**: PolygonAdminMultisig, PolygonCreateRollupMultisig\n * **defaultAdmin**: Timelock; ultimately PolygonAdminMultisig\n * **emergencyCouncilAdmin**: PolygonSecurityCouncil\n * **trustedAggregator**: EOA 4, EOA 5\n * **tweakParameters**: PolygonAdminMultisig",
"description": "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.\n* Roles:\n * **admin**: SharedProxyAdmin; ultimately PolygonAdminMultisig\n * **createRollup**: PolygonAdminMultisig, PolygonCreateRollupMultisig\n * **defaultAdmin**: Timelock; ultimately PolygonAdminMultisig\n * **emergencyCouncilAdmin**: PolygonSecurityCouncil\n * **trustedAggregator**: EOA 6, EOA 7\n * **tweakParameters**: PolygonAdminMultisig",
"upgradableBy": [
{
"name": "PolygonAdminMultisig",
"delay": "3d"
}
],
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/eth:0x5132A183E9F3CB7C848b0AAC5Ae0c4f0491B7aB2#code"
},
{
"name": "AgglayerGER",
"isVerified": true,
"address": "eth:0x580bda1e7A0CFAe92Fa7F6c20A3794F169CE3CFb",
"upgradeability": {
"proxyType": "EIP1967 proxy",
"admins": [
"eth:0x0F99738B2Fc14D77308337f3e2596b63aE7BCC4A"
],
"implementations": [
"eth:0x7F1655d9d570167B2a3FfD1Ef809D3Fdd74427C5"
]
},
"chain": "ethereum",
"pastUpgrades": [
{
"timestamp": 1679653151,
"transactionHash": "0x9946be78d6c6d19dd1c6c7134a8fac27e76d32cad36dae2398d28fe6ff838f10",
"implementations": [
"eth:0xbc1ea504fC54D078514eFCCA1F6860B5219B6BC3"
]
},
{
"timestamp": 1707822059,
"transactionHash": "0xb83824c7eb1e87bd12222d98cf1cbff317b0853ba1e5beda1e3e3d8a4cfd1b24",
"implementations": [
"eth:0x2E38cD55163137483E30580Cb468C2dFf1d85077"
]
},
{
"timestamp": 1730286719,
"transactionHash": "0x8c1be5b5d844d6e04b2c224cd810cda091d70e6d5c2e5e0464993f7df1ab8403",
"implementations": [
"eth:0x9Bdda421219900454E94e01d641fE64c60D8f4C8"
]
},
{
"timestamp": 1750689983,
"transactionHash": "0xcdd772d0b4764da67b80a72af2da7230f4f70f8c810cb8c4fe3882b8c4506ff3",
"implementations": [
"eth:0xc38C76aE3C8A7dee99d07f1A39246ABe18919a48"
]
},
{
"timestamp": 1761747071,
"transactionHash": "0x7be3301b763f904f5076e22914b0ea13e101ed3cff6480b23a7757e7b9875939",
"implementations": [
"eth:0x7F1655d9d570167B2a3FfD1Ef809D3Fdd74427C5"
]
}
],
"description": "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.\n* Roles:\n * **admin**: SharedProxyAdmin; ultimately PolygonAdminMultisig",
"upgradableBy": [
{
"name": "PolygonAdminMultisig",
"delay": "3d"
}
],
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/eth:0x580bda1e7A0CFAe92Fa7F6c20A3794F169CE3CFb#code"
},
{
"name": "Timelock",
"isVerified": true,
"address": "eth:0xEf1462451C30Ea7aD8555386226059Fe837CA4EF",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "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.\n* Roles:\n * **timelockAdmin**: PolygonAdminMultisig (no delay if in emergency state), Timelock (no delay if in emergency state); ultimately PolygonAdminMultisig (no delay if in emergency state)",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/eth:0xEf1462451C30Ea7aD8555386226059Fe837CA4EF#code"
},
{
"name": "L1CrossDomainMessenger",
"isVerified": true,
"address": "eth:0xF94B553F3602a03931e5D10CaB343C0968D793e3",
"upgradeability": {
"proxyType": "resolved delegate proxy",
"admins": [
"eth:0x313ce9Cec2070B519f13BDaFe07eabb4f215FEE6"
],
"implementations": [
"eth:0xb686F13AfF1e427a1f993F29ab0F2E7383729FE0"
],
"immutable": false
},
"chain": "ethereum",
"pastUpgrades": [
{
"timestamp": 1761567143,
"transactionHash": "0x548809f75e4988d16e41bd323e76519cf64ad325a7840911cdf865f67ffd284f",
"implementations": [
"eth:0xb686F13AfF1e427a1f993F29ab0F2E7383729FE0"
]
}
],
"description": "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.\n* Roles:\n * **admin**: ProxyAdmin; ultimately OwnerContract",
"upgradableBy": [
{
"name": "OwnerContract",
"delay": "no"
}
],
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/eth:0xF94B553F3602a03931e5D10CaB343C0968D793e3#code"
},
{
"name": "AnchorStateRegistry",
"isVerified": true,
"address": "eth:0x000590BB65ab1864a7AD46d6B957cC9a4F2C149d",
"upgradeability": {
"proxyType": "EIP1967 proxy",
"admins": [
"eth:0x313ce9Cec2070B519f13BDaFe07eabb4f215FEE6"
],
"implementations": [
"eth:0xeb69cC681E8D4a557b30DFFBAd85aFfD47a2CF2E"
]
},
"chain": "ethereum",
"pastUpgrades": [
{
"timestamp": 1761567143,
"transactionHash": "0x548809f75e4988d16e41bd323e76519cf64ad325a7840911cdf865f67ffd284f",
"implementations": [
"eth:0xeb69cC681E8D4a557b30DFFBAd85aFfD47a2CF2E"
]
}
],
"description": "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.\n* Roles:\n * **admin**: ProxyAdmin; ultimately OwnerContract",
"upgradableBy": [
{
"name": "OwnerContract",
"delay": "no"
}
],
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/eth:0x000590BB65ab1864a7AD46d6B957cC9a4F2C149d#code"
},
{
"name": "DelayedWETH",
"isVerified": true,
"address": "eth:0x1B8A252A71bC8997d3871aF420895B5845212fC6",
"upgradeability": {
"proxyType": "EIP1967 proxy",
"admins": [
"eth:0x313ce9Cec2070B519f13BDaFe07eabb4f215FEE6"
],
"implementations": [
"eth:0x33Dadc2d1aA9BB613A7AE6B28425eA00D44c6998"
]
},
"chain": "ethereum",
"pastUpgrades": [
{
"timestamp": 1761567143,
"transactionHash": "0x548809f75e4988d16e41bd323e76519cf64ad325a7840911cdf865f67ffd284f",
"implementations": [
"eth:0x33Dadc2d1aA9BB613A7AE6B28425eA00D44c6998"
]
}
],
"description": "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.\n* Roles:\n * **admin**: ProxyAdmin; ultimately OwnerContract",
"upgradableBy": [
{
"name": "OwnerContract",
"delay": "no"
}
],
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/eth:0x1B8A252A71bC8997d3871aF420895B5845212fC6#code"
},
{
"name": "PreimageOracle",
"isVerified": true,
"address": "eth:0x1fb8cdFc6831fc866Ed9C51aF8817Da5c287aDD3",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "The PreimageOracle contract is used to load the required data from L1 for a dispute game.\n",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/eth:0x1fb8cdFc6831fc866Ed9C51aF8817Da5c287aDD3#code"
},
{
"name": "MIPS",
"isVerified": true,
"address": "eth:0x305D1C0EED9a0291686f3BfDf1F5E54aaeeF80e4",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "The MIPS contract is used to execute the final step of the dispute game which objectively determines the winner of the dispute.\n",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/eth:0x305D1C0EED9a0291686f3BfDf1F5E54aaeeF80e4#code"
},
{
"name": "ProxyAdmin",
"isVerified": true,
"address": "eth:0x313ce9Cec2070B519f13BDaFe07eabb4f215FEE6",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "* Roles:\n * **owner**: OwnerContract",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/eth:0x313ce9Cec2070B519f13BDaFe07eabb4f215FEE6#code"
},
{
"name": "OptimismMintableERC20Factory",
"isVerified": true,
"address": "eth:0x62e1Aaeba9A8AA4654980653dB4B21FC82C61c15",
"upgradeability": {
"proxyType": "EIP1967 proxy",
"admins": [
"eth:0x313ce9Cec2070B519f13BDaFe07eabb4f215FEE6"
],
"implementations": [
"eth:0x8ee6fB13c6c9a7e401531168E196Fbf8b05cEabB"
]
},
"chain": "ethereum",
"pastUpgrades": [
{
"timestamp": 1761567143,
"transactionHash": "0x548809f75e4988d16e41bd323e76519cf64ad325a7840911cdf865f67ffd284f",
"implementations": [
"eth:0x8ee6fB13c6c9a7e401531168E196Fbf8b05cEabB"
]
}
],
"description": "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.\n* Roles:\n * **admin**: ProxyAdmin; ultimately OwnerContract",
"upgradableBy": [
{
"name": "OwnerContract",
"delay": "no"
}
],
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/eth:0x62e1Aaeba9A8AA4654980653dB4B21FC82C61c15#code"
},
{
"name": "L1ERC721Bridge_neutered",
"isVerified": true,
"address": "eth:0x85d37236f063C687d056b3604CBEe4B60d124858",
"upgradeability": {
"proxyType": "EIP1967 proxy",
"admins": [
"eth:0x313ce9Cec2070B519f13BDaFe07eabb4f215FEE6"
],
"implementations": [
"eth:0xFbd06fCb2a023d89a7ae9BeE89d157C5264cf42b"
]
},
"chain": "ethereum",
"pastUpgrades": [
{
"timestamp": 1761567143,
"transactionHash": "0x548809f75e4988d16e41bd323e76519cf64ad325a7840911cdf865f67ffd284f",
"implementations": [
"eth:0xFbd06fCb2a023d89a7ae9BeE89d157C5264cf42b"
]
}
],
"description": "Used to bridge ERC-721 tokens from host chain to this chain.\n* Roles:\n * **admin**: ProxyAdmin; ultimately OwnerContract",
"upgradableBy": [
{
"name": "OwnerContract",
"delay": "no"
}
],
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/eth:0x85d37236f063C687d056b3604CBEe4B60d124858#code"
},
{
"name": "L1StandardBridge_neutered",
"isVerified": true,
"address": "eth:0xAecF995ABf9E7eDE7ae0CE65E60622C9eD84823a",
"upgradeability": {
"proxyType": "EIP1967 proxy",
"admins": [
"eth:0x313ce9Cec2070B519f13BDaFe07eabb4f215FEE6"
],
"implementations": [
"eth:0x2978527d5D1372C32fEdC182FDE7559c0471d051"
]
},
"chain": "ethereum",
"pastUpgrades": [],
"description": "This OP stack bridge contract has been modified to disallow ETH and ERC-20 bridging.\n* Roles:\n * **admin**: ProxyAdmin; ultimately OwnerContract",
"upgradableBy": [
{
"name": "OwnerContract",
"delay": "no"
}
],
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/eth:0xAecF995ABf9E7eDE7ae0CE65E60622C9eD84823a#code"
},
{
"name": "ProxyAdmin",
"isVerified": true,
"address": "eth:0xC6901aBf8D39079d6b028dA550BB643f10840552",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "* Roles:\n * **owner**: OwnerContract",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/eth:0xC6901aBf8D39079d6b028dA550BB643f10840552#code"
},
{
"name": "PermissionedDisputeGame",
"isVerified": true,
"address": "eth:0xEeDa796a23bc98726e47934ca9B54fDDa5a608e8",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Same as FaultDisputeGame, but only two permissioned addresses are designated as proposer and challenger.\n* Roles:\n * **challenger**: EOA 8\n * **proposer**: EOA 9",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/eth:0xEeDa796a23bc98726e47934ca9B54fDDa5a608e8#code"
},
{
"name": "SP1Verifier",
"isVerified": true,
"address": "eth:0x0459d576A6223fEeA177Fb3DF53C9c77BF84C459",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Verifier contract for SP1 proofs (v5.0.0).\n",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/eth:0x0459d576A6223fEeA177Fb3DF53C9c77BF84C459#code"
},
{
"name": "SharedProxyAdmin",
"isVerified": true,
"address": "eth:0x0F99738B2Fc14D77308337f3e2596b63aE7BCC4A",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "* Roles:\n * **owner**: Timelock",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/eth:0x0F99738B2Fc14D77308337f3e2596b63aE7BCC4A#code"
},
{
"name": "BridgeLib",
"isVerified": true,
"address": "eth:0x3622Fcf450ca40a340b7492Ae5F60E7c7Ea68aB3",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Extension contract of the AgglayerBridge for asset metadata..\n",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/eth:0x3622Fcf450ca40a340b7492Ae5F60E7c7Ea68aB3#code"
}
]
},
"escrows": [
{
"address": "0x2a3DD3EB832aF982ec71669E178424b10Dca2EDe",
"sinceTimestamp": 1712620800,
"tokens": "*",
"contract": {
"isVerified": true,
"address": "eth:0x2a3DD3EB832aF982ec71669E178424b10Dca2EDe",
"upgradeability": {
"proxyType": "EIP1967 proxy",
"admins": [
"eth:0x0F99738B2Fc14D77308337f3e2596b63aE7BCC4A"
],
"implementations": [
"eth:0x66E0120e3c965552a89AcC37b03f762624baC5Ad"
]
},
"chain": "ethereum",
"pastUpgrades": [
{
"timestamp": 1679653127,
"transactionHash": "0x28f93532243dd8a8cc92ce630ef1920f40de15af7db2903efbf42f21fdf8152c",
"implementations": [
"eth:0x5ac4182A1dd41AeEf465E40B82fd326BF66AB82C"
]
},
{
"timestamp": 1707822059,
"transactionHash": "0xb83824c7eb1e87bd12222d98cf1cbff317b0853ba1e5beda1e3e3d8a4cfd1b24",
"implementations": [
"eth:0x0FeB850B183C57534b56b7d56520133C8f9BDB65"
]
},
{
"timestamp": 1750689983,
"transactionHash": "0xcdd772d0b4764da67b80a72af2da7230f4f70f8c810cb8c4fe3882b8c4506ff3",
"implementations": [
"eth:0x75D28BfDfF93B3e4f20184b442d2634DC01cA48b"
]
},
{
"timestamp": 1761747071,
"transactionHash": "0x7be3301b763f904f5076e22914b0ea13e101ed3cff6480b23a7757e7b9875939",
"implementations": [
"eth:0x66E0120e3c965552a89AcC37b03f762624baC5Ad"
]
}
],
"url": "https://etherscan.io/address/0x2a3DD3EB832aF982ec71669E178424b10Dca2EDe#code"
},
"chain": "ethereum",
"includeInTotal": true,
"sharedEscrow": {
"type": "AggLayer",
"nativeAsset": "etherWrapped",
"wethAddress": "0x5A77f1443D16ee5761d310e38b62f77f726bC71c",
"tokensToAssignFromL1": [
"OKB"
]
},
"chainId": 1
}
],
"risks": [
{
"category": "Funds can be stolen if",
"text": "a contract receives a malicious code upgrade. There is no delay on code upgrades.",
"isCritical": true
},
{
"category": "Funds can be stolen if",
"text": "the source code of unverified contracts contains malicious code.",
"isCritical": true
}
],
"zkProgramHashes": [
{
"title": "Pessimistic program of agglayer",
"description": "Verifies that a chain connected to Polygon Agglayer does not bridge out more tokens that were bridged in, thus preventing stealing tokens from other Agglayer chains. Also verifies aggchain proof for this chain.",
"proverSystemProject": "sp1",
"programUrl": "https://github.com/agglayer/agglayer/tree/v0.3.3-post.4/crates/pessimistic-proof-program",
"verificationStatus": "notVerified",
"hash": "0x00eff0b6998df46ec388bb305618089ae3dc74e513e7676b2e1909694f49cc30"
},
{
"title": "Pessimistic program of agglayer",
"description": "Verifies that a chain connected to Polygon Agglayer does not bridge out more tokens that were bridged in, thus preventing stealing tokens from other Agglayer chains. Also verifies aggchain proof for this chain.",
"proverSystemProject": "sp1",
"programUrl": "https://github.com/agglayer/agglayer/tree/v0.4.4/crates/pessimistic-proof",
"verificationStatus": "successful",
"verificationSteps": "\nPrepare:\n\n1. Install cargo make: `cargo install --debug --locked cargo-make`\n2. Install sp1 toolchain: `curl -L https://sp1up.succinct.xyz/ | bash`, then `sp1up`\n3. Install docker [https://docs.docker.com/get-started/get-docker/](https://docs.docker.com/get-started/get-docker/)\n\nVerify:\n\n1. Checkout the correct branch in [agglayer repo](https://github.com/agglayer/agglayer/tree/main): `git checkout v0.4.4`. Commit hash should be `caac9f06bc7cb1cf89912dbb4dffa4d594a00bd5`.\n2. Make sure docker is running by running `docker ps`\n3. From the root dir: `cargo make pp-elf` to generate pessimistic program elf from sources\n4. From the pessimistic-proof/elf dir: `cargo prove vkey --elf riscv32im-succinct-zkvm-elf` to check the verification key of this elf.\n ",
"hash": "0x000055f14384bdb5bb092fd7e5152ec31856321c5a30306ab95836bdf5cdb639"
}
]
}