-
Notifications
You must be signed in to change notification settings - Fork 84
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Updated Harberger Tax Model for BNS #118
Comments
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. |
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? |
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. |
@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. |
@stxnomnom, this would only be true if the steward is able to predict all of their valuations at time |
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? |
|
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. |
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?
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? |
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.
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.
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).
Yes, but this is no different of an assumption than with a scalar value, as that also has to price in transition/transaction costs. |
@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 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 |
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-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.
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. |
Maybe speak to the BNS community + Mechanism team to see if they have any comments? |
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. |
@Hero-Gamer Thanks for the suggestion, could you share a link to the repo where BNS/Mechanism-specific discussions take place? |
@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.
Generally agree with this here, however so much of the value is in the namespace itself (i.e.
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. |
This a continuation of my previous comment where I'll describe a mechanism that has the following benefits:
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. |
would anybody be interested coming onto SIP call and present this proposal to the community? |
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.
The text was updated successfully, but these errors were encountered: