Ethereum core developers are actively testing a critical part of the protocol’s future: validator custody. As the network evolves to support more flexible validator operations, the custody model that determines what data validators must retain is under close examination.
Fusaka Devnet 2 will be testing all validator custody features in a live environment.
What are 0x02 Credentials?
The testing process starts by registering validators with 0x02 credentials, a newer format that offers greater flexibility compared to the legacy 0x00 credentials. These validators are manually funded with 32 ETH deposits, simulating real-world staking scenarios while giving developers full control over the test conditions.
To verify the behavior of validator custody under these conditions, the environment uses tools like Assertoor and Kurtosis. Assertoor checks whether the CGC increases appropriately with each deposit. At the same time, Kurtosis provides a scalable platform for deploying and managing validator simulations, allowing detailed monitoring of custody behavior across different clients.
Together, these tools give developers deep visibility into how custody responsibilities scale with the number of validators and the size of their stakes. The aim is to confirm that custody logic works not only in theory but also under practical, varied conditions.
Fixing Custody Sync Issues
One important challenge being addressed in this phase is the issue of custody tracking during node restarts or software upgrades. In earlier versions, nodes that started from a finalized checkpoint did not have a clear understanding of when their custody duties began, leading to potential inconsistencies.
To solve this, a recent pull request (#4374) introduced Status v2, which adds a new field called earliest_available_slot. This allows a node to declare the first slot for which it has custody data, making custody boundaries explicit and preventing desynchronization. It ensures that even if a validator joins mid-way or restarts, it knows exactly what data it is responsible for serving.
Static vs Dynamic Custody
In the traditional static model, a validator’s custody duties are fixed at the time of registration. While easy to implement, this model cannot adapt to changing validator behavior, such as fluctuations in stake or validator exit.
In contrast, dynamic custody adjusts a validator’s responsibilities in real time based on their active balance and participation. While it introduces additional complexity, it also allows Ethereum to scale more effectively and respond to the real-world demands of staking pools, validator rotations, and liquid staking solutions.
Validator custody has direct consequences for Ethereum’s scalability, security, and operational flexibility. These early tests in Fusaka Devnet 2 mark a significant step in ensuring that the network is ready for the next phase of Ethereum.
If you find any issues in this blog or notice any missing information, please feel free to reach out at yash@etherworld.co for clarifications or updates.
Related Articles
- Ethereum Fusaka Devnet 0 Coming Soon
- Will Fusaka Be Ready in Time? Vitalik's 2025 Vision
- Glamsterdam: The Next Upgrade After Fusaka
- Ethereum Developers are Rethinking Transaction Signatures & Authority
- Censorship Resistance Vs Scalability
Disclaimer: The information contained in this website is for general informational purposes only. The content provided on this website, including articles, blog posts, opinions, and analysis related to blockchain technology and cryptocurrencies, is not intended as financial or investment advice. The website and its content should not be relied upon for making financial decisions. Read full disclaimer and privacy Policy.
For Press Releases, project updates and guest posts publishing with us, email to contact@etherworld.co.
Subscribe to EtherWorld YouTube channel for ELI5 content.
Share if you like the content. Donate at avarch.eth.
You've something to share with the blockchain community, join us on Discord!