ENS Proposals explained visually

I recently posted this on twitter and think it would be interesting here too:

A visual map of all the proposals we have voted and discussed so far.

EP1 was not executed on the DAO, but rather a request that the multisig transferred the ownership of multiple contracts (and all its USDC and ETH) to the newly formed DAO.

EP2 and EP3 were executed as single call, that amended the airdrop to include a missed special case, and to recover tokens sent to the contract address.

Notice that the DAO did not, in fact, change the airdrop, but rather used its own funds to approve tokens to a new contract.

In practice it’s the same because all funds not claimed by the airdropped can be later claimed by the DAO, but the distinction is important because the DAO does NOT have the power to change the original airdrop. So it can’t rewrite history to add some more people to it.

EP4 was about Steward elections. EP5 created a Dutch auction starting at 100k for any names that had just recently been available. How did it do that? It changed the price oracle so charge more for names depending when they had expired.

The next incoming ENS proposals are likely to be off chain: about changes in directorship of the incorporated foundation. But the next time we have an on-chain vote, I will create a new map like this so our delegates can be better informed of how it works under the hood.


This is outstanding! Thank you for putting these together. I wonder if we should add them to the EPs themselves?

Do you have an SVG version of your diagram? I can imagine someone might want to instrument it so it can be easily used to generate these kind of diagrams rather than you having to do each one manually.


I’ve made them in sketch and can export them in svg. The issue with automation is that the hardest part of these diagrams is figuring out what to show and how. For example, to get the governor from the wallet isn’t obvious as it requires calling hasRole with the keccak(“proposer”).

The best way to open these imho would be for me to publish them as big figma files

I was thinking more that you’d have a single diagram with everything, and the automation would choose which nodes and edges to gray out.


That’s cool. But in the case of a smart contract replacement, like the oracle change, it would need to show the new address


@avsa @nick.eth

Both tasks can be accomplished with hacking the XML parse of SVG file. I will give it a shot but probably cannot do it until after the Solana Hacker House Prague March 1-6.