New registration pathway - "minting" through a canonical registry

[thelastjosh]

Instead of having every DAO deploy their own registration contract, which is the current primary method for EIP-4824 adoption, would it also make sense to have a single, canonical registration contract on every chain that retains and publishes the information for many DAOs? I.e. instead of interacting with a factory contract to deploy a new contract, they instead interact with a single smart contract that stores the DAO's data.

Minting pattern vs deploy pattern. Insofar as registrations already kind of look like (soul-bound) NFTs, complete with a pointer to an off-chain IPFS file (!), we can think of this architecture as replicating the "minting" pattern in an NFT contract, which stores a unique tokenId for every new NFT created through that contract. In fact, I think we can probably do this by lightly modifying a standard soulbound NFT contract. Note, this is distinct from the "deploy new contract" pattern one observes with DAO frameworks.

Comparison

Let's compare the NFT-like minting approach with the DAO-framework-like "deploy new contract" approach.

1. UX - better. Ideally it should be like managing a (mutable) NFT inside their wallet.
2. Vibes - unclear.
3. Elegance - better. Does every 4824 registration need to be deployed to a new contract address? Probably not. And insofar as we can use existing EIP patterns like soulbound NFTs, that's even better.
4. Customizability - worse. Technically each DAO can customize the governance of their registration—though I have a hard time imagining them bothering to do this. In practice customization would happen at the framework level... but do frameworks care about customization here, vs. the simplicity?
5. Standardization - better. We can define a standard governance associated to registrations. (Though, to be fair, we effectively design the governance inside registration contracts too).
6. Customizability for us - better. We can implement more complex logic in this contract that we probably couldn't get away with. In fact, I think this architecture makes the most sense if/when DAOstar needs to deploy a smart contract service anyways on a given chain; i.e. "get your registration automatically when you interact with this service".
7. Upgrading contracts - probably better. Even if the canonical minting contract is non-mutable, it's still going to be easier to migrate over data and upgrade a single contract vs. 1000s of others.
8. Sustainability - better. We can attach an additional fee for registration to control spam and generate income, or even set it a yearly fee akin to ENS. Not something you can do with the registration factory.
9. Decentralization - a bit worse. Yeah, you don't "own" your own registration contract, but if that's the complaint you would have to argue that you don't "own" your NFT or your USDC either. However, it is definitely harder to audit a bigger piece of code.
10. Fees / on-chain efficiency - probably worse, though I'd have to ask a specialist.
11. Spam control - probably better. See fees (not just larger ones, but more controlled ones). See more complex logic for governance.
12. Privacy - probably better. You could imagine a version with private execution that hides the registration and requires some sort of key or even a payment to unlock.
13. Security - probably worse. More complex smart contracts are more vulnerable to attacks.
14. Ease of indexing / querying on-chain - probably better.

It still makes sense to support and index independent registration contracts. But if this architecture makes more sense we might want to migrate the registration interface.

[linear[bot]]

STK-130 New registration pathway - "minting" through a canonical registry

[thelastjosh]

No progress this week / recently.