Search for projects by name
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.
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.
2025 May 09 — Jul 03
2025 May 08 — Jul 03
The section shows the operating costs that L2s pay to Ethereum.
2025 May 08 — Jul 03
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
There is no mechanism to have transactions be included if the sequencer is down or censoring.
SNARKs are zero knowledge proofs that ensure state correctness, but require trusted setup.
All of the data needed for proof construction is published on Ethereum L1.
Even though there is a 3d Timelock for upgrades, forced transactions are disabled.
Only the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen.
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.
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.
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.
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.
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.
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.
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.
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.
Allowed to commit transactions from the current layer to the host chain.
Permissioned to post new state roots and global exit roots accompanied by ZK proofs.
A Multisig with 5/12 threshold.
Participants (12):
0xcAB3…62f90xAb35…235E0x54c4…65d90x2161…d4170xED7c…B5a20xdFEd…56Da0xffbf…32380xeD44…dB370x516e…46B70x4c16…88910xA0B0…f2270xEad7…9dB2A Multisig with 3/5 threshold.
A Multisig with 6/8 threshold.
Participants (8):
0xFe45…2e4b0xaF46…261D0xBDc2…FEFf0x4c16…88910x3ab9…D6220x49c1…0E860x9F7d…86A00x2188…1C28A Multisig with 3/8 threshold.
Participants (8):
0x3038…D3b50xa439…AE310xD947…fCFC0xCE27…AaAc0x0B84…Ca770x0185…22A60x7316…44960xC8aa…39e9A Multisig with 2/3 threshold.
A Multisig with 2/5 threshold. Member of Katana vaultBridge Multisig 1, Katana vaultBridge Multisig 2, Katana vaultBridge Multisig 3.
A Multisig with 2/3 threshold.
A Multisig with 2/3 threshold.
A Multisig with 3/7 threshold. Member of Katana vaultBridge Multisig 2.
A Multisig with 4/11 threshold.
Participants (11):
0x8117…E7Ac0x860e…c0530x5093…66280xA073…bda20xF331…647D0xF0B7…A4f00xa400…e6e40x3840…Fd5f0xa0C6…90380xefCf…dD5C0x4D80…5BAeA Multisig with 2/3 threshold.
A Multisig with 2/4 threshold. Member of Katana vaultBridge Multisig 3.
A Multisig with 1/2 threshold. Member of Katana vaultBridge Multisig 1, Katana vaultBridge Multisig 2, Katana vaultBridge Multisig 3.
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.
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.
Contains configuration parameters such as the Sequencer address, gas limit on this chain and the unsafe block signer address.
A verifier gateway for pessimistic proofs. Manages a map of chains and their verifier keys and is used to route proofs based on the first 4 bytes of proofBytes data in a proof submission. The SP1 verifier is used for all proofs.
The shared bridge contract, escrowing user funds sent to AggLayer participants. It is usually mirrored on each chain and can be used to transfer both ERC20 assets and arbitrary messages.
The central shared managing contract for Polygon AggLayer chains. This contract coordinates chain deployments and proof validation. All connected Layer 2s can be globally paused by activating the ‘Emergency State’. This can be done by the PolygonSecurityCouncil or by anyone after 1 week of inactive verifiers.
A merkle tree storage contract aggregating state roots of each participating Layer 2, thus creating a single global merkle root representing the global state of the AggLayer, the ‘global exit root’. The global exit root is synchronized to all connected Layer 2s to help with their interoperability.
A timelock with access control. In the case of an activated emergency state in the PolygonRollupManager, all transactions through this timelock are immediately executable. The current minimum delay is 3d.
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.
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.
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.
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.
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.
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.
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.