Which use cases might lend themselves to one implementation versus the other?

2 Answers 2


I'm currently building out a suite of contracts using the EIP-2535 standard. After doing extensive reading on both, for my needs EIP-2535 is superior.

Code organization is much cleaner - You are able to write smaller specialized contracts that can be implemented as facets to one main contract. I find this coupled with a good naming convention makes parsing through, and finding the function/group of functions you want to work on much easier.

Individual function upgradability - with the "diamond cut" function you can upgrade the functionality of a single function, or group of functions without having to redeploy the entirety of a logic contract. Additionally you can Add or Remove individual functions from a proxy using the same "diamond cut" function. This may rank on different levels of importance for some but for my use case it is a huge benefit.

No 24KB contract size limit - For me, this is the main selling point of EIP-2535. Since your contract functionality can be split up in to individual facets, it stands to reason that you are able to add as many facets as you need to have your contract include as much functionality that is necessary for your use case. I was really struggling with balancing number or features vs staying under the 24kb limit, and EIP-2535 completely eliminated that issue.

That's just my two cents based on my needs. Hope it helps!

  • Did you find any cases which would be better served by openzeppelin's proxy upgradeable standard? Commented Dec 22, 2022 at 5:58
  • 1
    I find EIP-2535 to really be an extension of the OZ proxy standard. Depending on the number of facets, deployment costs would obviously be slightly higher for EIP-2535, so with that said i think for smaller scoped contracts using OZ proxy would make sense, but for larger more complicated contracts, EIP-2535 provide additional features to nicely accommodate.
    – saltorious
    Commented Dec 22, 2022 at 18:15

Sometimes you need it, sometimes you don't. Even in the same project. Keep in mind that the diamond, while sporting quite a list of excellent features, does bring with it some complexity. As devs, we should only take on complexity when needed.

At Boson Protocol, for example, we built the V2 version of the protocol itself as a diamond. But our redeemable voucher NFT, which communicates with the diamond, is just a customized OZ ERC-721, accessed via a beacon proxy. The voucher NFT functionality was deemed unlikely to ever need to extend beyond the 24k contract size limit. And putting the OZ contracts behind the diamond was not an option, since the storage is incompatible with the diamond storage pattern.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.