In our partial common ownership system, the self-assessed value and contribution rate of a parcel are directly related, but separate values (i.e., given the required network fee % you can calculate one from the other).
Due to the nature of smart contracts, we shouldn’t store both of these values. We store one and derive the second. The fee rate must be stored in the contract so in the future it can be adjusted.
This topic is created to explore and explain the implications of the decisions that we make for both how these values are set by the user and how they are stored in our smart contracts.
@codynhat Correct me if I have any of this baseline information incorrect:
In the v0 contracts, we stored a parcel’s self-assessed value, its expiration date, and a global fee rate. If we changed the tax rate, we would have needed to recalculate and update every single parcel’s expiration date.
On the Cadastre, we required the user to enter their self-assessed value and network fee deposits. This was used to calculate the stored expiration date and an implied per second contribution rate for network fees.
In the new architecture contracts, we are storing the parcel’s per second contribution rate, its expiration date, and a global fee rate. If we were to change the fee rate, we could keep each parcel’s per second contribution rate the same (the user can always change it manually) and only the implied self-assessed value would need to change. This would avoid the requirement of a major smart contract update when rates change. It is also assumed in partial common ownership that a user values a parcel of land based on the ongoing marginal utility that they gain from controlling the land (i.e., their perceived marginal utility >= the assessed contribution rate that they’re willing to pay). Changing the fee rate doesn’t fundamentally alter the utility of a parcel, so from an economic perspective it makes sense to keep the contribution rate unchanged and change the self-assessed value. In practice, market participants might not think like this, so regardless we must implement any rate changes very slowly, publicly, and with lots of education/fair warning.
The other implication of storing the per second contribution rate pops up in the UX of the Cadastre. Per second contribution rates introduces the potential for rounding weirdness as we roll up from a per second value to self-assessed value (i.e., we might not see pretty round numbers). We also must determine if we want the user to enter their desired contribution rate (and encourage thinking that matches the underlying market incentives) or use the “easier” method of having the licensor just enter a self-assessed value.
Great summary. Here’s how I think of it. You can view these parameters as a formula:
Parcel Contribution Rate = Global Network Fee Rate * Self-Assessed Value
When the Global Network Fee Rate is changed, either the Parcel Contribution Rate or Self-Assessed Value has to change in order for the other to stay constant. Whichever one stays constant is the one that we should store as smart contract state in order to prevent a major migration. The non-constant can be calculated on the fly.
So, which one should be constant? You mention the economics above and having the Parcel Contribution Rate be constant, which I agree with.
As for the Cadastre UI, the question is which parameter should the user be able to edit and which one should be calculated? It does not have to be the same as which is stored as state, but as mentioned that will be affected by rounding weirdness. Overall, this is very novel territory and is really about the user experience of SALSA itself.
Is there existing research from RxC that we could learn from? Or is there some way we can experiment and see how users behave in each design?
Yeah we should definitely explore this with the PCO/Harberger-focused crew. It seems that we’re the first ones pushing the potential scales where a mass update of Self-Assessed Values would be a big deal. This will be a good thing to bring to the table.
If we’re committed to storage of the Parcel Contribution Rate for technical reasons, then there will be inherent rounding weirdness no matter which input method we choose. The input method & calculation display are basically just window dressing. It wouldn’t be too difficult to allow the user to choose which input method they want to use: enter their Self-Assessed Value → display the calculated Contribution Rate and vice versa.
The new implementation stores Parcel Contribution Rate as the constant. The only additional reason besides that making the most economic sense to be constant is it may make it easier to have streaming payments in the future (or other unknown payment methods). This is due to Parcel Contribution Rate also being the actual amount of fees being paid vs storing the Self-Assessed Value means the amount being paid is calculated.
There’s definitely some UX optimization to explore, but the basic idea would be that there’s a single field for entry of a numeric value + a dropdown/radio button allowing the user to choose between Parcel Contribution Rate or Self-Assessed Value entry. Depending on the user’s choice, the other value would be calculated, correctly labeled, and dynamically displayed as a non-editable value along side the entry. They can swap back and forth between the options always seeing both values, but we only write the Parcel Contribution Rate to the contract.
I don’t have your smart contract code in front of me, but if I’m reading this correct, @graven is proposing the implied rate per second existing as the return value of a computing function rather than an explicit state variable? And the reason it’s currently set as state variable is to provide some future-proofing for streaming payments?
Not sure if this is helpful, but here’s my implementation: