Search

Search for projects by name or address

Katana logo
Katana

Badges

About

Katana is a Layer 2 specializing on DeFi. Its unique architecture combines an OP stack base with Agglayer shared bridge interoperability and OP-Succinct SP1 validity proofs.


  • Total Value SecuredTVS
    $119.26 M17.6%
  • Past day UOPSDaily UOPS
    0.9562.2%
  • Stage
  • Type
    ZK Rollup

  • Purpose
    Universal
  • Chain ID
    747474

  • Tokens breakdown


    Interop protocols used

    AgglayerLayerZeroRelay
    +2 more

    Tokens transferred

    vbUSDCvbUSDTWEETH
    +29 more
    Sequencer failureState validationData availabilityExit windowProposer failure

    Badges

    About

    Katana is a Layer 2 specializing on DeFi. Its unique architecture combines an OP stack base with Agglayer shared bridge interoperability and OP-Succinct SP1 validity proofs.


    Total
    Canonically BridgedCanonically Bridged ValueCanonical
    Natively MintedNatively Minted TokensNative
    Externally BridgedExternally Bridged ValueExternal

    ETH & derivatives
    Stablecoins
    BTC & derivatives
    Other
    Avg value per second ≈ $16.27 K|1 particle ≈ $225
    Chain stats
    Stats
    Total volume$19.79 M
    Volume in$6.86 M
    Volume out$12.92 M
    Net flow-$6.05 M
    Total transfers465
    Transfers in231
    Transfers out234
    Avg. transfer value$42.57 K
    Connected11 chains
    Avg. value per second$229.12/s
    Top routes

    2025 Jun 03 — 2026 Jun 03

    Past Day UOPS
    0.9562.2%
    Past Day Ops count
    82.47 K
    Max. UOPS
    2.95
    2025 Jul 21
    Past day UOPS/TPS Ratio
    <1.01

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


    2025 Jun 04 — 2026 Jun 03


    Total cost
    $39.44 K
    Avg cost per L2 UOP
    $0.001918
    Avg cost per day
    $108.07

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


    2025 Jun 04 — 2026 Jun 03


    Data posted
    9.55 GiB
    Avg size per day
    26.73 MiB
    Avg size per L2 UOP
    498.72 B

    This section shows how "live" the project's operators are by displaying how frequently they submit transactions of the selected type. It also highlights anomalies - significant deviations from their typical schedule.

    No ongoing anomalies detected

    2026 May 05 — Jun 04

    Avg. tx data subs. interval
    7 minutes
    Avg. proof subs. interval
    1 hour
    Avg. state updates interval
    1 hour
    Past 30 days anomalies
    99% normal uptime

    Last 30 day anomalies

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

    No Tx data submissions were performed for 20min 36s (from 2026 Jun 03, 11:03 UTC until 2026 Jun 03, 11:24 UTC). These typically occur every 7min 1s on average.

    No State updates were performed for 4h 36s (from 2026 May 28, 18:57 UTC until 2026 May 28, 22:58 UTC). These typically occur every 1h 56s on average.

    No Proof submissions were performed for 4h 36s (from 2026 May 28, 18:57 UTC until 2026 May 28, 22:58 UTC). These typically occur every 1h 56s on average.

    Katana Launch

    2025 Jul 1st

    Katana is live on mainnet, integrated with Agglayer.

    Learn more
    Sequencer failureState validationData availabilityExit windowProposer failure
    Sequencer failure
    Self sequence
    The self-sequencing delay is configured offchain and the node source and config are unverified.

    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.

    State validation
    Validity proofs (ST, SN)

    STARKs and SNARKs are zero knowledge proofs that ensure state correctness. STARKs proofs are wrapped in SNARKs proofs for efficiency. SNARKs require a trusted setup.

    Data availability
    Onchain

    All of the data needed for proof construction is published on Ethereum L1.

    Exit window
    None
    Even though there is a 3d Timelock for non-emergency upgrades, self-proposing is disabled.

    There is no window for users to exit in case of an unwanted upgrade since the Security Council can remove the delay on upgrades.

    Proposer failure
    Cannot withdraw

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

    Katana
    Katana is a
    Stage 0
    ZK Rollup.
    The requirement for available node software is under review

    Learn more about Stages
    Please keep in mind that these stages do not reflect project security, this is an opinionated assessment of project maturity based on subjective criteria, created with a goal of incentivizing projects to push toward better decentralization. Each team may have taken different paths to achieve this goal.

    All data required for proofs is published on chain

    All the data that is used to construct the system state is published on chain in the form of cheap blobs or calldata. This ensures that it will be available for enough time.

    1. batchInbox - Etherscan address
    Learn more about the DA layer here: Ethereum logoEthereum
    Prover Architecture

    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, resulting in a full validity proof of L2 execution and agglayer bridge accounting.

    1. CDK-opgeth-zkrollup architecture
    Validity proofs

    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.

    • Funds can be stolen if the state transition validity proof cryptography is broken or implemented incorrectly.

    • Funds can be stolen if A malicious state transition is finalized by activating the permissioned optimistic mode.

    • Funds can be stolen if the proposer routes proof verification through a malicious or faulty verifier by specifying an unsafe route id.

    • Funds can be frozen if the AggLayerGateway is unable to route proof verification to a valid verifier.

    1. Op-Succinct architecture
    Pessimistic Proofs

    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.

    • Funds can be stolen if the pessimistic proof cryptography is broken or implemented incorrectly.

    PROVER

    Trusted Setups

    Onchain verifier

    Used in

    Mantle logoCelo logoKatana logoVector logoSophon logo

    Projects used in

    Search for projects used in

    Onchain verifier

    Used in

    Mantle logoCelo logoKatana logoVector logoSophon logo

    Projects used in

    Search for projects used in

    Program Hashes

    Name
    Hash
    Repository
    Verification
    Used in
    0x0065...1152
    Code unknown
    None
    Katana logo
    0x5c7c...2229
    Code unknown
    None
    Katana logo
    0x713f...fa1f
    Katana logo
    0x374e...dac6
    Katana logo
    0x6e38...1b53
    Katana logo
    0x7767...6f70
    Katana logo
    0x00ef...cc30
    Katana logoLumia Prism logoHaust Network logoX Layer logoPolygon zkEVM logo

    Projects used in

    Search for projects used in

    0x0000...b639
    Katana logoLumia Prism logoHaust Network logoX Layer logoPolygon zkEVM logo

    Projects used in

    Search for projects used in

    A diagram of the upgrades and governance
    A diagram of the upgrades and governance

    The 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.

    The PolygonSecurityCouncil can expedite the upgrade process by declaring an emergency state. This state pauses both the shared bridge and the AgglayerManager and allows for instant upgrades through the timelock. Accordingly, instant upgrades for all system contracts are possible with the cooperation of the SecurityCouncil. The emergency state has been activated 1 time(s) since inception.

    Furthermore, the PolygonAdminMultisig is permissioned to manage the shared trusted aggregator (proposer and prover) for all participating Layer 2s, deactivate the emergency state, obsolete rollupTypes and manage operational parameters and fees in the AgglayerManager directly. The local admin of a specific 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.

    Past upgrades

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

    Count of upgrades
    37
    Last upgrade
    12d 19h ago
    Avg upgrade interval
    4mo 6d
    2026 June 02, 12:43 UTC
    7changes

    Config ignores and conduit ms changes.

    contract Conduit Multisig 1 (eth:0x4a4962275DF8C60a80d3a25faEc5AA7De116A746) [GnosisSafe] {
    +++ description: None
    values.$members.0:
    + "eth:0xcdC931935768c0562AfE989A366a3Dc4d52F4853"
    values.$members.8:
    - "eth:0x3840f487A17A41100DD1Bf0946c34f132a57Fd5f"
    }
    contract Polygon Labs Engineering/Security Multisig (eth:0x9d851f8b8751c5FbC09b9E74E6e68E9950949052) [GnosisSafe] {
    +++ description: None
    values.$members.0:
    + "eth:0xf02BE0dA37dB50BEFA5a525158aa94b50F81D4B2"
    values.$members.1:
    + "eth:0xe0e8e6bBDef7bbcf8dF1F5Ac0ab9906BFe991d8B"
    values.$members.2:
    + "eth:0x6Ab87a62E250A5EB09a53Fca832B9Bda480c3890"
    values.multisigThreshold:
    - "2 of 5 (40%)"
    + "2 of 8 (25%)"
    }
    2026 May 29, 13:10 UTC
    8changes

    Standard L2 contract sources have been verified.

    contract AgglayerBridgeL2 (katana:0x2a3DD3EB832aF982ec71669E178424b10Dca2EDe) [katana/AgglayerBridgeL2] {
    +++ description: Agglayer bridge contract. Supports interop with Ethereum and blockchains connected to Agglayer. Escrows all preminted ETH because it cannot mint on the L2. The globalExitRootManager is used as an oracle to validate bridge messages against.
    values.claimedGlobalIndexHashChain:
    - "0x5fede20963bde12c20e3076c4426550f570914a8a035c1381bc98f8bed306a46"
    + "0xdef05ec6820a531b383dc3f9dbbc1aac9846e2eab7a821929b5a07cc51659e4c"
    values.getRoot:
    - "0x1d743ae7262c7410af3fb680660e6c1f336b2f49609f709a69a9fd8b9ad21bb2"
    + "0x5ed5cfaf86b2b848194a0a9ebfa969a88ddee6b8f6f007a0ef658482f2665402"
    }
    contract GlobalExitRootManagerL2SovereignChain (katana:0xa40D5f56745a118D0906a34E69aeC8C0Db1cB8fA) [katana/GlobalExitRootManagerL2SovereignChain] {
    +++ description: Manages Layer 2 and global merkle roots (exit roots). It stores exit roots written during bridge deposits, accepts imported global exit roots from a permissioned address, and manages historical roots.
    values.insertedGERHashChain:
    - "0xaae24c57922b6453c1812383dba7b31cf9788b57cfc281e208b4e2911e5feee7"
    + "0x59bc3b88b56a09b106e04e1ffe3fd6dc754bf81029ef9cfe2723275b8f5b347c"
    values.lastRollupExitRoot:
    - "0x1d743ae7262c7410af3fb680660e6c1f336b2f49609f709a69a9fd8b9ad21bb2"
    + "0x5ed5cfaf86b2b848194a0a9ebfa969a88ddee6b8f6f007a0ef658482f2665402"
    }
    2026 May 28, 08:16 UTC
    High severity
    37changes

    minimal diff upgrade to the OptiPortal that adds deposited transactions! https://flat.l2beat.com/diff/ink:0xC0D3C0d3C0d3c0d3C0d3C0D3c0D3c0d3c0D30016/katana:0xFBF44D0341C03098A1D9C0336e3d5C34E8BFdf1A users can now force transactions that do not relate to bridging (they still cannot force ETH- or token deposits). the force tx delay in op stack (or op-succinct) depends on the node config/programHash and both are unverified for katana. as soon as we have a source, we should look for sequencerWindowSize (OP stack standard is 3600). we will assume standard and show the delay as 12h but say that this is unverified. proposals are also still permissioned, meaning that, assuming sequencer and proposer/prover are the same entity, the system changed from 'sequencer can cherry-pick/censor' to 'proposer must blanket-censor, no cherry-pick'. the agglayer bridge is separate from the OP stack proof system and bridge and has its own proof system and l2 smart contract. this includes the gas token (ETH) bridge. the oracle on L2 that allows to update the agglayer bridge state roots is permissioned to an EOA atm.

    contract Yearn Strategist Multisig (eth:0x16388463d60FFE0661Cf7F1f31a7D658aC790ff7) [GnosisSafe] {
    +++ description: None
    values.$members.0:
    + "eth:0x5E5D6f849Fa86c058f148E9D3f643C8F4c43f20b"
    values.$members.1:
    + "eth:0x5250077c42627cBd112988f32D482acC9ff40bDB"
    values.$members.2:
    + "eth:0xC357eE8a8DdE88Dd5a3Ea54847Adef6846A28c51"
    values.$members.3:
    + "eth:0xFcc3796370e1538F8cC60bec19A8be5457f2C74F"
    values.$members.4:
    + "eth:0xFafFb75e14faFf9f11315E44a2E54A22872c7a34"
    values.$members.2:
    - "eth:0xBD5f1429Ab467E69BEeba51E547C00A21F2a2092"
    values.$members.3:
    - "eth:0x787aba336583f4A1D4f8cBBFDFFD49f3a38De665"
    values.$members.4:
    - "eth:0x2C2dc95F8C8060a7e3B354c1B9540881AEa1613C"
    values.$members.5:
    - "eth:0xd0002c648CCa8DeE2f2b8D70D542Ccde8ad6EC03"
    values.$members.6:
    - "eth:0x1b5f15DCb82d25f91c65b53CEe151E8b9fBdD271"
    }
    contract OptimismPortal2 (eth:0x250D30c523104bf0a06825e7eAdE4Dc46EdfE40E) [katana/OptimismPortal2] {
    +++ description: Stores the configuration of the OP stack components and 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.
    name:
    - "OptimismPortal2_neutered"
    + "OptimismPortal2"
    template:
    - "opstack/OptimismPortal2_noForce"
    + "katana/OptimismPortal2"
    sourceHashes.1:
    - "0x4cc0e4525ed77b81565c05c0e673e043a93d9878924197f772581f72c11c91c5"
    + "0xfcecb325a86c39482f8e9d29272f25089eec0b5fbefe21444fd1ea690c911f0c"
    description:
    - "The OptimismPortal contract usually is the main entry point to deposit funds from L1 to L2 or for finalizing withdrawals. It specifies which game type can be used for withdrawals, which currently is the PermissionedDisputeGame. This specific fork of the standard contract **disables the depositTransaction() function**, which prevents users from sending or forcing any transactions from L1 to L2, including token deposits. It is instead used for configuration and administration of the system."
    + "Stores the configuration of the OP stack components and 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."
    values.$implementation:
    - "eth:0x3e6753e6c0162061cfa7eEc88d8fdaE651160Bf4"
    + "eth:0x5dEcbEEEFeCc5353355CD79A8fECC4c03F61ce8a"
    values.$pastUpgrades.8:
    + ["2026-05-22T16:31:35.000Z","0x46d8e0a3a5383c133292ef51e4d7eef96fddc443b892d38e62c39b1186055691",["eth:0x5dEcbEEEFeCc5353355CD79A8fECC4c03F61ce8a"]]
    values.$upgradeCount:
    - 8
    + 9
    values.version:
    - "5.1.1"
    + "agg3.15.0"
    fieldMeta.respectedGameType:
    + {"severity":"HIGH"}
    implementationNames.eth:0x3e6753e6c0162061cfa7eEc88d8fdaE651160Bf4:
    - "OptimismPortal2"
    implementationNames.eth:0x5dEcbEEEFeCc5353355CD79A8fECC4c03F61ce8a:
    + "OptimismPortal2"
    usedTypes.0.arg.1337:
    + "KailuaGame"
    }
    contract AgglayerBridgeL2 (katana:0x2a3DD3EB832aF982ec71669E178424b10Dca2EDe) [katana/AgglayerBridgeL2] {
    +++ description: Agglayer bridge contract. Supports interop with Ethereum and blockchains connected to Agglayer. Escrows all preminted ETH because it cannot mint on the L2. The globalExitRootManager is used as an oracle to validate bridge messages against.
    values.claimedGlobalIndexHashChain:
    - "0xfcb94fe6eae1dd3db9426645c49bdd5a55f574591df36333e3822c2e28a6aa5d"
    + "0x5fede20963bde12c20e3076c4426550f570914a8a035c1381bc98f8bed306a46"
    values.getRoot:
    - "0x77b2c19aaa8daa89496903e91a84dfdf09cbc2821671eb351e953ed0c646be5b"
    + "0x1d743ae7262c7410af3fb680660e6c1f336b2f49609f709a69a9fd8b9ad21bb2"
    }
    contract GlobalExitRootManagerL2SovereignChain (katana:0xa40D5f56745a118D0906a34E69aeC8C0Db1cB8fA) [katana/GlobalExitRootManagerL2SovereignChain] {
    +++ description: Manages Layer 2 and global merkle roots (exit roots). It stores exit roots written during bridge deposits, accepts imported global exit roots from a permissioned address, and manages historical roots.
    values.insertedGERHashChain:
    - "0x64bc5ca77fa29cfc3cd117f2314df1d7c1c5f3d01f31f2c58bd277f3e75b1016"
    + "0xaae24c57922b6453c1812383dba7b31cf9788b57cfc281e208b4e2911e5feee7"
    values.lastRollupExitRoot:
    - "0x77b2c19aaa8daa89496903e91a84dfdf09cbc2821671eb351e953ed0c646be5b"
    + "0x1d743ae7262c7410af3fb680660e6c1f336b2f49609f709a69a9fd8b9ad21bb2"
    }
    2026 May 13, 12:35 UTC
    2changes

    ms member change.

    contract Safe (eth:0xFA58659F64a393A6E1A548ABc70Ad2CfE1e8f9Cb) [GnosisSafe] {
    +++ description: None
    values.$members.4:
    - "eth:0x6c20ea7778EA9F3Afd74Ce4538bc4D9d61E6ABb1"
    + "eth:0xFAc88BB6229F47A31A78F0Ba91E5a541Cb1866a3"
    }
    2026 April 29, 08:35 UTC
    High severity
    7changes

    Two unrelated changes: 1. EOA 0x227D9Ea8... set up an EIP-7702 delegation. This EOA is a signer on two katana multisigs. It now delegates to 0x63c0c19a... (MetaMask's EIP7702StatelessDeleGator v1.3.0) with delegationManager = 0xdb9B1e94... and entryPoint = 0x00000000...da032 (ERC-4337 EntryPoint v0.7). No protocol change for katana — just the signer's own EOA upgrading to a smart-account setup that runs through ERC-4337. 2. Conduit Multisig 1 ( eth:0x4a496227... ) — signer 0x381624F7 removed. Threshold unchanged at 4; total signers 13 → 12 (31% → 33%). Same shared multisig change observed on forknet .

    EOA (eth:0x227D9Ea843910Edd305c42e7bB9Ce6D9f369238c) {
    +++ description: None
    proxyType:
    - "EOA"
    + "EIP7702 EOA"
    sourceHashes:
    + ["0x41c6ce964a4ef3e910f9ddf78152734dae8d1b1094ffc8334c50249a3b112bbf"]
    values:
    + {"$implementation":"eth:0x63c0c19a282a1B52b07dD5a65b58948A07DAE32B","delegationManager":"eth:0xdb9B1e94B5b69Df7e401DDbedE43491141047dB3","DOMAIN_VERSION":"1","eip712Domain":{"fields":"0x0f","name":"EIP7702StatelessDeleGator","version":"1","chainId":1,"verifyingContract":"eth:0x227D9Ea843910Edd305c42e7bB9Ce6D9f369238c","salt":"0x0000000000000000000000000000000000000000000000000000000000000000","extensions":[]},"entryPoint":"eth:0x0000000071727De22E5E9d8BAf0edAc6f37da032","getDeposit":0,"getDomainHash":"0x876a24e12d1595ba43f838917743b4ea108e3957c4df5ec812cf3348b156d941","getNonce":0,"NAME":"EIP7702StatelessDeleGator","PACKED_USER_OP_TYPEHASH":"0xbc37962d8bd1d319c95199bdfda6d3f92baa8903a61b32d5f4ec1f4b36a3bc18","VERSION":"1.3.0"}
    }
    contract Conduit Multisig 1 (eth:0x4a4962275DF8C60a80d3a25faEc5AA7De116A746) {
    +++ description: None
    values.$members.1:
    - "eth:0x381624F7912BddD83dc67c6C53Ef6FE61B87Cf07"
    values.multisigThreshold:
    - "4 of 13 (31%)"
    + "4 of 12 (33%)"
    }

    The system has a centralized operator

    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.

    • Funds can be frozen if the permissioned proposer fails to publish state roots to the L1.

    1. batcherHash - Etherscan address

    Users can force any transaction

    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. The self-sequencing delay is configured offchain and the node source and config are unverified.

    1. depositTransaction() in OptimismPortal2 - Etherscan source code

    Regular messaging

    The user initiates L2->L1 messages by submitting a regular transaction on this chain. When the block containing that transaction is settled, the message becomes available for processing on L1. ZK proofs are required to settle blocks.

    Shared bridge and Pessimistic Proofs

    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.

    • Funds can be lost if the accounting proof system for the bridge (pessimistic proofs, SP1) is implemented incorrectly.

    1. Pessimistic Proof - Polygon Knowledge Layer
    2. Etherscan: AgglayerManager.sol - verifyPessimisticTrustedAggregator() function
    A dashboard to explore contracts and permissions
    Go to Disco
    Disco UI Banner

    Ethereum

    Roles:

    SequencerEOA 1

    Allowed to commit transactions from the current layer to the host chain.

    Trusted Aggregator (Proposer)EOA 4EOA 5

    Permissioned to post new state roots and global exit roots accompanied by ZK proofs.

    Actors:

    PolygonAdminMultisig0x242d…3e21

    A Multisig with 5/9 threshold.

    • Can upgrade with 3d delay
      • AgglayerGateway
      • AgglayerBridge
      • AgglayerManager
      • AgglayerGER
    • Can interact with AgglayerGateway
      • add new routes from proof selector to verifier / pessimisticVkey for pessimistic proofs with 3d delay
      • add or update default aggchain verification keys (aggchainVkey) for any given selectors
      • change the aggchainSigners and threshold (a multisig used for permissioned state transitions)
      • freeze routes from proof selector to verifier / pessimisticVkey for pessimistic proofs
    • Can interact with AgglayerBridge
      • upgrade the implementation of wrapped tokens deployed by the bridge with 3d delay
    • Can interact with AgglayerManager
      • deploy new projects that use predefined rollup types (implementations) and connect them or other Agglayer chains to the PolygonRollupManager
      • 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
      • manage parameters like fees for all connected projects, set the trusted aggregator, stop the emergency state, update projects and obsolete rollup types
    • Can interact with Timelock
      • 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
    Used in:
    Polygon Multisig 20xd067…98CC

    A Multisig with 3/5 threshold. Member of Katana vaultBridge Multisig 1, Katana vaultBridge Multisig 2, Katana vaultBridge Multisig 3.

    • Can upgrade with no delay
      • L1ERC721Bridge
      • L1CrossDomainMessenger
      • OptimismPortal2
      • SuperchainConfig
      • L1StandardBridge
      • OptimismMintableERC20Factory
      • AnchorStateRegistry
      • DelayedWETH
      • SystemConfig
      • DisputeGameFactory
    • Can interact with AggchainFEP
      • change verification keys (aggregationVkey, rangeVkeyCommitment, aggchainVkey) and the rollupConfigHash, manage multisig signers for permissioned state transitions and change critical configs for state validation
      • toggle the ‘optimisticMode’
    • Can interact with SystemConfig
      • it can update the preconfer address, the batch submitter (Sequencer) address and the gas configuration of the system
    • Can interact with AddressManager
      • set and change address mappings
    PolygonSecurityCouncil0x37c5…Dcb6

    A Multisig with 6/8 threshold.

    • Can interact with AgglayerManager
      • 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
    Used in:
    PolygonCreateRollupMultisig0xC74e…79dB

    A Multisig with 3/5 threshold.

    • Can interact with AgglayerManager
      • deploy new projects that use predefined rollup types (implementations) and connect them or other Agglayer chains to the PolygonRollupManager
    Used in:
    Katana vaultBridge Multisig 10x2De2…40ec

    A Multisig with 2/3 threshold.

    • Can upgrade with no delay
      • vbWBTC
      • vbETH
      • vbUSDT
    Polygon Labs Engineering/Security Multisig0x9d85…9052

    A Multisig with 2/8 threshold. Member of Katana vaultBridge Multisig 1, Katana vaultBridge Multisig 2, Katana vaultBridge Multisig 3.

    • Can upgrade with no delay
      • MigrationManager
    Katana vaultBridge Multisig 20xA8C3…C5Ff

    A Multisig with 2/3 threshold.

    • Can upgrade with no delay
      • vbUSDS
    Katana vaultBridge Multisig 30xf4F2…C04E

    A Multisig with 2/3 threshold.

    • Can upgrade with no delay
      • vbUSDC
    Yearn Strategist Multisig0x1638…0ff7

    A Multisig with 3/8 threshold. Member of Katana vaultBridge Multisig 2.

    A Multisig with 1/4 threshold.

    A Multisig with 2/4 threshold. Member of Safe.

    Katana Foundation Engineering/Security Multisig0x4e98…C38a

    A Multisig with 2/5 threshold.

    Katana yieldRecipient Mulsitig0x67C9…3756

    A Multisig with 2/7 threshold. Member of Safe.

    Katana Steakhouse Financial / Morpho Multisig0x827e…eCdB

    A Multisig with 2/6 threshold. Member of Katana vaultBridge Multisig 3.

    • Can interact with AggchainFEP
      • sign state transitions (replaces state validation for this aggchain)
    • A trusted Aggregator - acting directly

    Katana

    Actors:

    GnosisSafeL20x4e98…C38a

    A Multisig with 2/5 threshold.

    • Can upgrade with 12h delay
      • AgglayerBridgeL2
      • GlobalExitRootManagerL2SovereignChain
    • Can interact with AgglayerBridgeL2
      • manage token mappings and deployments
      • own and upgrade default L2 token contracts deployed by the bridge
      • pause the bridge
      • unpause the bridge
    • Can interact with GlobalExitRootManagerL2SovereignChain
      • manage ‘claimed’ status of global deposit indexes (can freeze bridge transactions), remove global exit roots (used for L2 deposits)
      • roll back or insert leaves into the local exit tree (LET) that enables withdrawals from the L2. (can steal)
    • Can interact with L2Timelock
      • propose, cancel and execute transactions in the timelock, manage all access control roles and change the minimum delay with 12h delay

    A Multisig with 3/5 threshold.

    • Can upgrade with no delay
      • DeployerWhitelist
      • L2CrossDomainMessenger
      • GasPriceOracle
      • L2StandardBridge
      • SequencerFeeVault
      • OptimismMintableERC20Factory
      • L1BlockNumber
      • L2ERC721Bridge
      • L1Block
      • L2ToL1MessagePasser
      • OptimismMintableERC721Factory
      • ProxyAdmin
      • BaseFeeVault
      • L1FeeVault
      • OperatorFeeVault
      • SchemaRegistry
      • EAS
    • Can upgrade with 12h delay
      • AgglayerBridgeL2
      • GlobalExitRootManagerL2SovereignChain
    • Can interact with L2Timelock
      • propose, cancel and execute transactions in the timelock, manage all access control roles and change the minimum delay with 12h delay

    A Multisig with 3/5 threshold.

    • Can interact with SequencerFeeVault
      • receive fees
    • Can interact with BaseFeeVault
      • receive fees
    • Can interact with L1FeeVault
      • receive fees
    • Can interact with GlobalExitRootManagerL2SovereignChain
      • update the global exit root (GER) that is used for L2 deposits
    A dashboard to explore contracts and permissions
    Go to Disco
    Disco UI Banner
    A diagram of the smart contract architecture
    A diagram of the smart contract architecture

    Ethereum

    The main system contract defining the katana Aggchain logic. This contract, based on the OP-Succinct L2OutputOracle, supports validity proofs and OP stack outputRoots (L2 state roots) are saved here.

    • Roles:
      • aggchainManager: Polygon Multisig 2
      • aggchainSigners: EOA 2 optimisticMode is enabled by the optimisticModeManager
      • optimisticModeManager: Polygon Multisig 2

    Stores the configuration of the OP stack components and 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 Sequencer address, gas limit on this chain and the unsafe block signer address.

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

    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.

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

    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.

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

    All supported tokens in this escrow are included in the value secured calculation.

    Proxy used in:

    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.

    • Roles:
      • admin: SharedProxyAdmin; ultimately PolygonAdminMultisig
      • createRollup: PolygonAdminMultisig, PolygonCreateRollupMultisig
      • defaultAdmin: Timelock; ultimately PolygonAdminMultisig
      • emergencyCouncilAdmin: PolygonSecurityCouncil
      • trustedAggregator: EOA 4, EOA 5
      • tweakParameters: PolygonAdminMultisig
    Proxy used in:

    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.

    • Roles:
      • admin: SharedProxyAdmin; ultimately PolygonAdminMultisig
    Proxy used in:

    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)
    Implementation used in:

    This token contract uses a standard ‘vault 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 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 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 2. If any vbTokens are minted ‘natively’ on Layer 2, this contract can receive the underlying assets and lock them in the Layer 1 vaults.

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

    This token contract uses a standard ‘vault 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 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
    ProxyAdmin0x14Be…e951
    • Roles:
      • owner: Katana vaultBridge Multisig 1
    ProxyAdmin0x19Db…8832
    • Roles:
      • owner: Polygon Multisig 2
    PreimageOracle0x1fb8…aDD3

    The PreimageOracle contract is used to load the required data from L1 for a dispute game.

    Implementation used in:
    ProxyAdmin0x263b…ED56
    • Roles:
      • owner: Polygon Labs Engineering/Security Multisig
    ProxyAdmin0x377a…4010
    • Roles:
      • owner: Katana vaultBridge Multisig 1
    ProxyAdmin0x4206…2d69
    • Roles:
      • owner: Katana vaultBridge Multisig 1

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

    Implementation used in:
    ProxyAdmin0x6d0f…9a52
    • Roles:
      • owner: Polygon Multisig 2
    ProxyAdmin0x8970…FE30
    • Roles:
      • owner: Katana vaultBridge Multisig 3
    PermissionedDisputeGame0xA7A2…d22D

    Same as FaultDisputeGame, but only two permissioned addresses are designated as proposer and challenger.

    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.

    • Roles:
      • admin: ProxyAdmin; ultimately Polygon Multisig 2
    Implementation used in:

    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
    Implementation used in:
    ProxyAdmin0xD1e3…a832
    • Roles:
      • owner: Katana vaultBridge Multisig 2
    SP1Verifier0x0459…C459

    Verifier contract for SP1 proofs (v5.0.0).

    Implementation used in:
    SharedProxyAdmin0x0F99…CC4A
    • Roles:
      • owner: Timelock
    Implementation used in:
    BridgeLib0x3622…8aB3

    Extension contract of the AgglayerBridge for asset metadata…

    Implementation used in:

    Katana

    Agglayer bridge contract. Supports interop with Ethereum and blockchains connected to Agglayer. Escrows all preminted ETH because it cannot mint on the L2. 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
    GlobalExitRootManagerL2SovereignChain0xa40D…B8fAImplementation (Upgradable)Admin

    Manages Layer 2 and global merkle roots (exit roots). It stores exit roots written during 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
    L2Timelock0xBBa0…6d13

    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)
    ProxyAdmin0x0F99…CC4A
    • Roles:
      • owner: L2Timelock
    • Roles:
      • admin: ProxyAdmin; ultimately SafeL2
    Can be upgraded by:

    The L2CrossDomainMessenger (L2xDM) contract sends messages from L2 to L1, 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 limit, it can be resubmitted via this contract’s replay function.

    • Roles:
      • admin: ProxyAdmin; ultimately SafeL2
    Can be upgraded by:

    Provides the current gas price for L2 transactions.

    • Roles:
      • admin: ProxyAdmin; ultimately SafeL2
    Can be upgraded by:

    Collects the sequencer fees.

    • Roles:
      • admin: ProxyAdmin; ultimately SafeL2
      • recipient: SafeL2
    Can be upgraded by:

    Simple contract that returns the latest L1 block number.

    • Roles:
      • admin: ProxyAdmin; ultimately SafeL2
    Can be upgraded by:

    Simple contract that returns information about the latest L1 block, which is derived permissionlessly from the L1 chain.

    • Roles:
      • admin: ProxyAdmin; ultimately SafeL2
    Can be upgraded by:

    Contract used internally by the L2CrossDomainMessenger to send messages to L1. It can also be used directly as a low-level interface.

    • Roles:
      • admin: ProxyAdmin; ultimately SafeL2
    Can be upgraded by:
    • Roles:
      • admin: ProxyAdmin; ultimately SafeL2
      • owner: SafeL2
    Can be upgraded by:

    Collects EIP-1559 base fees

    • Roles:
      • admin: ProxyAdmin; ultimately SafeL2
      • recipient: SafeL2
    Can be upgraded by:

    Collects the L1 portion of the L2 transaction fees.

    • Roles:
      • admin: ProxyAdmin; ultimately SafeL2
      • recipient: SafeL2
    Can be upgraded by:

    Holds the ‘operator fees’ for the L2 network, which are part of the L2 fees that users pay.

    • Roles:
      • admin: ProxyAdmin; ultimately SafeL2
    Can be upgraded by:

    Contracts to register schemas for the Ethereum Attestation Service (EAS).

    • Roles:
      • admin: ProxyAdmin; ultimately SafeL2
    Can be upgraded by:

    Contract containing the main logic for the Ethereum Attestation Service (EAS).

    • Roles:
      • admin: ProxyAdmin; ultimately SafeL2
    Can be upgraded by:
    BridgeLib0xb30C…E124

    Utility library contract for the AgglayerBridgeL2.

    TokenWrappedBridgeUpgradeable0xF077…1a2c

    An ERC-20 implementation designed for cross-chain assets on the L2. It restricts token minting or burning strictly to the primary bridge contract.

    The current deployment carries some associated risks:

    • Funds can be stolen if the contracts or their dependencies (e.g. AggLayerGateway) receive a malicious code upgrade. There is no delay on upgrades.

    Program Hashes

    Name
    Hash
    Repository
    Verification
    Used in
    0x0065...1152
    Code unknown
    None
    Katana logo
    0x5c7c...2229
    Code unknown
    None
    Katana logo
    0x713f...fa1f
    Katana logo
    0x374e...dac6
    Katana logo
    0x6e38...1b53
    Katana logo
    0x7767...6f70
    Katana logo
    0x00ef...cc30
    Katana logoLumia Prism logoHaust Network logoX Layer logoPolygon zkEVM logo

    Projects used in

    Search for projects used in

    0x0000...b639
    Katana logoLumia Prism logoHaust Network logoX Layer logoPolygon zkEVM logo

    Projects used in

    Search for projects used in