Hi everyone,
We have been using OpenZeppelin libraries from the beginning, but now we are requested to implement Diamond Storage Pattern (EIP-2535) to extend standard storage limitations in Solidity.
The idea sounds good for me, but I’m curious about why this approach has never been considered in the OpenZeppelin ecosystem.
Am I missing something? Is there any concern I should take into account? I’m not very fan of refactoring previously audited contracts.
Thanks too much
I've done an implementation.
I'm currently working on an upgrade to the latest version. This will probably take me another month to complete at least.
You might also be interested in my Diamonds node modulle.
https://github.com/GeniusVentures/diamonds.
It is still in active beta but it is very close to being released officially. It is meant to significantly reduce the complexity that we have run into over the last several years. It is very flexible and designed to be extensible.
Hey Alexander,
I want to make it clear that we as OpenZeppelin haven't worked on an official implementation for Diamond Proxies, nor do we currently support or recommend it. The rationale can be found here: Github Issue discussion, and our stance remains unchanged — secure tooling for safe Diamond upgrades is a prerequisite, and it's not part of our roadmap yet.
While we appreciate and welcome community contributions, I must clarify that the shared implementation above is a separate project, not affiliated with or reviewed by OpenZeppelin.
For unofficial forks and packages like this, it would be helpful to clearly indicate in the repository that they are not officially endorsed, to prevent confusion among community members.
Many thanks.