Search

Search for projects by name or address

SummaryValue SecuredActivityOnchain costsData postedLivenessMilestones & IncidentsRisk summaryRisk analysisStageData availabilityState derivationState validationUpgrades & GovernanceUpdatesOperatorWithdrawalsPermissionsSmart contracts

Starknet logo
Starknet

Badges

About

Starknet is a ZK rollup that uses STARK proofs to securely scale Ethereum and Ethereum blobs for data availability. Starknet is also actively engaged in bringing Bitcoin users the same scale, UX, and liquidity through a variety of products and programs.

  • Total Value SecuredTVS
    $397.63 M0.41%
  • Past day UOPSDaily UOPS
    4.2323.6%
  • Stage
  • Gas tokens
    ETH, STRK
  • Type
    ZK Rollup
  • Purpose
    Universal

    • Tokens breakdown

    Sequencer failureState validationData availabilityExit windowProposer failure
    Explore more in Discovery UI

    Badges

    About

    Starknet is a ZK rollup that uses STARK proofs to securely scale Ethereum and Ethereum blobs for data availability. Starknet is also actively engaged in bringing Bitcoin users the same scale, UX, and liquidity through a variety of products and programs.

    Stages changes

    25d
    13h
    41m
    21s
    The project will be downgraded to
    Stage 0
    because it does not satisfy upcoming Stage 1 requirements.

    The project will move to Stage 0 because:

    Not all program sources are public or not all program hashes can be independently regenerated.

    Learn more about the new requirements
    Value SecuredView TVS breakdown
    Total
    Canonically BridgedCanonically Bridged ValueCanonical
    Natively MintedNatively Minted TokensNative
    Externally BridgedExternally Bridged ValueExternal
    ETH & derivatives
    Stablecoins
    BTC & derivatives
    Other
    View TVS breakdown
    Activity
    Data source: Voyager API

    2025 Jul 22 — 2026 Jul 22

    Past Day UOPS
    4.2323.6%
    Past Day Ops count
    365.54 K
    Total Ops
    829.06 M
    since 2021 Nov 16
    Max. UOPS
    273.38
    2025 Oct 09
    Past day UOPS/TPS Ratio
    2.98
    Onchain costs

    The section shows the operating costs that L2s pay to Ethereum.

    2025 Jul 22 — 2026 Jul 22

    Total cost
    $48.98 K
    Avg cost per L2 UOP
    $0.000098
    Avg cost per day
    $133.83
    Data posted

    This section shows how much data the project publishes to its data-availability (DA) layer over time. The project currently posts data toEthereumEthereum.

    2025 Jul 22 — 2026 Jul 22

    Data posted
    13.05 GiB
    Avg size per day
    36.50 MiB
    Avg size per L2 UOP
    28.04 B
    Liveness

    This section shows how "live" the project's operators are by displaying how frequently they submit transactions of the selected type. It also highlights anomalies - significant deviations from their typical schedule.

    No ongoing anomalies detected

    2026 Jun 22 — Jul 23

    Avg. state updates interval
    42 minutes
    Past 30 days anomalies
    100% normal uptime
    Milestones & Incidents

    Starknet reverts 18mins of history

    2026 Jan 5th

    Starknet experienced an outage during which block production was halted.

    Learn more

    Starknet upgrades its proving system to Stwo

    2025 Oct 19th

    Starknet switches to the next-generation prover Stwo to prove its STF on Ethereum L1.

    Learn more
    Risk summary

    Funds can be stolen if

    1. a contract receives a malicious code upgrade. There is no delay on code upgrades (CRITICAL).

    Funds can be frozen if

    1. the operator censors withdrawal transaction.

    Users can be censored if

    1. the operator refuses to include their transactions.

    MEV can be extracted if

    1. the operator exploits their centralized position and frontruns user transactions.
    Risk analysis
    Sequencer failureState validationData availabilityExit windowProposer failure
    Sequencer failure
    Log via L1

    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.

    State validation
    Validity 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
    None (emergency upgrade path)
    7d (regular upgrade path)

    Non-emergency 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, leaving users 7d to exit.

    There is no window for users to exit in case of an unwanted upgrade since contracts are instantly upgradable.

    Proposer failure
    Security Council minority

    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.

    Stage
    Starknet
    Starknet is a
    Stage 1
    ZK Rollup.
    The project does not pass the walkaway test: users are not able to exit in the presence of malicious operators if the Security Council disappears.

    New requirements coming soon

    25d
    13h
    41m
    21s
    The project will be downgraded to
    Stage 0
    because it does not satisfy upcoming Stage 1 requirements.

    Not all program sources are public or not all program hashes can be independently regenerated.

    Learn more about the new requirements
    Learn more about Stages
    Please keep in mind that these stages do not reflect project security, this is an opinionated assessment of project 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.
    Data availability

    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.

    1. On-Chain Data - Starknet documentation
    Learn more about the DA layer here: Ethereum logoEthereum
    State derivation
    Node software

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

    Compression scheme

    Starknet uses stateful compression since v0.13.4.

    Genesis state

    There is no non-empty genesis state.

    Data format

    The data format has been updated with different versions, and the full specification can be found here.

    State validation

    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.

    Proven Program

    The current Starknet OS and aggregator sources are published in the Starknet sequencer repository, and the bootloader sources are published in cairo-lang. The exact 1,166-felt outer bootloader stored onchain has been reproduced from this source revision. 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.

    Validity proofs

    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.

    1. What is Starknet
    PROVER
    Stwo
    Stwo

    Trusted Setups

    Onchain verifier

    SHARPVerifier
    SHARPVerifier_2026_13_3

    Used in

    Starknet logoParadex logo

    Onchain verifier

    SHARPVerifier
    SHARPVerifier_2026_13_3

    Used in

    Starknet logoParadex logo

    Program Hashes

    Name
    Hash
    Repository
    Verification
    Used in
    200638...3432
    Github
    Starknet logo
    105025...1922
    Github
    Starknet logo
    342795...2024
    Github
    Starknet logoEdgeX logoParadex logoSorare logotanX logo

    Projects used in

    Search for projects used in

    344285...1079
    Github
    Starknet logoEdgeX logoParadex logoSorare logotanX logo

    Projects used in

    Search for projects used in

    235884...3330
    Github
    Starknet logoEdgeX logoParadex logoSorare logotanX logo

    Projects used in

    Search for projects used in

    254986...4351
    		Code unknown
    None
    Starknet logoEdgeX logoParadex logoSorare logotanX logo

    Projects used in

    Search for projects used in

    234451...4732
    		Code unknown
    None
    Starknet logoEdgeX logoParadex logoSorare logotanX logo

    Projects used in

    Search for projects used in

    The Starknet OS, aggregator, outer bootloader, supported-simple-bootloader commitment, and applicative bootloader are reproducible. Every SHARP verifier in the currently accepted fact-registry chain also pins a commitment to an ordered allowlist of recursive Cairo verifier programs. The active allowlist preimages and the programs behind them have not been reproduced, so an invalid nested-proof verifier cannot be ruled out independently.

    Upgrades & Governance
    A diagram of the upgrades and governance
    A diagram of the upgrades and governance

    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.

    Past upgrades

    The metrics include upgrades on the currently used proxy contracts. Historical proxy contracts and changes of such are not included.

    Count of upgrades
    80
    Last upgrade
    10d 10h ago
    Avg upgrade interval
    6mo 28d
    Updates
    2026 July 10, 10:17 UTC
    High severity
    11changes

    Updated Starknet OS and aggregation ZK programs, new versions verified.

    Updated Starknet OS and aggregation ZK programs, new versions verified.

    contract Starknet (eth:0xc662c410C0ECf747543f5bA90660f6ABeBD9C8c4) [starknet/Starknet] {
    +++ description: Central rollup contract. Receives (verified) state roots from the Sequencer, allows users to consume L2 -> L1 messages and send L1 -> L2 messages. Critical configuration values for the L2's logic are defined here by various governance roles.
    values.aggregatorHashMapped:
    - "2571508110958925737463010241874806654058743535666147712534445437599630018294"
    + "1050253032170513549151251823521174837478197699740478552102884446098263561922"
    values.aggregatorProgramHash:
    - "2571508110958925737463010241874806654058743535666147712534445437599630018294"
    + "1050253032170513549151251823521174837478197699740478552102884446098263561922"
    values.configHash:
    - "3188242426588271529884520804512942022765170489242162533995649881904346336763"
    + "2579130946496422157802313572919622021390761807038780433165936715591440018810"
    +++ description: The L2 programHash which is a hash of the L2 state machine logic. Liveness config MUST be changed in the .ts as soon as this is updated.
    +++ severity: HIGH
    values.programHash:
    - "2733003247060056328192560178934419513655729851806095615814023997114795707702"
    + "2006389624453304912912750132846114593020263069652857561377702883656839453432"
    values.programHashHistory.14:
    + "2733003247060056328192560178934419513655729851806095615814023997114795707702"
    values.programHashMapped:
    - "2733003247060056328192560178934419513655729851806095615814023997114795707702"
    + "2006389624453304912912750132846114593020263069652857561377702883656839453432"
    }
    2026 July 08, 09:36 UTC
    4changes

    Rotated two ms members.

    Rotated two ms members.

    contract Starkware SCMinority Multisig (eth:0xF6b0B3e8f57396CecFD788D60499DB49Ee6AbC6B) [GnosisSafe] {
    +++ description: None
    values.$members.1:
    - "eth:0x04D5b12b196a8CADEB2F476F22Ffb1334Ef9F94c"
    + "eth:0x99E84d004E73CC41eFacd382ef6FD34208B0F122"
    values.$members.2:
    - "eth:0x5C7DcaECB4D8e49Ea2487c5Cc23C5131Ddb2252F"
    + "eth:0xb731B63eC22904A17d1cf6fD771eb5BA87f35Fa3"
    }
    2026 July 06, 10:59 UTC
    8changes

    Rotated two ms members.

    Rotated two ms members.

    contract Starkware Security Council (eth:0x15e8c684FD095d4796A0c0CF678554F4c1C7C361) [GnosisSafe] {
    +++ description: None
    values.$members.3:
    - "eth:0x2914767E232FD7708ab06bA60dB16c36C555751d"
    + "eth:0x49C6396070D3310f335AE19169Da6B80ea67B831"
    values.$members.4:
    - "eth:0xfaECfa5E4180dd55D15396F804Fd00C6dbA233B0"
    + "eth:0x16117672EBF77d5DE9a1Af91F8F79b26421b310F"
    }
    contract Starkware SCMinority Multisig (eth:0xF6b0B3e8f57396CecFD788D60499DB49Ee6AbC6B) [GnosisSafe] {
    +++ description: None
    values.$members.0:
    - "eth:0x2914767E232FD7708ab06bA60dB16c36C555751d"
    + "eth:0x49C6396070D3310f335AE19169Da6B80ea67B831"
    values.$members.4:
    - "eth:0xfaECfa5E4180dd55D15396F804Fd00C6dbA233B0"
    + "eth:0x16117672EBF77d5DE9a1Af91F8F79b26421b310F"
    }
    2026 April 21, 08:57 UTC
    High severity
    22changes

    Starknet v0.14.2 upgrade: https://x.com/StarkWareLtd/status/2046232501887062448. Upgraded Rollup contract with minimal diff: https://disco.l2beat.com/diff/eth:0x2793010E6711Acd5C46ed17f2183a9d58db71e04/eth:0x9961D34D3baE6914635c882e8FE382e14E0F172A (mainly added safety checks on L1 - L2 msg hash computation). Also upgraded aggregation and starknet os programs: sources are here https://github.com/starkware-libs/sequencer/tree/c294a8ba263834d45cf525217d8700f5de24a260/crates/apollo starknet os program/src/cairo/starkware/starknet/core.

    Starknet v0.14.2 upgrade: https://x.com/StarkWareLtd/status/2046232501887062448.

    Upgraded Rollup contract with minimal diff: https://disco.l2beat.com/diff/eth:0x2793010E6711Acd5C46ed17f2183a9d58db71e04/eth:0x9961D34D3baE6914635c882e8FE382e14E0F172A (mainly added safety checks on L1 -> L2 msg hash computation).

    Also upgraded aggregation and starknet os programs: sources are here https://github.com/starkware-libs/sequencer/tree/c294a8ba263834d45cf525217d8700f5de24a260/crates/apollo_starknet_os_program/src/cairo/starkware/starknet/core.

    contract Starknet (eth:0xc662c410C0ECf747543f5bA90660f6ABeBD9C8c4) {
    +++ description: Central rollup contract. Receives (verified) state roots from the Sequencer, allows users to consume L2 -> L1 messages and send L1 -> L2 messages. Critical configuration values for the L2's logic are defined here by various governance roles.
    sourceHashes.1:
    - "0x8074e96abc7cacf654908c0111c69027cf599f3b67332f3680c5de768a2d6dfe"
    + "0x4ebd3e71fba7928b1daa4cdd93a1081aa0b578578cc8e6aada6a3b86b057fcb5"
    values.$implementation:
    - "eth:0x2793010E6711Acd5C46ed17f2183a9d58db71e04"
    + "eth:0x9961D34D3baE6914635c882e8FE382e14E0F172A"
    values.$pastUpgrades.10:
    + ["2026-04-20T11:53:35.000Z","0xb2fd817ea47d39435e0b08825964bcb0b2ae08ebc4c5a47954f9b169235ed1c1",["eth:0x9961D34D3baE6914635c882e8FE382e14E0F172A"]]
    values.$upgradeCount:
    - 10
    + 11
    values.aggregatorHashMapped:
    - "1701025211190912681772481128523426351562426117847395998223683709327746845867"
    + "2571508110958925737463010241874806654058743535666147712534445437599630018294"
    values.aggregatorProgramHash:
    - "1701025211190912681772481128523426351562426117847395998223683709327746845867"
    + "2571508110958925737463010241874806654058743535666147712534445437599630018294"
    values.identify:
    - "StarkWare_Starknet_2025_10"
    + "StarkWare_Starknet_2026_11"
    values.implementation:
    - "eth:0x2793010E6711Acd5C46ed17f2183a9d58db71e04"
    + "eth:0x9961D34D3baE6914635c882e8FE382e14E0F172A"
    +++ description: The L2 programHash which is a hash of the L2 state machine logic. Liveness config MUST be changed in the .ts as soon as this is updated.
    +++ severity: HIGH
    values.programHash:
    - "918745833886511857768061986591752808672496300091957204265383861063635175685"
    + "2733003247060056328192560178934419513655729851806095615814023997114795707702"
    values.programHashHistory.13:
    + "918745833886511857768061986591752808672496300091957204265383861063635175685"
    values.programHashMapped:
    - "918745833886511857768061986591752808672496300091957204265383861063635175685"
    + "2733003247060056328192560178934419513655729851806095615814023997114795707702"
    implementationNames.eth:0x2793010E6711Acd5C46ed17f2183a9d58db71e04:
    - "Starknet"
    implementationNames.eth:0x9961D34D3baE6914635c882e8FE382e14E0F172A:
    + "Starknet"
    }
    2026 January 27, 10:45 UTC
    4changes

    Added new EOA to be a security agent for ETH and STRK bridge (can enable withdrawal limit).

    Added new EOA to be a security agent for ETH and STRK bridge (can enable withdrawal limit).

    contract ETHBridge (eth:0xae0Ee0A63A2cE6BaeEFFE56e7714FB4EFE48D419) {
    +++ description: Standard Starkware canonical bridge escrow for ETH. Withdrawals can be throttled to 5% of the locked funds per 24 hours.
    values.accessControl.SECURITY_AGENT.members.1:
    + "eth:0x4032bE860716F6e4488CBc9f1505E26E2FA3C2c2"
    values.secAgentAC.1:
    + "eth:0x4032bE860716F6e4488CBc9f1505E26E2FA3C2c2"
    }
    contract STRKBridge (eth:0xcE5485Cfb26914C5dcE00B9BAF0580364daFC7a4) {
    +++ description: Standard Starkware bridge escrow (single token). Withdrawals can be throttled to 5% of the locked funds per 24 hours.
    values.accessControl.SECURITY_AGENT.members.1:
    + "eth:0x4032bE860716F6e4488CBc9f1505E26E2FA3C2c2"
    values.secAgentAC.1:
    + "eth:0x4032bE860716F6e4488CBc9f1505E26E2FA3C2c2"
    }
    Operator

    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.

    1. Censorship resistance of Starknet - Forum Discussion
    Withdrawals

    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.

    1. Withdrawing is based on l2 to l1 messages - Starknet documentation

    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.

    Permissions
    A dashboard to explore contracts and permissions
    Go to Disco
    Disco UI Banner
    Disco UI BannerExplore in Disco

    Ethereum

    Actors:

    Starkware Multisig 20x0152…C6Ec

    A Multisig with 2/4 threshold.

    • Can upgrade with no delay
      • StarkgateManager
      • StarkgateRegistry
      • WBTCBridge
      • FXSBridge
      • sfrxETHBridge
      • FRAXBridge
      • MultiBridge
      • UNIBridge
    • Can upgrade with 3d delay
      • USDTBridge
      • wstETHBridge
      • rETHBridge
      • USDCBridge
    • Can interact with StarkgateManager
      • enroll new tokens, deactivate existing ones (for deposits) or block tokens from being added to the Multibridge
      • manage critical access control roles related to upgrades and set the proxy governor that can upgrade the implementation
    • Can interact with StarkgateRegistry
      • manage critical access control roles and the role that can upgrade the implementation
    • Can interact with WBTCBridge
      • disable the withdrawal limit and manage the security agent role that can enable it
      • manage critical access control roles related to upgrades and set the proxy governor that can upgrade the implementation
    • Can interact with FXSBridge
      • disable the withdrawal limit and manage the security agent role that can enable it
      • manage critical access control roles related to upgrades and set the proxy governor that can upgrade the implementation
    • Can interact with USDTBridge
      • disable the withdrawal limit and manage the security agent role that can enable it
      • manage critical access control roles related to upgrades and set the proxy governor that can upgrade the implementation
    • Can interact with wstETHBridge
      • disable the withdrawal limit and manage the security agent role that can enable it
      • manage critical access control roles related to upgrades and set the proxy governor that can upgrade the implementation
    • Can interact with rETHBridge
      • disable the withdrawal limit and manage the security agent role that can enable it
      • manage critical access control roles related to upgrades and set the proxy governor that can upgrade the implementation
    • Can interact with sfrxETHBridge
      • disable the withdrawal limit and manage the security agent role that can enable it
      • manage critical access control roles related to upgrades and set the proxy governor that can upgrade the implementation
    • Can interact with FRAXBridge
      • disable the withdrawal limit and manage the security agent role that can enable it
      • manage critical access control roles related to upgrades and set the proxy governor that can upgrade the implementation
    • Can interact with LUSDBridge
      • disable the withdrawal limit and manage the security agent role that can enable it
      • manage critical access control roles related to upgrades and set the proxy governor that can upgrade the implementation
    • Can interact with MultiBridge
      • disable the withdrawal limit and manage the security agent role that can enable it
      • manage critical access control roles related to upgrades and set the proxy governor that can upgrade the implementation
    • Can interact with USDCBridge
      • disable the withdrawal limit and manage the security agent role that can enable it
      • manage critical access control roles related to upgrades and set the proxy governor that can upgrade the implementation
    • Can interact with UNIBridge
      • disable the withdrawal limit and manage the security agent role that can enable it
      • manage critical access control roles related to upgrades and set the proxy governor that can upgrade the implementation

    Participants (4):

    0xd388…d3F80x5923…85580xCe95…23a00x64F4…5770
    Starkware Security Council0x15e8…C361

    A Multisig with 9/12 threshold.

    • Can upgrade with no delay
      • ETHBridge
      • Starknet
      • STRKBridge
    • Can interact with ETHBridge
      • manage critical access control roles related to upgrades and set the proxy governor that can upgrade the implementation
    • Can interact with Starknet
      • Permissioned to manage the Operator role, finalize the application configuration, and change the OS program hash, aggregator program hash, OS-config hash, fee collector, or message cancellation delay
    • Can interact with STRKBridge
      • manage critical access control roles related to upgrades and set the proxy governor that can upgrade the implementation

    Participants (12):

    0x0762…F09c0x5C7D…252F0x04D5…F94c0x49C6…B8310x1611…310F0xF6AB…FbD80x16aB…57CD0x1027…8cac0x7383…E5600x590C…430C0x7A3a…982E0xFf71…0D90
    1. Security Council members - Starkware Governance Hub
    SHARP Multisig0x21F9…AEc4

    A Multisig with 2/4 threshold.

    • Can upgrade with 8d delay
      • SHARPVerifierCallProxy
    • Can interact with SHARPVerifierCallProxy
      • Administer the CallProxy’s GOVERNANCE_ADMIN and role-admin hierarchy. This AccessControl role is separate from the outer proxy governor that schedules implementation upgrades
      • Grant and revoke application roles, including the APP_GOVERNOR role that controls caller-specific fallback routes
      • Route fallback calls from specific callers to a still-active registry in the default verifier’s reference chain. This principally determines which verifier and bootloader configuration processes their proof submissions; the proxy’s explicit isValid entry point always queries the default target

    Participants (4):

    0x0405…84880x5923…85580xebc8…fD7F0x955B…2Fec
    Used in:
    Starkware Multisig 10x83C0…e988

    A Multisig with 2/6 threshold.

    • Can upgrade with 8d delay
      • ETHBridge
      • Starknet
      • STRKBridge
    • Can interact with Starknet
      • Permissioned to manage the Operator role, finalize the application configuration, and change the OS program hash, aggregator program hash, OS-config hash, fee collector, or message cancellation delay with 8d delay

    Participants (6):

    0xaDB2…38fc0x8e81…7Dd50x804d…C81f0x2871…B4030x64F4…57700x5923…8558
    Starkware SCMinority Multisig0xF6b0…bC6B

    A Multisig with 3/12 threshold.

    • Can interact with ETHBridge
      • disable the withdrawal limit and manage the security agent role that can enable it
    • Can interact with Starknet
      • Permissioned to regularly post L2 state updates and choose an available data-availability entry point. Under the current implementation, every update still needs a fact accepted by SHARP and cannot bypass the pinned program and config hashes
    • Can interact with STRKBridge
      • disable the withdrawal limit and manage the security agent role that can enable it

    Participants (12):

    0x49C6…B8310x99E8…F1220xb731…5Fa30x0762…F09c0x1611…310F0xF6AB…FbD80x16aB…57CD0x1027…8cac0x7383…E5600x590C…430C0x7A3a…982E0xFf71…0D90
    StarkgateManager0x0c5a…5B60

    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.

    • Can interact with MultiBridge
      • enroll new tokens or deactivate deposits into the escrow (for each token individually)
    Starkware Multisig 40x77Dd…88c5

    A Multisig with 1/3 threshold.

    Participants (3):

    EOA 10x5923…8558EOA 2
    Safe0xd6FD…2041

    A Multisig with 3/5 threshold.

    Participants (5):

    0x3236…Ce790x81a3…05010x5540…033F0x6963…9CAA0x6F8d…7969
    2 EOAs
    EOA 1EOA 2

    Member of Starkware Multisig 4.

    • Can interact with WBTCBridge
      • enable the withdrawal limit
    • Can interact with ETHBridge
      • enable the withdrawal limit
    • Can interact with USDTBridge
      • enable the withdrawal limit
    • Can interact with STRKBridge
      • enable the withdrawal limit
    • Can interact with MultiBridge
      • enable the withdrawal limit
    • Can interact with USDCBridge
      • enable the withdrawal limit
    EOA 30x2C16…0CA7
    • Can interact with Starknet
      • Permissioned to regularly post L2 state updates and choose an available data-availability entry point. Under the current implementation, every update still needs a fact accepted by SHARP and cannot bypass the pinned program and config hashes
    EOA 40x4032…C2c2
    • Can interact with ETHBridge
      • enable the withdrawal limit
    • Can interact with STRKBridge
      • enable the withdrawal limit
    EOA 50x5751…f21A
    • Can upgrade with no delay
      • SolvBTCBridge
      • LUSDBridge
    • Can interact with SolvBTCBridge
      • disable the withdrawal limit and manage the security agent role that can enable it
      • manage critical access control roles related to upgrades and set the proxy governor that can upgrade the implementation
    EOA 60xF689…e86b
    • Can upgrade with no delay
      • LBTCBridge
    • Can interact with LBTCBridge
      • disable the withdrawal limit and manage the security agent role that can enable it
      • manage critical access control roles related to upgrades and set the proxy governor that can upgrade the implementation
    Smart contracts
    A dashboard to explore contracts and permissions
    Go to Disco
    Disco UI Banner
    Disco UI BannerExplore in Disco
    A diagram of the smart contract architecture
    A diagram of the smart contract architecture

    Ethereum

    Starknet0xc662…C8c4Implementation (Upgradable)AdminAdmin

    Central Starknet rollup contract. For every state update it derives a SHARP fact from the state-transition output and either the Starknet OS or aggregator program hash, checks that fact through the configured SHARP call proxy, and requires the output’s OS-config hash to match. It also processes L1 <-> L2 messages and stores the finalized L2 state.

    • Roles:
      • admin: DelayedExecutor, Starkware Security Council; ultimately Starkware Multisig 1
      • operators: EOA 3, Starkware SCMinority Multisig
    Can be upgraded by:
    Starkware Security Council with no delayStarkware Multisig 1 with 8d delay
    Implementation used in:
    CpuVerifierAllSolidity_2026_130x0153…2CD6

    Immutable Solidity verifier for one Cairo CPU layout. It checks the STARK proof using layout-specific constraint, OODS, Merkle, FRI, and periodic-column helper contracts. The SHARP verifier can select any configured layout by cairoVerifierId.

    Implementation used in:
    CpuVerifierDex_2026_130x0cD0…5CdC

    Immutable Solidity verifier for one Cairo CPU layout. It checks the STARK proof using layout-specific constraint, OODS, Merkle, FRI, and periodic-column helper contracts. The SHARP verifier can select any configured layout by cairoVerifierId.

    Implementation used in:
    CairoBootloaderProgram0x2410…4A47

    Stores the complete compiled Cairo outer bootloader used as the top-level program of a SHARP proof. The SHARP verifier copies these words into public memory, pinning this exact executable onchain independently of the separately committed simple, applicative, and recursive-verifier programs.

    Implementation used in:
    CpuVerifierRecursive_2026_130x2867…9B6B

    Immutable Solidity verifier for one Cairo CPU layout. It checks the STARK proof using layout-specific constraint, OODS, Merkle, FRI, and periodic-column helper contracts. The SHARP verifier can select any configured layout by cairoVerifierId.

    Implementation used in:
    CpuVerifierSmall_2026_130x30F3…419b

    Immutable Solidity verifier for one Cairo CPU layout. It checks the STARK proof using layout-specific constraint, OODS, Merkle, FRI, and periodic-column helper contracts. The SHARP verifier can select any configured layout by cairoVerifierId.

    Implementation used in:
    MemoryPageFactRegistry_2023_90x4086…70fA

    Permissionless commitment calculator and registry used by the Solidity STARK verifiers. Anyone may submit a public-memory page and interaction elements; the contract computes its hash and cumulative product and registers the fact key committing to them, which the CPU verifier must bind to the proof. It is part of the proof verifier, not an application-level program registry. A malicious or nonconforming implementation can break public-memory soundness; binding to a different honest registry generally causes a liveness failure instead.

    Implementation used in:
    SHARPVerifierCallProxy0x4731…Db60Implementation (Upgradable)Admin

    Upgradeable call router through which Starknet and other applications access SHARP fact registries. It uses call, not delegatecall, so facts and immutable verifier configuration remain at each target registry. The explicit isValid entry point always queries the default target. Other calls handled by the fallback, principally proof submissions, can be routed per caller to a still-active registry in the default target’s reference chain. The default target can be replaced by SHARP Multisig after 8d.

    • Roles:
      • admin: SHARP Multisig
      • appGovernor: SHARP Multisig
      • appRoleAdmin: SHARP Multisig
      • governanceAdmin: SHARP Multisig
    Can be upgraded by:
    SHARP Multisig with 8d delay
    Proxy used in:
    SHARPVerifier0x4956…72b6

    Immutable GPS statement verifier shared by Starknet and other StarkWare systems. It verifies a STARK proof of the exact Cairo bootloader stored onchain, forces the bootloader configuration into public memory, and registers a fact for every bootloader task. A fact is also considered valid when it exists in the time-limited reference fact registry.

    Implementation used in:
    SHARPVerifier_2026_13_10x5C1C…a9fe

    Immutable GPS statement verifier shared by Starknet and other StarkWare systems. It verifies a STARK proof of the exact Cairo bootloader stored onchain, forces the bootloader configuration into public memory, and registers a fact for every bootloader task. A fact is also considered valid when it exists in the time-limited reference fact registry.

    Implementation used in:
    CpuVerifierDexWithBitwise_2026_130x6a67…3F11

    Immutable Solidity verifier for one Cairo CPU layout. It checks the STARK proof using layout-specific constraint, OODS, Merkle, FRI, and periodic-column helper contracts. The SHARP verifier can select any configured layout by cairoVerifierId.

    Implementation used in:
    CpuVerifierStarknet_2026_130x7157…A26D

    Immutable Solidity verifier for one Cairo CPU layout. It checks the STARK proof using layout-specific constraint, OODS, Merkle, FRI, and periodic-column helper contracts. The SHARP verifier can select any configured layout by cairoVerifierId.

    Implementation used in:
    SHARPVerifier_2026_13_20x7Da1…3fF7

    Immutable GPS statement verifier shared by Starknet and other StarkWare systems. It verifies a STARK proof of the exact Cairo bootloader stored onchain, forces the bootloader configuration into public memory, and registers a fact for every bootloader task. A fact is also considered valid when it exists in the time-limited reference fact registry.

    Implementation used in:
    CpuVerifierRecursiveLargeOutput_2026_130xbe0F…AEF3

    Immutable Solidity verifier for one Cairo CPU layout. It checks the STARK proof using layout-specific constraint, OODS, Merkle, FRI, and periodic-column helper contracts. The SHARP verifier can select any configured layout by cairoVerifierId.

    Implementation used in:
    MemoryPageFactRegistry0xe583…C460

    Permissionless commitment calculator and registry used by the Solidity STARK verifiers. Anyone may submit a public-memory page and interaction elements; the contract computes its hash and cumulative product and registers the fact key committing to them, which the CPU verifier must bind to the proof. It is part of the proof verifier, not an application-level program registry. A malicious or nonconforming implementation can break public-memory soundness; binding to a different honest registry generally causes a liveness failure instead.

    Implementation used in:
    SHARPVerifier_2026_13_30xE675…b406

    Immutable GPS statement verifier shared by Starknet and other StarkWare systems. It verifies a STARK proof of the exact Cairo bootloader stored onchain, forces the bootloader configuration into public memory, and registers a fact for every bootloader task. A fact is also considered valid when it exists in the time-limited reference fact registry.

    Implementation used in:
    CpuVerifierPerpetual_2026_130xFFC7…6b44

    Immutable Solidity verifier for one Cairo CPU layout. It checks the STARK proof using layout-specific constraint, OODS, Merkle, FRI, and periodic-column helper contracts. The SHARP verifier can select any configured layout by cairoVerifierId.

    Implementation used in:
    DelayedExecutor0xCA11…Ca0c

    A simple Timelock contract with an immutable delay of 8d. The owner (Starkware Multisig 1) can queue transactions.

    • Roles:
      • owner: Starkware Multisig 1
    ETHBridge
    Escrow
    0xae0E…D419Implementation (Upgradable)AdminAdmin

    Standard Starkware canonical bridge escrow for ETH. Withdrawals can be throttled to 5% of the locked funds per 24 hours.

    • Roles:
      • admin: DelayedExecutor, Starkware Security Council; ultimately Starkware Multisig 1
      • govAdmin: Starkware Security Council
      • secAdmin: Starkware SCMinority Multisig
      • secAgent: EOA 4, Starkware Multisig 4; ultimately EOA 1, EOA 2
    The following tokens are included in the value secured calculation:
    ETH token logo
    Can be upgraded by:
    Starkware Security Council with no delayStarkware Multisig 1 with 8d delay
    LORDSBridge
    Escrow
    0x023A…E5C9

    Custom (and immutable) entry point contract and escrow for users depositing LORDS to via StarkGate to the L2.

    The following tokens are included in the value secured calculation:
    LORDS token logo
    StarkgateRegistry0x1268…6812Implementation (Upgradable)Admin

    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.

    • Roles:
      • admin: Starkware Multisig 2
      • govAdmin: Starkware Multisig 2
    Can be upgraded by:
    Starkware Multisig 2 with no delay
    WBTCBridge
    Custom Escrow
    0x2837…b5b4Implementation (Upgradable)Admin

    Haltable version of the Starkware Multibridge escrow. Withdrawals can be throttled to 5% of the locked funds per 24 hours for each token individually. Deposits for a particular token can be halted by app governor, halt must be finalized in the second transaction that also sweeps all funds into a clrearing address. There is no logic to resume bridging after the halt.

    • Roles:
      • admin: Starkware Multisig 2
      • govAdmin: Starkware Multisig 2
      • secAdmin: Starkware Multisig 2
      • secAgent: Starkware Multisig 4; ultimately EOA 1, EOA 2
    The following tokens are included in the value secured calculation:
    WBTC token logo
    Can be upgraded by:
    Starkware Multisig 2 with no delay
    FXSBridge
    Custom Escrow
    0x66ba…0B7CImplementation (Upgradable)Admin

    Standard Starkware bridge escrow (single token). Withdrawals can be throttled to 5% of the locked funds per 24 hours.

    • Roles:
      • admin: Starkware Multisig 2
      • govAdmin: Starkware Multisig 2
      • secAdmin: Starkware Multisig 2
    The following tokens are included in the value secured calculation:
    FRAX token logo
    Can be upgraded by:
    Starkware Multisig 2 with no delay
    L1DaiGateway0x9F96…388d

    Gateway contract that is the user entrypoint to deposit DAI to a custom escrow to bridge via StarkGate.

    USDTBridge
    Custom Escrow
    0xbb34…7605Implementation (Upgradable)Admin

    Standard Starkware bridge escrow (single token). Withdrawals can be throttled to 5% of the locked funds per 24 hours.

    • Roles:
      • admin: Starkware Multisig 2
      • govAdmin: Starkware Multisig 2
      • secAdmin: Starkware Multisig 2
      • secAgent: Starkware Multisig 4; ultimately EOA 1, EOA 2
    The following tokens are included in the value secured calculation:
    USDT token logo
    Can be upgraded by:
    Starkware Multisig 2 with 3d delay
    wstETHBridge
    Custom Escrow
    0xBf67…985BImplementation (Upgradable)Admin

    Standard Starkware bridge escrow (single token). Withdrawals can be throttled to 5% of the locked funds per 24 hours.

    • Roles:
      • admin: Starkware Multisig 2
      • govAdmin: Starkware Multisig 2
      • secAdmin: Starkware Multisig 2
    The following tokens are included in the value secured calculation:
    wstETH token logo
    Can be upgraded by:
    Starkware Multisig 2 with 3d delay
    STRKBridge
    Escrow
    0xcE54…C7a4Implementation (Upgradable)AdminAdmin

    Standard Starkware bridge escrow (single token). Withdrawals can be throttled to 5% of the locked funds per 24 hours.

    • Roles:
      • admin: DelayedExecutor, Starkware Security Council; ultimately Starkware Multisig 1
      • govAdmin: Starkware Security Council
      • secAdmin: Starkware SCMinority Multisig
      • secAgent: EOA 4, Starkware Multisig 4; ultimately EOA 1, EOA 2
    The following tokens are included in the value secured calculation:
    STRK token logo
    Can be upgraded by:
    Starkware Security Council with no delayStarkware Multisig 1 with 8d delay
    rETHBridge
    Custom Escrow
    0xcf58…76C2Implementation (Upgradable)Admin

    Standard Starkware bridge escrow (single token). Withdrawals can be throttled to 5% of the locked funds per 24 hours.

    • Roles:
      • admin: Starkware Multisig 2
      • govAdmin: Starkware Multisig 2
      • secAdmin: Starkware Multisig 2
    The following tokens are included in the value secured calculation:
    rETH token logo
    Can be upgraded by:
    Starkware Multisig 2 with 3d delay
    sfrxETHBridge
    Custom Escrow
    0xd8E8…8Ee8Implementation (Upgradable)Admin

    Standard Starkware bridge escrow (single token). Withdrawals can be throttled to 5% of the locked funds per 24 hours.

    • Roles:
      • admin: Starkware Multisig 2
      • govAdmin: Starkware Multisig 2
      • secAdmin: Starkware Multisig 2
    The following tokens are included in the value secured calculation:
    sfrxETH token logo
    Can be upgraded by:
    Starkware Multisig 2 with no delay
    FRAXBridge
    Custom Escrow
    0xDc68…1ebbImplementation (Upgradable)Admin

    Standard Starkware bridge escrow (single token). Withdrawals can be throttled to 5% of the locked funds per 24 hours.

    • Roles:
      • admin: Starkware Multisig 2
      • govAdmin: Starkware Multisig 2
      • secAdmin: Starkware Multisig 2
    The following tokens are included in the value secured calculation:
    FRAX.legacy token logo
    Can be upgraded by:
    Starkware Multisig 2 with no delay
    MultiBridge
    Custom Escrow
    0xF5b6…69EbImplementation (Upgradable)Admin

    Starkware Multibridge escrow. Withdrawals can be throttled to 5% of the locked funds per 24 hours for each token individually.

    • Roles:
      • admin: Starkware Multisig 2
      • govAdmin: Starkware Multisig 2
      • manager: StarkgateManager
      • secAdmin: Starkware Multisig 2
      • secAgent: Starkware Multisig 4; ultimately EOA 1, EOA 2
    The following tokens are included in the value secured calculation:
    EKUBO token logoZEND token logoNSTR token logo
    Can be upgraded by:
    Starkware Multisig 2 with no delay
    USDCBridge
    Escrow
    0xF608…2816Implementation (Upgradable)Admin

    Standard Starkware bridge escrow (single token). Withdrawals can be throttled to 5% of the locked funds per 24 hours.

    • Roles:
      • admin: Starkware Multisig 2
      • govAdmin: Starkware Multisig 2
      • secAdmin: Starkware Multisig 2
      • secAgent: Starkware Multisig 4; ultimately EOA 1, EOA 2
    The following tokens are included in the value secured calculation:
    Can be upgraded by:
    Starkware Multisig 2 with 3d delay
    UNIBridge
    Custom Escrow
    0xf76e…236BImplementation (Upgradable)Admin

    Standard Starkware bridge escrow (single token). Withdrawals can be throttled to 5% of the locked funds per 24 hours.

    • Roles:
      • admin: Starkware Multisig 2
      • govAdmin: Starkware Multisig 2
      • secAdmin: Starkware Multisig 2
    The following tokens are included in the value secured calculation:
    UNI token logo
    Can be upgraded by:
    Starkware Multisig 2 with no delay
    DAIBridge
    Escrow
    0x0437…585C

    Simple escrow that accepts tokens and allows to configure permissioned addresses that can access the tokens.

    The following tokens are included in the value secured calculation:
    DAI token logo
    LBTCBridge
    Escrow
    0x96C8…685eImplementation (Upgradable)Admin

    Starkware Multibridge escrow. Withdrawals can be throttled to 5% of the locked funds per 24 hours for each token individually.

    • Roles:
      • admin: EOA 6
      • govAdmin: EOA 6
      • secAdmin: EOA 6
    The following tokens are included in the value secured calculation:
    LBTC token logo
    Can be upgraded by:
    EOA 6 with no delay
    SolvBTCBridge
    Escrow
    0xA86b…Ab10Implementation (Upgradable)Admin

    Haltable version of the Starkware Multibridge escrow. Withdrawals can be throttled to 5% of the locked funds per 24 hours for each token individually. Deposits for a particular token can be halted by app governor, halt must be finalized in the second transaction that also sweeps all funds into a clrearing address. There is no logic to resume bridging after the halt.

    • Roles:
      • admin: EOA 5
      • govAdmin: EOA 5
      • secAdmin: EOA 5
    The following tokens are included in the value secured calculation:
    SolvBTC token logo
    Can be upgraded by:
    EOA 5 with no delay
    LUSDBridge
    Custom Escrow
    0xF3F6…3DF5Implementation (Upgradable)Admin

    Standard Starkware bridge escrow (single token). Withdrawals can be throttled to 5% of the locked funds per 24 hours.

    • Roles:
      • admin: EOA 5
      • govAdmin: Starkware Multisig 2
      • secAdmin: Starkware Multisig 2
    The following tokens are included in the value secured calculation:
    LUSD token logo
    Can be upgraded by:
    EOA 5 with no delay
    CairoBootloaderProgram_2022_70x5d07…9dDf
    Implementation used in:
    MemoryPageFactRegistry_2022_70xFD14…D1b4
    Implementation used in:

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

    Program Hashes

    Name
    Hash
    Repository
    Verification
    Used in
    200638...3432
    Github
    Starknet logo
    105025...1922
    Github
    Starknet logo
    342795...2024
    Github
    Starknet logoEdgeX logoParadex logoSorare logotanX logo

    Projects used in

    Search for projects used in

    344285...1079
    Github
    Starknet logoEdgeX logoParadex logoSorare logotanX logo

    Projects used in

    Search for projects used in

    235884...3330
    Github
    Starknet logoEdgeX logoParadex logoSorare logotanX logo

    Projects used in

    Search for projects used in

    254986...4351
    		Code unknown
    None
    Starknet logoEdgeX logoParadex logoSorare logotanX logo

    Projects used in

    Search for projects used in

    234451...4732
    		Code unknown
    None
    Starknet logoEdgeX logoParadex logoSorare logotanX logo

    Projects used in

    Search for projects used in

    The Starknet OS, aggregator, outer bootloader, supported-simple-bootloader commitment, and applicative bootloader are reproducible. Every SHARP verifier in the currently accepted fact-registry chain also pins a commitment to an ordered allowlist of recursive Cairo verifier programs. The active allowlist preimages and the programs behind them have not been reproduced, so an invalid nested-proof verifier cannot be ruled out independently.