[PROPOSAL #88] [ACCEPTED] Increasing Hub Community Tax

Update 05/12: Post went on-chain and slight amendments made to fit the 5000 character limit Update 28/11: After seeing that consensus is pretty much reached, we are pushing the date of when the vote goes on-chain to Monday 5th December (7 days from now). Update 25/11: 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%. Background Over the past couple of weeks, there have been a lot of fruitful yet sometimes heated discussions regarding the ATOM 2.0 tokenomics. ‘Why do we need to create a treasury’ was asked regarding the proposed overhaul of the tokenomics model of the Hub and oftentimes the general consensus would be that it’s to future proof funding for the Cosmos Hub and anything that would need to be built or funded. The proposed solution was to have a direct mint of tokens to a treasury pool. However, the Hub already has a Community Pool that has been used in the past for various community spend proposals. This pool is funded through taxation on a per-block basis. The current tax rate (as will be discussed further below) is 2%. By increasing this we can achieve a similar outcome…

Excerpt (1197 of 5145 characters). Read the whole post on the forum ↗

Thanks for putting this up, I believe is necessary to properly fund the community pool without minting more tokens than necessary, equally important is how to manage those, but thats a topic for another thread

I think we could try with a 5% tax, as a staker that is something I feel comfortable with and its justified.

What would be the plan in case community dont want a tax increase? would love to read other ideas but the goal is clear, we must have a well-funded community pool

I don’t think its a good idea to reference the prop 82 debate in the final on chain proposal as this proposal is supposed to be a unified consensus. I also think the title should include something like ATOM 2.0 - part I, to kind show supporters of prop82 that this is being derived from the 2.0 WP.

My other concern is are we publishing this proposal with code or would it be another signal proposal?

Ideally once we discuss an ideal tax rate going forward, then this proposal can go up with the appropriate JSON file to change the param

Increasing Tax means the burden of filling up the pool/treasury falls on the shoulders of stakers only whereas in the case of front minting this burden is shared among stakers and non-stakers equally.

The second concern is the timing. In the case of front minting governance gets to allocate those assets immidiately while in the case of increasing Tax governance would need to wait for whole 12 months before doing so or allocate smaller amounts periodically.

That said, both models are very similar. It’s hard to support one and be completely against the other. While I see many advantages in front minting I’m almost as equally supportive of tax increase. Community pool is seriously underfed at the moment.

Hi @Damien, thanks for raising this.

I’m not opposed to a community pool tax increase, however I think that framing this proposal around relative $ value of community pool is slightly missing the point.

As a supplementary effort to this, we might ask ourselves why is the usage of the community pool so low on the chain that provides public goods for the ecosystem? Answering that question will help us further define an appropriate sized community pool for the Hub.

Additionally, rather than choosing an arbitrary dollar value to increase the pool by, it would make sense to outline what type of initiatives we would like to encourage and how we might go about doing so. The ATOM 2.0 whitepaper provides a strong start for thinking about that.

In the mean time, I fully support an initial proposal to raise this tax, though do note @Jazz 's point that in this case the burden for funding public goods (which support all) falls on the shoulders of validators and delegators, as opposed to a mint model which actually decreases inflation over time but equally spreads the cost across all ATOM holders.

There’s also been some discussion about removing the lower bound of the dynamic inflation (currently 7%) as part of the effort to slow down Atom’s issuance model. Many seem to be in favor of that, in addition to the community pool tax, so we would need to account for that if we are hoping to have a sizeable community pool. For example of why this matters: if the lower bound is removed and the staking rate rises with the release of Interchain Security and the liquid staking module, the nominal Atom value that ends up going to the community pool will be pretty underwhelming for giving the community some spending power. So, I guess you need to account for these factors. Do we want to reach a specific # goal of Atom going to the community pool per year, or by removing the lower bound, leave it purely up to the will of Atom stakers who decide to stake/unstake as usual? Also, another idea that can alter this idea is something Ethan brought up with AiB and the ICF possibly making a donation to the community pool: twitter.com Ethan Buchman (🐝,🦇) @buchmanster 9/ We’ve already been working on alternate approaches to topping up the community pool, using the…

Excerpt (1195 of 1411 characters). Read the whole post on the forum ↗

Hi @Damien Thank you for this.

Since it’s a part of 5 or maybe more subjects that are related to ATOM 2.0, could we get a more specific title for this? Just to make it easier to follow and differentiate it from other general topics.

Thanks.

To the point about stakers taking the tax burden on their shoulders, it must be noted that staking rewards are composed of the inflation of the total supply, including the non-stakers’ portion. From my perspective, this means that stakers don’t take the fall for an increase in tax, as it is imposed on the total supply inflation.

A 5-10% tax would be beneficial for the sustainability of the community pool. A lot of work still needs to be done around deploying these funds, however I think this is a good start and great discussion to be had.

The point on tax failing to raise sufficient atom was my main concern. I would like to see us review the tax rate at a frequency tbc to ensure we reach the target set in the initial wp within a year. If we are tracking behind tax should go up and if we are tracking ahead or the pool is not being spent then the rate should be reduced.

Agree to an extent but would like to add that staking isn’t the only way to offset the inflation anymore. There are many reasons to hold liquid ATOMs. LPing or lending being obvious examples.

So in case of front minting all ATOM holders get “diluted” equally while in case of taxes, stakers carry most of the weight.

Point being, with a simple tax increase, staking could become less competitive against other DeFi applications basically undermining the security of the Hub. (assuming we support tax increase before the adoption of liquid staking)

Interchain security go to market is dramatically underfunded at the current moment.

Teams who decide to partner with the Hub instead of being sovereign are going to need substantial amounts of bootstrapping funds and skin in the game from the ATOM stakers that will indicate likely passage of their deployment governance proposals.

Teams will need funding for security audits etc to convince ATOM stakers that their chains are ready to launch.

Some kind of permanent team for managing this will need to be deployed to manage these processes.

I would recommend increasing the tax rate asap.

Hi guys, Kam from the Imperator team. @Damien , thank you very much for this proposal. It’s clear that there is an important issue with this Community Pool compared to other chains: Cosmos Hub is the most mature chain in the ecosystem and it’s not ok to have such a small community pool - we need to solve this as soon as possible. Increasing the tax is a great solution as the concept of tax is already built in the system and works well. Now, the main point is to determine which percentage rate should we apply to it. There are few elements to take into account: • Find a rate that doesn’t bring more than what’s needed • Find a rate that doesn’t change the staking rate drastically Currently, the community pool has 1.25M ATOM and a tax rate of 2%. I think starting with a conservative rate of 5% is a good start as 2.09M ATOM would go into the community pool throughout the year for a total amount of 3.34M ATOM, all things being equal. This would represent 2.6x the current amount we have in the pool. Of course, this parameter is flexible: it’s easy to change it and adapt the rate if needed, and it is preferable to start conservatively. Regarding interchain security, I…

Excerpt (1196 of 1537 characters). Read the whole post on the forum ↗

I agree with Kam from the Imperator team.

KalpaTech is very much in support of increasing the community pool tax to a level of 10%. Part of our solutions proposed with the NWV vote was exactly this implementation, as the calculations show that applying a 10% community pool tax ( an increase from current 2%) will result in approx. 4 mil ATOM in the community pool/ year, the same amount which was proposed by the minting of the first tranche. twitter.com Adriana ⚛️ @adriana_kalpa 7/ 200M $ATOM are bonded on the Hub with a staking APR of ~20%, which accounts for an additional 40M $ATOM supply in 1 year. With a community tax of 10%, means that the Hub would be able to put ~4M $ATOM/year in the community pool. Same amount which is now requested to be minted. 9:18 PM - 5 Nov 2022 55 4 For reference, a calculation for the collection of ATOM in the community pool, with this new proposal, is showed below: • Bonded ATOM x Staking APR x Community Pool Tax • 203.06 M Bonded ATOM * 20.18% * 10% = 4,097,750 ATOM per year Parameters such as Bonded ATOM and Staking APR are dynamic. The calculation that accounts for an annualized amount in the Community Pool…

Excerpt (1199 of 1984 characters). Read the whole post on the forum ↗

@Kam Do you know for sure of the ICS project participants are well funded? Does that mean that you are ready to back up those projects in governance and encourage community members to do so when the proposals go up? Either way good to see you and @Adriana support this draft proposal of the tax rate.

the maximum bonded rate=7% inflation? how long do you estimate it might take for liquid staking to increase the bonding ratio to maximum? is liquid staking popular amongst validators? i dont really see the appeal of LSDs for most people. i know people say its liquid and you can earn more yield or whatever, but it is a bit of a pyramid scheme. same or longer bonding and just a farming token back if you LP and lock it up even longer in a token that isnt currently useful to sell because even if the price of atom drops by 90% the peg to atom/statom stays the same (if its true stride’s peg ratio is set to perpetually go up for stAssets?) liquid staking reducing inflation also makes the tax system less productive for the community pool, i assume LSD providers will strand enough votes to more heavily subsidize themselves by delegating to “incentive aligned” validators to vote for bulk printing or other restructuring of the monetary framework. I dont think that atom holders get enough out of the deal to compensate for the high risk of governance centralization under an LSD regime. The monetary framework of ATOM shouldn’t change its structure at the expense of atom holders to…

Excerpt (1190 of 1594 characters). Read the whole post on the forum ↗

Hi @Kam, thanks for the reply and discussion.

In response to the suggestion of a more conservative approach at first, wouldn’t it be more ideal to first front-load the pool at first and then propose a cut in the rate if deemed necessary?

This is purely down to human nature and it would be harder to convince if people see multiple proposals to increase tax rates rather than one tax rate proposal and then a possible tax cut in the future.

The funding through tranche of 4M Atom was one of the main reasons why Prop 82 was rejected with Veto. So if the community pool Tax increase will help to reach community consensus, I agree with this model. I think it could be interesting to consider a dynamic community tax based on the Atom bonded ratio. A community tax could incentives users/stakers to participate in Defi, in particular with upcoming launch of more Liquid Staking Providers that will likely set high early incentives. It could be defined a goal of Atom to accumulate yearly in the community pool and define a dynamic community tax to pursuit that goal. With the current Bonded ratio, 10% should be fine, but this percentage should be adapted to the increase or decrease of Atom staked. I liked more the Tranche model because the community tax model could cause instability in the Bonded Ratio that follows already a dynamic model for inflation, but I assume that long term contributors that stake an high percentage of Atom will remain delegated by supporting the community tax model, so I don’t see the Bonded Ratio dropping too much. But we can’t leave the creation of a budget to fund Hub development/expansion to…

Excerpt (1197 of 1617 characters). Read the whole post on the forum ↗

Thanks for the reply @Adriana good to see you are supporting the draft.

I agree with your analysis about the dynamic parameters that affect the community pool tax. In its current form, the likelihood that further adjustments might have to happen to the tax rate every so often can be quite high especially considering if a large shift occurs.

I personally like the idea and agree with you on the 10% community pool tax. Initially I think it is a good idea to front-load the community pool so that it can reach a somewhat reasonable level of tokens to support funding endeavours. And plus, as I mentioned in a reply earlier on, if changes were to occur it will most likely be for a lower tax rate and most likely the community will be open to lowering the tax rate if deemed necessary.

In the current game of chains, there are 4 projects: Stride, Duality, Neutron, Apollo.
Stride is already live and raised money, Duality raised money as well, Neutron raised money from the Hub to cover dev cost (prop 72 - we voted yes) and is raising, however I don’t know about Apollo - but this is still 75% of the current chains that don’t start from 0. I think it’s very important to help ICS chains, and depending on the conditions we will support them of course

Hey @Damien!

Yes that is right, on our side we’re totally open to any suggestions - what’s great with the tax rate is that it’s very flexible, let’s find something that suits most of us and go with one unique proposal otherwise it would be way too confusing.

It’s right that the current state of the community pool is alarming: starting with a high rate first to fill the pool and then reducing it when time comes is a great option.

@RobbStack
The current bonded ratio is ~60% according to Mintscan. If we decide to go for a dynamic rate with a 10% tax rate at the current bonded ratio, then the formula to get a linear dynamic tax rate would simply
be:
Tax rate = Bonded ratio/6

With a tax rate moving between 0% and 16.7%. For example, if the bonded ratio is 50, the community tax would be 8.3%.

I think I may be more aligned with increasing the tax first at 10% to fill the pool asap and reduce it once we believe that the pool is large enough. As we need to act asap, increasing it now to a fixed number might be the easiest solution. Let me know!

I’m very much in favor of this. I would propose to increase the community pool tax to 10%.

Tax raise is definitely a discouraging change for delegators and validators, but I agree that it is something that we need in order to move forward. I think we need to secure some funding that can be deployed for ICS development in a month or so. We can’t wait a full year for the community pool to be topped up.

Considering that we want to deploy 4M throughout the year, what about mixing the idea of community pool tax increase, foundation donations, and minting?

For example, let’s say we secure 2M through community tax raise; 1M through foundation donations; and 1M through minting new tokens.

This way, all groups of interest evenly share the pressure. Plus, we can secure some immediate funding from the donations and minting while preparing community pool for the future.

Hello Damien, tax rate may be one of the good options that we can suggest. However, we first need a place to gather real cosmos hub contributors to sit down and discuss on the tax rate before we submit a governance proposal. What is your opinion on gathering the contributors first?

Am in favor of increasing tax rate to 10% and frontloading the community pool. It’s true that any increases will be harder to justify than any decreases.

Starting now would give us approx another 1M ATOM by mid Q1 2023, coinciding with the launch of ICS. Once ICS launches and we see how the economics behave, we might see an increase in teams applying for funding, it would be good to have some dry powder.

Agree.

Although it may not be easy to agree on a new tax rate, bottle line is that a tax increase proposal should have a much higher chance to pass than minting new tokens.

Hi Jay, can you please be more clear on this point?
What more than the forum should be the place to gather Contributors’ opinions and feedback?
You seem to hint with your comment that the people commenting here are not real cosmos hub contributors. Differently, I think that people to rightfully call themselves real cosmos hub contributors should be actively involved in the convs that take place here, the temple of the hub governance.

Imo there seems to be a fairly good alignment towards the draft proposal, it’s more a matter to identify the percentage (5,10 or else)

I agree with your points regarding @Jay_Lee point. Contributors and everyone should make use of the forum to voice their opinions. This is the place where discussions should take place.

There is the option of having some sort of community call however I think the forum is sufficient to gather everyone who wants to have their say here.

Regarding percentage of the rate I think the ideal step forward, from what I have gathered, is that 10% should be the figure that goes onto the proposal. I believe many people here are in favour of front-loading the pool.

we can set up a Twitter space if you think might be beneficial to bring more awareness/reach a wider consensus :3

Its either mint or tax, since tax has more consesus we would like to support upto 10%.
We can always cycle back in a year and reduce this if this is not becoming usefull.

We agree with this proposal. It is good way to secure the funding and can be easily adjusted in the future.

No reason to push it to the max (10%) immediately just because you can. Secure the needed funding only. 7% should be enough.

Bit more modest proposal also gets through easier.

How about some cap for it in USD also? If 7% gives more than needed funding when ATOM is $10, is 4x more funding needed when ATOM is $40?

Thanks for the feedback. Just have a couple of questions;

1. In relation to the suggested 7% instead of 10% to secure the needed funding, what do you mean by needed funding? Is there a figure? The point of the Community Pool in my eyes is to have a sufficient amount of funding available for any type of project/grant/etc. that may need.

2. Relating to a previous post I made, having to raise taxes more than once in the short-to-medium term wouldn’t sit well with people hence why a proposed 10% was floated around. Wouldn’t it be best to again, front load the pool and then reduce to accommodate?

What a wonderful post. Thank you for caring enough to formally start this conversation. @Damien A front loaded community tax that’s dynamic and goes down over the next several years makes sense to us too. If it’s automated and decided ahead of time vs governance votes down the road it might make the most sense. You said, “having to raise taxes more than once in the short-to-medium term wouldn’t sit well with people hence why a proposed 10% was floated around. Wouldn’t it be best to again, front load the pool and then reduce to accommodate?” We agree completely, but worry that 10% up front is unpalatable too. The concern with going up to 10% is that it’s a 500% tax increase from current levels and that large of an increase on a percentage basis won’t taste good to those who oppose the idea. It’s an easy way to attack and one that proponents of a 10% tax should be prepared to defend. @Instafinanzas made the point that managing those funds must be discussed too. @FrancescoSVC also said, “A lot of work still needs to be done around deploying these funds.” So we believe some serious thought and preparation needs to go into a follow up signaling proposal or conversation. How the…

Excerpt (1199 of 3786 characters). Read the whole post on the forum ↗

@common_spelling said, “is liquid staking popular amongst validators? i dont really see the appeal of LSDs for most people. i know people say its liquid and you can earn more yield or whatever, but it is a bit of a pyramid scheme.” and “LSD providers will strand enough votes to more heavily subsidize themselves by delegating to “incentive aligned” validators to vote for bulk printing or other restructuring of the monetary framework. I dont think that atom holders get enough out of the deal to compensate for the high risk of governance centralization under an LSD regime.” We think these are pretty good points to discuss. We’re not sold on liquid staking yet either. When leverage goes against you, it’s a waterfall down to the bottom and we care too much about the Hub to ignore this. I come from the world of traditional finance. The other half of Blocks United comes from Silicon Valley big tech. I perceive the sound money philosophies of @jaekwon ’s followers to be important. Their view that if you’ve never managed money professionally, you don’t have enough experience to decide the fate of the Cosmos… is worth serious consideration. These huge decisions that the community is about…

Excerpt (1199 of 2245 characters). Read the whole post on the forum ↗

(first post ) Well, i wonder if it can be possible to make a proposal in the others chain (like osmosis, juno, evmos, etc) to give a special “grant” or “subvention” for the hub development.
I think as atom holder, i am also a juno, osmosis, evmos holders, etc then i will no mind.
I do know they are sovereign chain but that doesn’t mean their holder (or community) dont want to contribute.

Also a tax that is flexible might be the best option with fews conditions like

If % of atom staked is inferior to 60% = 10% tax or will stay at 10% for 3-6 months to increased community pool if atom staked < 60% then will decreased over time.

LS will make % of atom staked increased then we might not keep tax % at 10%.

We just have to figure it out the numbers.

Great Post, you most certainly looked into all the sides of the argument and summarized them all here!

I agree. There will be oppositions and disagreements over the percentages. But isn’t that the reason why we are all here having open discussions, making compromises?

Some of us think 10% is too high, some of us think 5% is too low. So maybe we start with 5%, but supplement the community pool with a little bit of minting or foundation contributions just for the initial stage.

Minting might be against our initial opinion, but I think making compromises are important in governance.

catdotfish: Hi Jay, can you please be more clear on this point? What more than the forum should be the place to gather Contributors’ opinions and feedback? You seem to hint with your comment that the people commenting here are not real cosmos hub contributors. Differently, I think that people to rightfully call themselves real cosmos hub contributors should be actively involved in the convs that take place here, the temple of the hub governance. Imo there seems to be a fairly good alignment towards the draft proposal, it’s more a matter to identify the percentage (5,10 or else) Hello catdotfish. Sorry if my words were not clear enough and somehow misleading. First of all, I feel like I need to clarify on this to make one thing super clear. You mentioned that ‘You seem to hint with your comment that the people commenting here are not real cosmos hub contributors.’ I didn’t hint or even say that people commenting here are not real cosmos hub contributors. I think people who are commenting here are the real contributors and I really appreciate everyone here who are actively discussing about the proposal. One thing that I wanted to suggest from the previous comment…

Excerpt (1198 of 1297 characters). Read the whole post on the forum ↗

Hello,

I’m only a “user” but just do give a perception feedback. Indeed, 10% looks a lot, especially as it will gives the same yearly value that has been rejected (4M/y, Cf Adriana post). 5 to 7% looks more OK, perception wise

Also I think it can be nice to put in comparaison the staking APR of ATOM compared to a lot of projects (ETH etc) where they usually get around 5 to 7% APR. So saying we go from 20% APR for ATOM to 18% APR for ATOM looks very OK and even maybe still a bit too high compared to others

Hello, thanks for starting this discussion. I think this is a reasonable first step forward. @Jazz I tried to explain this to you on twitter: It is a false narrative that a tax is worse for stakers. Blending out other market factors with the current frame of inflation the marketcap would stay the same while the supply increases. This means the value of a staked position would stay the same while a “hodl”-position would lose value over time (depending on the amount of inflation). If the sole aim is to raise a specific sum for the community pool and you mint it, this dilutes the value for stakers and non-stakers alike. If you have a tax, it’s true that it’s paid just by stakers, but they lose still less value in their atom due to inflation than non-stakers. In case of an inflation of 15%, non-stakers would lose the full amount while stakers would still have (100 - 15 * 0.02/0.07/0.1)% left per year. In an inflationary model stakers are definitely way better of than non-stakers even with taxes compared to a pure mint! That said, I wouldn’t mind one mint at the beginning. If it’s true what @zaki_iqlusion said and we need funds asap we shouldn’t be too picky in my opinion. As a…

Excerpt (1198 of 1708 characters). Read the whole post on the forum ↗

Hi, this is Fredy, from Dragon

Thanks Damien for rising the discussion topic.
We are in favor of a 10% Tax and we find no issue with this model.
We also would agree on a single minting event to bootstrap the process.

What we still do not understand is this sudden rush that some members have been showing up during prop #82. There was no such rush for years.
Possible causes most likely are external causes that affect other chains or personal projects. We think that the hub should not be influenced that way. The sovereignty of the hub should make us to act proactively, and not reactively or depending on external reasons.

Regards.

I think most of us here are in favor of raising community tax. But how much? How can we agree to a number? Should we have an early poll?

I agree with 10% tax.

However, what’s more important than deciding on the tax rate is asking the leaders of ATOM2.0 for the plan to use the budget. At this point, we don’t know how much Cosmos needs in order to execute ATOM2.0 vision.

First thing has to be a budget spending plan from the ATOM2.0 leaders! Tell us in details how much we need to spend to make ATOM great again.

I believe agreeing on a number might take some more time and deliberation from what I gather.

I point you to a Poll that @Adriana put out a few days back with this exact question - https://twitter.com/adriana_kalpa/status/1593988531348799492

I might argue that only Twiiter users were included so I bet that skews the results in some way. And only 716 people voted out of the many thousands who use Cosmos. I’d be interested to see the results from the same poll posted on Reddit, Telegram, etc. I’m not against 10%, especially since front loading the tax to fill the pool makes sense. Just curious to see if the results are any different on other social channels.

I posted the survey on Reddit: https://www.reddit.com/r/cosmosnetwork/comments/z11s39/in_order_to_build_a_more_sustainable_community/

Witval would fully support the idea of strengthening CommunityPool. But we are worried about flat-tax rate for all the valdiators. Lowerend validators already not making break-even, this flat increase of the tax to 10 or 20% would only make the things worst for them. We propose to make necessary updates to tax logic and introduce voting-power based tax. Like if validator has 10% voting power, they are entitled to pay 10% tax, if the validator has 0.5% Vp, they will only pay 0.5% tax on rewards

That’s an interesting idea.

Without question the Cosmos needs the funds to do proper BD. The 10% tax should be an initial investment and increased if success if found. In the next official prop, it would be great to see some sort of direct value accrual to the token, rather than the treasury itself from what are essentially venture-level bets (accepting fees for security in consumer chains’ tokens).

An interesting model to look at to balance inflationary security rewards and transactions is Elrond. In their white paper, they create a model where inflation depends upon Txs and is adjusted downwards as Txs increase their share of the security budget. Cosmos should consider implementing something similar combined with an incentive tax for ecosystem development.

After putting quite a bit of thought into it, Blocks United would support a 10% tax that dynamically lowered itself as the community pool met target funding.

I really like the idea of using the tax mechanism to increase the hub community pool and I would even go as far as increasing that to 15%.

But… We could take into consideration of using the progressive tax system which could even help with decentralization.

Lets say for example: stakers with less than 5k atoms would be taxed 5%.

ATOM stakers with more than 5k and less than 20k ATOMs could be taxed with 10%.

And all stakers with more than 20k a tax of 15%.

Interesting thought, but that would only cause people to fragment their wallets… and not achieve the effect you want to achieve…

I do feel something where the community tax is proportional to %VP. Then you would also stimulate decentralisation at the same go as filling the community pool.

Oh yeah implementing that on the validator %VP could achieve the intended goal.

imo, validators/delegators that are part of the top 1/3 should be taxed higher than the rest of the set.
Increasing the nakamoto coefficient while solving the funding for ICS would be a nice outcome for ATOM

Hey Guys,

Thanks for bringing up this discussion.

We do support a community pool tax increase, but before defining a % we should account:

• How much do we want to save per year? Should we settle this goal in terms of $ATOM or Fiat? If so, should we update this tax every quarter based on price action? A bearish price action should lead to a higher tax rate.
• Once ICS will be live, a funding schedule based on oncoming teams/projects might help us adjust the percentage to fit hub’s investments.

Considering that at the moment, the community pool has 1.25 million ATOM, we think a 10% target tax reviewed every quarter would be appropriate.

1mln every quarter, at the current price are approximately 9 million $, but it’s hard to determine where these market conditions will lead us, this is why we think it’s important to update this percentage constantly.

Hey @MadeinBlock, thanks for what you wrote.

I think in the long run, a sort of dynamic tax rate based on certain parameters and externalities per quarter or yearly is probably a good way to go or at least a good idea in theory.

I’m not sure if defining a goal in terms of Fiat is the best way to go to keep things relative. Having Fiat goals can lead to potentially unnecessarily high taxes especially, if for example, the price of ATOM were to dip significantly.

Here’s a Poll from CosmostationVD account on Twitter

Seems like there’s a little discrepancy between the results from Adriana’s followers and Cosmostation’s followers.

Cosmostation

Cosmostation’s followers dominantly voted for 5%.

Damien: Having Fiat goals can lead to potentially unnecessarily high taxes especially, if for example, the price of ATOM were to dip significantly. It is true, indeed, the purpose of relying on fiat-based goals should aim to a conservative and more realistic approach in terms of market conditions and we may also take in consideration to enforce a maximum tax variation per quarter. Let’s say that this proposal passes with: a 5% tax rate, a goal of 15 million $ (approximately 1.500.000 ATOM right now, 25% less $ATOM then what we are actually going to accumulate with a consistent 5% tax) and a maximum rate change of 5%. After every quarter the new rate should be based on the average price for those 90 days occurred. If the market lowered the average price, we may consider to increase the tax rate (still limited with a cap). If not, we can keep the same rate or even lower it. After 4 quarters, worst case scenario our community tax would be at 20% rate, with a total of 5 million ATOM (500,000 from the first quarter, 1,000,000 from the second, 1,500,000 from the third and 2,000,000 from the last one, considering a 5% increase for each quarter). In order to consider our…

Excerpt (1197 of 1252 characters). Read the whole post on the forum ↗

Full support from Citizen Cosmos on increasing tax to community pool. IMO, it should be in build into the inflation normally. i.e. everyone will be loosing a little staking reward. But thats life. I think token holders, by which im referring to each one of us that holds ATOM, should be prepared for many more pools like this to be created in the future. This is normal. We need to grow.

Having fiat goals can be dangerous because it can cause a death spiral.

1. $ATOM price goes down
2. Tax Raise (delegator revenue decrease)
3. $ATOM staking dis-incentivized

and then 1,2,3 repeats again and again like the UST-LUNA case.

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,…

Excerpt (1199 of 2816 characters). Read the whole post on the forum ↗

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…

Excerpt (1198 of 1560 characters). Read the whole post on the forum ↗

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:

Cosmos Hub ⚛️

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.

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,

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.

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.

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?

wouldnt a dynamic rate come with an incentive not to fund from the pool because it corresponds to an increase in tax to voters?

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)

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)

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.

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.

photon could act as a larger denomination of atom with a hard cap and limited redemption /month back into atom.

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.

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!

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.

Suggested tagging and naming conventions for proposals

LAST CALL yyyy-mm-dd: Serves as a clear notification that the proposal is close to being put to VOTE ON CHAIN. Changing a status to LAST CALL means that social consensus has been reached and we still want to give it a limited amount of time (i.e., 2 days) to let the community continue to react or analyze.

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 )

Thanks for raising this regarding naming conventions.

Would be good to publicise this further for full transparency.

Update: Pushed this on our socials - https://twitter.com/SimplyStaking/status/1597230047555121152 - feel free to retweet.

This whole thing is a NO for me… I’ve noticed no one has brought up the issue of time… How long is this funding measure going to take. If this is obviously one of the main differences with the proposed tax vs inflation debate. Applying this tax will simply take too long. What’s more, no one has even addressed the fact that this would demand a major slow down of the application of Atom 2.0. Almost as if the whole point of this is to cement a massive pause on the implementation of Atom 2.0 without having to say so upfront. So NO!

Hush: I’ve noticed no one has brought up the issue of time… How long is this funding measure going to take. This is mentioned here: Damien: Current rate of Issuance: 9.6ATOM per block according to x/mint Current amount of blocks per year: 4,360,000 Instead of the current 0.192ATOM (0.02*9.6) being transferred to the pool with the 2% tax, a proposed 0.67ATOM (if 7%) will be given to the community pool per block. Per day this equates to (according to minting parameters) ~8,025 ATOM directed to the community pool. Yearly would add up to ~2.9M ATOMS to the pool which is significantly higher than the roughly 850K ATOM added yearly (according to current metrics). If the community tax were to go up to 10% we would see around 11,460 ATOM per day (0.96 ATOM per block) get moved to the community pool. Over a year this would allocate around ~4.2M ATOM to the community pool. and also elsewhere in the thread . As for: Hush: Applying this tax will simply take too long. So NO It will take time to fill up the community pool, but that time can be used to develop a collective roadmap and standards on how we’d like to see the pool used.…

Excerpt (1198 of 1580 characters). Read the whole post on the forum ↗

That is a good idea when you put it that way.

I think it needs to be more clear about the use of the community pool, for example, 4 million token a year, every month is more than 300,000 token, how this monthly token is used, whether it needs to continue to draw tax from the stakers if it is not used up, since the funds come from the stakers, how to return to the stakers after use, if there can be such a positive cycle, I think any stakers support cosmos ecological pools, but if the ecology doesn’t bring any return to the stakers, then why should they do that? In fact, community pools are also distributed funds, and if we can actively build it and support the cycle, we can expand the ecology and increase the return

Hi @tusiki, regarding your point relating to how funds can return to stakers and how it can bring value to stakers. The community pool is there for the stakers and is controlled ultimately by the stakers to drive value to the Hub and return the value back to those stakers.

Honestly have a feel we are making some of the same mistakes that were made with 82 on this. A lot of those here in this forum already agree on this. Those that don’t frequent the forums (majority) probably have no idea of the consensus here and they’ll suddenly see a prop with a big change attached.

Hey @yoda , actually in this particular case we had a strong community effort to boost awareness on the community tax proposal prior to the on-chain voting. Besides the discussion here on the forum, the Community Tax proposal was also one of the solution provided by the community during the Atom 2.0 debate and appointed in the Atom 2.1 draft. • In the last weeks the discussion of the Community Tax proposal happened on Telegram in the community governance channel, where the forum thread is pinned. • We had a Cosmos Hub Twitter Space discussing the Community Tax draft last week. • Polls on Twitter to hear the community sentiment have been shared by validators, in particular Cosmostation and Adriana from KalpaTech. • Most of Cosmos Hub Validators have been reached to share feedback on the proposals prior to the on-chain voting. I think it is very important to increase the interaction with the community prior to the on-chain voting period and in this particular case I definitely see that efforts have been made in the right direction. But we definitely have to keep improve the interaction with the community with proposals draft, so if you have any feedbacks on…

Excerpt (1195 of 1307 characters). Read the whole post on the forum ↗

As a “normal user”, I think the wording in the proposal is important. And first to have the link to the forum (it’s often not posted, for example no link in the prop 82) as there is there often most answers to questions we may have on the proposal. But also a bit more explanation on the reasoning / discussions

For example in my opinion two clear proposals :

• Adan non profit : Keplr Dashboard
• No with veto : Keplr Dashboard

Thanks for this Will, please note we’ll be doing some edits to the proposal you see above in the coming days to make sure its incorporates some of the suggestions and changes from the forum, such as yours.

Again you still haven’t addressed the main issues of timing. All you have done is shown in the proposal that everything will take much longer than the inflationary method. There is no consideration of the impact on Atom 2.0. You show that the tax can be implemented on either a conservative figure or an exaggerated percentage. But even in the exaggerated time line the 4.2M Will be generated in a year, so what about another tranche? How long will it take to generate three or four tranches? In the long run 4.9M is not a lot, and won’t be as helpful as you think. Generating the funds would take 5 years and up. You haven’t discussed and seem to have completely overlooked that the delivery on Atom 2.0 full feature suite would take another 10 maybe 15 years. That’s why it’s a NO! . The other issue is this seemingly surreptitious method of slowing do Atom 2.0. It seems underhanded/perfidious. Meanwhile, we continue inflating away our value…

@hush it is unclear what your issue is with timing. What is the rush? from what I last saw, the approximation for tranches was 10x 4mmATOM/year.

Which, at 10% TAX would be >4mmATOM/year…

There isnt even a proposal to spend the current community pool funds.

Hush:

The other issue is this seemingly surreptitious method of slowing do Atom 2.0. It seems underhanded/perfidious.

what is it that is being slowed down?
There is no coherent atom 2.0 proposal that has been made widely available.
what do you mean when you say atom 2.0? what necessary feature suite are you referring to?

Are you really that unclear about atom 2.0? This is the link to the Cosmos prop 82 proposal. Interchain Explorer by Cosmostation
All elements in the proposal will be drastically slowed. Atom 2.0 could be delivered relatively quickly, if not for an allocator that would take anywhere between 3-5 years to fund, slowing the rest of the project to a crawl. Please note that some elements of the Cosmos community don’t wish for a atom 2.0 implementation while the majority do. As shown by the majority YES vote on prop 82 and the censuring by way of VETO deposit burn of a successful prop.

prop82 was voted down. & yes, i am very unclear about atom 2.0.

How do you know it will take 3-5 years to fund the allocator? where are you pulling your numbers from?

The overwhelming consensus even by the authors was that prop82 needed to be amended past v.2.

you are emphatically arguing for an obsolete iteration of an unclear concept.

What makes the allocator necessary for 2.0?

If you read the prop 82 proposal, you would know why the funding the allocator is necessary(because inflation would fall to about 1%, other than the Tranches, there is no other way to fund necessary projects).
If you read this proposal you would know where I got the 3-5 year timeline (Using taxes at a high proposed tax rate we would have 4.2M per year. Similar to a tranche. Proposal 82 wanted between 2-4 tranches. Because of how math works, that is about 5 years if funded through taxes).
As for your Atom 2.0 was voted down comment. NWV is meant to strip out bad actors and spam proposals. The minority used NWV to put down a proposal with a majority yes vote, with a 33.4% minority. I don’t think that is how NWV was meant to be used.

Screenshot 2022-11-29 7.55.04 PM1663×337 29.8 KB

why would inflation spontaneously reduce to 1%?

the allocator is just a bunch of DAOs and councils? It sounds like the allocator is all about bootstrapping chains that havent gone through the natural selection of bear markets. is 2.0 about funding new growth throughout the ecosystem or to bail out chains that cant handle the normal stresses of a bear market?

OMG read the Proposal! READ the proposal!! READ THE GODDAMNED PROPOSAL!!! Prop 82… Read it…

i am, its why i asked the previous questions. the allocator section talks about buying a ton of LSDs to bootstrap AMM pools and “incentive align” participants…
It has bullet points that talk about funding LSDs, oR funding chains despite their unproven market utility, are artificially funded by delegators which results in those same delegators loosing their staking rewards…

Hey @Hush , thank you for sharing your concerns and participate in the forum discussion. The Community Tax proposal is born from the intent of the main parties involved in the Atom 2.0 debate to reach a meeting point. The Proposal doesn’t aim to follow the Atom 2.0 tranche model, but mainly to reinforce an underfunded community pool. As shown in the draft the Cosmos Hub community pool is currently not competitive compared to the Cosmos ecosystem standard, especially in relation with the market cap of Atom. Even Stargaze a project with a much lower market cap valuation has a more competitive community pool. The community pool represents the stakers and the ability of the community to fund multiple initiatives that bring value back to the Hub. Especially for what the Cosmos Hub aim to achieve with Interchain Security and also to maintain a leading position in the Cosmos Ecosystem, having a strong community pool is necessary. Regarding slowing inflation, this can be addressed once the Cosmos Hub will have protocol revenue, you can’t remove inflation until there is a form of alternative revenue. Interchain Security is a first step to create a new form of revenue for…

Excerpt (1196 of 1613 characters). Read the whole post on the forum ↗

I understand that this proposal doesn’t seem to follow the Atom 2.0 tranche model. It seems to me this proposal was setup to completely oppose the Atom 2.0 model.

You speak of a way to generate revenue via Interchain Security. What about MEV? I say that because Interchain Security may evolve into Mesh Security in the future and MEV is another avenue for revenue. I don’t think IS will always be a Cosmos(atom) exclusive product.

If the community plans on moving past an Inflationary model, these are the type of products we will need and hampering Atom 2.0 with an extended timeline is not in the community’s best interest.

There was desire from the community to find funding that doesn’t alter the emission schedule and where the community has more control over the release-of-funds. This culminated in agreement to explore alternative methods to the mint. Hush: You speak of a way to generate revenue via Interchain Security. What about MEV? I say that because Interchain Security may evolve into Mesh Security in the future and MEV is another avenue for revenue. I don’t think IS will always be a Cosmos(atom) exclusive product. While the MEV concepts outlined in the whitepaper were exciting, there is still a ton of R&D needed around cross-chain MEV . So, it’s not something that would be built overnight regardless of the passing of this or any other proposal. AFAIK, skip protocol is already helping test out and iterate on the cross-chain MEV thesis throughout the ecosystem, and fair block is also working on MEV via encryption (front-running prevention) and will use ICS. Rather than charging forward at full speed toward the ATOM 2.0 vision, we can work on sense-making and understanding the collective’s opinion about what to implement and how to go about doing it. In the long-run we will…

Excerpt (1198 of 1455 characters). Read the whole post on the forum ↗

Just to clarify your point - this proposal was not setup to oppose ATOM 2.0 or any other form of prior proposal. This was setup to be a unity response to the opposing views when it came to funding the Hub.

We felt that this proposed way was the least controversial and that the majority can get behind.

It is a good suggestion it will contribute to development but we need to make sure that the funds will be allocated as intended.

The majority chose the Atom 2.0 proposal and its inflation tranches… So what you are doing is lobbying for the minority position…

Currently atom has just one use case. It is an on/off ramp for the cosmos ecosystem. Osmosis(osmo) is being listed on both CEX and DEX, so in a short while Cosmos(atom) is going to lose its one use case. Cosmos(atom) has always had this major/massive problem, it is not a hub and has no utility. Without a utility, people will soon realize that it is redundant/vestigial. ala.tusz.am: Rather than charging forward at full speed toward the ATOM 2.0 vision, we can work on sense-making and understanding the collective’s opinion about what to implement and how to go about doing it. In the long-run we will all benefit from this approach. At the very least, it honors the many voices in the community that encouraged a more methodical approach to researching and implementing (or not) components of the ATOM 2.0 paper. But, that probably deserves it’s own thread… Even you see that we need a new model or you wouldn’t be so all in on Interchain Security. Which is also untested, something brand new. You are willing to charge forward with IS, all I am suggesting is we have a backup in the form of MEV. Just in case something changes/doesn’t work out the way we would like. Atom 2.0…

Excerpt (1199 of 1266 characters). Read the whole post on the forum ↗

I do not think I am lobbying for anyone. I just wish for a fair system that everyone gets behind so we can move forward in an attempt to bring utility to the hub.

The tranche model and the community tax model share their similarities. A tranche of 4M would have been minted every 12 months. The community pool with the increased tax would get roughly 4.2M per 12 months.

The wording in prop 82 was, “10 tranches of 4M ATOMs may be issued to the Treasury at any time per ATOM holder vote”. Where did you get the idea that the Tranches would be every 12 months?

Do you understand now why this 5 year tax raise is unacceptable?

And note the community pool is not empty at this point in time. So we have some funds to bridge the period until the new community tax is implemented and fills the community pool at a high pace.

Just seeing this comment…I’m not sure I understand what you mean by “an incentive not to fund from the pool”, what I mean is that the tax would go to the pool, not sure how this would disincentive funding from the pool. If the tax are dynamic and increases were incremental, I don’t think voters would even notice, especially of the benefits are reflected in the price of ATOM. Just my option though. Hope I understood your statement.

Cosmos Hub ⚛️

Underrated comment. IMO the words are number one reason for voting yes / no - not the meaning, alas. We need to learn to simplify what we are trying to say

This video has muted comments, so people can’t see what critics of the proposal would say. There is no consensus on the rate of the Taxes. These taxes would lower delegators APR. None of this seems to be thought out. All this video has done is shown limitations of this proposal.

Meanwhile an inflation would simply generate the exact amount that would be needed in the community pool. No extended tax periods, no need for a static or dynamic rate. The funds would be immediately usable.

Hush:

The wording in prop 82 was, “10 tranches of 4M ATOMs may be issued to the Treasury at any time per ATOM holder vote”.

Stop say atom 2.0 wrote 4M atoms every year…

I see you have adjusted the proposal to no longer be at odds with Atom 2.0. I like the changes and rather this proposition. Removing the contentious comments and separating this proposal from prop 82’s tranches make it a, “do until”, rather than a override of the Atom 2.0 funding. This I can vote yes on.

Interchain Explorer by Cosmostation

Interchain block explorer and data analytics for sovereign blockchain networks.

Hey @Damien I think the appropriate post-tag is VOTE ON CHAIN, rather than accepted. For reference: Suggested tagging and naming conventions for proposals • DRAFT: A period to engage in discussion and respond to feedback and review from core stakeholders and community members. • LAST CALL yyyy-mm-dd: Serves as a clear notification that the proposal is close to being put to VOTE ON CHAIN. Changing a status to LAST CALL means that social consensus has been reached and we still want to give it a limited amount of time (i.e., 2 days) to let the community continue to react or analyze. • DEPOSIT: Proposal has moved on-chain but not met the minimum deposit threshold. It is seeking contributions to the deposit. Not all proposals will move through this stage. • ABANDONED: Proposal has been dropped before moving on-chain. • VOTE ON-CHAIN: The proposal is on-chain and able to be voted on. • NO DEPOSIT: Proposal was rejected for not reaching minimum deposit threshold. • ACCEPTED: The proposal met quorum and passed the vote. • REJECTED: The proposal met quorum but was rejected. • NO QUORUM: The proposal did not meet quorum during the voting period. • VETOED: The…

Excerpt (1193 of 1243 characters). Read the whole post on the forum ↗

Thanks for this! Will keep these naming conventions in mind for the future.

I am in agreement with this proposal as although 2% to 10% tax change is a considerable jump, I consider it a less radical change than what was previously proposed.

It will also cement some solidarity within the Cosmos hub, and represent a positive trajectory as we move forward in a careful and considered manner rather than trying to achieve too much at once.

I agree with that ICS can be so great for Hub

So your grand plan for MEV is to have another chain build out and test Cross Chain MEV. Then what? When it is successfully implemented, swoop in and integrate it on Cosmos Hub? You obviously haven’t thought this through.