Having fiat goals can be dangerous because it can cause a death spiral.
- $ATOM price goes down
- Tax Raise (delegator revenue decrease)
- $ATOM staking dis-incentivized
and then 1,2,3 repeats again and again like the UST-LUNA case.
3 Likes
Hey everyone,
@Damien Thank you for brining up the subject and initiating discussion around it.
@BlocksUnited Thanks for the great recap.
Thanks to @ Adriana, @ RobbStack, @ LittleLionMan, etc. for bringing up ideas about a dynamic and adaptable taxation rate for the community pool.
Through this post, I would like to propose and bring to your consideration a fairly simple adaptive taxation model for the chain based on only three (3) parameters:
- the value target for the community pool (in tokens),
- the minimal taxation rate (to ensure minimal community pool funding), and
- the maximal taxation rate (to ensure the taxation rate does not become too extreme).
Put short, the idea is to set a target value we would like to have in the community pool (e.g. 10M $ATOM), and then let the dynamic taxation rate adapt (within a given range, e.g. 2%-12%) to reach this goal while staying in the allowed range.
This means that, if the community pool is in dire need of funding (like it is at the moment), the taxation rate would reach the upper bound of the allowed range (e.g. 12%). On the other hand, if the community pool is well funded and the target is close, met or exceeded, the taxation rate would tend towards the lower bound of the allowed range (e.g. 2%).
More formally, the proposed model is as follows.
Objective
Make the number of tokens in the community pool T tend towards the
target T^* while keeping the taxation rate \tau between lower
and upper bounds, respectively \tau_{min} and \tau_{max}.
T \rightarrow T^* | \tau \in [\tau_{min}, \tau_{max}]
Parameters
Target: T^* = 10000000 tokens
Minimal tax rate: \tau_{min} = 2\%
Maximal tax rate: \tau_{max} = 12\%
Token Issuance
Issuance rate: I_r \approx 9.6 tokens/block
Blocks per year: B_y \approx 4360000 blocks/year
Yearly token issuance: I_y = I_r \cdot B_y \approx 41856000 tokens/year
Daily token issuance: I_d = \frac{I_y}{365} \approx 114674 tokens/day
Community Pool
Current tokens: T \approx 1240000 tokens
Missing tokens: \Delta T = T^* - T
Taxation
Taxation rate: \tau = \operatorname{clip}\Bigg( \frac{\Delta T}{I_y}, \tau_{min}, \tau_{max} \Bigg)
Pool allocation from taxation: I \cdot \tau
Thus, as the community pool grows, i.e. T increases, the number of missing tokens \Delta T diminishes, which in turn reduces the taxation rate \tau. On the other hand, if some of the community pool is spent, i.e. T decreases, the number of missing tokens \Delta T augments, which in turn augments the taxation rate \tau to refill the pool.
I ran some simulations of the model, assuming a community pool spending of 25k $ATOM every 30 days, and the results are as follows.
VoilĂ ! Just more food for thought.
Always glad to read your comments and ideas.
Have a good one,
2 Likes
Hey everyone,
We would like to thank those who are actively contributing to this discussion. We are very happy with how it is progressing and how there seems to be a mutual agreement between the majority.
From what we have gathered in the forum and during the course of the Twitter Space discussion, we would like to present a short summary followed by what should come next.
The plan for this initial proposal was to keep it simple and not to bloat the proposal. There have been a lot of talk about incorporating a dynamic tax rate based on voting power and even talk about having automatic/manual adjustments to the tax rate based on parameters that are evaluated every so often. These ideas are all really good and should merit their own discussion after this proposal as we think that they will add more value to this.
We consciously omitted such options because we wanted to keep things simple and create as little controversy as we could with our proposal. We took this proposal as a âFirst Stepâ and part of a greater roadmap.
The need for a bump to the Community Pool is understood by all involved. We still urge those who have their reservations about this to join the discussion so we can aim to have a collective agreement on the way forward.
We hope that the discussion wonât die out after this proposal goes live as we hope to continue discussing a collective roadmap and set of goals going forward.
We are hoping to put this proposal On-Chain by the End of Year 2022 (could be before) with a proposed Community Pool tax rate of 10%.
5 Likes
Hi @Saphyl,
Thanks for your thoughts. The Hub held a Twitter spaces a couple days ago and the dynamic tax came up. There currently isnât code to run a dynamic tax, so those on the call thought it best to start with a 10% tax to fund the pool. That would then pay for devs to figure out how to write code for an automated dynamic tax.
You can listen to the Twiiter spaces here:
2 Likes
End of year is a stretch for a discussion period but Iâll support it. If thatâs going to be the case then I think the voting period should be short as well to not 14 days but 5 to 7 days. If the standard is to have a 9 to 13 week discussion period before the proposal is up then so be it as well. We should write down the implicit expectations so we are not fighting about it later.
2 Likes
Hi @BlocksUnited,
Unfortunately, I could not attend the Twitter space live, but I did listen to the recording. Good discussion.
To clarify, I am totally fine with starting with a fixed 10% taxation rate for now. I think it is a fair value to start with that, as you mentioned, will allow devs some time to figure out the dynamic taxation rate. I am open to moving my dynamic taxation rate model proposition to another thread if need be. 
The model I proposed was mainly to start discussion on how to go about such a dynamic taxation rate while trying to keep it as simple, yet formally correct, as possible. As proposed, the model would start with a fixed (max-capped) taxation rate for about the first year anyways due to the underfunding of the pool, which is very well aligned with starting with a fixed 10% rate to get things started.
Again, I am open to moving my dynamic tax rate model proposition to another thread to keep this proposal draft thread simpler.
Thanks for your feedback,
2 Likes
I love this!
It is a simple, understandable model to explain but will take care of a proper funding of the community pool.
Start with a fixed fee, work towards this dynamic model. And it can be copied more-or-less from the bonded rate and the staking APR where a dynamic rate is already in place.
1 Like
Maximizing model and code reuse by following a logic very similar to what is already in place with the dynamic staking APR is exactly what I was going for. 
I think it is important to keep things as simple and understandable (yet also formally correct) as possible while facilitating implementation, and reducing the time and effort required to make such a model operational.
Other important considerations were to minimize the number of model parameters (to reduce governance overhead while remaining flexible) and to provide decent (in my humble opinion, and definitely adjustable) default values.
2 Likes
I would love a hard cap for ATOM but I know itâs not thats simple, that saidâŚwhy not spin up a stake pool (or two) for the treasury while keeping the 2% tax (and/or incrementally increase the tax up or down dependent on need)?
Correct me if Iâm wrong but wonât ATOM benefit a lot with implementation of IBC rented security? If so, is this being taken into consideration?
2 Likes
wouldnt a dynamic rate come with an incentive not to fund from the pool because it corresponds to an increase in tax to voters?
1 Like
True, but you need to see it the other way around.
We can go for a fixed fee of 10% from now until infinity.
OR
We can go for a dynamic fee which takes the amount of funds in the community pool into account. Upper level can be 10-12%, but it can also be lower. So in predictable circumstances the fee can also be below 10% (and thus be positive for stakers in terms of APR)
1 Like
IBC rented security (ICS) can indeed be a good money-maker, but we donât know yet.
Note that the fee for funding the community pool is not linked to ICS. The funding for the community pool is to be able to fund projects building on the Hub, which might be chains with ICS (but if I understood correctly it does not necessarily be the same)
1 Like
Got itâŚbut would it be safe to say that the financial benefit from ICS wonât be zero? Is it to say that fee from ICS canât be liked in some way? I ask because that I think itâs better than increasing the supply. Without a hard cap it gives way to uncertainty about infinite printing which is the whole conundrum that. the USD faces.
Thanks for the Twitter Space and the summary.
It seems like 10% increase reflects the public sentiment adequately.
But perhaps the on-chain proposal should be up pretty soon before the community loses momentum on the ATOM2.1 vision? Iâm afraid people will start forget about everything by next year.
5 Likes
A sort of âdynamicâ tax rate sounds interesting indeed, however what concerns me is that this might take longer time and efforts to design a more sophisticated version with detailed plans.
We can initially start with 10% for all, then adjust the rates of validators according to a more detailed standards in the future.
2 Likes
photon could act as a larger denomination of atom with a hard cap and limited redemption /month back into atom.
1 Like
With a 10% community tax rate, the difference with atom 2.0 issuance will be the timing to get the fund ready. On the Atom 2.0 whitepaper, a 4m atom will be issued once after passing the governance proposal. With community tax, getting 4m atom would take around 1 year.
Do we know what would be the first project to use this funding? And what is the timeline? Thanks.
@Damien I see that the original post was edited to indicate that the proposal will go up by EoY (or sooner). And it seems that soft-consensus has been reached about a path forward re: community tax.
Do you think we could move toward a more specific last-call date for sometime in early December, such as on December 5th? This way, the vote will wrap up before many people go on holidays, and we can hit the ground running in 2023 with discussions of a collective roadmap and how to come up with a budgeting framework for the community pool.
Just my 2c and thanks for all of your work here.
1 Like
I agree with both what you have to say and what @Gorany has said too.
With this in mind and with consensus reached, we will be putting up the vote in 7 days time (Monday 5th December) with the aim of having it pass by the end of year so, as you said, we can start 2023 with this in place.
As I want to reiterate again, this is just the first step of many improvements to be made.
Thank you all, looking forward to keeping the discussions going!
6 Likes
Wonderful to hear, thanks for your work on this. Also, for visibility reasons, it might be worthwhile to update the proposal title to last-call.
Additionally, perhaps we can gather some others to publicize this last-call date so no one is caught off-guard that the discussion period is coming to a close.
Some places itâs worthwhile to post (apologies if I miss anyone, not sure who this is relevant to):
- twitter ( @catdotfish @RobbStack @Adriana )
- Community $ATOM Governance Discussions ( @johnniecosmos @Cosmos-Harry )
2 Likes