Decentralised Blue Check

The problem

All naming systems have a problem with squatting on brand names. The traditional DNS system solves this with arbitration systems through the traditional legal system. At ENS we don’t have this kind of system currently in place, because a key weakness of an arbitration system is that the system itself needs power to take over a name. If any system has the power to take over the name, it reduces the sovereignty of a name, a quality that is a top priority for a naming system. For ENS this would also begin to infringe on the first amendment of the ENS constitution:

“Name ownership shall not be infringed”

At ENS we have researched at length to create a system that is squatter resistant. It is a difficult problem to solve, because naturally it’s hard to decide on who deserves a name. There are also multiple different parties that may have a claim on the name.

For squatting brand names I see there are two main drawbacks:

  1. Brands need to pay a high premium for their name and may be disincentivised from joining the space. This in turn reduces the adoption of ENS.

  2. More severely, a squatter can decide to turn malicious and use the brand name to imitate the brand itself to trick users (e.g. phishing or fraud)

This proposal does not address the first point directly, but rather tries to limit the amount of damage a squatter can do if they decide to impersonate a brand.

Spoof resistant names

As early as 2017/2018 we have talked about maintaining an ENS black list that contained malicious sites trying to exploit users. This would have been a opt-in system that essentially allowed certain front-end name resolutions to censor names. Rather than propose a black list for ENS, I would like to explore the possibility of white list, or a “blue tick” verification system for ENS.

Using a 2LD .eth name such as verified.eth we could allow registration of subnames that map to .eth names:

const contentHash = await getContentHash(‘vitalik.eth’)

const contentHashVerification = await getContentHash(‘vitalik.verified.eth’)

const isBlueTickVerified = contentHash === contentHashVerification

On name resolution, the client would check the records for both names, and if they match, it could give the name a ‘blue tick’ (twitter verified) or a ‘lock’ (https lock on browsers) depending if the context is a decentralised website or a social network.

Why is a decentralised blue check better than a centralised version?

Having a name spoof resistant on one platform such as Twitter (blue ticks) is good for just that platform. Once you go to Instagram, Youtube or Facebook you have to get verified all over again. But with ENS names you can take your verification across different platforms as long as they use this standard. For this reason I believe that decentralised blue ticks are better than their centralised counterparts.

Time of verification

The time of the verification could be done at two different times. It could be done optimistically by allowing anyone to register names. This would reduce friction for users registering names, but would reduce the confidence of the name in the short term when the name has zero attestations that the name is held by a legitimate user. At any time post-registration, anyone else that has a claim on the name could then dispute the current ownership, force the name into an arbitration period and attempt to claim the name.

Another option for verification would be to additionally add a verification period prior to registering. All names on the system are guaranteed to have been viewed by jurors at least once and there is an elevated level of trust that users can put into the system immediately. However this has the clear disadvantage of creating friction for users to register names and could possibly reduce the usage (which would affect adoption of such a standard).

At the current moment, I believe optimistic registration makes most sense and we could optionally allow a user to pay for a judging period at any time to add 1 ‘attestation point’ to the strength of the validity of the name. The clients using this standard could then decide not to show a verified check mark for unattested names. “Self-arbitration” should cost about half that of a normal arbitration as the jurors would only need to judge 1 set of evidence.

Possible use of a 1 or 2 letter subname

Although this could be done with a longer 2LD such as verified.eth, it could beneficial to the DAO and users to use a short 2LD such as v.eth or ip.eth. This would make the subname easier to remember, quicker to type and more attractive to users that aren’t looking for verification on a brand name. Although the primary use case of the system would be provide a decentralised “blue check mark”, I don’t deny that short subnames would also be highly sought after.

For example: I do not own jeff.eth, I own jefflau.eth, however I have a strong claim on jeff.v.eth due to my government ID. I could choose to buy jeff.v.eth as an alternative username that could be attractive as my web3 username. For anyone thinking they won’t be valuable, think about how sought after gmail domains were in the early days!

The DAO could create an RFP where a service provider could build all the infrastructure for such an endeavour and then a percentage of the fees could be split between the DAO. Vitalik Buterin writes about in his recent post about ENS and suggests a 50:50 split between the service provider and the DAO. This could be further expanded into a three-way split with an additional “pool” that could be used for incentivising arbitration over public good domains that may not have the funds to pay for verification or arbitration. These cases could also be judged by ENS token holders as part of a DAO proposal or certain people could be delegated power to judge this by the ENS DAO.

This could create a significant revenue for the DAO, help ENS stay more sustainable and possibly have additional funds for funding the ENS ecosystem or public goods within the Ethereum space.

Concluding thoughts

Even if we don’t decide to use a short 2LD for this usecase, I think the benefits for a decentralised blue tick mark could already be enough to experiment with arbitration systems. To have this standard be something useful in production that many application support, the arbitration system would have to be battle tested and proven to be resistant to gaming. Nevertheless this could provide a realistic and worthwhile battleground for such a system to be tested.

Subscribe to jefflau.eth
Receive the latest updates directly to your inbox.
Mint this entry as an NFT to add it to your collection.
Verification
This entry has been permanently stored onchain and signed by its creator.