Updated Harberger Tax Model for BNS

[stxnomnom]

I propose that a (twist on) Harberger Tax be used for allocating BNS domain names, which could be more fair, and generate higher fees on Stacks as compared to the flat fee model that it has today.

In a typical Harberger Tax, the owner of the property (in our case a BNS name) self-assesses the value of their ownership and pays a recurring tax that is some percentage of that assessed value. The problem with having just one self assessed price is that it ignores the fact that there is a time component to prices and can ultimately require owners to self-assess a price that is just too high for them to pay for them to have any strong guarantee that the name won't be bought up from underneath them—which could cause real harm. See this post advocating against a Harberger Tax for ENS. The concerns presented in the post are valid, but I believe can be addressed by the following structure:

If instead of just self-assessing one scalar price for the domain name, the owner specifies a price as a function of time (t) and pays a weighted average percentage of the output of that function as the tax. The price at time (t) is what someone needs to pay the owner to take control of the domain name at that time (t). t is now, t + 1 is the next block, so on and so forth.

This allows an owner to specify a high price for the control of their name in the immediate/short term and incrementally step down the price as (t) gets further into the future, thus lowering the overall tax amount for the owner and giving them a strong assurance of ownership in the short term.

Owners can price the short term takeover at a price where they'd be happy to relinquish control, and at a minimum know whether or not someone is trying to take control of their domain name at any time in the future and can thus buy themselves time to make a decision about what to do.

For instance I could set the price of my domain name to $1 million for the first day then drop it down to $1k for all time after that. I'd be happy if someone wants to take control of my name right away for $1 million, and if they try to take control of it for $1k at t + 2 days and on, then I at least have bought myself a day before control is transferred over and can decide if I want to revalue and thus keep control, or allow the sale to go through. In this example, at a 2% tax rate, the yearly tax I would pay for this valuation function would be: $1,000,000 * (.02 / 365) + $1,000 * (.02 * 364/365) = $75.

Looking forward to feedback and some constructive criticism on this and whether or not others think something along this line can be viable.

[badonyx]

Agreed that the existing fee model for BNS is inadequate. Not sure if this is the right approach but it's a good starting point for the discussion. Thanks for sharing.

[stxnomnom]

Are there any specific points you have against such an approach that you could give me a chance to address? Or are you opposed to any Harberger-like tax scheme in general?

[will-holley]

The ability to adjust the self-assessment at will (https://github.com/721labs/partial-common-ownership/blob/ca72ca7f13dd0a2103d592b39a4fcaa749e9045f/contracts/token/modules/Valuation.sol#L45) combined with periodic rather than continuous auctions solves for this without migrating from a scalar valuation.

[stxnomnom]

@will-holley I might flip your argument around here and say that moving from a scalar valuation to valuation as a function of time makes it unnecessary to be constantly adjusting the self-assessment and can still allow for a continuous auction. So in that sense it would be objectively better as there is less maintenance overhead and no functional concessions made.

Using a function valuation, you can emulate all the outcomes of using just a scalar value, but now you also have an extra dimension—time—on which to value property which can allow you to be even more precise in your valuation. Of course this relies on the assumption that time is relevant to valuation, which I believe to be the case.

[will-holley]

@stxnomnom, this would only be true if the steward is able to predict all of their valuations at time t = 0 with greater accuracy; this is false. We both agree that time is relevant to valuation, but in practice, the more accurate self assessment function is both pro- and re-active i.e. v(t) considers both {v(0), ..., v(t-1)} and {v(t+1), ..., v(limit)} at each point in time t.

[stxnomnom]

this would only be true if the steward is able to predict all of their valuations at time t = 0 with greater accuracy; this is false

I'm unclear on why this would be the case. Could you elaborate and explain why you'd need more accuracy under my proposed model as compared to your alternative? You would still be able to update your valuation function at will under the proposed model.

As far as I understand, the proposed model can indeed emulate all results of your alternative, plus allow for an extra dimension to valuation (which I argue ameliorates some of the impractical implications of a 'standard' Harberger tax). If you disagree with this assertion could you provide an example where my model cannot replicate the functionality of the model you propose?

[will-holley]

1. HT is explicitly designed (as originally detailed in Radical Markets) to maximize the accuracy (and truthfulness) of the self assessed valuation. Both over and under-appraisals result in sub-optimal efficiency. Continuous valuations over time (i.e. t => limit) will always be more accurate than the valuation at t = 0.
2. Entertaining your proposal, how would it work technically for non-linear appraisals? As outlined above, a linear valuation function would not accurately model how valuation progresses in practice and, at the onset, the appraiser doesn't know the most accurate valuation function. As this function is ultimately emergent post-hoc, the most efficient way to arrive at it (going back to the explicit goal of maximizing efficiency through accuracy) is to continuously reappraise over time as the steward changes their past analysis and future expectation of payoff. And, finally, if that is the case, including duplicate logic that is knowingly inefficiency introduces unnecessary complexity and violates DRY for what I see as no benefit.

[stxnomnom]

1. We agree on all of this here. And just as a scalar price of a standard HT can be continuously revised, so too can the valuation function. Both methods can be used react to new information so there is no difference in that regard. Reading back the thread I see how you may have interpreted this to not be the case, so I hope this clarifies.

2. Since we agree on point 1 that makes most of this point moot. So the real question to answer here is what is the benefit of using a function vs. a scalar? Using a function as a valuation allows us to explicitly model a condition that we cannot when just using a scalar value. And that is when does control of the asset actually transfer?

Under a scalar model we have to make an arbitrary assumption as to when this occurs and it may depend on the type of asset. E.g. Home sales may typically take 30+ days to close, whereas the transfer of control can be much faster for an empty plot of land, and yet even faster for a domain name. So not only can this condition vary between different types of assets, but it can also vary based on individual preferences. Again using the home example, a younger owner may be happy to move out with just a week notice and for a lower premium over the traditional "market" value of the home, whereas an older owner may want a longer lead time to be able to move and thus require an even larger premium for longer.

Using a function valuation model, we no longer have to 'hardcode' the transfer delay as a one-size-fits-all, but instead can let each individual explicitly express this preference and thus put a value on it. This gives us an even more accurate valuation (as something that could not be valued is now able to be valued) and thus greater efficiency.

In conclusion, a function valuation allows us to specify the (price,time) at which we'd sell AND transfer control. A preference that is unable to be modeled by using just a scalar value.

[will-holley]

And just as a scalar price of a standard HT can be continuously revised, so too can the valuation function.

Before proceeding, how this revision occurs, technically, is still unclear to me. Or for that matter, how it's set in the first place. If i'm understanding you correctly, you expect each steward to both design a function that accurately matches their valuation and deploy in in code?

when does control of the asset actually transfer?

In all cases, on title transfer, which is not arbitrary, and should be considered separately from transition times. Again, if i'm understanding you correctly, you expect the steward to price and include within their valuation function the cost of a hypothetical transition?

[stxnomnom]

Before proceeding, how this revision occurs, technically, is still unclear to me

Before we get into the technical implementation details, I'd like to make sure we're on the same page with respect to the idealized concept of the proposal. Once we're clear on that, then we can see if it can be practically implemented within the constraints of any particular blockchain network. However, as a short answer, the revision occurs in the same way that it would as you have referenced here. Instead of specifying a scalar value, you specify a function of t. If you wanted it to resolve to a scalar value, then your function would just be invariant on t and return a constant value.

If i'm understanding you correctly, you expect each steward to both design a function that accurately matches their valuation and deploy in in code?

Yes. However the functions will likely be very similar and any perceived complexity in this could be addressed by UX. My guess is the function may have a shape like this:

Here, x is time, y is price. Each owner would likely have a similar shape and either shift it up or down and/or skew it to their preference. As you can see in the graph, owners would probably price their asset very high in the short term, when x (or t) is closer to 'now', as the price at x is the price one must pay to take control of the asset at time x. They can effectively price out a short term attack as mentioned in this article. As you move further out in time the price can drop more quickly down to what would be a traditional 'market' price.

When calculating tax owed, you accrue the tax pro rata based on the average value of the function over v(t=0) to v(limit) instead of accruing based on just a single scalar value as with a traditional HT.

In all cases, on title transfer

But when does that title transfer occur? With a system like HT, where something is always on sale, does the transfer occur as soon as a property is sold? Or is there some grace period? In my proposal, this is explicitly priced and specified. To take control of a property instantly you'd pay the price at t=0; to take control in 30 blocks, you pay the price at t=30. In the case of a name system, taking control means having write access to that particular name. So if you want write access right away you have to pay the t=0 price (which would likely be extraordinarily high to prevent short-term takeover attacks). Paying the price at t=30 means you pay that price into the smart contract escrow (and at the same time register your valuation function), but you still do not have write access to the name. That wouldn't occur until 30 blocks have passed.

The good thing about this is now the current steward (and public) can see that there is a sale pending which will go through at t=30. If the current steward wishes to keep control at that time and block the transfer of control, then they have that time to re-register at a higher valuation, and if they are fine with the proceeds from the sale then they can do nothing and let the sale go through and the funds will be release from escrow at that time.

With such a system we can price out short term takeover attacks, while still keeping costs low for the owner (since they are taxed on the average of the whole curve, not just the single high scalar price which is necessary to prevent an attack).

you expect the steward to price and include within their valuation function the cost of a hypothetical transition?

Yes, but this is no different of an assumption than with a scalar value, as that also has to price in transition/transaction costs.

[will-holley]

@stxnomnom – You are greatly oversimplifying the function. If all the problem space of functions were limited to such simple logic, then it would be possible to encode this into the respective-blockchain's virtual machine without changes to the underlying contract code. In reality, however, I may have more complex logic, such as pricing as a derivative of some future event which is undefined at t = 0 and thus cannot be encoded or is entirely off-chain. Rather than trying to capture this complexity in the contract logic itself (ultimately, technically, separate contracts per-function would likely be the solution, requiring the steward to actually code their function), re-appraising at each respective time t alleviates this need with no accuracy or efficiency sacrifice.

I agree that transition periods may be necessary, such as in the case of a domain name, but this is agnostic to the HT logic (and depends on the mechanics of the asset in question). For that reason, the transition period does not inherently effect the pricing logic unless the transition period is a function of price, which isn't a design requirement for a HT system. Now, to be practical, domain names should exhibit a transfer period in order to update records, etc., and I agree that it should be fixed and encoded a t = 0 such that all parties are aware and can price as such. To use your example, if Bob purchases at t=0, transition period is tp=5 and Alice purchases at t=30, perhaps Bob maintains custody until t+tp=35, i.e. Bobs pricing always should factor in the "free" 5 periods.

[stxnomnom]

I may have more complex logic, such as pricing as a derivative of some future event which is undefined at t = 0 and thus cannot be encoded or is entirely off-chain

Doesn't using a scalar value also suffer from this issue? You react to external events by updating your valuation. This is the same with my proposal.

re-appraising at each respective time t alleviates this need with no accuracy or efficiency sacrifice

Re-appraisal can still occur with a function. Just as the scalar value is not set in stone at t=0, neither is the valuation function. And also you cannot effectively defend against a short-term takeover attack by using a scalar value while keeping the tax affordable which is the major impracticality of an HT. That's what you gain from this system.

he transition period does not inherently effect the pricing logic unless the transition period is a function of price, which isn't a design requirement for a HT system

My proposal ultimately addresses this though. Being able to define (price,time) pairs which define when the control is transferred and at what price so there doesn't need to be some arbitrarily picked transition period (which could depend on asset and individual). If you don't want someone to be able to get control at t=0, then you just define a price for t=0 that effectively prices anyone out. And if someone does end up paying that price, then you are happy about it as you've set the price to be worth it.

[Hero-Gamer]

Maybe speak to the BNS community + Mechanism team to see if they have any comments?