Repository navigation
Submit design proposals for an onchain Diamond factory/generator that uses Compose #6
Description
Need design ideas and proposals for implementing a diamond factory/generator for this library, that can be used by people to generate diamonds that reuse the onchain facets of this library. All kinds of aspects need to be designed and discussed and planned, including security and safety mechanisms and command line tools and user interfaces.
For now please submit ideas and suggestions and proposals and plans and concerns, and any thing as comments to this issue.
Activity
mudgen commentedon Oct 17, 2025
Diamond generator to look at: https://github.com/JoshdfG/Foundry-Factory-Diamond-Template
cyotee commentedon Oct 20, 2025
How far would you want to take this factory process?
I made a Diamond factory with hooks for using packages.
https://github.com/cyotee/crane/blob/main/contracts/interfaces/IDiamondFactoryPackage.sol
To summarize, the interface is for contracts to act as packges for use with factory.
The factory defines a lifecycle that makes calls to a package to calculate a salt, process user arguments, initialize a new Diamond proxy, and process any post-deploy actions. It also inserts Diamond Loupe and ERC165 facets by default.
Diamond Cut inclusion is handled by this package, Where it allows for providing the encoded call for the initialization code.
My goal was to support all conceivable deployment scenarios, and standardize a lot of boilerplate logic. Trying to make it easy to deploy a Diamond by letting developers only worry about declaring their specific configuration.
I also included CREATE2 metadata exposure. That allows the factory to be idempotent by checking and confirming if an instance was already deployed, and then just return that address.
But it is likely a bit more opinionated them you might want.
If something similar is desirable to you, I could make a more streamlined and less opinionated version that conforms with your project directives.
pellyadolfo commentedon Oct 20, 2025
I did something basic as a factory for my project a couple of years ago
https://github.com/Catallactic/catallactic-suite/blob/main/contracts/controller/CryptocommoditiesFactory.sol
Would be nice having a registry of facets per deployed chain.
cyotee commentedon Oct 20, 2025
This factory should probably have an opinion about initialization best practice. And since the project wants to promote reuse of on-chain code, it should probably group Diamond Cuts by facets and the initialization call relevant to those facets; emitting several DiamondCut events to record the several initialization calls.
Something like
struct DiamondCut {
FacetCut[] facetCuts;
address initTarget;
bytes encodedInitArgs;
}
struct DiamondDeploymentArgs {
DiamondCut[] diamondCuts;
bytes32 optionalSalt;
}
function deployDiamond(
DiamondDeploymentArgs calldata args
) external returns (address diamond);
Then execute this pseudocode
for each DiamondCut process FacetCut[];
Delegatecall initTarget with encodedInitArgs;
emit DiamondCut event;
The Diamond proxy would be deployed with CREATE2/3 using a hash of the DiamondDeploymentArgs as the salt. That way the optionalSat can be defined to allow for deployments of duplicate proxies.
cyotee commentedon Oct 20, 2025
Facet Registry could expose sets of facets, grouped by exposed ERC165 interface ID/s, and storage namespaces. If a facet exposes a subset of a ERC's functions, then it just uses the ERC165 interface ID produced from those functions. Might need to also declare the interface ID the subset is from, but distinct from the fully implemented IDs so there's no confusion.
darkrain commentedon Oct 20, 2025
I stumbled upon this project by chance and am ready to fully participate because we're solving the same problem, except you're creating ready-made packages for my tool - https://github.com/EMVPack/core
I think I've already started solving this problem without knowing about your project. Only more comprehensively. I'm annoyed that our implementation updates are chaotic, and we're not taking advantage of reusing ready-made implementations.
I haven't gotten around to the diamond factory yet, but I created TransparentProxy because I already had a lot of experience with it, but I didn't have any experience with diamonds.
But as I see it now, each diamond is a separate package with a package type of implementation and a proxy type of diamond. Diamonds have dependencies on faces, and each face is also a separate package and is effectively used only by diamonds.
What this provides:
My goal:
I want application development in the EVM ecosystem to stop being intimidating for solo developers, so they can build their applications quickly, securely, and with minimal investment.
mudgen commentedon Oct 21, 2025
That is correct!
Wonderful!
Let's work together and make this happen. I would be happy for our facets/diamonds/packages to integrate and work with your tooling or however we can best work together. Together we can do more.
darkrain commentedon Oct 21, 2025
Okay, I'm ready to take on this task, implement the factory in my tool, create packages from all of ready facets (ERC173, ERC721, ERC20), and demonstrate how it works. What's the deadline for this task? I'm currently preparing for the release and will be working on other tasks for another 2-3 days.
mudgen commentedon Oct 21, 2025
Sounds great. Deadline is as soon as you can. Keep in mind that the contracts in Compose are not production ready yet but can be used for development, proof of concept and testing etc.
darkrain commentedon Oct 21, 2025
Yes, i understand, my tool in same stage.
mudgen commentedon Oct 21, 2025
I am converting this issue into a discussion. So let's use Github discussion functionality, to discuss!