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?

[314159265359879]

Interesting discussion. novel maybe, I doubt there will be many people wanting this. Quiet bad for current holders if applied to existing namespaces/names. There would have to be a real need/pain with current model to convince current holders to adapt such a change, I think.

Having just the option for future namespaces leaves current ones untouched seems like the superior options. Permissionless open network with choice for the user. If proves superior users will transition naturally. Perhaps it will useful for specific use cases, al the more reason to add optionality rather then a one-size-fits-all model.

That still leaves the question how to practically implement such a scheme.

[stxnomnom]

@Hero-Gamer Thanks for the suggestion, could you share a link to the repo where BNS/Mechanism-specific discussions take place?

[stxnomnom]

@314159265359879 Thanks for adding to the discussion! Your concerns are certainly valid, and I share the concern as to how it may be difficult to incentivize current owners to move to this model considering they currently are able to obtain names inexpensively. I'll provide a few arguments as to why I think it could be in their best interest still to move to a model as proposed.

1. As proposed above, yes, current owners would likely pay more for their names. I would argue though that holders of BNS names are also holders of STX so they would benefit from STX itself increasing in value. All things equal, STX gains in value as more of it is burnt through BNS fees. So when BNS registrations only require a small amount of STX burnt that is not close to the actual market value of the names (what one could get in a secondary market sale), then that represents value that is not accruing to the STX token and thus negatively affecting their investment in STX. Now, you might say that they'll capture that value from the sale of their domain names and it will end up being a wash. The problem with this, is that it requires them to speculate on much more illiquid and uncertain assets (BNS names) in hopes to potentially capture that value at some undetermined time in the future. Whereas, they wouldn't need to speculate on individual names if they could just hold STX and have the value of BNS accrue to the STX token directly through higher fee burns.

2. While my first point may be sufficient on its own to persuade the Stacks community to move to this type of model for BNS (implementation concerns notwithstanding), I think there may be a mechanism where BNS owners can actually pay less or nothing at all for their names (in a specific case), and have more liquidity for them. If this were to be the case, then that could be the incentive we need to transition. I'm still in the process of developing the idea that can deliver this, and I'll detail it in another comment.

Having just the option for future namespaces leaves current ones untouched seems like the superior option

Generally agree with this here, however so much of the value is in the namespace itself (i.e. .btc), that it would be hard to make an actual comparison solely on the merits of the models if the proposed model was implemented under a less desired TLD.

That still leaves the question how to practically implement such a scheme

Indeed, as always, the devil is in the details. My main goal with this issue is to work through some of the conceptual ideas of this and try to drum up some discussion in the community and hope to get some new ideas, both in support, and against the proposal.

[stxnomnom]

This a continuation of my previous comment where I'll describe a mechanism that has the following benefits:

1. Provide potentially cost-free access to names (only in a specific case)
2. Increase liquidity in names
3. Have a market-based tax rate for each name
4. Make BNS names a yielding asset for non-owners

In my original post, I used an arbitrary tax rate of 2% as an example, however it would be nice if we could come up with a market-based tax rate instead of an arbitrarily chosen number.

By using a valuation as a function of time instead of a mere scalar value, we now have an extra dimension to our valuation: time. Since we have this, we can now see how price changes over time. From change in price over change in time, we can get an implied yield. Perhaps we can come up with some sort of a construction where we can use this new information that's afforded to us in the proposed model to impute a tax rate based on this implied yield.

Moving on.

How could someone get a cost-free domain? Well, just because they've specified a valuation curve for the domain, doesn't mean they necessarily have to pay a tax on it. If no one else is interested in the name, then maybe they shouldn't have to pay anything. However, another party could come in and 'force' a fee payment to them, from the domain owner by registering their own valuation curve and collateralizing it. This, in effect, acts as a collateralized bid. Other parties can essentially 'stake' (lock up their capital for a period of time) against a domain and thus manifest the fee payment. I don't know what the exact formula would be to determine the fee amount, but it seems there could be some construction we could come up with that is dependent on 1.) the various valuation curves registered by different parties and their implied yields over some period of time, and 2.) the amount collateralized.

So how does this increase liquidity in the names? Other actors are incentivized to bid on and post collateral against domain names as they are then able to collect a fee (as determined by some future specified formula as previously mentioned) from the owner of the domain name. Should the owner wish to not pay the resulting fee, they could instead update their valuation function to be 'below' the bidder's and can sell and start capturing the fee from the new owner.

Would appreciate some help with filling in the details on how this can all come together and figuring out what formula we could use that takes into account the 2 parameters I listed above.

Why would current BNS owners want this? They won't have to pay anything for domains that no one wants which saves them from the costs of speculation. Others are incentivized to give bids on domain names so they can capture the fee. These bids give speculators increased liquidity.

[Hero-Gamer]

would anybody be interested coming onto SIP call and present this proposal to the community?