Highlight: Robin Hanson's more owner-forgiving modified Harberger tax

Cross-posted from ethresear.ch here.

From https://www.overcomingbias.com/2019/01/fine-grain-futarchy-zoning-via-harberger-taxes.html :

Added 11pm: One complaint people have about a Harberger tax is that owners would feel stressed to know that their property could be taken at any time. Here’s a simple fix. When someone takes your property at your declared value, you can pay 1% of that value to get it back, if you do so quickly. But then you’d better raise your declared value or someone else could do the same thing the next day or week. You pay 1% for a fair warning that your value is too low. Under this system, people only lose their property when someone else actually values it more highly, even after considering the transaction costs of switching property.

There’s many different ways to implement similar ideas that have slightly different user experience. One possibility is to set up a system where users pay the Harberger tax by prepaying funds into a contract, and there exists a separate mechanism where users can submit bids for any item of property; each bid must be fully collateralized. The tax rate that the current owner pays is computed based on the value of the highest bid. The owner has the ability to sell to the highest bidder at the bid price at any time (or the sale happens automatically if the prepaid tax contract runs out of money). This system is more favoring because sales are owner-initiated rather than buyer-initiated. One can also provide owners a further measure of stability by limiting the rate at which their tax can go up (eg. to one doubling per week).

This kind of owner-forgiving Harberger tax is not very useful for the “market-based eminent domain” use case: if Elon Musk suddenly puts up bids for an entire strip of houses going through a city to build a hyperloop there, then once some owners sell the other owners will know they can extract high prices and would be able to raise their prices (whereas with the traditional harberger tax everything would get snapped up at once). However, it seems very useful in cases where you’re not expecting buyers to want to buy a large set of items at the same time, eg. ENS domains.

1 Like

Your link is broken. Take out the trailing :

If I understand correctly , is this the scenario?

  • The current owner (Mr. A) of a.eth has 100ETH into X contract.
  • The current owner (Mr. A) has a bid of 1ETH into Y contract.
  • The current price of a.eth is 1ETH/y and can retain up to 100 years.
  • A bidder (Mr. B) puts 10ETH into X contract.
  • A bidder (Mr. B) puts 2ETH into Y contract.
  • Mr.A now can sell the name to Mr. B for 5 years at 2ETH/y price.

Am I correct to assume that people can only top up fund to X contract, but cannot withdraw?

Let’s go through a fuller story.

  1. Mr A registers a.eth, somehow no one contests. During the registration process, Mr A puts 100 ETH into the contract as a rent payment budget. Mr A now owns a.eth, with a rent of 0 (or alternatively one could set a base minimum fee of eg. $5 per year).
  2. Mr B registers a bid for a.eth, at a price of 10 ETH, and locks up an additional fee prepayment of 2 ETH (so 12 ETH total) [it’s theoretically legal to have a fee prepayment of zero but that’s stupid because then if you win the domain you would immediately lose it due to the fee contract going bankrupt]. The fee that A has to pay now goes up to 0.1 ETH per year (10 ETH bid * 1% assumed tax rate per year).
  3. Mr C registers a bid for a.eth at a price of 20 ETH, and locks up an additional fee prepayment of 2 ETH (so 22 ETH total). The fee that Mr A has to pay now goes up to 0.2 ETH per year (20 ETH * 1%)
  4. A year passes. At this point, Mr A is free to withdraw only 99.8 ETH from the fee prepayment contract, because 0.2 ETH per year is taken as a fee (no need to have a “pinging” mechanism; the contract can lazy-evaluate the remaining balance at any time). Mr B and Mr C still have 12 and 22 ETH locked up, respectively; you don’t pay a fee to bid.
  5. Mr A decides that he wants to sell, so he sells to the highest bidder (Mr C). Mr A gets the 20 ETH, and automatically gets handed back his remaining fee balance, so he gets a total 119.8 ETH. Mr C is now the owner of the domain; of his original 22 locked up ETH, 20 was given to Mr A, so 2 is the remaining fee balance. The next highest bidder is Mr B, who bids 10 ETH, so the fee that Mr A has to pay is 10 * 1% = 0.1 ETH per year.
  6. A year passes. At this point, Mr C is free to withdraw only 1.9 ETH.
  7. It turns out that Mr C lost his private key, so he will never voluntarily give up the domain. Suppose no one else comes to make a higher bid. 19 years later, Mr C’s contract is “bankrupt”. If there is another bidder, the highest bidder can now snap up the domain at his own bid price; if there is no bidder, then anyone can snap it up for free.

Am I correct to assume that people can only top up fund to X contract, but cannot withdraw?

Any deposit that is made into a fee payment contract can be withdrawn, except for an amount that corresponds to the fee that has accrued. Any deposit that is made to make a bid can be recovered by withdrawing the bid at any time.

Hope that helps.

1 Like

Thanks for the clarification. I have a few follow up questions.

  1. Is this based on the assumption that renewal (or sell to someone) happens yearly base, or the owner can set the locking period flexibly?
  2. How do you derive the best tax ratio (which is set to 1% in your assumption). What will be the difference if the tax is 10%, 50%, or even 100%? The effect I understand are the followings but do I miss any?
    2.1 At step #7, the lower the tax ratio is (=more funds needed to be locked) the longer lockup period will become longer.(if tax is 100%, then the name becomes available for sale as soon as renewal date comes).
    2.2 The lower the tax ratio is, people have higher barrier to entry to bid.

Another thought is that I wonder if the contract can earn interest while sitting as collateral, which is now becoming very popular like this contributing additional revenue stream for ENS.

1 Like
  1. I think it’s okay to make it fully flexible and not set specific periods (I think this also removes the edge case you mention in 2.1; a tax rate of 200% per year is just a tax rate of 17% per month)
  2. Theory would say that a tax rate that’s some fraction of the natural turnover rate (ie. the % chance per year any given domain gets traded) is optimal. Half the turnover rate would work. But any number greater than zero gives at least some portion of the desired affect

Potentially you could allow bids to be made in different currencies (though you’d need a whitelist to prevent weird mischief like coins that have logic specifically designed to revert fee payments) and then those currencies could include interest-bearing wrapper coins like cDAI.

1 Like

Interesting mechanism. Are there any attack vectors that someone try to bid very high amount (with short locking period) to make the tax very high so that the owner is forced to sell? Even if the distraction is for the short period, it could have devastating effect given ENS name is used to send money (unlike ads which don’t hurt anyone apart from the advertiser of the rent being too high).

Another question is to analyse the demand for such mechanism. I don’t think it is worth delaying 3~6 short name auction in favour of this mechanism, but may be an interesting experiment for 1~2 chars. Would be nice if there are some ways to gauge demand so that we don’t spend months building and no one end up using.

FYI Response from Glen Weyl

@makoto could you share screenshots from Glen’s tweets, he blocked me on twitter cause I called him an idiot.

With respect to 2., your mechanism actually changes this property: if auctions are used to set prices, rather than the owner self-assessing a price, then the (allocatively) optimal tax rate actually becomes 100%. To see this, note that a 100% auction tax rate is essentially equivalent to the license owner just competing in a standard auction against other bidders for the license; for “good” auction formats e.g. second price sealed bid or ascending, this is efficient. This is bad because we need higher tax rates (and lower investment incentives) for any given level of allocative efficiency. One small potential benefit, however, is that there’s no risk of “overshooting” the optimal tax rate and inducing too much turnover.

With respect to 1. we don’t really know the tradeoffs between more and less frequent reallocation events, should look into it further.

Attack vectors: This is an issue; if it is possible for an attacker to steal a lot of money by only holding the ENS name for a very short period this is potentially quite bad for this system. I am unfamiliar with, well, everything about ENS, but in particular what the primary users and uses are, so if someone could explain that briefly or link me to a primer or something, that would be very useful.

A deterrant to this kind of attack would be, actually, making the holding period longer. For example, suppose we made the holding period/time between auctions 2 weeks or a month. An attacker could make a high bid, take a ENS and steal money from it, but would have to hold on to it for a while, and pay a fair amount of taxes, before they could re-sell in the next reallocation event. It’s actually easier to buy, steal, and sell if the holding period is shorter.

Again, my institutional knowledge is sorely lacking, but it seems like the economic time horizon on which optimal reallocation occurs in this setting is, like, on the order of weeks or months. So that’s approximately the frequency at which we should run these reallocation auctions.

Think about this. We want to trade off the benefits of efficient, frequent reallocation with the costs that auctions too often are susceptible to the kinds of “trolling attacks” you talk about. Suppose a dev works on some application for a month or two. It’s largely fine it they have to wait two weeks or so to buy the ENS they need. Six months or a year is probably too long for this kind of thing. Higher reallocation frequencies would have relatively more limited benefits, and would potentially facilitate the kinds of trolling attacks/theft you point out.

A deterrant to this kind of attack would be, actually, making the holding period longer. For example, suppose we made the holding period/time between auctions 2 weeks or a month.

Requiring bids to stick around for at least 2 weeks definitely seems reasonable to me! Another alternative (and I think my preferred one) that mitigates “trolling attacks” is to cap the rate at which the fee can grow, to eg. one doubling per week, so you can’t force the fee up significantly without exposing a pretty long time period within which the buyer can just sell to you. This also has the nice property that if you prepaid for N weeks, you know you get at least log(N) weeks of stability regardless of what happens (can replace “week” with any other time period if desired").

@makoto could you share screenshots from Glen’s tweets, he blocked me on twitter cause I called him an idiot.

Just visit his twitter page in a private browsing tab

With respect to 2., your mechanism actually changes this property: if auctions are used to set prices, rather than the owner self-assessing a price, then the (allocatively) optimal tax rate actually becomes 100%.

Interesting! I can see how that’s true. Then the scheme just reduces to an auction where the existing owner has last-mover advantage. Though in practice we’d want rates lower than 100% because investment efficiency matters too.

[Glen’s comments]

Glen’s main criticism seems to be basically the point that I anticipated with this paragraph in my original post:

So if you want to buy hexagon.eth, and the buyer knows that you’ve already spent thousands of dollars on trademark and business registration for “Hexagon” and used that name to pitch to investors, yes, you’re screwed (though still less screwed than the status quo, where the owner has no penalty in raising their price!). But in my experience, snapping up the domains is one of the first things that you do as part of starting a project with some name, so you’re not yet stuck with complements.

I’d also add that allocative efficiency is NOT the only benefit of Harberger taxes. The other benefits are (i) it’s a tax and you can use the money raised with it to do other useful things, and (ii) it reduces the unearned privilege that early entrants into the system have. I think people really undervalue (ii); there’s going to be a lot more pressure to compete with ENS in 2035 if all the domains are owned by randos that got lucky in 2015-2019.

1 Like

Agree with both (i) and (ii). You can see this in, e.g. radio spectrum allocation – early uses of EM spectrum (radar, TV broadcasting) have much lower data efficiency and thus economic value than modern uses (wifi, 5G). But since the earlier users hold perpetual use licenses, they basically get to extract all of the value from late users – and moreover the govt doesn’t capture the revenue from the big increases in spectrum value for spectrum that’s already sold.

If ENS domain names are sold using Harberger licenses, it’s both easier to reallocate down the road, and has the benefit that if ENS dramatically increases in value, the central platform can make revenue not only from selling new unallocated domain names, but also from the tax payments flowing in from already allocated names, which are probably the more valuable ones.

Imagine, for example, if internet domain names were allocated with Harberger licenses, with the revenue going to a foundation used to fund open source projects, e.g. through a quadratic voting system or something. The foundation would be pretty well off, with flow payments from big valuable names like home.com, USA.com, etc.

I thought a bit more about how to set the tax rate; haven’t done any math but it seems a reasonable heuristic would still be to tune it to the approximate horizon on which investment has value. If investments in “advertising” a domain name seem likely to make users associate a domain name with a certain group for e.g. half a year or so, we probably want to tune the tax rate so owners have a substantial stake in the asset half a year in the future, so maybe 5-10%, no more than 20% monthly taxes. Basically targeting something like 50% depreciation each half year, so a license holder can be thought of as holding a stake in the asset, which discounted and added up, lasts roughly half a year into the future

Unfortunately this number probably changes over time – turnover is probably relatively high for early-stage platforms and users and slows down as the ecosystem settles down. And we don’t yet have a great understanding of how to adjust taxes over time in a reasonable way.

ENS is means to be basically a domain name system to be used for things inside the ethereum ecosystem, so I think the investment horizon is in many cases going to be many years. So my instinct is definitely to target <10% annual.

1 Like

I like where this is going, but I’m still super-duper hesitant to implement anything that can result in someone losing their domain unexpectedly due to inaction. With renewals, the user knows they don’t have to check back until the time comes to renew the domain. With a harberger tax, though, that could happen at any time, meaning they (or an automated service) have to keep a constant eye on the domain.

A limit on the rate-of-change of rent mitigates this a bit, but since it can still grow exponentially, its usefulness here is limited - to be sure of holding a name for a year, you’d have to lock up 2^52 times the current yearly rent.

I’m also still hesitant to embrace the basic idea behind a harberger tax for ENS: That a domain owner should be charged rent proportional to how much other people want the domain. Unlike land ownership, there are large externalities to owning a domain; mew.eth might be much more valuable to a scammer than it is to MEW themselves, because while a scammer can steal funds, MEW themselves might only use it to trustlessly issue subdomains for their users’ convenience.

There’s definitely a tradeoff between convenience for owners and convenience for bidders and you could move that slider around; eg. you could set the minimum doubling time to 3 months instead of a week, or you could set it to a fixed amount, eg. $10 per year per day.

That a domain owner should be charged rent proportional to how much other people want the domain.

The extent to which other people want a domain is the best guide we have to how valuable a domain is, and unless we want to privilege people of today over people who live 20 years from now, some kind of permanently open competitive dynamic between present and potential owners is necessary…

If we had Barry’s coercion resistant voting gadget with a functioning identity system, then one could use some form of quadratic voting to allow people to signal public-good value of a domain. But we don’t have that so…

MEW themselves might only use it to trustlessly issue subdomains for their users’ convenience.

The use of ENS for subdomains definitely is an argument in favor of strong stability of ownership; it’s hard to coordinate everyone to force an upgrade. So one possible equilibrium of this whole experiment is that short ENS names would get gobbled up quickly and be very inflexible with persistent owners, but most people would interact with the system through subdomains, and then you can have an open market for registration and economic mechanisms at the subdomain level, the same way we do in traditional DNS.

1 Like

One thing worth considering is that we can actually test this out on a domain-by-domain basis. Anyone can write a smart contract that implements one of these variants and commit ownership of a name to it irreversibly. The contract can use some or all of its income to pay rent on the .ETH registrar.

If the system turns out to be useful, we can apply to ICANN to obtain .rad or .radical TLD which allows to mirror the .rad TLD on ENS using DNSSEC and set the HarbergerRegistrar to the TLD. Combined with EthDNS, you could even enforce a special TLD which only allows people to host website using ipfs/swarm contenthash!

It would be interesting to set it up on a domain by domain basis, but it might only be an effective test, if we can get enough people interested in that domain.

I like the ideas that @vbuterin put forward about needing a system that allows for fair allocation to people that don’t exist yet. We already know that DNS has not allowed that fair allocation and almost all domains names that are worthwhile are already taken. Those that are not born yet haven’t got a chance.

I wonder if there is any other way to stop the rent growing exponentially without a rate limiter as @nickjohnson pointed only mitigates the issue. If someone is long on ETH, attacking a domain by adding a bunch of ETH to that name is effectively free, especially to a name that cannot be realistically given up (i.e. mew.eth due to subdomains). I could see this happening just to ‘grief’ high profile projects rather than any intention to buy the name to scam, possibly by a competitor with a lot of ETH.

@vbuterin Is there a reason there isn’t a fee for a bid? What about adding a ‘tax’ to having your bid sitting there on a name? It might reduce the likelihood of someone putting a bid up for a particular name without any intention of actually buying it.