{
"dataAvailability": [
{
"name": "All data required to reconstruct rollup state is published on chain",
"description": "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.",
"risks": [],
"references": [
{
"title": "On-Chain Data - Starknet documentation",
"url": "https://docs.starknet.io/architecture/data-availability/"
}
]
}
],
"exitMechanisms": [
{
"name": "Regular messaging",
"description": "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.",
"risks": [
{
"category": "Funds can be frozen if",
"text": "the operator censors withdrawal transaction."
}
],
"references": [
{
"title": "Withdrawing is based on l2 to l1 messages - Starknet documentation",
"url": "https://book.cairo-lang.org/ch16-04-L1-L2-messaging.html#sending-messages-from-starknet-to-ethereum"
}
]
},
{
"name": "Emergency exit",
"risks": [],
"description": "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.",
"references": []
}
],
"forceTransactions": {
"name": "Users can't force any transaction",
"description": "There is no general mechanism to force the sequencer to include the transaction.",
"risks": [
{
"category": "Users can be censored if",
"text": "the operator refuses to include their transactions."
}
],
"references": [
{
"title": "Censorship resistance of Starknet - Forum Discussion",
"url": "https://community.starknet.io/t/censorship-resistance/196"
}
]
},
"operator": {
"name": "The system has a centralized operator",
"description": "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.",
"risks": [
{
"category": "MEV can be extracted if",
"text": "the operator exploits their centralized position and frontruns user transactions."
}
],
"references": []
},
"stateDerivation": {
"nodeSoftware": "The [Juno](https://github.com/NethermindEth/juno) node software can be used to reconstruct the L2 state entirely from L1. The feature has not been released yet, but can be found in this [PR](https://github.com/NethermindEth/juno/pull/1335).",
"compressionScheme": "Starknet uses [stateful compression since v0.13.4](https://docs.starknet.io/architecture/data-availability/#v0_13_4).",
"genesisState": "There is no non-empty genesis state.",
"dataFormat": "The data format has been updated with different versions, and the full specification can be found [here](https://docs.starknet.io/architecture/data-availability/)."
},
"stateValidation": {
"description": "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.",
"categories": [
{
"title": "Proven Program",
"description": "The current Starknet OS and aggregator sources are published in the [Starknet sequencer repository](https://github.com/starkware-libs/sequencer/tree/APOLLO-0.14.3-RC.11/crates/apollo_starknet_os_program/src/cairo/starkware/starknet/core), and the bootloader sources are published in [cairo-lang](https://github.com/starkware-libs/cairo-lang/tree/1c5dace6fbd1dc9d1ae2eb878dc1dd85f23512ab/src/starkware/cairo/bootloaders). The exact 1,166-felt outer bootloader stored onchain has been reproduced from [this source revision](https://github.com/starkware-libs/cairo-lang/tree/56407b69f3f19f69302a8623baa8c5f71f967eed/src/starkware/cairo/bootloaders/bootloader). However, SHARP also commits to an ordered allowlist of recursive Cairo verifier programs whose active preimages and source-to-hash mappings have not been published, so the complete proven program is not independently reproducible.",
"risks": []
},
{
"title": "Validity proofs",
"description": "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.",
"risks": [],
"references": [
{
"title": "What is Starknet",
"url": "https://starkware.co/starknet/"
}
]
}
]
},
"upgradesAndGovernance": {
"content": "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. \n\nThe 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.\n\nAll 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."
"content": "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 two distinct signer groups: the 2/6 Starkware Multisig 1, which forms the normal upgrade path by routing all actions through the DelayedExecutor timelock with a 8d onchain delay, and the 9/12 Security Council, which can upgrade instantly and is intended for emergencies only. The delay window on the normal path gives the community time to observe queued actions and allows the Security Council to counteract a malicious action with its instant rights. The 2/4 Starkware Multisig 2 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. \n\nThe 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.\n\nAll 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.",
"governanceInfo": {
"securityCouncil": {
"Composition": "**9/12** onchain Safe multisig — 12 members, geographically and organizationally diverse (<50% from one country, <4 from one organization). The Starknet Foundation appoints and can administratively remove members. No fixed term length and no live tokenholder election mechanism.",
"Members public": "**Not mapped**, SNIP-25 and Foundation announcements publish only composition criteria (technical reputation, KYC/AML, diversity limits, conflict-of-interest rules).",
"Charter": "[SNIP-25](https://github.com/starknet-io/SNIPs/blob/main/SNIPS/snip-25.md) defines duties (security-only mandate), vetting-failure reports, eligibility and the code of conduct.",
"Can bypass DAO?": "**Yes** — 9/12 can approve and execute an emergency upgrade immediately. The same instant rights let it counteract a malicious action queued in the DelayedExecutor during its 8d window.",
"DAO can override SC?": "**No**, the community can only dispute the emergency upgrades after the fact in advisory way."
},
"upgrades": {
"Major upgrade path": "Release announcement (≥1 SNIP + specific GitHub commit) → 2-week community deliberation → 1-week final review → 1-week STRK vote on the [Governance Hub on L2](https://governance.starknet.io/) → Security Council vetting → deployment queued in the DelayedExecutor by the 2/6 Starkware Multisig 1, whose 8d onchain delay covers the procedural ≥7-day freeze → execution. Minimum wall-clock ≈ **5 weeks** (8d onchain-enforced if executed via DelayedExecutor).",
"Minor upgrade path": "Announcement (SNIP may be submitted in parallel) → 1-week review → 1-week STRK vote on L2 → deployment queued in the DelayedExecutor, whose 8d onchain delay covers the procedural ≥5-day freeze → execution. No Security Council approval required. Minimum wall-clock ≈ **22 days** (8d onchain-enforced if executed via DelayedExecutor).",
"Emergency upgrade path": "**9/12 Security Council, instant**.",
"Exit window": "**8d** enforced onchain by the DelayedExecutor on the normal upgrade path (procedurally ≥7 days after the vote for major releases, ≥5 days for minor). **0** for emergency upgrades by the Security Council."
},
"tokenGovernance": {
"Governance token": "`STRK` — ~10.15B total supply, not permanently capped. Users can vote with L1 STRK, natively staked STRK or L2 vSTRK tokens, each gives 1 vote. In 2025 the Starknet Foundation [delegated ~1.7B STRK](https://www.starknet.io/blog/starknet-foundation-delegation-program/) to ~180 ecosystem delegates.",
"Voting venue": "[Starknet Governance Hub](https://governance.starknet.io/) using Snapshot X — proposals, space configuration and results are recorded and verified on Starknet, with relayed gasless signed votes.",
"Proposal threshold": "**None**, but proposal admission is curated, not triggered permissionlessly by an onchain token threshold.",
"Quorum": "**No protocol-wide quorum rule published.** Historical votes used a simple majority with no minimum quorum.",
"Execution model": "**Vote as onchain record, permissioned deployment** — passed proposals are queued in the DelayedExecutor by the 2/6 Starkware Multisig 1 and execute after 8d."
}
}
}
}
zksync2+29-1
scalingTechnology+29-1
{
"architectureImage": "zkstack-rollup",
"dataAvailability": [
{
"name": "All data required for proofs is published on chain",
"description": "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.",
"risks": [],
"references": []
}
],
"exitMechanisms": [
{
"name": "Regular messaging",
"description": "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.",
"risks": [],
"references": [
{
"title": "Withdrawing funds - ZKsync documentation",
"url": "https://docs.zksync.io/zksync-protocol/rollup/bridging-assets"
}
]
},
{
"name": "Forced messaging",
"description": "If the user experiences censorship from the operator with regular L2->L1 messaging they can submit their messages directly on L1. The system is then obliged to service this request or halt all messages from L1, including all forced withdrawals and deposits. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
"risks": [],
"references": []
}
],
"forceTransactions": {
"name": "Users can force any transaction via L1",
"description": "If a user is censored by the L2 Sequencer, they can try to force their transaction via an L1 queue. Right now there is no mechanism that forces L2 Sequencer to include transactions from the queue in an L2 block. The operator can implement a TransactionFilterer that censors forced transactions.",
"risks": [
{
"category": "Users can be censored if",
"text": "the operator refuses to include their transactions."
},
{
"category": "Users can be censored if",
"text": "the operator implements a TransactionFilterer, which is possible without delay."
}
],
"references": [
{
"title": "L1 - L2 interoperability - Developer's documentation",
"url": "https://docs.zksync.io/zksync-protocol/era-vm/contracts/handling-l1-l2-ops"
}
]
},
"operator": {
"name": "The system has a centralized operator",
"description": "The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.\n\nBatch execution is initiated by permissioned executor EOAs, but each batch also requires approval from the sufficient number of EraMultisigValidator members before it can be executed on L1.",
"risks": [
{
"category": "MEV can be extracted if",
"text": "the operator exploits their centralized position and frontruns user transactions."
},
{
"category": "Users can be censored if",
"text": "the validator multisig does not approve batch execution."
}
],
"references": [
{
"title": "EraMultisigValidator - Etherscan proxy contract",
"url": "https://etherscan.io/address/0xdC26B08F0335b68721F64001C38b05D0BC9B539d"
}
]
},
"stateDerivation": {
"nodeSoftware": "The node software is open-source, and its source code can be found [here](https://github.com/matter-labs/zksync-era).\n The main node software does not rely on Layer 1 (L1) to reconstruct the state, but you can use [this tool](https://github.com/eqlabs/zksync-state-reconstruct) for that purpose. Currently, there is no straightforward method to inject the state into the main node, but ZKsync is actively working on a solution for this.",
"compressionScheme": "Bytecodes undergo compression before deployment on Layer 1 (L1). You can find additional information on this process [here](https://github.com/matter-labs/zksync-era/blob/main/docs/src/guides/advanced/11_compression.md).",
"genesisState": "There have been neither genesis states nor regenesis.",
"dataFormat": "Details on data format can be found [here](https://github.com/matter-labs/zksync-era/blob/main/docs/src/guides/advanced/09_pubdata.md)."
},
"stateValidation": {
"description": "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.",
"categories": [
{
"title": "Prover Architecture",
"description": "ZKsync Era proof system Boojum can be found [here](https://github.com/matter-labs/era-boojum/tree/main) and contains essential tools like the Prover, the Verifier, and other backend components. The specs of the system can be found [here](https://github.com/matter-labs/zksync-era/tree/main/prover)."
},
{
"title": "ZK Circuits",
"description": "ZKsync Era circuits are built from Boojum and are designed to replicate the behavior of the EVM. The source code can be found [here](https://github.com/matter-labs/era-zkevm_circuits/tree/main). The circuits are checked against tests that can be found [here](https://github.com/matter-labs/era-zkevm_test_harness/tree/main).",
"risks": [
{
"category": "Funds can be lost if",
"text": "the proof system is implemented incorrectly."
}
]
},
{
"title": "Verification Keys Generation",
"description": "SNARK verification keys can be generated and checked against the Ethereum verifier contract using [this tool](https://github.com/matter-labs/zksync-era/tree/main/prover/crates/bin/vk_setup_data_generator_server_fri). The system requires a trusted setup."
}
]
},
"upgradesAndGovernance": {
"content": "There are two main paths for contract upgrades in the shared ZK stack ecosystem - standard and emergency - both converging on the shared upgrade management contract ProtocolUpgradeHandler.\nThe standard path involves a governance proposal and voting through the DAO, multiple timelock delays and finally approval by the Guardians or 4 SecurityCouncil participants.\nThe emergency path allows for contract upgrades without any delay by the EmergencyUpgradeBoard, which acts as a 3/3 Multisig between SecurityCouncil, Guardians and the FoundationMultisig.\n## Standard path\n### On ZKsync Era\nDelegates can start new proposals by reaching a threshold of 21M ZK tokens on the ZKsync Era Rollup's ZkProtocolGovernor contract.\nThis launches a 3d 'voting delay' after which the 7d voting period starts. During these first two periods, the proposal can be canceled by the proposer or if it falls below the proposing threshold.\nA proposal is only successful if it reaches both quorum (630M ZK tokens) and simple majority. When it reaches quorum, a remaining voting period of 3d is guaranteed by a potential late quorum vote extension.\nIn the successful case, it can be queued in the 0s timelock which forwards it via the Gateway to Ethereum as an L2->L1 log.\n### On Ethereum\nAfter the execution of the proposal-containing batch (3h delay), the proposal is now picked up by the ProtocolUpgradeHandler and enters the 3d 'legal veto period'.\nThis serves as a window in which a veto could be coordinated offchain, to be then enforced by non-approval of Guardians and SecurityCouncil. A threshold of 2 Guardians can extend the veto period to 7d.\nAfter this a proposal enters a *waiting* state of 1mo, from which it can be immediately approved (cancelling the delay) by 4 participants of the SecurityCouncil.\nFor the unlikely case that the Security Council does not approve here, the Guardians can instead approve the proposal, or nobody. In the two latter cases, the waiting period is enforced in full.\nA proposal cannot be actively cancelled in the ProtocolUpgradeHandler, but will expire if not approved within the waiting period. An approved proposal now enters the *pendingExecution* state for a final delay of 1d and can then be executed.\n### Other governance tracks\nThere are two other tracks of Governance also starting with DAO Delegate proposals the ZKsync Era rollup: 1) Token Program Proposals that add new minters, allocations or upgrade the ZK token and\n2) Governance Advisory Proposals that e.g. change the ZK Credo or other offchain Governance Procedures without onchain targets.\nThe protocol for these two other tracks is similar to the first part of the standard path described above (albeit having different quorum and timelock values), and not passing over to the Ethereum L1.\nFurther customizations are that the ZkFoundationMultisig can propose to the ZkTokenGovernor without a threshold and that the Guardians' L2 alias can cancel proposals in the ZkTokenGovernor and the ZkGovOpsGovernor.\n## Emergency path\nSecurityCouncil (6/8), Guardians (5/8) and ZkFoundationMultisig (3/5) form a de-facto 3/3 Multisig\nby pushing an immediate upgrade proposal through the EmergencyUpgradeBoard, which circumvents all delays and executes immediately via the ProtocolUpgradeHandler.\n## Upgrade Delays\nThe cumulative duration of the upgrade paths from the moment of a voted 'successful' proposal is 4d 3h or 8d 3h (depending on Guardians extending the LegalVetoPeriod) for Standard, 0 for Emergency and 1mo 4d for the path in which the SecurityCouncil is not approving the proposal.\n## Freezing\nThe SecurityCouncil can freeze (pause withdrawals and settlement) all chains connected to the current ChainTypeManager.\nEither for a softFreeze of 12h or a hardFreeze of 7d.\nAfter a softFreeze and / or a hardFreeze, a proposal from the EmergencyUpgradeBoard has to be passed before subsequent freezes are possible.\nOnly the SecurityCouncil can unfreeze an active freeze.\n## ZK cluster Admin and Chain Admin\nApart from the paths that can upgrade all shared implementations, the ZK stack governance system defines other roles that can modify the system:\nA single *ZK cluster Admin* role who governs parameters in the shared contracts and a *Chain Admin* role (defined in each chain-specific diamond contract) for managing parameters of each individual ZK chain that builds on the stack.\nThese chain-specific actions include critical operations like setting a transaction filterer that can censor L1 -> L2 messages, changing the DA mode, migrating the chain to a different settlement layer and standard operations like setting fee parameters and adding / removing Validators in the ValidatorTimelock.\nFor rollups, data availability on Ethereum is validated by a RollupL1DAValidator contract (or a RelayedSLDAValidator on the Gateway). Each rollup can become a permanent rollup (through their Chain Admin) which disallows DA changes to non-whitelisted sources or settlement layers in the future.\nThe source of truth for rollup-compliant DA validator contracts is the RollupDAManager contract, which is administered via the ProtocolUpgradeHandler.\nZKsync Era's Chain Admin differs from the others as it also has the above *ZK cluster Admin* role in the shared ZK stack contracts.",
"image": "zkstack"
"image": "zkstack",
"governanceInfo": {
"securityCouncil": {
"Composition": "**4/8** to approve upgrades · **3/8** soft freeze · **6/8** hard freeze, unfreeze and emergency approval. No fixed terms: members serve until replaced via Protocol Governor proposal.",
"Members public": "**Mapped** — 8 representatives of different orgs + signer addresses [published in Schedule 3](https://docs.zknation.io/zksync-governance-procedures/schedule-3-zksync-security-council).",
"Charter": "[ZKsync Governance Procedures, Schedules 2–3](https://docs.zknation.io/zksync-governance-procedures/schedule-3-zksync-security-council) + bylaws of the ZKsync Security Council entity.",
"Can bypass DAO?": "**Freeze yes, upgrade no (alone)** — can unilaterally and immideately freeze the protocol: 12h soft freeze (3/8) or 7d hard freeze (6/8). Upgrades require approvals from 5/8 Guardians and 3/5 ZK Foundation Multisig.",
"DAO can override SC?": "**Partially** — the Token Assembly can pass a Protocol Governor proposal replacing SC members, but it needs SC approval (4/8) or 5/8 Guardians as fallback. No unconditional tokenholder path."
},
"guardians": {
"Composition": "**5/8** for vetoes and approvals, no fixed terms. Addresses and names of individuals that take Guardian role are [published in Schedule 4](https://docs.zknation.io/zksync-governance-procedures/schedule-4-zksync-guardians).",
"Powers": "**Veto + fallback approval + emergency co-sign.** L1 Onchain veto (5/8) cancels Token/GovOps proposals during voting delay or vote. Offchain veto (5 signed statements to the SC Foundation) blocks Protocol proposals during the 3d legal veto period; 2/8 can extend it to 7d. 5/8 can approve a Protocol proposal in risk review if the SC won't. The Guardian multisig is 1 of 3 emergency upgrade signers. Veto justification due on the forum within 48h.",
"Self-protection": "**Yes** — Guardian membership is changed via Protocol Governor proposal, but Guardians may explicitly veto proposals affecting the Guardian body itself (Schedule 4 §5.2). Token holders have no unconditional onchain removal path."
},
"upgrades": {
"Normal upgrade path": "ZIP submission on L2 → 3d voting delay → 7d vote (late quorum +3d) → L2→L1 message to the ProtocolUpgradeHandler → 3d Guardian offchain-veto window (extendable to 7d by 2/8) → ≤1mo risk review, SC approval (4/8) short-circuits to → 1d timelock → permissionless execution on Ethereum. Fastest ≈ **14 days** from submission; Guardian-fallback path ≈ **44 days**.",
"Emergency upgrade path": "**6/8 SC + 5/8 Guardians + 3/5 ZKsync Foundation, instant**.",
"Exit window": "**~4 days** after the vote closes when the SC approves promptly (3d veto window + 1d timelock). **0** for emergency upgrades.",
"Token Program path": "Grants or modifies capped ZK minting/burning rights. TPPs via Token Governor: 3d delay → 7d vote (late quorum +2d) → 3d timelock → permissionless execution on Era, ≈ **13 days**.",
"GovOps path": "GAPs via GovOps Governor: same 3d + 7d + 3d schedule, but advisory only, implementation is left to the proposer or named parties."
},
"tokenGovernance": {
"Governance token": "`ZK` — 21.00 B maximum mintable supply, 14.82 B currently minted, 1 delegated token = 1 vote. ZK tokens need to be delegated for voting, but are not locked.",
"Voting venue": "[ZKsync Governance Portal](https://vote.zknation.io/dao) powered by Cactus (formerly Tally). Three OpenZeppelin Governors on ZKsync Era: Protocol, Token, GovOps, each with its own timelock.",
"Proposal threshold": "**21,000,000 ZK** delegated (0.1% of the 21.00 B max mintable supply), identical for all three governors.",
"Quorum": "**630,000,000 ZK** (3% of max mintable supply) for all three governors. Simple majority of For vs Against; abstentions don't count. Late-quorum extension: +3d (Protocol), +2d (Token/GovOps).",
"Execution model": "**On-chain payload · Permissionless execute.** Protocol proposals travel via L2→L1 message and are permissionlessly executed on Ethereum after review + timelock; Token proposals execute permissionlessly on Era after their timelock."
}
}
}
}