Search for projects by name
Starknet is a general purpose ZK Rollup based on STARKs and the Cairo VM.
Starknet is a general purpose ZK Rollup based on STARKs and the Cairo VM.
2024 May 16 — 2025 May 16
2024 May 16 — 2025 May 15
The section shows the operating costs that L2s pay to Ethereum.
2024 May 16 — 2025 May 15
Stage 1
2025 May 15th
Starknet is now Stage 1 by introducing a Security Council, upgrade delays and censorship resistance.
Users can submit transactions to an L1 map, but can’t force them. When users “complain” that their transaction is stuck on L1 and not picked up by the sequencer, the Security Council minority can bypass the sequencer by posting a state root that includes it.
STARKs are zero knowledge proofs that ensure state correctness.
All of the data (SD = state diffs) needed for proof construction is published onchain.
Standard upgrades are initiated on L1 and go through a 8d delay. In case users are censored, the Security Council minority can be alerted to enforce censorship resistance by submitting a new state root. This process is assumed to take 1d.
Only the whitelisted proposer can update state roots on L1, so in the event of failure the withdrawals are frozen. The Security Council minority can be alerted to enforce censorship resistance because they are a permissioned Operator.
State diffs are publish onchain as blob or calldata on every state update. The state diffs contain information on every contact whose storage was updated, and additional information on contract deployments. From diffs full system state can be recovered. Contracts’ code is not published on L1, but can be trustlessly verified if available elsewhere.
Starknet uses stateful compression since v0.13.4.
There is no non-empty genesis state.
The data format has been updated with different versions, and the full specification can be found here.
Each update to the system 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.
Each update to the system 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.
The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system. Typically, the Operator is the hot wallet of the Starknet service submitting state updates for which proofs have been already submitted and verified.
MEV can be extracted if the operator exploits their centralized position and frontruns user transactions.
There is no general mechanism to force the sequencer to include the transaction.
Users can be censored if the operator refuses to include their transactions.
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. Note that the message request can be censored by the Sequencer.
Funds can be frozen if the operator censors withdrawal transaction.
There is no generic escape hatch mechanism as Starknet cannot be forced by users into a frozen state. Note that a freezing mechanism on L2, to be secure, requires anti-censorship protection.
The Starknet zk Rollup shares its SHARP verifier with other StarkEx and SN Stack Layer 2s. Governance of the main Starknet rollup contract and its core bridge escrows (ETHBridge, STRKBridge) is currently split between the 9/12 Security Council with instant upgrade capability and the 2/4 Starkware Multisig 2 who can upgrade with a 8d delay. The former Multisig also governs most other bridge escrows with instant upgradeability. The shared SHARP verifier used for state validation can be changed by the 2/4 SHARP Multisig with and a 8d delay, affecting all rollups like Starknet that are sharing it.
The Operator role in the Starknet contract is permissioned to update the state of the Starknet rollup by supplying valid (zk) state transition proofs. Since this role is not permissionless, Starknet implements a StarknetSCMinorityMultisig with the Operator role, which allows a 3/12 minority of the StarknetSecurityCouncil to enforce censorship resistance by including transactions that are not included by regular Operators.
All bridge escrows allow enabling a withdrawal throttle of 5% of the locked funds per 24h period. Enabling it is permissioned to a Multisig while disabling it in the core bridge escrows (STRKBridge, ETHBridge) can be done by a 3/12 minority of the Security Council.
Permissioned to regularly update the state of the L2 on L1. Each state update must have been proven via the SHARP verifier and contains state diffs for data availability.
Permissioned to manage the Operator role, finalize state and change critical parameters like the programHash, configHash, or message cancellation delay in the core contract.
Upgradable call proxy contract through which the SHARPVerifier can be called. A call proxy does not delegatecall and the storage context remains at the target contract. It allows SHARP Multisig to change the otherwise immutable verifier contract with 8d delay.
Shared Starkware SHARP verifier used collectively by Starknet and other SN stack and StarkEx projects. It receives STARK proofs from the Prover and verifies the integrity of the offchain execution including a correctly computed state root which is part of the Program Output.
Standard Starkware canonical bridge escrow for ETH. Withdrawals can be throttled to 5% of the locked funds per 24 hours. This contract stores the following tokens: ETH.
Custom (and immutable) entry point contract and escrow for users depositing LORDS to via StarkGate to the L2. This contract stores the following tokens: LORDS.
A simple registry that maps tokens to their StarkGate escrows. It also keeps a list of tokens that are blocked from being added to StarkGate.
Standard Starkware bridge escrow (single token). Withdrawals can be throttled to 5% of the locked funds per 24 hours. This contract stores the following tokens: WBTC.
Standard Starkware bridge escrow (single token). Withdrawals can be throttled to 5% of the locked funds per 24 hours. This contract stores the following tokens: FXS.
Gateway contract that is the user entrypoint to deposit DAI to a custom escrow to bridge via StarkGate.
Standard Starkware bridge escrow (single token). Withdrawals can be throttled to 5% of the locked funds per 24 hours. This contract stores the following tokens: USDT.
Standard Starkware bridge escrow (single token). Withdrawals can be throttled to 5% of the locked funds per 24 hours. This contract stores the following tokens: wstETH.
Standard Starkware bridge escrow (single token). Withdrawals can be throttled to 5% of the locked funds per 24 hours. This contract stores the following tokens: STRK.
Standard Starkware bridge escrow (single token). Withdrawals can be throttled to 5% of the locked funds per 24 hours. This contract stores the following tokens: rETH.
Standard Starkware bridge escrow (single token). Withdrawals can be throttled to 5% of the locked funds per 24 hours. This contract stores the following tokens: sfrxETH.
Standard Starkware bridge escrow (single token). Withdrawals can be throttled to 5% of the locked funds per 24 hours. This contract stores the following tokens: FRAX.
Standard Starkware bridge escrow (single token). Withdrawals can be throttled to 5% of the locked funds per 24 hours. This contract stores the following tokens: LUSD.
Starkware Multibridge escrow. Withdrawals can be throttled to 5 of the locked funds per 24 hours for each token individually. This contract stores the following tokens: EKUBO, ZEND, NSTR.
Standard Starkware bridge escrow (single token). Withdrawals can be throttled to 5% of the locked funds per 24 hours. This contract stores the following tokens: USDC.
Standard Starkware bridge escrow (single token). Withdrawals can be throttled to 5% of the locked funds per 24 hours. This contract stores the following tokens: UNI.
Simple escrow that accepts tokens and allows to configure permissioned addresses that can access the tokens. This contract stores the following tokens: DAI.
Auxiliary to the SHARPVerifier contract: Verified ‘memory fact pages’ get stored here. This is important as it registers all necessary onchain data produced by the verifier.
StarkGate bridge for EKUBO, ZEND, NSTR (and potentially other tokens listed via StarkgateManager).
DAI Vault for custom DAI Gateway managed by MakerDAO. The current bridge cap is 5.00 M DAI.
StarkGate bridge for LORDS.
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).