# Introduction An introduction to Cero solution for decentralized sequencing. Cero is a highly configurable decentralized consensus system which brings both technical & socio-economic security to rollup and app-chain networks. Cero targets following in its current form, * **Economic Stability**: Cero encourages participation of Rollup operators on its shared sequencing services thereby providing, * Additional revenue stream: In form of sequencing block rewards accross entire ecosystems of rollups. * Diversified yields: Allowing accuring of the transaction fee reveue across multiple tokens present in the ecosystem reduces the voltality of the token values as compared having your entire revenue on single token. We also continue to identify more ways of generating economic growth for rollups. * **MEV Exploitation Protection**: Blockchain networks by nature are susceptible to exploitation due to inidividual nodes performing transaction ordering. This is even more risky in case of lesser decentralized or centralized validator set or sequencers. * Cero provides true decentralization for the sequencers to mitigate the risk. * Mempool privacy or encryption is another feature that helps prevents against attacks like front-running or sandwhich attacks. * **Censorship & Single Point Failures**: True decentralization is more than just high availability. It is one where no single party can censor user's transactions or bring down entire system. Especially for rollups which rely on centralized sequencers, the risk of being cheated remains a focus for Cero. * **Configurability & Modularity**: While the effective number of rollups generating value remain limited in the world, its important to extend to all the ecosystems equally while covering the operators personalized preferences. Cero is designed to provide framework to multiple preferences, * Multiple Settlement Layers: The rollup contracts can rely upon Cero contracts present on there preferred L1. This is how Cero intends to unify multiple ecosystems that are being developed independently as of now. * Multiple DA Support: While working with many of the industry grade solutions, we realized that more often than not rollups have a strong preference of how they want their data to be managed. Hence, we offer an extensible layer for providing preference of data availability networks. We in fact are looking to bring personalized preferences to many other aspects as well. ### What Else? We are also excited to announce that we are looking to working in providing the following set of features, * **Extensibility**: Adding more preferences of DA & L1 options to capture more ecosystem's value. * **Composability**: We would soon enter the era of using any chain to perform any action on another. Shared sequencing is the only way to make this happen. * **Dedicated performance**: Blockchain trillema hits hard when decentralizing and we all know it. Calling for dedicated performance is yet possible with dedicated performance with the power of multi-ledger sequencing network! * **Good MEV capitalization**: On our mission to make rollups more economically viable, we are working with the best of our partners to extract more revenue using proven good MEV practices. # Why Cero? As blockspace on Ethereum and other blockchain network remains expensive and slow to aquire. App-chains & Rollups have become the promising way of how one can achieve promises of decentralization. Yet the problems that a chain, especially rollups face is still difficult enough to get the adoption going. * **Economic viability** for underlying infrastructure(especially in case of ZK proof based systems), on-chain costs(in case of rollups or interop solutions). * **Censorship of transactions**: A centralized sequencer or a small validator set can easily choose to censor some transactions by dropping them from their mempool or not adding them there in the first place. * **MEV exploitation**: To maximize the extortion out of any specific application, a validator or centralized sequencer may choose to order the transactions in a manner that allows exploitations to take place with activities such as sandwich attack or frontrunning. * **Single-point failures**: A simple failure in a centralized sequencer can lead to a complete halt in the entire blockchain, whether intentional or unintentional, leading to substantial loss of business and funds. * **Composability**: The block production taking place independently across chains leads to leads to failure in composability within the ecosystem which is almost impossible to solve in fragmented chains. Rollups working on centralized sequencers have high risk on above points, while validator based side chains struggle with the same as the consensus is yet not decentralized enough. While the solutions to work on above challenges exist, there are many constrainsts that have proven themselves as challenges. Evidence to this is that very few, even in top rollups running today are actually decentralized. * **Design drawbacks** - Lack of decentralization in the architecture, unproven complex economic structures and tradeoffs in scalability. * **Configurability & modularity restrictions** - The rollups of today are quite specific on their preferences in choice of their settlement layer, DA layer, interoperability interfaces, and also various configurations of batch sizes and timely finalization. * **Lack of support from Rollup stacks** - Not being able to integrate directly into the stacks with a standard interface has made the world of modular blockchains very difficult to adopt. * **Lack of readiness** - We have only a handful of networks using decentralized sequencing, due to the slow advancement in the technology. * **Targeted adoption** - Much of the sequencing solutions are only targeted towards a specific audience of rollups looking to solve a very specific problem. Rollups in enterprise domain, privacy oriented rollups and L3s and many more implementations are left out. * **Performance bottlenecks** - Decentralized attempts of sequencing networks have come at the big cost of performance. Based on our experience as described above, we are deduce that a universal transaction ordering layer which is built in mutiple dimensions simutaneously with the backing of our amazing partners would lead us to build a strong solution to the problem that has existed for long. # MEV - Good & Bad MEV stands for maximal extractlable value. #### Good MEV vs Bad MEV In the intricate landscape of blockchain networks, understanding the dichotomy between "Good MEV" and "Bad MEV" is crucial for both developers and users aiming to navigate these environments effectively. * **Good MEV**: Good MEV represents activities that contribute positively to the blockchain ecosystem, potentially benefiting all participants. A classic example of good MEV is arbitrage, where traders capitalize on price inefficiencies across different exchanges. This activity not only allows traders to profit but also serves the broader ecosystem by ensuring price consistency and reducing volatility across platforms. Another example might include actions that help with efficient transaction ordering, which can optimize block space usage and improve the overall throughput of the network. * **Bad MEV**: In stark contrast, bad MEV involves manipulative practices that can compromise user experience and trust. Bad MEV is often associated with exploitative strategies such as front-running, where a miner or validator exploits their position to insert a transaction ahead of the original transaction in the blockchain sequence, resulting in increased costs or missed opportunities for the original transaction. Other forms of bad MEV include sandwich attacks, where a malicious actor places transactions around a user's transaction to manipulate the price for profit, leading to financial losses for unsuspecting users. The delineation between good and bad MEV is not only academic but also practical, as it informs the design of mitigation strategies. Efforts to curb bad MEV focus on increasing transparency, implementing fair transaction ordering algorithms, and introducing decentralized MEV protection solutions. Conversely, encouraging good MEV involves fostering market mechanisms that enhance efficiency and stability without detrimentally impacting users. Recognizing and addressing these aspects of MEV is vital for developing sustainable and user-friendly blockchain ecosystems, thereby preserving their decentralized ideals while fostering trust among participants. You can read more about MEV strategies [here](https://cero.network/blog/the-dark-side-of-mev-extraction-exploitation-is-your-blockchain-at-risk/). ### MEV Exploitation Impact #### Key Statistics: * **Annual MEV Loss**: It is estimated that blockchain networks lose over $1 billion annually due to Miner Extractable Value (MEV) exploitation. * **Transaction Impact**: Approximately 1-5% of total transactions on Ethereum are affected by MEV-related activities, leading to significant user fund losses. * **Gas Fee Escalation**: MEV exploitation contributes to an increase in gas fees by up to 20%, particularly during high-traffic periods. * **User Loss**: On average, individual users can lose between 0.5% to 3% of their transaction value due to MEV extraction practices. These numbers underscore the importance of MEV protection measures, such as those offered by Cero, to safeguard the financial interests of users on blockchain networks. # Economics Design Deriving the economics of Cero powered chains ## Overview In this section we dive into the understanding the economic model offered by Cero for Rollups/AppChains. To connect the dots better, we have structured the following sections to explain the traditional business models of Rollups first and then the one offered by Cero in order to compare the between both. # Traditional Business Model of Rollups ## Overview Rollups, initially designed to be off-chain computation were developed to only extend existing public networks like Ethereum. They have lately transformed into a lot more than just an extension of Ethereum, developing their own identity. This is majorly due to the innovation in modular blockchain landscape. However, due to their starting point they naturally adopted a business model resembling that of Web2 applications given that they esentially were just off-chain compute. ### Revenue Flow The revenue of the Rollup operator in this case would come from the fees accumlated from the transactions on top of the Rollup itself. This is very similar to how validators gain a size of their revenue form transaction fees as well, however in this case the fees goes only to single sequencer which is owned by the Rollup operator. The revenue could be on the native token of the underlying chain, usually Ethereum or a custom token which is usally issued on the L1 chain itself. ### Expense Flow The expenses of a typical rollups can be understood as following recurring costs, * Network Infrastucture - Basically the cost to host, monitor, manage & operate the infrastructure. This cost can vary from rollup to rollup based on factors like - (a) type of rollup - optimisitc or ZK, (b) settlement times or withdrawl time * L1 costs - Pushing the required details like batch hashes, state root hashes, exit roots, execution proofs and more, to the L1 contracts for settlment costs in the L1 gas fees. * DA costs - Pushing the transaction data to the DA of choice to making it available in a decentralized fashion. ### So How Does It Hold? Based on the above defined revenue model and expenses, a Rollup can become profitable only at a certain transaction volume where its break even would exist. Below this break even point, it is not feasible to sustain the rollup. It is important to note that the break even itself would would vary on a number of factors such as:- L1 gas price, L1 token rate, L2 gas price, L2 token rate & transaction volumes on L2. #### Benefits * The design gives a simple and straight forward model of clear revenue and expenses to any business application which is much closer to Web2 based business models. * It allows to add more utility to the custom token as the blockspace can be charged with help of this custom token. #### Cons * **Unpredictable Expenses**: While in a typical business the expenses scale increase alongside the volume of good exchanged, the voltality of gas price and the token price on L1(ETH) is a big factor. A Rollup may have same or even lesser transcation volumes on top of it, yet it may be 3 or even 4 times more expensive when gas price on the network misbehaves while L1 token's price itself is also very volatile. * **Volatile Revenue**: The transaction volumes on the networks can be more or less, contributing to volatility. But perhaps even more importantly, reliance of revenue accumalationg all on one token, whose rate itself can be very volatile can be damaging to business. * **Lack of Revenue Streams**: There is only one primary revenue stream which is the transaction fee. While rollups are free to create additional business models to sustain the business, this still remains the primary revenue channel. For private rollups or non-user facing Rollups, they don't even have the above described revenue stream which limits the adoption only to public use cases. # Cero-charged Business Model for Rollups ## Motivation The Cero ecosystem allows Rollups & App-chains from various other ecosystems to particpate under the umbrella of shared sequencing. For example, OpStack Superchains, Polygon CDK chains, Arbitrum Orbits, ZkSync Elastic Chains & perhaps Avalanche L1s jointly would use the same sequencing services to form a larger connected ecosystem. Apart from some other benefits like composability, it is interesting to observe some behaviours of how economies of scale can have an impact in this 'Super Ecosystem' of chains. For easier references ahead we'll refer to this Super Ecosystem as **Super-system**. We'll propose more based on this a little later in this section. To design a viable economical structure we list certain objectives based on the pain points described [here ](/concepts/economics-design/traditional-business-model-of-rollups#cons)which should be targetted by this Super-system, * **No Cost Overheads** - Rollups struggle to justify their base costs, which includes their L1 gas costs, DA costs, machine costs(especially in ZK rollup), and also other operational & mangerial costs. Similarly side chains struggle to justify their machine infrastructure costs as well. Hence, while the rollups/app-chains would want to benefit from a decentralized(or more decentralized) transaction ordering system like Cero, they should not experience any additional cost overheads which are not balanced by additional revenue. * **Strong Sequencers Incentive** - A network dedicated for sequencing needs to gather enough incentives that makes it worthwhile for the system to be healthily operational; i.e. (a) always serving sequencing functions, (b) although the fairness doesn't need rely upon economically disincentivising misbehaviour among sequencers, it is still important. * **Democratizing Revenue, Not Diminshing It** - With decentralized sequencing, the transaction fee could be imagined to go towards the distributed sequencers. This would result in diminishing of revenue for Rollup operators. We don't want to cut down existing revenue amounts. * **Add Additional Revenue Streams** - The business model of most rollups as described [here ](/concepts/economics-design/traditional-business-model-of-rollups#overview)relies upon the native token(ETH or custom token) based transaction fee only. We would ideally want to add more channels to the revenue in exchange to service that the Rollup operator can extend to other Rollups as well. * **Stabalize Revenue** - As described in the traditional business model, the revenue majorly relies upon transaction volumes and the native token's market value, both of which are dangerously volatile. It is in our mind to minimise this risk, perhaps with some diversification. * **No Additional User Facing Token** - It is important that we do not increase the burden of maintaining balances in additional tokens for the end users of the Rollup. ## Cero-charged Economics Motivated by the above objectives, Cero derives Super-system's economic design that can described in following characterisitcs. * Cero defines its service model where a single Rollup can increase their participation across other Rollups across the entire Super-system by becoming a validator. Ensuring Rollup operators particpation along with external parties ensures there isn't leakage of value within the Super-system and a Rollup's sequencer can be made multi-purpose to serve other Rollups, thereby increasing the efficiency of resources. * The transaction fee would remain in native token of the Rollup where it is to be executed. The user should not require maintaining balances in additional tokens apart from the one natively supported by the target Rolllup. * A Rollup would need to subscribe to Cero's services by paying a monthly subscription fee in CERO tokens. This flat fee would be again routed to the validators, which would again be the mix of Rollups and external parties. This subscritption amount further stabalizes the circulation within the Super-system. * Regardles of who ends up sequencing the transactions, the majority of transaction fee is captured by Rollup operator still. While a small percentage of the transaction fee is shared with the other validators/sequencers. This would lead to a validator aquiring the revenue in multiple yeilds of tokens. This along with the subscription costs which remains in CERO tokens further diversifies the revenue for Rollup operators, diminishing there dependency on value of single token. The amount of tokens aquired in different yields by a Rollup, depends upon the amount of contribution to the fee pool of the entire Super-system. This also means validators which do not contribute to the fee pool, including external validators would not be benefitting from additional Rollup tokens yields. * Validators get block rewards in CERO tokens in exchange to their commitment of servicing the Super-system for sequencing, propotional to their staked amount. This also creates additional revenue opportunity for Rollup operators while further diverisifying the dependency from a single token. * There is also a point to be made in benefit to the end users which are utilising a Cero-charged Rollup, which is that it derisks loss of funds due to any bad MEV activity or censorship. * Due to the nature of aggregating transactions for DA and L1 operations, while at the same time including external parties in validator sets, the L1 & DA costs are improved for the Rollups. Above points explain how Rollups unifying to form a larger function to each other can increase their own sustainability. It should be noted however that the implementation of such a model has a large amount of complexity associated with it. Hence, we have identified to mitigate mitigate a number of risks. There are following measures taken for the same, * There is a distinction between the external validators and Rollup validators. An external validator would only benefit from block rewards and subscription fee revenue pool, while a Rollup validator would benefit from the same but also with additional yields coming in form of other tokens. * There is a careful propotion of external validators and Rollup validators that shall exist in the Super-system. This is again to incentivise and encourage the Rollup operators to create real value within the Super-system by providing them enough security and stability. * While there would be no restrictions for a Rollup to subscribe and benefit from the shared sequencing, there onboarding would be done after a curation process to become an external validator at which point the Rollup may apply for upgrading to a Rollup validator so to start benefitting from diverse yields. To upgrade to a Rollup validator another curation process would be in place to observe the token price stability and user adoption on the Rollup. It is important to note that the governing process holds the rights to reject validator onboarding & upgrades for Rollups. These are steps that the governance takes to protect the Super-system from any Rollups that may contribute to the instability or damage revenue streams. * The governance in place would be diversified to include more parties in the operational process. We imagine that Cero network would function as a fully democratic governance for the Rollups, by the Rollups and of the Rollups. We continue to identify more safeguards in our journey to improve the experience for our partners for this purpose. ## Future Scope We continue to identify additional ways of making Rollups sustainable and a few directions we are working at include the following, * Good MEV based opportunities for Defi powered Rollups. * Extending to wider ecosystems for more value capture and further adoption. * Composability which opens path ways to new modern Dapps on Super-system's Rollups. # Showdown Due to the newly introduced mechanics, it can be difficult to grasp and compare both traditional and Cero powered business models. Hence we've created the following side by side comparison to better visualise it together. | Value Accumalation By Rollups | Traditional Model | Cero-charged Model | | ----------------------------- | --------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | | Services | | | | Token Yields | | | | Revenue Streams | | | | Expenses | | | # Preconfirmations A decentralized sequencer network can enhance transaction efficiency and speed by offering preconfirmations for Rollup transactions. By distributing sequencing responsibilities among multiple validators, this network can quickly verify and prioritize transactions ordering before they are actually processed on-chain. Here's how it works:
1. **Transaction Submission**: Users submit transactions to the decentralized sequencer network instead of sending them directly to the Rollup smart contract. 2. **Preconfirmation Phase**: Validators in the sequencer network collectively verify the validity and order of the incoming transactions. 3. **Preconfirmation Issuance**: Once consensus is reached, the sequencer network issues a preconfirmation for the transaction, indicating it will be included in the next Rollup batch to be processed on-chain. 4. **Transaction Pulled by Rollup**: The Rollup, constantly subscribed to the Cero network are able to pull transactions based on the pre-confirmation and can execute it simutaneously. 5. **Finality on Rollup**: Transactions made part of the periodic batches are pushed on the DA layer and the L1 contract, where the Rollup contract can reference it for further on-chain execution. This mechanism streamlines transaction throughput, minimizes latency, and ensures reliable processing while maintaining the decentralized ethos. # Validation Rules While Cero network does not maintain the state tree of all the Rollup subscribed to it, its still important for it to validate the transactions before they are preconfirmed or added to the batches. The reasoning behind this is pretty straight, the transaction order once confirmed by the Cero chain should be absolute and Rollups cannot drop the transactions at will once confirmed by Cero chain. These checks include the following, 1. London Fork - Before London fork, only allow legacy transactions. If London fork is enabled, then allow EIP1559. 2. EIP155 - Only allow transactions with EIP155 enabled. 3. Min Gas Price Check - Only accept transactions with minimum gas price set to the Rollup's configured value. 4. Rollup's Registration Check - Ensure the transactions for sequencing are corresponding to a registered Rollup. 5. Max Gas Limit - Gas limit inside a Rollup. 6. Max Transaction Fee - Maximum transaction acceptable in a transcation. 7. Balance Checks - If an account has sufficient balance to cover for fees for the time of execution on Rollup's side. # Registering Chain To utilize the sequencing services, a Rollup needs to register themselves to the Cero network. This allows Cero network to informed about the Rollup with crucial information required for functioning. Based on this information, Cero is able to perform the required checks when transactions are provided to the network. The registered details include: 1. Chain Id 2. Rollup Type 3. Chain Name 4. Token Name 5. Token Symbol 6. DA Services 7. Rollup Owner 8. Rollup Contract Address # System Overview ## Overview Cero network abstracts operations on DA and L1 networks in such a manner that, multiple DA & L1 networks can be added as extension to the existing framework while continuing to provide existing options. This allows a shared service to multiple ecosystems at once, even if there are using different L1s, DAs, or perhaps not using them at all.

Cero Super-system Overview

Cero network relies upon the principle that a single sequencer can extend its service to the entire network in order to make most of its resources and commit continuity to the entire network. Cero public network has its own common ledger which forms on a common consensus model, while some Rollups are also free to setup Cero's dedicated network, which would just be a smaller set of nodes eith their selective participation. This flexibility has been chosen keeping in mind that many of the Rollup types, especially the private Rollups. It is important to note that we have created the Cero codebase in a modular architecture which has shaped its core framework to support multiple settlement & DA layers. While it supports only one at the moment, we will make use of the same framework to support additional settlement & DA layers as well.

Multi-settlement & Multi-DA Approach

## Integration With Rollup Stacks For a Rollup to communicate with the Cero network, following customizations are expected to be in place. * **RPC Node** - A Rollup stack's RPC component needs to integrate with Cero in order to forward transactions to the Cero network. It needs to bypass its own local or the centralized mempool of transactions and forward it to Cero's mempool instead to make the transaction forwarding and sequencing truly decentralized without any central service in between. * **Rollup's Sequencer/Executor Node** - Rollup's centralized sequencer, or better termed as executor node needs to have customizations such as - * For executing ordered transactions, it needs to strictly pick continuous transactions from Cero network based on preconfirmations, add them to its block without dispute, and execute them as well. * It is also important to customize the Rollup sequencer to start and cut its batches according to Cero's batches in perfect synchronization. * The Sequencer or its side components responsible to push data to L1 Rollup contract need to be modified as well according to the new interfaces of modeifed contract as described below. * **Smart-contract Customizations** - Rollup's contracts would also require customizations so to integrate with the Cero sequence contract. They no longer would receive the batch number and cut off from the Rollup sequencer, instead whenever information is pushed regarding batch like state root, L1 info tree, exit tree, etc. it should all be pushed against a specific batch number while the Rollup contract shall reference the Cero sequence contract instead for knowing the actual batch. For a clear view of the data flow between the components, please look at [data flow information](/architecture/data-flow) and for more on smart contracts please look at [L1 contracts](/architecture/l1-contracts) section. # Data Flow For a more detailed view of how a transaction invokes a whole stream of operations in the system, please refer to the diagram below.

Cero Data Flow

It is important to note that in above diagram while submitting a transaction, a user can submit through an RPC node of the Rollup which would be integrated with the RPC of Cero. While, transaction after committed to the Cero ledger can be picked up by the Rollup's Sequencer instead for processing the transaction while adding to the Rollup's block. # L1 Contracts Cero provides settlement of transactions onto L1 by grouping them together into batches. These batches belonging to different Rollups are clubbed into sequences which is then pushed onto the specific L1 in intervals by the chosen sequencers. Submitted sequence of batches can be later referred by the Rollup contracts for the on-chain execution that needs to follow. Cero employs a number of L1 contracts for settlements of the batches of transactions in a verifiable manner. These contracts are as follows, 1. Ownership Contract: Used for declaring the owner account. 2. AdminManager: To store and declare Admin and Manager accounts for ACL. 3. CeroSharedSequence: To manage all the function used in the sequencing based function. 4. ValidatorFacet: To manage validator based address. Have validator based CRUD operations. 5. EmergencyManager: To manage an emergency state based on per unique rollup id. Has functions like Activate and Deactivate. 6. RollupManagerFacet: Is used for rollup management based CRUD operations. 7. DiamondLoupeFacet: To manage the delete, update, add function for facets. # Sequencer's Design # RPC API References Cero exposes following APIs for Rollup's integration & telemetry purposes. # Lotus Testnet On 14th Feburary 2025, as part of Cero's first alpha Tesnet launch, Lotus has been released for first look at the project. The network was launched with all the essentials of the decentralized shared sequencing and marks the completion of the first milestone of the project. | Component / Detail | Info | | ------------------- | ----------------------------------------------------------------------------------------------------------------------------- | | Telemetry Dashboard | | | Explorer | | | L1s Supported | Ethereum Holesky | | DA Supported | Celestia | | L1 Smart Contract | [0x0C2a910d45716EEC50AE7AA6632F0dd0b48d8CD2](https://holesky.etherscan.io/address/0x0C2a910d45716EEC50AE7AA6632F0dd0b48d8CD2) | | DA Blobs Namespace | | {% hint style="info" %} Note: Please mind that this an alpha Testnet and shouldn't be used for production purposes as it is expected to be refreshed some time in the future. {% endhint %}