Tax rate changes

[will-holley]

Notes from 21/11/22 Working Group Call

• When tax rate changes, how does owner's perception of value change? What does owner expect to happen?
  • Emotional: anger, confusion, etc.
  • Are people thinking about value in terms of what they receive in a subsequent sale?
    • Focusing the owner's mind: "What is this token worth to you?"
    • More of a mental lift to start with rate that owner is paying and then think about valuation? [Matt]
  • Property tax increases diminish value
  • How do we make this change intuitive for owners?
• Under some circumstances, should self-assessed value automatically update?
  • Minter: Toggle for owner to update the rate or the self-assessed value?
• Class-Wide (Global) vs. Per-Token Rate Changes [GeoWeb]
• Technical
  • What information should be stored in state? Storing rate, expiration date, taxation amount?

[gravenp]

Thanks for taking notes, @will-holley!

My attempt to summarize the challenge is finding the right balance between the user experience of partial common ownership, technical limitations/implications of smart contracts, and economic reasoning.

It's currently a big lift to convince people to adopt this radical property rights system, so making it easy to understand, use, and manage should drive a lot of design decisions to start (without sacrificing the core principles). This challenge is most apparent in the question and implementation of, "How am I even supposed to price property under this new system?" Pricing is a complex often subjective question even in traditional property rights systems. For many it's just an exercise in +/- from an existing market reference. So... what do we do without a good existing reference?

My initial reaction was to embrace bottom-up economic reasoning: have users set their desired tax/fee payment rate and calculate their self-assessed value accordingly (Self Assessed Value * Tax Rate = Payment Rate). There are two problems here. As Matt pointed out, most people aren't used to thinking in discounted cash flow terms and may prefer to just set their price directly and more subjectively. The second is that if you key off the tax payment rate (both from a user entry perspective & by directly storing the payment rate in the smart contract) the implication is that a change in the tax rate would immediately, proportionally lower all self-assessed values and the total market value. That could be quite jarring. In non-smart-contract-intermediated markets, changes to a tax rate would be factored into self-assessed values over time. There would be downward pressure from a tax increase on value, but you would also assume that the tax rate increase is being driven by a desire to pay for useful public goods, services, etc. that increase market value. How those two forces net out is up to the market.

Given the above, I now lean toward embracing the subjectivity and complexity of all that goes into a self-assessed value in the design and implementation of a PCO smart contract. Because changes in a tax rate would have complex impact on the market's value, we shouldn't try to bake in too many hard-coded assumptions. There isn't a perfect or certain answer, so it seems that defaulting to the self-assessed value staying constant rather than the payment rate (effectively one or the other needs to be stored in the smart contract and you don't want to have to do mass updates) is the safer choice. Users can and should update their self-assessed values and implied payment rates, but they can do that over time, factoring in their personal perspective/information to come to a new equilibrium.