Kroma logoKroma

Value Locked

$72.22 K

48.27%

Canonically Bridged
$72.22 K (100%)
Externally Bridged
$0.00 (0%)
Natively Minted
$0.00 (0%)
  • Breakdown
  • Daily TPS
    0.03756.59%
  • 30D tx count
    36.17 K
  • Stage
    Stage 0
  • Technology
    Optimistic Rollup
  • Purpose
    Universal

  • ...

    View tokens

    Choose a token

    Canonically Bridged Tokens (Top 15)

    Can't find a token?

    Request it here

    Milestones

    Kroma Mainnet Launch

    2023 Sep 6th

    Kroma is live on mainnet.

    Learn more
    Show more

    Description

    Kroma aims to develop an 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. Kroma’s goal is to eventually transition to a ZK Rollup once the generation of ZK proofs becomes more cost-efficient and faster.

    If you find something wrong on this page you can submit an issue or edit the information.

    Risk Analysis

    Sequencer failureState validationData availabilityUpgradeabilityProposer failure

    State validation

    Fraud proofs (INT, ZK)

    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 be subject to delay attacks and can fail under certain conditions.

    Data availability

    On chain

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

    Upgradeability

    Yes

    The code that secures the system can be changed arbitrarily and without notice.

    Sequencer failure

    Self sequence

    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 is a 12h delay on this operation.

    Proposer failure

    Self propose

    Anyone can be a Proposer and propose new roots to the L1 bridge.

    Rollup stage

    KromaKroma is aStage 0Optimistic Rollup.
    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.

    Technology

    Fraud Proofs ensure state correctness

    Kroma uses an interactive fraud proof system to find a single block of disagreement, which is then zk proven. The zkEVM used is based on Scroll. Once the single block of disagreement is found, CHALLENGER is required to present zkProof of the fraud. When 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. If the malicious ATTESTER and CHALLENGER collude and are willing to spend bonds, they can perform a delay attack by engaging in continuous challenge resulting in lack of finalization of the L2 state root on L1. The protocol can also fail under certain conditions.

    • Withdrawals can be delayed if the fraud proof system is under a delay attack.

    • Funds can be lost if the cryptography is broken or implemented incorrectly.

    1. Colosseum.sol#L300 - Etherscan source code, createChallenge function
    2. Colosseum.sol#L378 - Etherscan source code, bisect function
    3. Colosseum.sol#L434 - Etherscan source code, proveFault function
    4. KROMA-020: lack of validation segments and proofs in Colosseum.sol - ChainLight security audit

    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.

    1. Derivation: Batch Submission - Kroma specs
    2. BatchInbox - Etherscan address
    3. KromaPortal.sol#L430 - Etherscan source code, depositTransaction function

    Operator

    The system has a centralized sequencer

    While proposing blocks 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.

    1. SystemConfig - batcher address

    Users can force any transaction

    Because the state of the system is based on transactions submitted on-chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract directly.

    1. Sequencing Window - Kroma specs
    2. KromaPortal.sol#430 - Etherscan source code, depositTransaction function

    Withdrawals

    Regular exit

    The user initiates the withdrawal by submitting a regular transaction on this chain. When the block containing that transaction is finalized the funds become available for withdrawal on L1. The process of block finalization usually takes several days to complete. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.

    1. KromaPortal.sol#L241 - Etherscan source code, proveWithdrawalTransaction function
    2. KromaPortal.sol#L324 - Etherscan source code, finalizeWithdrawalTransaction function

    Other considerations

    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.

    1. Introducing EVM Equivalence

    Permissions

    The system uses the following set of permissioned addresses:

    KromaAdmin 0x3aa0…29e6

    Only member of the UpgradeGovernor, which owns the Timelock and therefore controls the ProxyAdmin. Can instantly upgrade the system.

    SecurityCouncil 0x3de2…6Ec4

    MultiSig (currently 1/1) that is a guardian of KromaPortal, priviliged Validator that does not need a bond and priviliged actor in Colosseum contract that can remove any L2Output state root regardless of the outcome of the challenge.

    SecurityCouncilAdmin 0xA03c…9081

    Can add, remove and replace members of the SecurityCouncil multisig, and can also add addresses to the Governor whitelist. Currently EOA.

    Sequencer 0x41b8…cE12

    Central actor allowed to commit L2 transactions on L1.

    Guardian 0x3de2…6Ec4

    Actor allowed to pause withdrawals. Currently set to the Security Council.

    Smart Contracts

    A diagram of the smart contract architecture
    A diagram of the smart contract architecture

    The system consists of the following smart contracts:

    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 1h.

    Can be upgraded by: KromaAdmin

    Upgrade delay: No delay

    The OptimismPortal contract is the main entry point to deposit funds from L1 to L2. It also allows to prove and finalize withdrawals. This contract stores the following tokens: ETH.

    Can be upgraded by: KromaAdmin

    Upgrade delay: No delay

    It contains configuration parameters such as the Sequencer address, the L2 gas limit and the unsafe block signer address.

    Can be upgraded by: KromaAdmin

    Upgrade delay: No delay

    The L1ERC721Bridge contract is the main entry point to deposit ERC721 tokens from L1 to L2.

    Can be upgraded by: KromaAdmin

    Upgrade delay: No delay

    The L1 Cross Domain Messenger contract sends messages from L1 to L2, and relays messages from L2 onto L1. In the event that a message sent from L1 to L2 is rejected for exceeding the L2 epoch gas limit, it can be resubmitted via this contract’s replay function.

    Can be upgraded by: KromaAdmin

    Upgrade delay: No delay

    Timelock contract behind which the ProxyAdmin is. There is a 30d delay, but it can be bypassed by the KromaAdmin without conditions.

    Contract designated as a guardian, meaning it can pause withdrawals. Managed by the SecurityCouncilAdmin.

    Can be upgraded by: KromaAdmin

    Upgrade delay: No delay

    Controls the Timelock. It is governed using a Soulbound NFT. It can bypass the Timelock delay without conditions.

    ProxyAdmin 0x665c…1edd

    Admin of the L2OutputOracle, Timelock, KromaPortal, SystemConfig, SecurityCouncil, L1CrossDomainMessenger, L1ERC721Bridge, ZKVerifier, Colosseum, L1StandardBridge, UpgradeGovernor, SecurityCouncilToken, ValidatorPool proxies. It’s effectively controlled by the KromaAdmin. The proxy is behind a Timelock, but the delay can always be bypassed.

    Contract used to challenge state roots and prove fraud. The SecurityCouncil can interfere by deleting challenges and roots.

    Can be upgraded by: KromaAdmin

    Upgrade delay: No delay

    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.

    Can be upgraded by: KromaAdmin

    Upgrade delay: No delay

    ZKMerkleTrie 0x3392…610B

    Trie contract used to prove withdrawals.

    ZK verifier used to verify the last step of a fraud proof, which corresponds to a block.

    Can be upgraded by: KromaAdmin

    Upgrade delay: No delay

    Poseidon2 0xFd23…d273

    Contract used to compute hashes. It is used by the ZKMerkeTrie. The contract has been generated using the circomlibjs library.

    1. poseidon_gencontract.js - circomlibjs source code

    Value Locked 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.

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