Starknet

Central Starknet rollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign rollup. contract. For every state updateA mechanism that allows to update the claimed state of a project. It usually involves verifying a state transition proof, but it can also be done in a trusted manner by a permissioned actor. it derives a SHARP fact from the state-transition output and either the Starknet OS or aggregator program hashA fixed-length fingerprint of variable-size input, produced by a hash function., checks that fact through the configured SHARP call proxy, and requires the output’s OS-config hash to match. It also processes L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. <-> L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. messages and stores the finalized L2 state.

• Roles:
  • admin: DelayedExecutor, Starkware Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.; ultimately Starkware Multisig 1
  • operators: EOA 4, Starkware SCMinority Multisig

Immutable Solidity verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. for one Cairo CPU layout. It checks the STARKShort for "scalable transparent argument of knowledge", a STARK is a type of zero-knowledge proof that resolves one of the primary weaknesses of ZK-SNARKs, its reliance on a "trusted setup”. STARKs also come with much simpler cryptographic assumptions, avoiding the need for elliptic curves, pairings, and the knowledge-of-exponent assumption and instead relying purely on hashes and information theory. This means that they are secure even against attackers with quantum computers. proof using layout-specific constraint, OODS, Merkle, FRIA proximity test method that is used to determine whether a set of points is mostly on a polynomial with a degree less than a specified value. It resembles the FFT but the arithmetic complexity of its prover is strictly linear and that of the verifier is strictly logarithmic., and periodic-column helper contracts. The SHARP verifier can select any configured layout by cairoVerifierId.

Immutable Solidity verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. for one Cairo CPU layout. It checks the STARKShort for "scalable transparent argument of knowledge", a STARK is a type of zero-knowledge proof that resolves one of the primary weaknesses of ZK-SNARKs, its reliance on a "trusted setup”. STARKs also come with much simpler cryptographic assumptions, avoiding the need for elliptic curves, pairings, and the knowledge-of-exponent assumption and instead relying purely on hashes and information theory. This means that they are secure even against attackers with quantum computers. proof using layout-specific constraint, OODS, Merkle, FRIA proximity test method that is used to determine whether a set of points is mostly on a polynomial with a degree less than a specified value. It resembles the FFT but the arithmetic complexity of its prover is strictly linear and that of the verifier is strictly logarithmic., and periodic-column helper contracts. The SHARP verifier can select any configured layout by cairoVerifierId.

Stores the complete compiled Cairo outer bootloader used as the top-level program of a SHARP proof. The SHARP verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. copies these words into public memory, pinning this exact executable onchain independently of the separately committed simple, applicative, and recursive-verifier programs.

Immutable Solidity verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. for one Cairo CPU layout. It checks the STARKShort for "scalable transparent argument of knowledge", a STARK is a type of zero-knowledge proof that resolves one of the primary weaknesses of ZK-SNARKs, its reliance on a "trusted setup”. STARKs also come with much simpler cryptographic assumptions, avoiding the need for elliptic curves, pairings, and the knowledge-of-exponent assumption and instead relying purely on hashes and information theory. This means that they are secure even against attackers with quantum computers. proof using layout-specific constraint, OODS, Merkle, FRIA proximity test method that is used to determine whether a set of points is mostly on a polynomial with a degree less than a specified value. It resembles the FFT but the arithmetic complexity of its prover is strictly linear and that of the verifier is strictly logarithmic., and periodic-column helper contracts. The SHARP verifier can select any configured layout by cairoVerifierId.

Immutable Solidity verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. for one Cairo CPU layout. It checks the STARKShort for "scalable transparent argument of knowledge", a STARK is a type of zero-knowledge proof that resolves one of the primary weaknesses of ZK-SNARKs, its reliance on a "trusted setup”. STARKs also come with much simpler cryptographic assumptions, avoiding the need for elliptic curves, pairings, and the knowledge-of-exponent assumption and instead relying purely on hashes and information theory. This means that they are secure even against attackers with quantum computers. proof using layout-specific constraint, OODS, Merkle, FRIA proximity test method that is used to determine whether a set of points is mostly on a polynomial with a degree less than a specified value. It resembles the FFT but the arithmetic complexity of its prover is strictly linear and that of the verifier is strictly logarithmic., and periodic-column helper contracts. The SHARP verifier can select any configured layout by cairoVerifierId.

PermissionlessAnyone willing should be able to join and leave the network at any time, without causing significant disturbance to the network or being detrimental to the party in question. No single entity should have the power to allowlist or blocklist participants. commitment calculator and registry used by the Solidity STARKShort for "scalable transparent argument of knowledge", a STARK is a type of zero-knowledge proof that resolves one of the primary weaknesses of ZK-SNARKs, its reliance on a "trusted setup”. STARKs also come with much simpler cryptographic assumptions, avoiding the need for elliptic curves, pairings, and the knowledge-of-exponent assumption and instead relying purely on hashes and information theory. This means that they are secure even against attackers with quantum computers. verifiers. Anyone may submit a public-memory page and interaction elements; the contract computes its hashA fixed-length fingerprint of variable-size input, produced by a hash function. and cumulative product and registers the fact key committing to them, which the CPU verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. 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 livenessLiveness refers to the ability of a system to respond to requests and to process them in a timely manner. In the context of L2s, it refers to the ability of settling transactions, proofs and state roots to the base layer. failure instead.

Upgradeable call router through which Starknet and other applications access SHARP fact registries. It uses call, not delegatecall, so facts and immutable verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. 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

Immutable GPS statement verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. shared by Starknet and other StarkWare systems. It verifies a STARKShort for "scalable transparent argument of knowledge", a STARK is a type of zero-knowledge proof that resolves one of the primary weaknesses of ZK-SNARKs, its reliance on a "trusted setup”. STARKs also come with much simpler cryptographic assumptions, avoiding the need for elliptic curves, pairings, and the knowledge-of-exponent assumption and instead relying purely on hashes and information theory. This means that they are secure even against attackers with quantum computers. 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.

Immutable GPS statement verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. shared by Starknet and other StarkWare systems. It verifies a STARKShort for "scalable transparent argument of knowledge", a STARK is a type of zero-knowledge proof that resolves one of the primary weaknesses of ZK-SNARKs, its reliance on a "trusted setup”. STARKs also come with much simpler cryptographic assumptions, avoiding the need for elliptic curves, pairings, and the knowledge-of-exponent assumption and instead relying purely on hashes and information theory. This means that they are secure even against attackers with quantum computers. 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.

Immutable Solidity verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. for one Cairo CPU layout. It checks the STARKShort for "scalable transparent argument of knowledge", a STARK is a type of zero-knowledge proof that resolves one of the primary weaknesses of ZK-SNARKs, its reliance on a "trusted setup”. STARKs also come with much simpler cryptographic assumptions, avoiding the need for elliptic curves, pairings, and the knowledge-of-exponent assumption and instead relying purely on hashes and information theory. This means that they are secure even against attackers with quantum computers. proof using layout-specific constraint, OODS, Merkle, FRIA proximity test method that is used to determine whether a set of points is mostly on a polynomial with a degree less than a specified value. It resembles the FFT but the arithmetic complexity of its prover is strictly linear and that of the verifier is strictly logarithmic., and periodic-column helper contracts. The SHARP verifier can select any configured layout by cairoVerifierId.

Immutable Solidity verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. for one Cairo CPU layout. It checks the STARKShort for "scalable transparent argument of knowledge", a STARK is a type of zero-knowledge proof that resolves one of the primary weaknesses of ZK-SNARKs, its reliance on a "trusted setup”. STARKs also come with much simpler cryptographic assumptions, avoiding the need for elliptic curves, pairings, and the knowledge-of-exponent assumption and instead relying purely on hashes and information theory. This means that they are secure even against attackers with quantum computers. proof using layout-specific constraint, OODS, Merkle, FRIA proximity test method that is used to determine whether a set of points is mostly on a polynomial with a degree less than a specified value. It resembles the FFT but the arithmetic complexity of its prover is strictly linear and that of the verifier is strictly logarithmic., and periodic-column helper contracts. The SHARP verifier can select any configured layout by cairoVerifierId.

Immutable GPS statement verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. shared by Starknet and other StarkWare systems. It verifies a STARKShort for "scalable transparent argument of knowledge", a STARK is a type of zero-knowledge proof that resolves one of the primary weaknesses of ZK-SNARKs, its reliance on a "trusted setup”. STARKs also come with much simpler cryptographic assumptions, avoiding the need for elliptic curves, pairings, and the knowledge-of-exponent assumption and instead relying purely on hashes and information theory. This means that they are secure even against attackers with quantum computers. 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.

Immutable Solidity verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. for one Cairo CPU layout. It checks the STARKShort for "scalable transparent argument of knowledge", a STARK is a type of zero-knowledge proof that resolves one of the primary weaknesses of ZK-SNARKs, its reliance on a "trusted setup”. STARKs also come with much simpler cryptographic assumptions, avoiding the need for elliptic curves, pairings, and the knowledge-of-exponent assumption and instead relying purely on hashes and information theory. This means that they are secure even against attackers with quantum computers. proof using layout-specific constraint, OODS, Merkle, FRIA proximity test method that is used to determine whether a set of points is mostly on a polynomial with a degree less than a specified value. It resembles the FFT but the arithmetic complexity of its prover is strictly linear and that of the verifier is strictly logarithmic., and periodic-column helper contracts. The SHARP verifier can select any configured layout by cairoVerifierId.

PermissionlessAnyone willing should be able to join and leave the network at any time, without causing significant disturbance to the network or being detrimental to the party in question. No single entity should have the power to allowlist or blocklist participants. commitment calculator and registry used by the Solidity STARKShort for "scalable transparent argument of knowledge", a STARK is a type of zero-knowledge proof that resolves one of the primary weaknesses of ZK-SNARKs, its reliance on a "trusted setup”. STARKs also come with much simpler cryptographic assumptions, avoiding the need for elliptic curves, pairings, and the knowledge-of-exponent assumption and instead relying purely on hashes and information theory. This means that they are secure even against attackers with quantum computers. verifiers. Anyone may submit a public-memory page and interaction elements; the contract computes its hashA fixed-length fingerprint of variable-size input, produced by a hash function. and cumulative product and registers the fact key committing to them, which the CPU verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. 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 livenessLiveness refers to the ability of a system to respond to requests and to process them in a timely manner. In the context of L2s, it refers to the ability of settling transactions, proofs and state roots to the base layer. failure instead.

Immutable GPS statement verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. shared by Starknet and other StarkWare systems. It verifies a STARKShort for "scalable transparent argument of knowledge", a STARK is a type of zero-knowledge proof that resolves one of the primary weaknesses of ZK-SNARKs, its reliance on a "trusted setup”. STARKs also come with much simpler cryptographic assumptions, avoiding the need for elliptic curves, pairings, and the knowledge-of-exponent assumption and instead relying purely on hashes and information theory. This means that they are secure even against attackers with quantum computers. 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.

Immutable Solidity verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. for one Cairo CPU layout. It checks the STARKShort for "scalable transparent argument of knowledge", a STARK is a type of zero-knowledge proof that resolves one of the primary weaknesses of ZK-SNARKs, its reliance on a "trusted setup”. STARKs also come with much simpler cryptographic assumptions, avoiding the need for elliptic curves, pairings, and the knowledge-of-exponent assumption and instead relying purely on hashes and information theory. This means that they are secure even against attackers with quantum computers. proof using layout-specific constraint, OODS, Merkle, FRIA proximity test method that is used to determine whether a set of points is mostly on a polynomial with a degree less than a specified value. It resembles the FFT but the arithmetic complexity of its prover is strictly linear and that of the verifier is strictly logarithmic., and periodic-column helper contracts. The SHARP verifier can select any configured layout by cairoVerifierId.

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

• Roles:
  • owner: Starkware Multisig 1

Standard Starkware canonical bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. escrow for ETH. Withdrawals can be throttled to 5% of the locked funds per 24 hours.

• Roles:
  • admin: DelayedExecutor, Starkware Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.; ultimately Starkware Multisig 1
  • govAdmin: Starkware Security Council
  • secAdmin: Starkware SCMinority Multisig
  • secAgent: EOA 5, Starkware Multisig 4; ultimately EOA 1, EOA 2, EOA 3

Custom (and immutable) entry point contract and escrow for users depositing LORDS to via StarkGate to the L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups..

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

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, EOA 3

Standard Starkware bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a 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

Gateway contract that is the user entrypoint to deposit DAI to a custom escrow to bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. via StarkGate.

Standard Starkware bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a 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, EOA 3

Standard Starkware bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a 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

Standard Starkware bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. escrow (single token). Withdrawals can be throttled to 5% of the locked funds per 24 hours.

• Roles:
  • admin: DelayedExecutor, Starkware Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.; ultimately Starkware Multisig 1
  • govAdmin: Starkware Security Council
  • secAdmin: Starkware SCMinority Multisig
  • secAgent: EOA 5, Starkware Multisig 4; ultimately EOA 1, EOA 2, EOA 3

Standard Starkware bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a 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

Standard Starkware bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a 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

Standard Starkware bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a 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

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, EOA 3

Standard Starkware bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a 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, EOA 3

Standard Starkware bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a 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

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

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

• Roles:
  • admin: EOA 7
  • govAdmin: EOA 7
  • secAdmin: EOA 7

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 6
  • govAdmin: EOA 6
  • secAdmin: EOA 6

Standard Starkware bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. escrow (single token). Withdrawals can be throttled to 5% of the locked funds per 24 hours.

• Roles:
  • admin: EOA 6
  • govAdmin: Starkware Multisig 2
  • secAdmin: Starkware Multisig 2