Katana

Stores the configuration of the OP stack components and proof systemThe infrastructure that allows projects to verify their state transitions. It is composed by onchain verifiers and offchain provers. The main two flavors are optimistic and ZK proof systems, but they can be combined in a hybrid model. In general though, if a system is able to accept state roots optimistically, even if it has a ZK component, it is considered an optimistic proof system.. Specifies which game type is used for state validation, which currently is the PermissionedDisputeGame. This contract is modified to disable asset bridging, but it allows forced transactions.

• Roles:
  • admin: ProxyAdmin; ultimately Polygon Multisig 2

Contains configuration parameters such as the SequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs. address, gas limitThe maximum amount of gas a transaction or block may consume. on this chain and the unsafe blockAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over. signer address.

• Roles:
  • admin: ProxyAdmin; ultimately Polygon Multisig 2
  • batcherHash: EOA 1
  • owner: Polygon Multisig 2

This is NOT the shared SuperchainConfig contract of the OP stack Superchain but rather a local fork. It manages pause states for each chain connected to it, as well as a global pause state for all chains. The guardian role can pause either separately, but each pause expires after 3mo 1d if left untouched.

• Roles:
  • admin: ProxyAdmin; ultimately Polygon Multisig 2
  • guardian: Katana Foundation Engineering/Security Multisig

A verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. 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.

• Roles:
  • addPpRoute: Timelock; ultimately PolygonAdminMultisig
  • admin: SharedProxyAdmin; ultimately PolygonAdminMultisig
  • aggchainDefaultVKey: PolygonAdminMultisig
  • alMultisig: PolygonAdminMultisig
  • freezePpRoute: PolygonAdminMultisig

The shared bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a 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.

• Roles:
  • admin: SharedProxyAdmin; ultimately PolygonAdminMultisig
  • proxiedTokensManager: Timelock; ultimately PolygonAdminMultisig

A merkle treeA hash-based data structure in which each leaf node is a hash of a block of data, and each non-leaf node is a hash of its children. The root of the tree is a cryptographic fingerprint of the entire data structure. Merkle trees (Merkle Patricia Tries) are used in Ethereum to efficiently store key-value pairs. storage contract aggregating state rootsA cryptographic hash succinctly representing a state using a Merkle tree. of each participating Layer 2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups., 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 interoperabilityRefers to the capability of different blockchain networks to communicate and share data. It enables the transfer of assets and information between blockchains, facilitating functionality and collaboration between blockchain ecosystems..

• Roles:
  • admin: SharedProxyAdmin; ultimately PolygonAdminMultisig

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.

• Roles:
  • timelockAdmin: PolygonAdminMultisig (no delay if in emergency state), Timelock (no delay if in emergency state); ultimately PolygonAdminMultisig (no delay if in emergency state)

This token contract uses a standard ‘vault bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. token’ implementation created by Agglayer CDK. It keeps deposited assets in a vault and issues an IOU token (Vault Bridge WBTC) which can be deposited to Agglayer. The underlying asset is generating yield, which does not accrue to the vbWBTC-IOU but is sent to Safe.

• Roles:
  • admin: ProxyAdmin; ultimately Katana vaultBridge Multisig 1

This token contract uses a standard ‘vault bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. token’ implementation created by Agglayer CDK. It keeps deposited assets in a vault and issues an IOU token (Vault Bridge ETH) which can be deposited to Agglayer. The underlying asset is generating yield, which does not accrue to the vbETH-IOU but is sent to Safe.

• Roles:
  • admin: ProxyAdmin; ultimately Katana vaultBridge Multisig 1

This token contract uses a standard ‘vault bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. token’ implementation created by Agglayer CDK. It keeps deposited assets in a vault and issues an IOU token (Vault Bridge USDS) which can be deposited to Agglayer. The underlying asset is generating yield, which does not accrue to the vbUSDS-IOU but is sent to Safe.

• Roles:
  • admin: ProxyAdmin; ultimately Katana vaultBridge Multisig 2

Helper contract for the vaultBridge tokens on Layer 2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups.. If any vbTokens are minted ‘natively’ on Layer 2, this contract can receive the underlying assets and lock them in the Layer 1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. vaults.

• Roles:
  • admin: ProxyAdmin; ultimately Polygon Labs Engineering/Security Multisig

This token contract uses a standard ‘vault bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. token’ implementation created by Agglayer CDK. It keeps deposited assets in a vault and issues an IOU token (Vault Bridge USDC) which can be deposited to Agglayer. The underlying asset is generating yield, which does not accrue to the vbUSDC-IOU but is sent to Safe.

• Roles:
  • admin: ProxyAdmin; ultimately Katana vaultBridge Multisig 3

This token contract uses a standard ‘vault bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. token’ implementation created by Agglayer CDK. It keeps deposited assets in a vault and issues an IOU token (Vault Bridge USDT) which can be deposited to Agglayer. The underlying asset is generating yield, which does not accrue to the vbUSDT-IOU but is sent to Safe.

• Roles:
  • admin: ProxyAdmin; ultimately Katana vaultBridge Multisig 1

• Roles:
  • owner: Katana vaultBridge Multisig 1

• Roles:
  • owner: Polygon Multisig 2

The PreimageOracle contract is used to load the required data from L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. for a dispute game.

• Roles:
  • owner: Polygon Labs Engineering/Security Multisig

• Roles:
  • owner: Katana vaultBridge Multisig 3

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.

• Roles:
  • admin: ProxyAdmin; ultimately Polygon Multisig 2

Contains the latest confirmed state rootA cryptographic hash succinctly representing a state using a Merkle tree. that can be used as a starting point in a dispute game. This variant stores respectedGameType, retirementTimestamp, and disputeGameFinalityDelaySeconds locally and drops the legacy *FromGame fields, since the AggregateVerifier model does not expose vm()/weth()/absolutePrestate() on its game implementation.

• Roles:
  • admin: ProxyAdmin; ultimately Polygon Multisig 2

The MIPS contract is used to execute the final step of the dispute game which objectively determines the winner of the dispute.

• Roles:
  • owner: Katana vaultBridge Multisig 2

Same as FaultDisputeGame, but only two permissioned addresses are designated as proposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block. and challenger.

VerifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contract for SP1 proofs (v5.0.0).

• Roles:
  • owner: Timelock

Extension contract of the AgglayerBridge for asset metadata…

VerifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contract for SP1 proofs (v6.1.0).

Agglayer bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. contract. Supports interop with Ethereum and blockchains connected to Agglayer. Escrows all preminted ETH because it cannot mint on the L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups.. The globalExitRootManager is used as an oracle to validate bridge messages against.

• Roles:
  • admin: ProxyAdmin; ultimately GnosisSafeL2, SafeL2
  • bridgeManager: GnosisSafeL2
  • emergencyBridgePauser: GnosisSafeL2
  • emergencyBridgeUnpauser: GnosisSafeL2
  • getProxiedTokensManager: GnosisSafeL2

Manages Layer 2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. and global merkle roots (exit roots). It stores exit roots written during bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. deposits, accepts imported global exit roots from a permissioned address, and manages historical roots.

• Roles:
  • admin: ProxyAdmin; ultimately GnosisSafeL2, SafeL2
  • globalExitRootRemover: GnosisSafeL2, GnosisSafeL2 if the bridge is paused
  • globalExitRootUpdater: EOA 3

A timelock with access control. The current minimum delay is 12h.

• Roles:
  • timelockAdmin: GnosisSafeL2 (no delay if in emergency state), SafeL2 (no delay if in emergency state)

• Roles:
  • owner: L2Timelock

• Roles:
  • admin: ProxyAdmin; ultimately SafeL2

The L2CrossDomainMessenger (L2xDM) contract sends messages from L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. to L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development., and relays messages from L1 onto L2 with a system tx. In the event that a message sent from L2 to L1 is rejected for exceeding the L1 gas limitThe maximum amount of gas a transaction or block may consume., it can be resubmitted via this contract’s replay function.

• Roles:
  • admin: ProxyAdmin; ultimately SafeL2

Simple contract that returns the latest L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. blockAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over. number.

• Roles:
  • admin: ProxyAdmin; ultimately SafeL2

Utility library contract for the AgglayerBridgeL2.

An ERC-20 implementation designed for cross-chain assets on the L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups.. It restricts token minting or burning strictly to the primary bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. contract. The bridge address is set on each token proxy during initialization.