Kroma
Badges
About
Kroma aims to develop a universal ZK Rollup based on the Optimism Bedrock architecture. Currently, Kroma operates as an Optimistic Rollup with ZK fault proofs, utilizing a zkEVM based on Scroll and a zkVM based proven with SP1.
Badges
About
Kroma aims to develop a universal ZK Rollup based on the Optimism Bedrock architecture. Currently, Kroma operates as an Optimistic Rollup with ZK fault proofs, utilizing a zkEVM based on Scroll and a zkVM based proven with SP1.
Recategorisation
The project will be classified as "Other" due to its specific risks that set it apart from the standard classifications.
The project will move to Others because:
Consequence: projects without a proper proof system fully rely on single entities to safely update the state. A malicious proposer can finalize an invalid state, which can cause loss of funds.
2024 May 24 — 2025 May 24
2024 May 24 — 2025 May 23
The section shows the operating costs that L2s pay to Ethereum.
2024 May 24 — 2025 May 23
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 Apr 24 — May 24
SP1 fault proofs upgrade
2025 Feb 11th
Kroma adds an option to prove faults using the SP1 zk virtual machine.
Ecotone upgrade
2024 Apr 25th
Introduces EIP-4844 data blobs for L1 data availability and more L2 opcodes.
Funds can be stolen if
Funds can be lost if
MEV can be extracted if
Fraud proofs allow actors watching the chain to prove that the state is incorrect. Interactive proofs (INT) require multiple transactions over time to resolve. ZK proofs are used to adjudicate the correctness of the last step. The challenge protocol can fail under certain conditions. The current system doesn’t use posted L2 txs batches on L1 as inputs to prove a fault (for the zkEVM prover path), meaning that DA is not always enforced.
All of the data needed for proof construction is published on Ethereum L1.
There is no window for users to exit in case of an unwanted regular upgrade since contracts are instantly upgradable.
Kroma is a All transaction data is recorded on chain
All executed transactions are submitted to an on chain smart contract. The execution of the rollup is based entirely on the submitted transactions, so anyone monitoring the contract can know the correct state of the rollup chain.
- Derivation: Batch Submission - Kroma specs
- BatchInbox - Etherscan address
- KromaPortal.sol - Etherscan source code, depositTransaction() function
EthereumKroma nodes source code, including full node, proposer and validator, can be found here. Also, the geth server, source maintained here, is a fork of go-ethereum. For more details on how they are different from the Optimism implementation, see here. The instructions to run the proposer (called validator) and the ZK prover, are documented here.
Data batches are compressed using the zlib algorithm with best compression level.
The genesis file can be found here.
Kroma uses an interactive fraud proof system to find a single block of disagreement, which is then ZK proven. Once the single block of disagreement is found, the challenger is required to present a ZK proof of the fraud. This can be either a proof verified in a zkEVM verifier base on Scroll, or in a zkVM verifier built by Succinct SP1. If the proof is validated, the incorrect state output is deleted. The Security Council can always override the result of the challenge, it can also delete any L2 state root at any time. The protocol can fail under certain conditions.
Funds can be lost if the cryptography is broken or implemented incorrectly.
The system has a centralized sequencer
While forcing transaction is open to anyone the system employs a privileged sequencer that has priority for submitting transaction batches and ordering transactions.
MEV can be extracted if the operator exploits their centralized position and frontruns user transactions.
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.
Regular messaging
Autonomous exit
Users can (eventually) exit the system by pushing the transaction on L1 and providing the corresponding state root. The only way to prevent such withdrawal is via an upgrade.
EVM compatible smart contracts are supported
OP stack chains are pursuing the EVM Equivalence model. No changes to smart contracts are required regardless of the language they are written in, i.e. anything deployed on L1 can be deployed on L2.
Ethereum
Roles:
Allowed to pause withdrawals. In op stack systems with a proof system, the Guardian can also blacklist dispute games and set the respected game type (permissioned / permissionless).
Allowed to commit transactions from the current layer to the host chain.
Actors:
A soulbound token implementation to identify participants of the KromaSecurityCouncil. Owners of the token are members of the council. There are currently 10 members.
- Can upgrade with no delay
- ZKProofVerifier
via
- acting via UpgradeGovernor → L1Timelock → ProxyAdmin - L2OutputOracle
via
- acting via UpgradeGovernor → L1Timelock → ProxyAdmin - L1Timelock
via
- acting via UpgradeGovernor → L1Timelock → ProxyAdmin - ValidatorManager
via
- acting via UpgradeGovernor → L1Timelock → ProxyAdmin - KromaPortal
via
- acting via UpgradeGovernor → L1Timelock → ProxyAdmin - SystemConfig
via
- acting via UpgradeGovernor → L1Timelock → ProxyAdmin - KromaSecurityCouncil
via
- acting via UpgradeGovernor → L1Timelock → ProxyAdmin - L1CrossDomainMessenger
via
- acting via UpgradeGovernor → L1Timelock → ProxyAdmin - L1ERC721Bridge
via
- acting via UpgradeGovernor → L1Timelock → ProxyAdmin - ZkVerifier
via
- acting via UpgradeGovernor → L1Timelock → ProxyAdmin - Colosseum
via
- acting via UpgradeGovernor → L1Timelock → ProxyAdmin - USDCBridge
via
- acting via UpgradeGovernor → L1Timelock - L1StandardBridge
via
- acting via UpgradeGovernor → L1Timelock → ProxyAdmin - AssetManager
via
- acting via UpgradeGovernor → L1Timelock → ProxyAdmin - UpgradeGovernor
via
- acting via UpgradeGovernor → L1Timelock → ProxyAdmin - SecurityCouncilTokenOwners
via
- acting via UpgradeGovernor → L1Timelock → ProxyAdmin - ValidatorPool
via
- acting via UpgradeGovernor → L1Timelock → ProxyAdmin
- ZKProofVerifier
- Can interact with L1Timelock
- cancel queued transactions
via
- acting via UpgradeGovernor - execute transactions that are ready
via
- acting via UpgradeGovernor - manage all access control roles and change the minimum delay
via
- acting via UpgradeGovernor → L1Timelock - or - acting via UpgradeGovernor - propose transactions
via
- acting via UpgradeGovernor
- cancel queued transactions
- Can interact with SystemConfig
Custom Multisig contract in which each signer is identified by a token. The threshold is 8 and the token contract is called SecurityCouncilToken.
- Can interact with Colosseum
- dismiss ongoing challenges and override state roots (
forceDeleteOutput())
- dismiss ongoing challenges and override state roots (
- Can interact with ValidatorPool
- become a validator without posting a bond
- A Guardian - acting directly
SP1Verifier is a contract used to verify proofs given public values and verification key.
- Can interact with SP1VerifierGateway
- can verify proofs for the header range [latestBlock, targetBlock] proof
- A Multisig with 3/5 threshold. Escrows a pool of KRO used as validator rewards by the AssetManager.
- Can interact with SecurityCouncilTokenOwners
- one of the signers of the KromaSecurityCouncil
- Can interact with SecurityCouncilTokenOwners
- one of the signers of the KromaSecurityCouncil
- Can interact with SecurityCouncilTokenOwners
- one of the signers of the KromaSecurityCouncil
- Can interact with SecurityCouncilTokenOwners
- one of the signers of the KromaSecurityCouncil
- Can interact with SecurityCouncilTokenOwners
- one of the signers of the KromaSecurityCouncil
- Can interact with SecurityCouncilTokenOwners
- one of the signers of the KromaSecurityCouncil
- Can interact with SecurityCouncilTokenOwners
- one of the signers of the KromaSecurityCouncil
- Can interact with SecurityCouncilTokenOwners
- one of the signers of the KromaSecurityCouncil
- Can interact with SecurityCouncilTokenOwners
- one of the signers of the KromaSecurityCouncil
- Can interact with SecurityCouncilTokenOwners
- one of the signers of the KromaSecurityCouncil
Ethereum
Sends messages from host chain to this chain, and relays messages back onto host chain. In the event that a message sent from host chain to this chain is rejected for exceeding this chain’s epoch gas limit, it can be resubmitted via this contract’s replay function.
- Roles:
- admin: ProxyAdmin; ultimately SecurityCouncilTokenOwners
Used to bridge ERC-721 tokens from host chain to this chain.
- Roles:
- admin: ProxyAdmin; ultimately SecurityCouncilTokenOwners
The main entry point to deposit ERC20 tokens from host chain to this chain.
- Roles:
- admin: ProxyAdmin; ultimately SecurityCouncilTokenOwners
- This contract can store any token.
- Roles:
- admin: ProxyAdmin; ultimately SecurityCouncilTokenOwners
The L2OutputOracle contract contains a list of proposed state roots which Proposers assert to be a result of block execution. Anyone can participate as a Proposer by depositing in the ValidatorPool. A root can be proposed every 1800 blocks (2s block time).
- Roles:
- admin: ProxyAdmin; ultimately SecurityCouncilTokenOwners
A standard timelock with access control. The current minimum delay is 0s.
- Roles:
- admin: ProxyAdmin; ultimately SecurityCouncilTokenOwners
- canceller: UpgradeGovernor; ultimately SecurityCouncilTokenOwners
- executor: UpgradeGovernor; ultimately SecurityCouncilTokenOwners
- proposer: UpgradeGovernor; ultimately SecurityCouncilTokenOwners
- timelockAdmin: L1Timelock, UpgradeGovernor; ultimately SecurityCouncilTokenOwners
Manages the set of Proposers (Validators in Kroma) and selects the next proposer with the window to submit the output root within 30m, after which anyone can propose for them. It is also the entry point for other contracts, such as the L2OutputOracle and the Colosseum, which distribute output rewards and slash challenge losers. It makes successive calls to the AssetManager to apply changes to the proposers’ assets.
- Roles:
- admin: ProxyAdmin; ultimately SecurityCouncilTokenOwners
This is a fork of the standard OP stack OptimismPortal contract, the main entry point to deposit funds from L1 to L2. It also allows to prove and finalize withdrawals.
- Roles:
- admin: ProxyAdmin; ultimately SecurityCouncilTokenOwners
- guardian: KromaSecurityCouncil
- This contract stores the following tokens: ETH.
Merkle Trie contract used to prove withdrawals that were initiated in the legacy system, deprecated for new withdrawals and succeeded by a merkle tree library in the KromaPortal.
This contract is the router for zk proof verification. It stores the mapping between identifiers and the address of onchain verifier contracts, routing each identifier to the corresponding verifier contract.
- Roles:
- owner: SP1VerifierGatewayMultisig
- verifier: SP1Verifier
- Roles:
- owner: L1Timelock
Contract used to challenge state roots and prove fraud. If successful, the wrong state root in the L2OutputOracle is replaced.
- Roles:
- admin: ProxyAdmin; ultimately SecurityCouncilTokenOwners
- security_council: KromaSecurityCouncil
- Roles:
- admin: L1Timelock; ultimately SecurityCouncilTokenOwners
- This contract stores the following tokens: USDC.
Manages the delegation and undelegation of KRO tokens and Kroma Guardian House (KGH) NFTs for Proposers (Kroma Validators) and distributes rewards.
- Roles:
- admin: ProxyAdmin; ultimately SecurityCouncilTokenOwners
A governance proxy contract using token voting with SecurityCouncilTokenOwners as identification of actors allowed to vote/sign a proposal which is passed to the L1Timelock afterwards.
- Roles:
- admin: ProxyAdmin; ultimately SecurityCouncilTokenOwners
- token: SecurityCouncilTokenOwners
Contract used to manage the Proposers. Anyone can submit a deposit and bond to a state root, or create a challenge. It also manages the Proposer rotation for each submittable block using a random selection. If the selected proposer fails to publish a root within 30m then the submission becomes open to everyone.
- Roles:
- admin: ProxyAdmin; ultimately SecurityCouncilTokenOwners
- security_council: KromaSecurityCouncil
Value Secured is calculated based on these smart contracts and tokens:
Main entry point for users depositing ERC20 token that do not require custom gateway.
Main entry point for users depositing ETH.
Main entry point for users depositing USDC.
The current deployment carries some associated risks:
Funds can be stolen if a contract receives a malicious code upgrade. There is no delay on code upgrades (CRITICAL).