I’ve been exploring Compose, and their Diamond Contracts really impressed me.
Most smart contracts are just one giant block of code.
Adding features or upgrading them quickly becomes messy.
Compose takes a different approach
It breaks contracts into facets.
Each facet handles a specific job.
The diamond connects them into a single system.
The address stays the same.
The storage stays the same.
Only the logic you update changes.
This means you can add, replace, or remove features without redeploying everything.
For projects that evolve over time, this makes a big difference.
Compose also offers a standard library of facets that you can mix and match.
Or you can write your own facets and plug them.
Because each facet is small and focused, the entire contract stays organized, readable, and reusable.
This makes debugging simpler, keeps upgrades clean, and ensures it works for both upgradeable and immutable systems.
Diamond Contracts aren’t just a concept they’re practical framework for building complex, scalable on-chain applications.
Compose makes building and maintaining them practical, reliable, and ready for the next era of on-chain development.
Big thanks to @mudgen for making this easier 🙌
This is truly amazing @mudgen.
I agree, ERC-2535 despite always being used It's sometimes complex and hard to comprehend even though it's meant to be easily understood.
But with this innovation of yours we're expecting a simplified and more effective way for diamond contracts, which would later improve functionality.
And the terminologies stated are very clean and easy to remember especially in the crypto space filled with large numbers of things one has little or no understanding to, these terminologies could really be helpful and easy to recall.
Also love the Optional upgrade path for existing ERC-2535 Diamond implementations, which might really help push the Ethereum Ecosystem forward and improve simplicity.
This is genuinely impressive work, @mudgen.
I recently learnt that ERC-2535 Diamonds have always been powerful, but let’s be honest, the mental overhead and complexity can make them hard to reason about, even for experienced devs
They promise simplicity, yet understanding and explaining them often takes real effort.
What you’re introducing here feels like a meaningful step forward: a cleaner, more intuitive way to think about diamond contracts that improves usability without sacrificing flexibility.
The terminology in particular stands out. It’s concise, memorable, and far easier to reason about a big win in a space already overloaded with abstractions and jargon. Clear language goes a long way toward real adoption.
The optional upgrade path for existing ERC-2535 implementations is also a smart move. It lowers the barrier for current projects while nudging the ecosystem toward a simpler, more coherent standard.
If this gains traction, it could significantly improve how builders approach modular smart contract design on Ethereum.
This proposal is a meaningful step forward for Ethereum diamond contracts. @mudgen
It simplifies structure while keeping flexibility, with concise, memorable terminology that’s easier to reason about than current implementations.
The optional upgrade path for ERC-2535 lowers adoption barriers, nudging the Ethereum ecosystem toward a cleaner standard.
If adopted, it could significantly improve modular smart contract design and usability.
Happy weekend @mudgen
This proposal is solid and much needed. It keeps the core power of ERC-2535 while removing the confusion that scared people away.
The terminology changes lower the learning curve, the new indexed events are a huge upgrade for explorers, analytics, and governance tooling, and the single functionFacetPairs() introspection function captures what Diamonds truly are without unnecessary complexity.
Gas cost increase is minimal and worth the transparency and tooling benefits. The backward-compatible upgrade path is also a smart move.
Overall, this doesn’t replace ERC-2535 it matures it. If adopted, it could finally kill the “Diamonds are too complex” narrative.
Use a diamond instead of a regular proxy when your contract has multiple functional areas that are best maintained, upgraded, and reasoned about independently.
Diamonds let you split the system into facets, each with its own clearly defined responsibilities. This makes the codebase easier to understand, test, audit, and evolve over time.
If your system is small and revolves around a single upgradeable contract, a simple proxy is fine. But once you have distinct domains of logic—tokens, roles, governance, configuration, accounting, protocol modules, etc.—a diamond gives you a clean, scalable way to organize them without creating a monolithic upgradeable blob.
Diamonds help keep large systems understandable by separating functionality into clear, testable, and maintainable pieces.
Reach for a diamond when your contract has multiple functional areas that are better understood and tested in isolation.
I've never said this publicly before.
In 2020, after I wrote the ERC-2535 Diamond Standard, I was threatened with legal action by @DiamondStandard.
They claimed I infringed on their "Diamond Standard" trademark. That's why I renamed the standard to ERC-2535 Diamonds.
For years, and even now, people still call ERC-2535 the Diamond Standard -- just not me.
I'm not sure that an Ethereum smart contract standard can infringe on trademarks since it is unrelated to the sale of goods and services. In addition I never encountered any consumer confusion between the smart contract standard and the commercial products from Diamond Standard Inc.
I mention this because I am considering proposing a new smart contract standard, a simpler version of ERC-2535 Diamonds, and honestly...
I want the name "Diamond Standard" back.
The redacted legal letter that was sent to me is here: https://t.co/e7OEPhofck
Are there any trademark or IP lawyers on X?
Does their claim actually hold under trademark law?
Developing an Ethereum smart contract standard is an open process. It is developed out in the open. I should not have withheld that the standard's name was being suppressed by threat of trademark legal action.
I withheld that information because I was trying to avoid uncomfortable drama and I feared that information could make people want to avoid using the standard.
I shouldn't have done that. One's personal integrity (doing what you know is right) is more important than trying to avoid uncomfortable drama and fears of what might happen (which probably won't happen).
Be strong, courageous, honest and invite the world to create great things with you.
anyone got good prompt for generating state of the art dev doc?
without common ai writing flaw and great technical accuracy.
@GuiBibeau i’m sure you have something worth sharing
cooking the next upgrade of https://t.co/U00aJVyUCO docs
Guess what? I want to change the ERC-2535 Diamonds standard.
Yes — the Final Ethereum standard that’s been around for 5 years.
Why? Because it can be better.
Most people don’t realize this, but “Final” EIPs can still be updated. EIP-1 says Final EIPs may be changed to add non-normative clarifications — meaning improvements that don’t alter the rules or behavior of the standard, but make it clearer and easier to understand.
The biggest complaint over the years has been the extra terminology I introduced — I took the diamond metaphor too far. Too many diamond-industry words. Too much cognitive overhead.
You’re right. I did. And now I want to fix it.
I’m proposing simpler, clearer terminology that keeps Diamonds powerful but removes the unnecessary baggage.
Details here:
🔗 https://t.co/dmHPJ530HH
To all EVM-compatible L1 and L2 blockchains:
Please reduce the gas cost of DELEGATECALL.
It is foundational to modular smart contract design.
Thank you,
Nick Mudge
@superformxyz thread is here..
1/4
Just spent the weekend digging into @superformxyz dev updates, and holy shit the pace is insane. They shipped v0.7.3 last night and that's a good news for all of us...
Full EIP-2535 Diamond proxy upgrade, gas down 31% on L2 deposits. No fluff, just raw efficiency. If you are still bridging manually, you are ngmi so let's do it without any ifs buts...
Thread 👇 #Superform
Boson dACP स्मार्ट कॉन्ट्रैक्ट्स EIP-2535 डायमंड आर्किटेक्चर का पालन करते हैं, जिससे साइज लिमिटेशन दूर होते हैं और समय के साथ मॉड्यूलर अपग्रेड्स संभव हो पाते हैं।
यह Ethereum, Polygon, @base, Arbitrum और Optimism पर डिप्लॉय है
🟩 @kaleido_finance IS GOING MULTI-CHAIN 🫰
Something big is moving… and it’s not just a launch.
Kaleido’s EIP-2535 modular setup + AI stack is gearing up to duplicate its entire engine across chains, bringing unified liquidity wherever it lands.
A new chain is already in sight.
A chain with the speed, the users, and the room for real growth.
🟩 Can you guess which chain gets kGM next?
Drop your guess, the closest call might just get a serious reward. 👀✨
#KaleidoFinance #Web3 #Crypto
Building on erc 2535 Diamond? If yes, then know this:
💎its pretty standard to not over populate facets. Keep minimum logic and contract should be mainstream with ownership, governance (if for an institution) if only required. Depends.
💎its common to have deterministic deployments in diamond architectures. Avoid it if certain ux dont need it, a common misconception which fills in more over utility in the contract in most cases.
💎diamond storage is very essential and try to initiate the architecture or design from storage. eventually logic/facets depend on same storage. Super important.
💎keep initialization stuff completely seperate, important for rookies to understand.
💎document about all essentials. typical dev norm. Better to build in public and be transparent, there are some great projects that use diamonds.