Search

Search for projects by name

Katana logoKatana

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.


Value secured
$188.74 M>1K%
Canonically Bridged
$4.57 M
Natively Minted
$0.00
Externally Bridged
$184.17 M

  • Tokens
  • Past day UOPS
    0.88454%
  • Stage
  • Type
    ZK Rollup

  • Purpose
    Universal
  • Chain ID
    747474
  • 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.

    Value Secured

    2025 May 09 — Jul 03


    Total value securedTotal
    $188.74 M>1K%
    Canonically BridgedCanonically Bridged ValueCanonical
    $4.57 M591%
    Natively MintedNatively Minted TokensNative
    $0.000.00%
    Externally BridgedExternally Bridged ValueExternal
    $184.17 M>1K%
    Activity

    2025 May 08 — Jul 03

    Onchain costs

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


    2025 May 08 — Jul 03


    1 year total cost
    $960.45
    Avg cost per L2 UOP
    $0.002798
    1 year data posted
    94.00 MiB
    Avg size per L2 UOP
    287.18 B

    Liveness

    The chart illustrates how "live" the project's operators are by displaying how frequently they submit transactions of the selected type and if these intervals deviate from their typical schedule.


    2025 Jun 03 — Jul 03

    30D avg. tx data subs. interval
    1 hour
    30D avg. proof subs. interval
    1 hour
    30D avg. state updates interval
    1 hour
    Past 30 days anomalies
    Milestones & Incidents

    Katana Launch

    2025 Jul 1st

    Katana is live on Ethereum mainnet.

    Learn more
    Risk summary
    Risk analysis
    Sequencer failureState validationData availabilityExit windowProposer failure
    Sequencer failure
    No mechanism

    There is no mechanism to have transactions be included if the sequencer is down or censoring.

    State validation
    ZK proofs (SN)

    SNARKs are zero knowledge proofs that ensure state correctness, but require trusted setup.

    Data availability
    Onchain

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

    Exit window
    None
    The Security Council can remove the delay on upgrades.

    Even though there is a 3d Timelock for upgrades, forced transactions are disabled.

    Proposer failure
    Cannot withdraw

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

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

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

    All data required for proofs is published on chain

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

    1. batchInbox - Etherscan address
    Learn more about the DA layer here: Ethereum logoEthereum
    State validation
    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.

    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.

    Operator

    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.

    • Funds can be frozen if the permissioned sequencer fails to publish transaction data to the L1.

    1. batcherHash - Etherscan address

    Users can't force any transaction

    The mechanism for allowing users to submit their own transactions is currently disabled.

    • Users can be censored if the operator refuses to include their transactions.

    1. _depositTransaction() in OptimismPortal2 - Etherscan source code
    Withdrawals

    Regular messaging

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

    Other considerations

    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: PolygonRollupManager.sol - verifyPessimisticTrustedAggregator() function
    Upgrades & Governance
    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 RollupManager (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 PolygonRollupManager 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 rolupTypes and manage operational parameters and fees in the PolygonRollupManager 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.

    Permissions
    A dashboard to explore contracts and permissions
    Go to Disco
    Disco UI Banner

    Ethereum

    Roles:

    Sequencer 0x1FFD…412a

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

    Trusted Aggregator (Proposer) (2) 0x20A5…51dE0x6329…f7ab

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

    Actors:

    PolygonAdminMultisig 0x242d…3e21

    A Multisig with 5/12 threshold.

    • Can upgrade with 3d delay
      • AggLayerGateway
      • PolygonSharedBridge
      • PolygonRollupManager
      • PolygonGlobalExitRootV2
    • 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
      • freeze routes from proof selector to verifier / pessimisticVkey for pessimistic proofs
    • Can interact with PolygonSharedBridge
      • upgrade the implementation of wrapped tokens deployed by the bridge with 3d delay
    • Can interact with PolygonRollupManager
      • 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 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:
    Katana Foundation Engineering/Security Multisig 0x4e98…C38a

    A Multisig with 3/5 threshold.

    • Can upgrade with no delay
      • L1ERC721Bridge
      • L1CrossDomainMessenger
      • OptimismPortal2
      • SuperchainConfig
      • DelayedWETH
      • AnchorStateRegistry
      • L1StandardBridge
      • OptimismMintableERC20Factory
      • SystemConfig
      • DisputeGameFactory
    • Can interact with AggchainFEP
      • change the op-succinct related verification keys (aggregationVkey, rangeVkeyCommitment) and the rollupConfigHash
      • toggle the ‘optimisticMode’
    • Can interact with DelayedWETH
      • can pull funds from the contract in case of emergency
    • 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
    PolygonSecurityCouncil 0x37c5…Dcb6

    A Multisig with 6/8 threshold.

    • Can interact with PolygonRollupManager
      • 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:
    PolygonCreateRollupMultisig 0xC74e…79dB

    A Multisig with 3/8 threshold.

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

    A Multisig with 2/3 threshold.

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

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

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

    A Multisig with 2/3 threshold.

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

    A Multisig with 2/3 threshold.

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

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

    Katana yieldRecipient Mulsitig 0x67C9…3756

    A Multisig with 2/3 threshold.

    Katana Steakhouse Financial / Morpho Multisig 0x827e…eCdB

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

    Polygon Multisig 2 0xd067…98CC

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

    Participants (2):

    0x1DD6…11640xa439…AE31
    • Can interact with AggchainFEP
      • finalize any state root with only their signature
    Smart contracts
    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 Layer 2 logic. As this contract is based on the OP-Succinct L2OutputOracle, OP stack outputRoots (L2 state roots) are saved here.

    • Roles:
      • aggchainManager: Katana Foundation Engineering/Security Multisig
      • optimisticModeManager: Katana Foundation Engineering/Security Multisig
      • trustedSequencer: EOA 2 optimisticMode is enabled by the optimisticModeManager

    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.

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

    Contains configuration parameters such as the Sequencer address, gas limit on this chain and the unsafe block signer address.

    • Roles:
      • admin: ProxyAdmin; ultimately Katana Foundation Engineering/Security Multisig
      • batcherHash: EOA 1
      • owner: Katana Foundation Engineering/Security Multisig
    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
      • freezePpRoute: PolygonAdminMultisig
    Proxy used in:

    The shared bridge contract, escrowing user funds sent to AggLayer participants. 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
    • This contract can store any token.
    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 3, EOA 4
      • 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:
    Timelock 0xEf14…A4EF

    A timelock with access control. In the case of an activated emergency state in the PolygonRollupManager, 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)
    Proxy 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 Katana yieldRecipient Mulsitig.

    • 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 Katana yieldRecipient Mulsitig.

    • 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 Katana yieldRecipient Mulsitig.

    • 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 Katana yieldRecipient Mulsitig.

    • 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 Katana yieldRecipient Mulsitig.

    • Roles:
      • admin: ProxyAdmin; ultimately Katana vaultBridge Multisig 1
    ProxyAdmin 0x14Be…e951
    • Roles:
      • owner: Katana vaultBridge Multisig 1
    ProxyAdmin 0x19Db…8832
    • Roles:
      • owner: Katana Foundation Engineering/Security Multisig
    ProxyAdmin 0x263b…ED56
    • Roles:
      • owner: Polygon Labs Engineering/Security Multisig
    PermissionedDisputeGame 0x2d4B…f5e4

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

    ProxyAdmin 0x377a…4010
    • Roles:
      • owner: Katana vaultBridge Multisig 1
    ProxyAdmin 0x4206…2d69
    • Roles:
      • owner: Katana vaultBridge Multisig 1
    ProxyAdmin 0x6d0f…9a52
    • Roles:
      • owner: Katana Foundation Engineering/Security Multisig

    Contains the latest confirmed state root that can be used as a starting point in a dispute game.

    • Roles:
      • admin: ProxyAdmin; ultimately Katana Foundation Engineering/Security Multisig
    ProxyAdmin 0x8970…FE30
    • Roles:
      • owner: Katana vaultBridge Multisig 3
    ProxyAdmin 0xD1e3…a832
    • Roles:
      • owner: Katana vaultBridge Multisig 2
    SP1Verifier 0x0459…C459

    Verifier contract for SP1 proofs (v5.0.0).

    Proxy used in:
    SharedProxyAdmin 0x0F99…CC4A
    • Roles:
      • owner: Timelock
    Proxy used in:

    Value Secured is calculated based on these smart contracts and tokens:

    Proxy used in:

    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.