Starknet
Badges
About
Starknet is a general purpose ZK Rollup based on STARKs and the Cairo VM.
Badges
About
Starknet is a general purpose ZK Rollup based on STARKs and the Cairo VM.
2024 Mar 09 — 2025 Mar 09
2024 Mar 09 — 2025 Mar 08
The section shows the operating costs that L2s pay to Ethereum.
2024 Mar 09 — 2025 Mar 08
Starknet Provisions
2024 Feb 14th
Starknet begins allocating $STRK to early contributors and users.
Funds can be stolen if
Funds can be lost if
Funds can be frozen if
Users can be censored if
MEV can be extracted if
Sequencer failure
No mechanismThere is no mechanism to have transactions be included if the sequencer is down or censoring.
State validation
ZK proofs (ST)STARKs are zero knowledge proofs that ensure state correctness.
Data availability
Onchain (SD)All of the data (SD = state diffs) needed for proof construction is published onchain.
Exit window
NoneThere is no window for users to exit in case of an unwanted regular upgrade since contracts are instantly upgradable.
Proposer failure
Cannot withdrawOnly the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen.
Starknet is a Validity proofs ensure state correctness
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.
Zero knowledge STARK cryptography is used
Despite their production use zkSTARKs proof systems are still relatively new, complex and they rely on the proper implementation of the polynomial constraints used to check validity of the Execution Trace.
Funds can be lost if the proof system is implemented incorrectly.
All data required to reconstruct rollup state is published on chain
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.
EthereumStarknet doesn’t use any compression scheme.
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.
The system has a centralized operator
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.
Users can't force any transaction
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.
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. Note that the message request can be censored by the Sequencer.
Funds can be frozen if the operator censors withdrawal transaction.
Emergency exit
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 overall rollup system is currently split between a Security Council for the Starknet rollup contract and a 2 / 4 Multisig for the SHARP verifier proxy with instant upgrade capability. Other Multisigs are governing the bridge escrows or permissioned for operations (posting state updates with proofs).
The 9 / 12 StarknetSecurityCouncil can upgrade the Starknet contract, force state finalization, change central configurations and manage the Operator role. Starkgate bridge contracts can be upgraded (and configured) by the 2 / 4 StarkgateBridgeMultisig without delay, allowing the potential theft of all bridged funds.
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 potentially allows a minority of the StarknetSecurityCouncil to enforce censorship resistance by including transactions that are not included by regular Operators.
The shared SHARPVerifier contract is governed by the 2 / 4 SHARPVerifierAdminMultisig, who can upgrade it without delay, affecting state validity of all StarkEx and SN stack chains that are using it and potentially allowing this Multisig to finalize malicious state updates.
Ethereum
Roles:
Permissioned to manage the Operator role, finalize state and change critical parameters like the programHash, configHash, or message cancellation delay in the core contract.
- StarknetAdminMultisig has the role with 8d delay
Actors:
- A Multisig with 2 / 4 threshold.
- Is allowed to interact with StarkgateManager - enroll new tokens, deactivate existing ones (for deposits) or block tokens from being added to the Multibridge.
- Is allowed to interact with StarkgateManager, WBTCBridge, FXSBridge, USDTBridge, wstETHBridge, STRKBridge, rETHBridge, sfrxETHBridge, FRAXBridge, LUSDBridge, MultiBridge, USDCBridge, UNIBridge - manage critical access control roles and the role that can upgrade the implementation.
- Is allowed to interact with StarkgateRegistry - manage critical access control roles and the role that can upgrade the implementation.
- Is allowed to interact with WBTCBridge, FXSBridge, ETHBridge, USDTBridge, wstETHBridge, STRKBridge, rETHBridge, sfrxETHBridge, FRAXBridge, LUSDBridge, MultiBridge, USDCBridge, UNIBridge - disable the withdrawal limit.
- Is allowed to interact with WBTCBridge, FXSBridge, ETHBridge, USDTBridge, wstETHBridge, STRKBridge, rETHBridge, sfrxETHBridge, FRAXBridge, LUSDBridge, MultiBridge, USDCBridge, UNIBridge - enable the withdrawal limit.
- Is allowed to interact with ETHBridge - manage critical access control roles related to upgrades and set the proxy governor that can upgrade the implementation.
- Can upgrade the implementation of StarkgateManager, StarkgateRegistry, FXSBridge, sfrxETHBridge, FRAXBridge, MultiBridge, UNIBridge.
- Can upgrade the implementation of WBTCBridge, ETHBridge, USDTBridge, wstETHBridge, STRKBridge, rETHBridge, USDCBridge with 3d delay.
- A Multisig with 9 / 12 threshold.
- A Governor.
- Can upgrade the implementation of Starknet.
- A Multisig with 2 / 6 threshold.
- Can act on behalf of DelayedExecutor with 8d delay.
- A Governor - acting via DelayedExecutor with 8d delay.
- Can upgrade the implementation of Starknet - acting via DelayedExecutor with 8d delay.
- A Multisig with 3 / 12 threshold.
- An Operator.
- A Multisig with 2 / 4 threshold.
- Can upgrade the implementation of SHARPVerifierCallProxy.
Used in:
- Acts as a central contract to manage StarkGate bridge escrows (add new ones, deactivate existing, change configs) when given the Manager role from the respective escrows.
- Is allowed to interact with MultiBridge - enroll new tokens or deactivate deposits into the escrow (for each token individually).
A Multisig with 1 / 3 threshold.
Ethereum
Upgradable contract through which the SHARPVerifier can be called. This allows SHARPVerifierAdminMultisig to change the otherwise immutable verifier contract with 0s delay.
Proxy used in:
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.
Implementation used in:
- A simple Timelock contract with an immutable delay of 8d. The owner (StarknetAdminMultisig) can queue transactions.
- Can act as a Governor.
- Can be used to upgrade implementation of Starknet.
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.
Implementation used in:
Value Secured is calculated based on these smart contracts and tokens:
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).