Problem
Columbus 3 instituted a five-fold tax rate increase to 0.5% to boost staking rewards. As expected, this resulted in a notable rewards spike. Nonetheless, the on-chain calibration algorithm, whose job is to ensure a gradual and steady increase in rewards, has – counterintuitively – kept increasing the tax rate (0.625% at the moment). This has occurred because the rewards benchmark was re-set in Columbus 3 – simply put the calibration algorithm can only consider the trend in rewards post Columbus 3. Transaction volume has not grown sufficiently in recent weeks (after Columbus 3), therefore the algorithm has reacted by increasing the tax rate. The lack of historical context (rewards pre Columbus 3) has resulted in action contrary to the algorithm’s intent.
Proposal
I propose a temporary freeze in the tax rate until sufficient reward history has been established and the volume uptrend resumes. This logic was previously implemented in Columbus 1 in the form of a 12 week “probationary” period during which the tax rate is fixed. A similar measure would make a lot of sense here and solve the “lack of history” problem.
Please share your thoughts/alternate proposals. A formal governance proposal will follow.
Why don’t we just leave it at 0.5% fix? I am sure merchants would prefer a static tax rate (as they are relatively used to from credit card networks), vs something that could change by 20% in a month. I understand why we initially implemented the variable rewards when there was little transaction volume, but that time has passed and Terra is able to sustain its validators even with a 0.5% rate.
I like the idea of a fixed fee, but I am not sure how the fixed fee would protect network security in face of foreseen and unforeseen shocks. If a fixed fee would pose risks to the network, I support the freeze.
On another note. Are there any efforts to transfer the tax rate factors history to subsequent network upgrades? This seems to be a more suitable solution than having to put a band aid on the tax every time there is a network upgrade.
As @gaia pointed out, the ability to vary the tax rate is key to system stability. The protocol needs a way to provide stable staking rewards, and the only way to achieve this is by making the tax rate countercyclical. Your concern about merchants is valid, but we have found that a variable tax rate is not a problem insofar as Terra is offering fees that are notably lower than competition.
Maintaining historical context of rewards and tax rate between forks is certainly the way to go, and would have prevented the need for a freeze had we done so in the Col 2 → Col 3 transition. The core dev team has already put together a fix that will obviate the need for similar measures in the future.
Polychain Labs has read the on-chain proposal and this forum posting and for the following reasons intends to vote No.
The on-chain proposal does not reference a final and immutable proposal but instead references an on-going forum discussion.
No parts of the proposal indicate an implementation plan or strategy. How, by whom, or when would this go into effect if it passes.
The author has outlined a potential quirk in the algorithm but has not made it clear that this behavior is unexpected or problematic for the continued operation of the network. The author indicates the algorithm will correct itself over time and thus seems to be behaving as designed.
We do not feel that this proposal as presented on-chain is a reflection of how we would like to see healthy on-chain governance function.
The proposal to set “Windowprobation” to 18 (as argued above) is final and immutable. If the proposal passes, the parameter change activates programmatically on-chain.
“How, by whom”: The change is programmatic and on-chain. There is no human intervention.
“When”: If the proposal passes, it will activate on Wednesday, February 5th 2020, 5:15:38 pm KST.
The continued increase in fees is contrary to the intent of the on-chain algorithm, which is to create stable/gradual increase in rewards. Fees are likely to approach their 1% cap if the proposal is not implemented, thereby burdening the network for no reason (rewards have been increasingly rapidly as is). Furthermore, increasing fees during a boom gives no room for fees to increase during a bust, which is the key premise of the stability mechanism. The current trend may therefore compromise the network’s future ability to keep Terra stable.
@nplatias Thanks for the clarifications around how the proposal will be executed. I see now that parameter voting is available whereas I was not aware of that when we first looked at the proposal.
Could you clarify the relationship of the Windowprobation parameter to the tax rate? I read the above posting but have not internalized how a value of 18 translates to your desired outcome.
@Roman@xinshudong Windowprobation specifies the number of epochs (weeks) since Columbus 3 genesis during which the tax rate is frozen. At the time of the proposal 6 weeks had passed since genesis, therefore 18 weeks achieves the desired result.
Hi there @nplatias ; upping this topic 1 year later : Why the tx fee is still locked à 0.607% a year after proposal 4 passed ? I though the Proposal was to temporarly freeze tax rate for 18 weeks.
As our current probation period is 18(set by this governance proposal), and one epoch is 100800 blocks, The dynamic tax_rate change will start at 1,915,200 blocks. As current block height is 1,815,233, this is 99967 blocks from now on and it is approximately one week from now.
