Search
Search for projects by name or address
L2.Finance-zk
Critical contracts can be upgraded by an EOA which could result in the loss of all funds.
Badges
About
Celer's Layer2.finance in ZK proofs Mode Built with StarkEx from StarkWare.
About
Celer's Layer2.finance in ZK proofs Mode Built with StarkEx from StarkWare.
Funds can be stolen if
Funds can be lost if
Users can be censored if
MEV can be extracted if
Users can force the sequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs. to include a transaction by submitting a request through 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.. If the sequencer censors or is down for , users can use the exit hatch to withdraw their funds.
STARKs are zero knowledge proofs that ensure state correctness.
Proof construction relies fully on data that is NOT published onchain. There exists a Data Availability Committee (DAC)A set of members whose task is attesting and ensuring that the data is available for the public. An onchain DAC verifier checks that a threshold of signatures from the DAC members is reached before considering a data commitment as available and therefore valid to be used in the system. that is tasked with protecting and supplying the data.
There is no window for users to exit in case of an unwanted upgrade since contracts are instantly upgradable.
Users are able to trustlessly exit by submitting a Merkle proof of funds.
Data is not stored on chain
The balances of the users are not published onchain, but rather sent to external trusted parties, also known as committee members. A 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. is valid and accepted onchain only if at least a quorum of the committee members sign a state update.
Funds can be lost if the external data becomes unavailable (CRITICAL).
Users can be censored if the committee restricts their access to the external data.
Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract. The system state is represented using Merkle roots.
Past upgrades
The metrics include upgrades on the currently used proxy contracts. Historical proxy contracts and changes of such are not included.
2025 July 14, 12:45 UTC7changesDiscovery rerun on the same block number with only config-related changes.
Discovery rerun on the same block number with only config-related changes.
New and verified contracts
| + | Status: CREATED |
| contract OrderRegistry (0x518c4A79a1102eEDc987005CA8cE6B87Ca14dDf8) | |
| +++ description: Helper contract for registering limit orders from L1. | |
| + | Status: CREATED |
| contract StrategyCompound (0x5b000954F70B0410685193B0afd3074B744B5C97) | |
| +++ description: None | |
| + | Status: CREATED |
| contract GpsFactRegistryAdapter (0x6e3AbCE72A3CD5edc05E59283c733Fd4bF8B3baE) | |
| +++ description: Adapter between the core contract and the eth:0x47312450B3Ac8b5b8e247a6bB6d523e7605bDb60. Stores the Cairo programHash (`3485280386001712778192330279103973322645241679001461923469191557000342180556`). | |
| + | Status: CREATED |
| contract StarkExchange (0x82123571C8a5e0910280C066bc634c4945FFcbC8) | |
| +++ description: Central Validium contract. Receives (verified) state roots from the Operator, 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. | |
| + | Status: CREATED |
| contract Compound Token (0xc00e94Cb662C3520282E6f5717214004A7f26888) | |
| +++ description: None | |
| + | Status: CREATED |
| contract Broker (0xe7c753895d492f8D4B06a2A1B16c1aEF2A7d16E5) | |
| +++ description: None | |
| + | Status: CREATED |
| contract Committee (0xF000A3B10e1920aDC6e7D829828e3357Fc5128A9) | |
| +++ description: None | |
2024 December 04, 14:14 UTC2changesDiscovery rerun on the same block number with only config-related changes.
Discovery rerun on the same block number with only config-related changes.
New and verified contracts
| + | Status: CREATED |
| contract StrategyCompound (0x5b000954F70B0410685193B0afd3074B744B5C97) | |
| +++ description: None | |
| + | Status: CREATED |
| contract Comp (0xc00e94Cb662C3520282E6f5717214004A7f26888) | |
| +++ description: None | |
The system has a centralized operator
The operatorAn operator is the entity charged with managing a rollup and progressing its state. A rollup operator can be a centralized sequencer, proposer, prover, challenger, pauser of admin that is able to perform upgrades. is the only entity that can propose blocksAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over.. A live and trustworthy operator is vital to the health of the system. Typically, the Operator is the hot wallet of the StarkEx 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 force exit the system
Force exit allows the users to escape censorship by withdrawing their funds. The system allows users to force the withdrawal of funds by submitting a request directly to the contract onchain. The request must be served within a defined time period. If this does not happen, the system will halt regular operation and permit trustless withdrawal of funds.
Users can be censored if the operator refuses to include their transactions. However, there exists a mechanism to independently exit the system.
Regular exit
The user initiates the withdrawal by submitting a regular transaction on this chain. When the blockAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over. containing that transaction is settled the funds become available for withdrawal on 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.. ZK proofs are required to settle blocks. Finally the user submits an L1 transaction to claim the funds.
Forced exit
If the user experiences censorship from the operatorAn operator is the entity charged with managing a rollup and progressing its state. A rollup operator can be a centralized sequencer, proposer, prover, challenger, pauser of admin that is able to perform upgrades. with regular exit they can submit their withdrawal requests directly on 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.. The system is then obliged to service this request. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular exit.
Emergency exit
If the enough time deadline passes and the forced exit is still ignored the user can put the system into a frozen state, disallowing further state updates. In that case everybody can withdraw by submitting a merkle proof of their funds with their 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. transaction.
Ethereum
Actors:
Can upgrade implementation of the system, potentially gaining access to all funds stored in the 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.. Currently there is no delay before the upgrade, so the users will not have time to migrate.
There exists a Data AvailabilityThe property of a rollup's data being reachable by any node retrieving the data that were rolled up and executed to reach the proposed state. Data availability (DA), specifically decoupling it from the rollup nodes themselves, is one of the preeminent factors which allows a rollup to scale securely. A rollup is faced with a decision of what to use as a DA layer to guarantee that any node can retrieve this data--permissionlessly under any circumstance. For this reason, using Ethereum for DA currently provides the strongest security guarantees. If data is stored somewhere other than a permissionless L1, then the project is not a rollup, but rather a validium or an optimium. Committee with unknown members and an unverified smart contract.
Can upgrade implementation of SHARP VerifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover., potentially with code approving fraudulent state. Currently there is no delay before the upgrade, so the users will not have time to migrate.
Most Broker functionality is restricted only for the owner, it includes managing rides, setting prices or slippages, burning shares.
Most Broker functionality is restricted only for the owner, it includes managing rides, setting prices or slippages, burning shares.
Ethereum
The source code of this contract is not verified on Etherscan.
Broker manages investment strategies on 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. for tokens deposited to the system. Strategies invest in specific protocols, e.g. Compound and they escrow LP tokens as custom Wrapped tokens.
It is through this contract that groups of users interact with the Compound DeFi protocol.
CallProxy for GpsStatementVerifier.
Starkware SHARP verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. used collectively by Starknet, Sorare, ImmutableX, Apex, Myria, rhino.fi and Canvas Connect. It receives 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. proofs from the ProverAn entity that generates the cryptographic proof to convince the verifier that the statement is true. In a ZK-Rollup, the prover generates the ZK (validity) proof to submit to the verifier contract. attesting to the integrity of the Execution Trace of these Programs including correctly computed state rootA cryptographic hash succinctly representing a state using a Merkle tree. which is part of the Program Output.
Part of 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. VerifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover..
Part of 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. VerifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover..
Part of 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. VerifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover..
MemoryPageFactRegistry is one of the many contracts used by SHARP verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover.. This one is important as it registers all necessary onchain data.
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).
Funds can be stolen if the source code of unverified contracts contains malicious code (CRITICAL).