ENS Improvement Proposal: Slow deposit withdrawal

[alexvandesande]

Preamble

Title: EnsIP: Slow deposit withdrawal
Author: Alex Van de Sande (avsa@ethereum.org)
Type: Ens Improvement Proposal
Status: Draft
Created: 2017-09-07

Goal

This is a collections of thoughts on the result of using capital cost of locking deposits as a cost for owning domains and how we can improve that on the future. This is the second on a series of improvement proposals on ENS that I'd like to see a public discussion.

Why name Auctions? Name auctions serve the purpose of trying to give control to the name to the entity who values it the most, and therefore we assume will make better utility out of it. But name auctions require a cost and therefore the funds need to go somewhere. Usually here are the traditional options:

1. Funds go to a central party One of the goals of ENS, is to make it a decentralized system and not a domain sale from a central entity. This would defeat that.

2. Funds go to a DAO This is not a new idea, in fact, one of the first proposals was to make the money on the sale go into a central DAO that could be used to decide on the future use of funds. The issue is that this hits one of the largest unsolved problems in the ecosystem: how funds are to be governed? Should they go to domain owners, then it would encourage creation of dummy domains for a 51% attack. Preventing by proof of unique identities that would hit on another one of the largest unsolved problems on the ecosystem. Other more clever ideas, like Futarchy Governance, remain untested and unproven. If a temporary central entity is created, then we are back to issue 1.

3. Funds are burned The usual neutral option, and the one decided for fees was to burn them. While in theory this distributes values equally to all ether holder, proportional to their holdings, in practice that extra value is impossible to measure and it feels largely like a waste of resources.

4. Locking This is the option that was picked. It's a good temporary measure as it pushes the problem further. It also allows an easier migration for the other methods in the future. But does it work as a cost?

Locking as an Opportunity cost

In theory, locking up ether is an opportunity cost. That ether cannot be staked, or used for lending or any other way that it could create some interest. It also cannot be invested in an ICO, and any token airdrop or token split that uses ether holdings might be unreachable. There is a real cost, to be measured both in ether and dollars, on locking your ether for a year.

In practice, thou, this hasn't been a great deterrent. Most of the staking/lending products are still not on the market, and no airdrops or token splits had happened during the soft launch. In conversations with owners of large amounts of domains, they thought that opportunity cost of ether was either irrelevant or similar to the opportunity potential of some names. Had ENS not presented itself, they intended to keep that amount as ether in cold storage and not use it to anything else. Some had in fact considered the cost as a negative, they believed the chance of a faulty implementation of ENS was smaller than the chance of their cold wallet backup failing and had that it was also a way to keep their ether safe from themselves, as they didn't trust themselves not to lose it in bad trades. Many have said that when the year long period was over, if Casper or other mechanism were available, they could reconsider their choices and maybe release the name.

Worst of all, there is a deep asymmetry between the cost for someone who wanted to build a product and a reseller: for a reseller the cost was just a temporary opportunity cost, while for honest product builders it needed to be considered burnt forever. The wallet of the ethereum foundation is set at wallet.ethereum.org and we have an interest in migrating that into a more permanent swarm/ipfs storage, but when it does so, it might not use wallet.ethereum.eth but some lesser valuable name like ethereum-wallet.eth, because if we ever use that name to secure a high value app like a wallet, it could never be released, or it could be snatched by a scammer that could steal all the user's private keys. My Ether Wallet has a similar opinion, that they are aware that they will never be able to release any valuable name they use, even if it's ether content is worth an order magnitude more than it's worth now. The problem is exacerbated because for bad actors, the worth of a name is orders of magnitudes larger than for honest actors, as they can use compromised apps to scam unsuspecting users without consequence, so a lot of names simply cannot ever be reauctioned safely.

Therefore at the moment, the current system isn't considered a large enough cost for large capital holders with interest in reselling domains, but it's deterrently expensive for those with the intent of building a product.

Locking up as an incentive to release

On the other hand, locking up as an incentive to release the name to the public domain seems to be a positive effect. There are a lot of uncertainties on this ecosystem, the value of ether, the demand for ethereum domains etc, and thus the perceived low risk of the domain distribution scheme, has been considered a positive. Many domain owners have expressed an interest in releasing names they bought to the system, either because they bought names on a whim, because they want to do something else with the ether or any other reason.

Had the ether of the sale been burnt, or sent to some other DAO incapable of refunding them, they might not have participated, or worse might hold on the name until they could find a suitable buyer. If names were not refundable for their value in ether, then in the scenario that ether value increases while demand for ENS names never picks up, some names would remain forever locked, as owners might refuse (even if irrationally) to sell names for less than the ether they burnt.

Foregoing locking up ether might have the effect of less participation or of having some names forever unused which is the opposite of what is desirable in this system. While we have not yet reached a date in which names become available for release, initial conversations indicate that getting back the ether for releasing them is an incentive for broader participation and as a refunder of last resort for overpriced abandoned names**.

Proposal: Unlock deed value slowly over the years

The most obvious solution would be to allow the owner to get some of their locked ether back, while keeping the ownership of the name. The "amount refundable" can be a static function of time, that is calculated whenever the owner wants to retrieve deposits. A proposed value would be to allow names to be redeemed 25% of the total value every year (continuously not necessarily a step function): it would mean about 43% of the ether is recoverable after a year, 76% after 5 years and 94% after 10 years. Another option would be to use an exponential curve, where you can recover 5% per year squared: it would be 28% of the total after five years and 99.5% of the amount after 10 years.

While 10 years might be a lot for someone holding a name expecting it to be profitable (bitcoin didn't even exist 10 years ago) it's not that much for someone building a product expecting to have long term users.

Proposal: Treat Deed value as prepaid rent and unlock it slowly over the years

On another EIP we will explore how utility rents can be used, but it's a known consensus that some sort of rental fee will eventually be implemented as a way to incentive unused names to be sold or released. While the behavior of those fees are yet to be determined, they have these desirable characteristics:

• Are predictable enough that name owners aren't surprised by sudden fee hikes
• Are slow enough that if the name becomes late on his bills the owner has time to solve the issue
• Can be paid by anyone, so that if an app is abandoned by their owners but it's still loved by their users, the funds can be crowdsourced
• Allow it to be registered for a long time

An easy way to do this would be to automatically deduce the amount owned from the initial deed. If fees are small enough, a high valued name can have it's own rent paid for years to come with just the initial bid amount. "Rent owed" can be calculated real time, and that value is subtracted from the amount of ether that can be unlocked at any time.

When the "rent owed" is larger than the amount of ether on the domain, then the name can tagged as "insolvent" by anyone, which will trigger a public event. This would alert anyone who cares about these particular names to take action: either to consider bidding on it when it becomes available, or to deposit more ether into it. As soon as more ether is deposited and the value is over the amount owed, the tag is removed. The name can be released exactly a year after it has been tagged as insolvent for the last time. There would be a one year grace period in which the name could be recovered by paying the late rent.

Treating deed value as prepaid rent allows name ownership of living names to be highly stable, but allows abandoned and forgotten names to be taken back to the market after a few years.

[Arachnid]

A good summary of the current consensus - thanks Alex!

Personally, for the reasons you outline (primarily the variation in capital costs and lockup periods for different actors), I'm a fan of eliminating deposits altogether in favor of rent.

If a decay scheme is used, it should be simple exponential decay, which produces an asymptotic trend towards 0; this is easy to implement and well understood, and is time-invariant (eg, it doesn't care when the process started).

[alexvandesande]

I'm a fan of eliminating deposits altogether in favor of rent.

Which is why I added the section following it, where I believe its value as an incentive to release (added to rent!) justifies it

it should be simple exponential decay, which produces an asymptotic trend towards 0;

So it would be something like total/time? The issue there is that it would go down very quickly in my opinion, which is the opposite of what we want.

[carver]

[Rent can] be paid by anyone, so that if an app is abandoned by their owners but it's still loved by their users, the funds can be crowdsourced

If there is a significant amount deposited and the rent is too small, then a griefing attack is possible, which keeps name owners from retrieving their deposit.

I would favor building this public rent payment mechanic into contracts that own their name, when it's appropriate.

[Arachnid]

So it would be something like total/time? The issue there is that it would go down very quickly in my opinion, which is the opposite of what we want.

Exponential decay always destroys the same percentage over the same time - like radioactivity, you can describe it in terms of half life. Mathematically it's deposit * e ^ (-t/r), where t is the time elapsed, and r is the decay rate.

[Arachnid]

If there is a significant amount deposited and the rent is too small, then a griefing attack is possible, which keeps name owners from retrieving their deposit.

I would favor building this public rent payment mechanic into contracts that own their name, when it's appropriate.

This can be mitigated by allowing owners to withdraw the deposit and release the name immediately - but then contributors have no assurance the owner won't do just that.

Personality I agree - it should be up to owning contracts to expose a payment method if they want.

[pipermerriam]

Personality I agree - it should be up to owning contracts to expose a payment method if they want.

I'm of the same opinion. Rather than baking these assurances into the protocol, I think it should be left up to domain owners whether they choose to implement such a feature. (The same pattern we came to loose consensus on for how domain owners can provide guarantees for subdomain owners).

[alexvandesande]

Exponential decay always destroys the same percentage over the same time - like radioactivity, you can describe it in terms of half life. Mathematically it's deposit * e ^ (-t/r), where t is the time elapsed, and r is the decay rate.

Then it's equivalent to the 25% per year curve that I plotted on the graph (dotted blue curve). I see the elegance on being time invariant, but I also like that in the other option we have a very small drop in the first years and then it very quickly goes to 0. But yeah, it's an implementation detail.

a griefing attack is possible, which keeps name owners from retrieving their deposit. I would favor building this public rent payment mechanic into contracts that own their name, when it's appropriate.

I am not against making this a contract level decision, but just to be clear the only thing the "grieving attack" achieves is to prevent the name from being released to the public. If the name owner hasn't lost his keys they can always release it, and if they have, by the time the name is available, the funds will have run out by definition

[github-actions]

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.