Devnet Genesis: Enabling Revenue Sharing Discussion

Dec 3, 2025 by Alex Johnson 52 views

This article delves into the technical discussion surrounding the implementation of revenue sharing on a Devnet Genesis within the Ethereum Optimism ecosystem. This initiative aims to explore and test the functionalities of revenue sharing on a non-CGT (Cost of Goods Sold Tax) chain, given the current incompatibility between these features. The primary goal is to meticulously examine the chain state concerning revenue sharing contracts, execute fee disbursements, and ensure the entire process operates as intended. This article is for developers who want to understand about Revenue Sharing Enabled On Genesis.

Scope of Revenue Sharing on Genesis

In this Revenue Sharing genesis, the main focus lies on activating revenue sharing on a chain that doesn't utilize CGT (Cost of Goods Sold Tax) mechanisms. This is because the current iterations of revenue sharing features are not yet compatible with CGT chains. The core objective is to thoroughly validate the chain's state in relation to revenue sharing contracts. This involves performing disbursements of fees and rigorously verifying that all components function correctly. By focusing on a non-CGT chain, developers can isolate and fine-tune the revenue-sharing mechanics without the complexities introduced by CGT.

The tests involved check the chain state on the revenue sharing related contracts, then perform some disbursement of the fees and check that everything works as expected. This includes setting up and checking the addresses for chainFeesRecipient and shareRecipient, enabling the useRevenueShare setting, and ensuring sufficient ETH is available in the dev account. This meticulous approach to testing and validation is crucial for the successful implementation of revenue sharing in the Ethereum Optimism ecosystem. By identifying and addressing potential issues early on, developers can ensure a smoother transition to full-scale deployment.

Acceptance Tests for Revenue Sharing on Genesis

To ensure the successful implementation of revenue sharing on the Devnet Genesis, a series of rigorous acceptance tests are crucial. These tests are designed to validate various aspects of the revenue-sharing mechanism, from the initial chain state to the final disbursement of fees. Here’s a breakdown of the key tests:

Chain State Verification: The initial step involves a comprehensive check of the chain state immediately after genesis. This includes verifying the correct setup and configuration of revenue-sharing related contracts. As detailed in this GitHub pull request, efforts are underway to decouple specific checks from integration tests. This decoupling allows for a more granular examination of the chain's state post-genesis, ensuring that all parameters are correctly initialized. The process is essential for establishing a solid foundation for subsequent revenue-sharing activities.
Low-Threshold Disbursement: This test involves executing a disbursement of fees with an amount lower than the predefined threshold. The purpose is to confirm that the disbursement mechanism functions correctly without triggering a withdrawal. Given that the current withdrawal window is set to one day, this test allows for verification of the disbursement process under normal operational conditions. It ensures that the system can handle small transactions effectively and accurately.
Threshold-Triggered Withdrawal: The third test is designed to evaluate the system's ability to handle larger disbursements that meet or exceed the withdrawal threshold. This test involves executing a disbursement that triggers a withdrawal to Layer 1 (L1). Simultaneously, the withdrawal should initiate a deposit, transferring the fees to the designated FeesDepositor target address on Layer 2 (L2). This end-to-end test confirms the seamless transfer of fees across layers and validates the interaction between different components of the revenue-sharing system. This ensures that the revenue sharing mechanism is not only functional but also robust and reliable.

Key Configurations for Revenue Sharing

Configuring the revenue-sharing mechanism correctly is paramount for its successful operation. Several key parameters need to be set accurately to ensure the seamless flow of fees and the proper functioning of the system. Here are the essential configurations required:

Chain Fees Recipient: An arbitrary address must be designated as the chainFeesRecipient. This address will serve as the recipient of the chain's fees and can be an Externally Owned Account (EOA), a multisignature wallet, or any other suitable account. The choice of recipient depends on the governance and operational structure of the chain. Ensuring this address is correctly set is crucial for directing fees to the appropriate destination.
Share Recipient (FeesDepositor): The shareRecipient address needs to be configured, which corresponds to the FeesDepositor address. This address is responsible for depositing the shared fees. The FeesDepositor has a proxy address at 0xed9B99a703BaD32AC96FDdc313c0652e379251Fd and an implementation address at 0x8b9e4dd2487501d98198e736b92de7a357b0b7e4. The implementation address is essential if persistence is required. This configuration ensures that the shared fees are correctly deposited and managed within the system. Proper setup of the FeesDepositor address is vital for the integrity of the revenue-sharing mechanism.
Use Revenue Share Setting: The useRevenueShare setting must be set to true. This activation is the fundamental switch that enables the revenue-sharing functionality within the system. Without setting this parameter to true, the revenue-sharing mechanism will remain inactive, and fees will not be distributed as intended. Ensuring this setting is correctly configured is a prerequisite for the entire revenue sharing process to function.

Design Documents, Specifications, and FMAs for Revenue Sharing

Comprehensive documentation is essential for understanding the design, specifications, and Functional Mock-ups (FMAs) of the revenue-sharing mechanism. These documents provide a detailed overview of the system's architecture, functionality, and performance. Here are key resources that offer insights into the design and implementation of revenue sharing:

Design Documents: The design documents offer a high-level overview of the revenue-sharing system. They outline the architectural choices, the rationale behind design decisions, and the overall structure of the system. For instance, this pull request on the Ethereum Optimism design documents provides valuable information on the design considerations for revenue sharing. These documents are crucial for understanding the conceptual framework of the system and how different components interact.
Specifications: The specifications provide a detailed technical description of the revenue-sharing mechanism. They define the interfaces, data structures, and algorithms used in the system. The specifications ensure that all developers and stakeholders have a clear understanding of the technical requirements and expectations. For example, this pull request on the specifications offers in-depth technical details on the revenue-sharing implementation. These specifications are vital for ensuring consistency and interoperability across different parts of the system.

Dev Account with Sufficient ETH

To facilitate testing and development of the revenue-sharing mechanism, a development account with a substantial amount of Ether (ETH) is necessary. Ideally, the account should hold around 50 ETH to cover the various transactions and operations required for testing. This includes deploying contracts, executing disbursements, and triggering withdrawals. Having a well-funded development account ensures that developers can thoroughly test the system without being constrained by insufficient funds. This enables a more robust and reliable implementation of the revenue sharing functionality.

Conclusion

The successful implementation of revenue sharing on the Devnet Genesis is a significant step towards enhancing the Ethereum Optimism ecosystem. By meticulously testing and validating the revenue-sharing mechanism, developers can ensure its reliability and effectiveness. The configurations, acceptance tests, and documentation outlined in this discussion provide a comprehensive framework for understanding and deploying revenue sharing. This proactive approach to development and testing will pave the way for a more sustainable and equitable distribution of fees within the network.

For further reading on Ethereum Optimism and revenue sharing, you can visit the official Ethereum Optimism website.