On Property rights and threat models for ENS

This is likely to be deemed to be an ultra vires act, as you can’t tie the hands of a future body to act that possess the same powers, pursuant to the Constitution.


Thanks @AvsA for this concise summary. It was really necessary since a lot of misinformation floating around is about “ENS will take your names based on your views”.


I have started a repo for threat analysis to DAO structures, starting with ENS. It’s in Python. I’ll update where there are any mentionable findings.


I ran some very basic simulations to access if the DAO can be ‘taken hostage’ by a select number of delegates by triggering on-chain votes with sufficient quorum of 1,000,000 votes. @AvsA pointed out that the top 5 delegates make up for sufficient quorum. I generalised the process to N number of delegates (‘colluders’) over the list of top 50 delegates scrapped from Sybil.org. The top 20 delegates are listed below for quick look-up:

1	brantly.eth		    5.362		367162
2	coinbase.eth		4.840		331375
3	nick.eth			4.149		284107
4	she256.eth	 	    4.065		278319
5	cory_eth			4.000		273907
6	avsa.eth			3.245		222209
7	lefteris.eth		3.202		219252
8	rainbowwallet.eth	2.986		204457
9	fireeyesdao.eth		2.493		170668
10	mikedemarais.eth	2.418		165575
11	griff.eth		    2.417		165522
12	simona.eth		    2.342		160346
13	ChainLinkGod		2.197		150455
14	superphiz.eth		1.996		136646
15	imtoken.eth		    1.719		117721
16	keikreutler.eth	 	1.349		92342
17	maaria.eth	   	    0.975		66762
18	devdao.eth		    0.913		62496
19	marspunks.eth		0.887		60748
20	metaphor.xyz		0.882		60418

The full set of results can be found here. To summarise:

colluders  threats
3          0
4          302
5          17920
6          478783

‘colluders’ == number of rogue delegates
‘threats’ == number of possible combinations of rogue delegates with > 1,000,000 votes in total

These results suggest that a vote can be triggered by as few as 4 not-necessarily-top delegates. In comparison, in a utopic world where all 50 delegates have equal votes, quorum cannot be reached unless a minimum of 9 delegates collude.

In further detail, in each case I looked for reoccurrence of delegates across all combinations of attacks and gave them a threat score (see below)

All three cases put together show the expected trend (see below). Notably, when N > 25, ‘colluders’ effectively become ‘agreers’ since now the majority decides the fate of the protocol.


Thanks @AvsA for starting this thread!

root.ens.eth is owned by the multisig, so I’m still confused as to whether or not the .eth lock can be overridden by the multisig (or governance, in the future), even via a Constitution change or using other extraordinary measures.

Nick, can you help to clarify this?

I think that .eth cannot even be changed by the root, that’s what @James and @nick.eth said in this thread: [EP1] [Social] Proposal: Transfer ENS Treasury and Contract Ownership

Importantly, control over the ENS root will remain with the ENS root multisig for now. Control over the root allows for the creation and replacement of ENS top-level domains (TLDs) other than .eth (.eth is locked and cannot be changed by the root).

I get that. But, this being Ethereum, we can never be sure that something that was changed after the smart contract was deployed is irreversible unless we can look at it on-chain and understand that it’s forever immutable. I am just trying to understand how the “lock” was implemented and get totally confident that it can’t be reversed by the multisig.


This is a fantastic comment! Considering that the delegate power will always be a power law, what do you think is a good quorum to raise the bar?


The lock cannot be overriden. It exists to deny even the owner the ability to change a record.


Well played: the extent of a corporation’s competence to enter into contracts depends on the scope of the power its charter grants.

1 Like

More than that: Canonical definition of ultra vires directly decides on the scope of limiting power by eliminating all acts that violate causality principles, for example, new laws cannot be enforced on non-existent entities (in the future). Beyond the trivial ultra vires, the charter can of course set their own ultra vires.

Does this mean that the keys are burnt for this contract? Other than that, a code can always be reversed unless there is a one-way hashing in there somewhere that explicitly prevents this.

The quorum question isn’t easy to answer if you are looking for one consistent value. if you are willing to adopt a dynamic value, then it is easier. The reason: the delegate vote distribution (as well as threat score) will always be a power law (Rankγ) like you said, but it could be of different index γ which decides the slope. In utopia, γ = 0. In real life, you’d still want this value to be as low as possible and the power law to be as flat as possible. Flatter power law will require more number of colluders to attack and therefore decrease the likelihood. Having said that, the delegate vote count is not fixed, so the power laws are always shifting. Currently, threat to ENS starts at 4 colluders and Brantly, Coinbase, Nick feature in roughly 80%, 65%, 40% of these hypothetical attacks respectively as a reference. What number do you think is safe? It is a dynamic question (γ is varying) and should be treated as such. Beyond that, even if you flatten the power law, there will still be a finite number of colluders who could attack the protocol.

However, it doesn’t hurt to run a simulation with a higher quorum and with the current delegate vote distribution, a quorum of 2,000,000 will require a minimum of 7-8 colluders. This is obviously far better than 4 colluders but not very safe in a general context. Other list of values below:

quorum       min_colluders
1,000,000    4
2,000,000    7-8
3,000,000    13-14
4,000,000    27-28

Having looked at these values, quorum should be raised to 2,000,000 in my opinion. The “attacks” are only attacks on quorum so relatively safe and don’t need a hyper-strict criteria. I will run more simulations for a full on-chain voting. If I find something meaningful, I’ll go ahead and attack the protocol. You know where to find me. :smiling_imp:

Contracts don’t have private keys. The code limits what can be done with the resources it manages.

Can the smart contract implementation that contains the lock be replaced with a new implementation?

Would it be possible to document the Ethereum addresses for all of these smart contracts so we can get some independent eyes on them?


1 Like

Registrar contract: 0x57f1887a8BF19b14fC0dF6Fd9B2acc9Af147eA85
Controller contract: 0x283Af0B28c62C092C9727F1Ee09c02CA627EB7F5 (original post is missing this @AvsA)
DAO Access contract: 0x323A76393544d5ecca80cd6ef2A560C6a395b7E3
ENS Root contract: 0xaB528d626EC275E3faD363fF1393A41F581c5897 (this is what you want I think)
Root Multisig contract: 0xCF60916b6CB4753f58533808fA610FcbD4098Ec0


Avsa is putting something together; for now, you can see them as subdomains of ens.eth: ENS App

I’ll be continuing the threat analysis in greater detail on this dedicated domain: ens.inplco.eth which essentially links to this mirror: ENS - Interplanetary Forum. I’ll keep updating here with meaningful findings but not in full detail

CC: @nick.eth, @AvsA

Minor update on the threat analysis:

Maximum possible threat score: 7.0


Do we know how this distribution compares to other somewhat similar DAOs? Are we in the middle of the bell curve on this, or are we a deviation?

1 Like