Smart Contract library for building modular, diamond-based smart contract systems on EVM chains

Joined November 2025
We’re now building on a strong foundation. Go read the finalized ERC-8153 standard. Huge thanks to @mudgen for this incredible piece of architectural work.
1
3
4
162
New docs are up for ERC-20 👀 We broke down the different pieces of ERC-20 into individual facets, so you can see exactly what each one does and compose the functionality you actually need. Transfers, approvals, minting, burning, permits, metadata, and more
2
1
4
119
Let’s build your first Diamond together 👉👈 Follow our step-by-step tutorial to create a simple Counter project and learn how diamonds are structured along the way. compose.diamonds/docs/gettin…
3
2
222
Your next project is one command away. Run the new init command to scaffold a Diamond and start building with the Compose library right away. Install the CLI here: compose.diamonds/docs/gettin…
5
6
352
Your next project is one command away. Run the new init command to scaffold a Diamond and start building with the Compose library right away. Install the CLI here: compose.diamonds/docs/gettin…
5
6
352
We published the Compose Whitepaper 💎 It explains our vision for building the tooling and paradigm needed for shared on-chain infrastructure to become reusable and trusted. Leave your thoughts. Compose is built with community input. compose.diamonds/whitepaper
2
2
9
1,992
Setting it up a diamond project shouldn’t be painful. Introducing Compose CLI. A new way to scaffold modular smart contract systems using the Compose library. 1. Choose your template. 2. Choose your framework 3. Start building immediately. Supports both Foundry & Hardhat.
1
1
1
12
822
Modular smart contract development deserves better tooling, and this CLI is only our first step toward improving the overall diamond developer experience. We plan to add more templates and continue evolving it to support developers through every stage of the diamond lifecycle.
1
93
This description of diamond contracts from @adxtyahq is refreshing. He describes a diamond proxy as "totally simple, totally plain". He is right. A good diamond proxy contains no business logic. It routes function calls to implementation contracts (facets).
Let’s talk about EIP-2535 (Diamond Proxy) Been getting a lot of questions around this, so here’s a short video explaining how it actually works. What should I cover next?
5
2
2
42
2,232
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.
10
3
18
711
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.
3
3
10
701
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.
8
3
26
830
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.
2
3
8
431
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.
1
8
15
651