The ATOM Wars: a new governance platform for liquidity injections

Note: The purpose of this post is to make concrete suggestions for the design of a system that would complement the Cosmos Hub’s role as a shared security provider and ATOM’s role as the Interchain Capital. It is written by Thyborg & Juan Beccuti (Informal) with numerous ideas & feedbacks from Zaki Manian (Iqlusion), EffortCapital (Blockworks), Sam Hart (Timewave), Jehan Tremback (Informal), Ethan Buchman (Informal), Elijah (Neutron) and Riley (Stride).

The Cosmos ecosystem stands out for its unique implementation of token-based governance to allocate funding. And among all Cosmos chains, the Hub distinguishes itself through the diversity of opinions, large participant base, and higher caliber of the discourse. Consequently, many have argued that the main value of ATOM lies in its governance capabilities.

How do we translate hypothetical governance capabilities into actual value accrual for stakeholders? We start the ATOM Wars.

TLDR: ATOM holders are given the ability to lock up their staked tokens for up to one year in exchange for boosted decision power with regards to the allocation of liquidity injections into third-party projects, sparking a bidding competition (the “war”) that open ups a number of new revenue generation opportunities for the Cosmos Hub.

In practical terms, these liquidity injections are already happening. Notably, under Prop 800, ATOM voters supported the two “ATOM Security Zone” projects Neutron & Stride by deploying 450K of ATOM liquidity to Neutron. In their footsteps, Persistence & Osmosis posted Prop 853 and Prop 858 to receive 600K and 800K ATOM respectively. One goal is now to convert these users into paid customers.

Against a backdrop of heightened competition for shared security, a parallel goal is to enhance Cosmos Hub’s ICS value proposition. This is achieved by structuring the "ATOM Wars’’ platform in a manner that unequivocally prioritizes consumer chains, thereby fortifying the Cosmos Hub’s standing in this rapidly changing landscape.

THE ATOM WARS CONCEPT

The term “ATOM Wars” is inspired by the Curve Wars on Ethereum. In Curve, liquidity providers (LPs) are incentivized through trading fees and CRV emissions. The inflationary rewards vary for each pool and are subject to governance decisions. LPs have the option to lock CRV for extended periods, acquire voting rights, and participate in decisions regarding the distribution of inflationary rewards across pools. The projects using Curve strive to acquire voting power to enhance pool rewards, attract more LPs, and subsequently increase their token liquidity. These LPs, in turn, can partake in subsequent reward decisions to boost revenues, creating a positive flywheel.

The ATOM Wars concept operates on a similar principle. It capitalizes on the demand from projects/chains to add ATOM liquidity into their systems. The available ATOM liquidity in the community pool is limited, prompting projects/chains to engage in competition for access. We aim to convert the liquidity requirements of projects/chains into incentives that encourage ATOM stakers to decide where and where not to inject liquidity.

THE vATOM TOKENS

Voting rights for liquidity injections differ from the current standard governance model. ATOM participants choose between different locking periods and receive special voting rights in the form of a new token called vATOM.

In its first version, the ATOM Wars platform will only accept stATOMs, i.e., ATOMs liquid staked through the Stride liquid staking protocol. stATOM holders will be able to pick a lock period and receive vATOMs in return. In the next interaction of the platform, we will likely use the Liquid Staking Module DelegationShares instead; that would allow any ATOM staker to acquire vATOMs by directly locking their "DelegationShares’’ (obtained via through LSM) into the new governance platform.

The following table shows how many vATOMs may be obtained as a function of the locking period

stATOM Lock Power
1 month 1x
3 months 1.5x
6 months 2x
1 year 4x

Each stATOM earns a certain amount of vATOMs, For example, a user locking 1 stATOM for 1 month will receive 1 vATOM while a user locking 1 stATOM for 1 year will receive 4 vATOM.

Let’s imagine a worst-case scenario where no project participates in the system. This is a situation where the most committed ATOM holders (i.e., those who locked their ATOMs for a considerable amount of time) would be left worse off than before. In order to mitigate this risk, we suggest a short-term and a long-term solution. In the short term, we would allocate a portion of the Cosmos Hub community pool funds to guarantee a (small) extra APR to the vATOM holders. In the long term, we would transition the Cosmos Hub inflation to a model where rewards are increased for longer locking periods. This means that those who lock up their tokens for extended durations would not only gain more voting power in the ATOM Wars but also receive a larger share of inflationary rewards.

Let’s now discuss a more positive scenario where the system does generate revenues. There are two different revenue sources:

  1. The liquidity injections (also known as “Protocol Owned Liquidity”) earn a yield from swap fees, external incentives, lending, superfluid staking etc. For instance, Stride worked out that the 900K ATOMs on Osmosis are currently earning the Cosmos Hub roughly 100K per year. We suggest that this income continues to go to the community pool.
  2. The bids made by different projects to secure the liquidity injections. For that, we suggest that the largest portion go to vATOM voters, and the remainder into a liquidity bucket (owned by the community pool but earmarked for re-investments).
Liquidity Injections (POL) Bids
Cosmos Hub 100% 10%
vATOM voters 0% 90%

LIQUIDITY ALLOCATIONS

Every month, the system distributes an ATOM Liquidity Bucket. The bucket is divided into tranches of different sizes. During this period, each project joins and defines why & how it will use the funds along with the amount it will pay to voters. When the round concludes, projects are ranked based on votes, and funding is allocated.

We’ll describe each of the terms used in this summary in greater detail below:

Liquidity bucket: ATOMs from the community pool will be transferred into a separate Bucket with the explicit purpose of being distributed among the projects participating in the ATOM Wars. We suggest an initial funding of 1M ATOM (roughly ⅓ of the current community cool). This amount might be increased if the system proves to be profitable for the ATOM community.

Tranches: Tranches make it easier for smaller & newer projects to participate in the system. In their absence, established projects likely end up winning every auction. Since we’d like this system to be used for bootstrapping new projects, we suggest 3 tranches of 700K, 250K, and 50K respectively (# tranches & their size may change over time).

Round frequency: Funds are distributed periodically. Our suggestion is for each allocation to be 1 month. Having regular rounds encourages competition for funds and ensures that resources are allocated to more projects. This duration may be adjusted based on insights from market usage, but 1 month will allow us to identify & address any design.

Participation: A project signals its intention to participate by creating an “account” where it outlines why & how it plans to use the funds. Projects can join the round at any time; some may join right when the round begins, while others might decide to participate just before the round’s deadline. A project can open only one account per round.

Spam deterrence: Creating an account requires a 100 ATOM entry fee serving as a deterrent against spam. Unlike the fee for submitting a proposal to the Hub, this entry fee won’t be refunded; instead, it will be distributed among all vATOM holders.

Bid: This is the amount that a project is willing to pay to its vATOM supporters. This is contingent on winning the auction; if a project doesn’t secure any funds, it won’t need to pay anything. In the first version, we’re planning to accept bids in the project tokens or ATOMs. This may be later restricted to ATOMs. A project sets its bid upon joining the round. The bid can be increased (but not decreased) to get additional support until the round ends.

Voting Rules: Voters only receive a portion of the bids when they vote for a project. They decide which project to vote for. They can change from supporting one project to another at any point before the deadline. They can also decide not to support any project. An important metric is the “Expected Payment per Vote”, which is the bid divided by the number of supporters. Note that, given a bid, the payment that each voter is getting decreases when the support increases.

Voting Rationality: Voters observe the expected payments per vote and funding purpose to determine which project to support. The purpose is crucial as it provides two important signals: the quality / trustworthiness of the project, and the manner in which the funds will be used (liquidity pool, stable-swap, money market, stable-coin collateral etc.)

Information: At any moment the following information will be publicly observable:

  1. The tranche: Which tranche the project is bidding for
  2. The bid: How much the project pays to its supporters (conditional on winning)
  3. The purpose: A description of how the project will use these funds
  4. The votes: How many votes/supporters each project has

The tranches and the amount in each are fixed. Everything else can change while the round is running.

Quorum: Each round needs to reach a minimum of voters. Failure to reach the quorum will result in the cancellation of the current round, and projects will need to await the next round.

Allocation rules: Upon auction deadline, each project has a total count of supporters or votes. The project with the most support wins the tranche. Since a project can open only one account, it can secure only one tranche. Funds are reallocated only if the winner changes from the previous round. If there’s no participation in the next round after a winner, the funds remain with the previous round’s winner (in this scenario, the liquidity still generates a yield)

ICS CHAINS

ICS chains are the most committed to ATOM’s success. They also contribute revenues back to the Cosmos Hub. It’s in the interest of the Cosmos Hub to implement a design that favours these projects over their competition and make ATOM wars the tip of the spear to build a real narrative around shared security and alignment.

We suggest that a dedicated tranche be reserved for ICS chains, with exclusive participation in this specific category. ICS chains would still have the option to bid for other tranches simultaneously. This enables voters to support a project in the ICS tranche and concurrently back a project competing for the other tranches.

The system would also enable discounted token swaps for ICS chains, i.e the purchase of ATOMs from the community pool at a significant discount. These ATOMs would be locked in exchange for vATOMs that would participate in the auctions. The longer the locking period, the larger the discount. This approach has the benefit of increasing the general demand for ATOMs.

In further iterations of the platform and based on market feedback, we may also consider additional elements such as a Security-based Multiplier where votes supporting a chain with an ICS agreement may carry additional weight.

Security agreement Multiplier (mS)
Replicated security (or Top-N) 2
Partial set security 1.5
Mesh security 1.25
No security agreement 1

The Security-Based Multiplier concept could be supplemented by a Revenue-share Multiplier:

THE DAO WARS

At some point, the Curve Wars shifted to a new layer. Because Curve holders found the risk of locking their tokens for the maximum period (4 years in Curve) too high, a project called Convex Finance emerged. It offered users to deposit their tokens into Convex which would lock them up for 4 years and manage the votes. Users would also receive tradable tokens in return. Since Convex has its own token, some participants prefer buying Convex tokens to influence Curve’s governance through Convex rather than directly through Curve. As of September 2023, Convex controlled almost 85% of Curve TVL.

It is likely that similar dynamics will be at play in the ATOM wars, and we would consider this a good thing, as it would abstract the complexities of voting away from users. If multiple of these aggregators come up, they will compete by offering attractive rewards to ATOM holders, bringing to the Cosmos Hub the speculative energy that has been missing since its launch.

GOVERNANCE EXPANSION

The ATOM Wars system scheme differs from the standard Cosmos Hub governance in that ATOM stakers choosing longer locking periods get extra voting power (in the form of vATOMs).

Giving extra voting power to a subset of ATOM holders that has proven to be actively involved has major advantages: it recognizes the reality that not all ATOM holders want to participate in governance and empowers those who value their vote more. Consequently, we may consider extending the decision scope of vATOM holders beyond liquidity injections. Funding proposals, DAOs members election & firing would be interesting new use cases.

Ultimately, we may consider applying this adjustment in the governance framework to most governance matters, except for the oversight of ATOM Wars (the standard voting procedure to terminate the vATOM system if necessary)

PRIVATE CAPITAL EXPANSION

In the first version of the ATOM wars, the liquidity bucket will be sourced from the community pool, i.e “public funding”. It is however possible to imagine that private capital would be willing to contribute to the liquidity bucket. Since private capital participation enhances the impact of the system and boosts demand for ATOMs, we recommend the following incentives

  1. Earn an APR from the Protocol-Owned-Liquidity
  2. Receive a share of the bids from ATOM Wars

As discussed in a vATOM section, 90% of these bids would go to voters. The remaining 10% would be distributed between the Cosmos Hub and Private Capital, with the split being a function of the ratio contributed to the liquidity bucket PCap/(PCap+CHub)

The revenue distribution summary would look like this:

Liquidity Injections (POL) ATOM Wars Bids
Cosmos Hub 100% ∈[3%,10%]
Private Capital 100% ∈[0%,7%]
vATOM voters 0% 90%

FAQ

Who can participate in the auctions? With the current design, any project can join the auction and bid for a tranche. Voters could choose to not support those projects with a bad reputation and/or not beneficial for the AEZ.

What happens if a project doesn’t return its liquidity injection before the next round starts? Note that a similar risk appears in the current governance system. Voters are tasked to evaluate the quality of the reputation of each project seeking funds. Tranches in our design help minimize risk because a malicious project would only be able to secure one tranche.

May a single entity gain significant control over special voting rights? This was the situation with Convex during the Curve Wars. Convex looked to aggregate votes and control incentive allocations. Since the entire system can be updated (or removed completely) through standard governance procedures, we find the risk to be acceptable.

May projects try to bribe voters outside of the system? Bribery is challenging (perhaps impossible) to completely deter. It’s in fact possible that such activities are happening currently in standard governance. Our design aligns incentives and makes it more transparent.

What rationality should guide bidders? Our design resembles a sequence of multi-object English auctions (or ascending auctions) with a deadline. However, they are not standard auctions (in which the highest bid wins) since voters may also decide based on reputations. Dynamic effects are important and with time, it’ll be possible to learn the “willingness to pay” for each project.

Is it optimal for bidders to follow a snipping strategy? A snipping strategy would try to increase bids at the very last moment to reduce rivals’ ability to react. However, the effectiveness is limited because this isn’t an auction where the highest bid at the deadline automatically wins. Here, the snipping strategy relies on voters’ reactions to be successful and they may not do it if the bid is increased at the very last second/minute.

Is this scheme resistant to collusion? Collusion may involve multiple projects coordinating on how much to pay supporters to alleviate competition costs. In a scenario with numerous projects and more demand than available funds in the bucket, the likelihood of all projects colluding appears low.

More generally, can the system be attacked or manipulated? We kept the design clean and simple to minimize potential vulnerabilities but we recognize that further analysis would be necessary to validate it.

What if very few projects participate in the system? Low competition may result in lower bids and tranches not being allocated. If this persists, we may adjust the number of tranches to boost competition.

Will there be a reserve price? Weak competition may arise when there are more funds available than there is demand for liquidity. In this case, setting a reserve price is advisable. However, this typically requires information on demand, willingness to pay, and other factors, which will not be available in the initial rounds. But as we collect market data, we may add this option in future releases.

Are there alternative allocation schemes aside from the one discussed above? There are certainly numerous potential designs. We preliminary selected this option because it is simple and it provides beneficial side effects, such as boosting the attractiveness of ICS agreements, incentivizing longer staking periods, and exporting ATOM as Interchain Capital.

Will the liquidity bucket and tranches change from one round to another? The size of the liquidity bucket may be updated through regular governance. The tranche distribution may be updated by vATOM holders, although we don’t expect it every round.

Is this system changing ATOM governance? The system is currently only designed for liquidity injection proposals. All other governance matters will adhere to the standard procedures, where 1 ATOM equals 1 vote.

Isn’t choosing to lock stATOMs a huge favor to Stride? This is a temporary solution for quicker implementation, as the v2 version will use the LSM DelegationShares. It’s worth noting that as Stride is a consumer chain, a portion of the fees collected by Stride returns to the Cosmos Hub as ICS revenues.

18 Likes

First and foremost, thank you for crafting this topic, we were desperately hoping for innovation on the Hub and you’ve been able to clearly express a new vision for PoL that is interesting to say the least. We must say that we align with many of the ideas presented here, some have significant overlap with our own ideas which we had planed to release later this week ! Assuming that you now have the first mover advantage, we will take the necessary time to fully review every detail of your proposed vision, cross it over with our own and provide a comprehensive review with possible suggestions for improvement.

#1 Design Choices:

The ATOM Warz clearly mimics Curve’s architecture for its liquidity war. What concerns us in this regard is the fact that history has shown us that despite the undeniable positive effect on CRV token prices, it ended up in a deterring system undermining CRV’s governance to the profit of Convex. For context, readers can find a brief summary of this here.

We think this design choice is a double-edged sword, introducing a gamified method that has proven to be incredibly effective at generating a locked-up supply (reducing supply while creating demand inevitably shows up as a price increase). On the downside, the counterparty risk to this system is the lowered governance power and risks of unhealthy bribed allocation purely driven by speculation.

Despite these concerns, we think the Hub’s version proposed here offers significant improvements over Curve’s. The use of liquid staking token derivatives (LSTs) coupled with @effortcapital’s proposed LST tax should put a limit on this system in terms of the damage it could pose to the Hub’s main chain governance participation. At Govmos, we think the Hub’s governance is an asset we can’t trade-off for a price gain, ever.

Moreover, the proposed evolution towards the use of a dedicated LST minted on the Liquid Staking Module (LSM) could be very interesting if it allows users to retain their voting power on the Hub, as well as choosing which validator they want to delegate to. Using a separated “ATOMwarz” LST for this specific usage will also greatly improve risk management by isolating risks.

Improvement propositions:
We sincerely recommend designing this system with a dedicated LST on day 1 instead of using stATOM and then switching. This will offer much better security guarantees and will further help gather data on the usage of the system. @Stride is expected to greatly benefit from this protocol anyway; we expect most of the PoL to be converted to stATOMs before being allocated by the bidders.

#2 Proposed Parameters:

Using a weighted vATOM token based on a predefined lockup period is great to remove circulating supply while also adding incentives to a durable participation of the users in this system. In our personal proposition, we envisioned a similar system that had almost identical weights.

On the downside, you propose to use an early-stage incentive to compensate for a situation in which “no project participates.” We think every user should be aware of the risks involved in locking away their tokens, and we will definitely oppose any use of community funds to compensate for discretionary risk-taking strategies. Such safety procedures could be implemented by an internal super-majority vote for vATOM holders to decide on a global disbursal of deposits.

Regarding the profit distribution mechanism, you’ve proposed 90-10; we think an 80-20 is a more balanced approach to compensate for the risk that is inherently associated with the liquidity allocation made by the bidders. We suggest the 20% community share to be compounded as new funds allocated to the program, growing the pie over time.

Then you propose another weighted system by introducing a “security agreement multiplier” effect to the votes. We think this idea is interesting but will have to be carefully adjusted after sufficient data points have been collected. We will have to make sure this isn’t deterring other projects in the larger ecosystem to benefit from these bids.

Improvement propositions:
Adjusting the proposed revenue distribution to 80-20 instead of 90-10.
Redirecting the 20% share of the Hub as a compounded allocation to this program.
No community funds to add incentives to depositors (no public spending to subsidize private risk-taking).

#3 DAO Wars & Expansion:

Back in 2022, we shared a vision for a set of privately managed “councils” in this post. The emphasis was on the governance aspect, but we still saw huge opportunities to use these systems for managed capital allocations.

The references you made to the Convex “rehypothecation” of voting shares are very important. To us, that’s exactly the situation we would like to avoid while still encompassing the need to foster sub-sets to be created. Rehypothecation pertains to the creation of another layer of derivative financial instruments. Assuming this system will already be using derivative financial instruments (LSTs), adding another layer of dependency is an absolute veto for us. A much safer solution would require each sub-set to generate its own derivative from native ATOMs using the LSM directly. A viable model resembles the system we shared back in 2022; here is an extract of the original post which relates to this:


(you can adjust the zoom if necessary or look at the original post)

Regarding the private capital expansion you envisioned, it is similar to the Treasury Allocation Module we had in mind in our system. But there are reasons to believe that private capital will likely want to isolate risks (and therefore rewards) into separate “buckets.” This is why we thought this would be more likely to find market-fit into a smart contract environment. Still, even though we have doubts on this particular front, we are curious to see if there will be private demand for publicly managed liquidity.

Improvement propositions:
Basic risk education has to be performed to prevent the creation of derivatives of derivatives. We have endlessly commended the creation of a Financial Committee. This committee should have oversight of these complex risks and be able to act as a safeguard by calling Hub’s governance if they see inappropriate and dangerous risk-taking.

Conclusion:

The proposition to create a liquidity market to allocate community funds is fitting perfectly with our models. We had plans to release an application system that had many similarities to your proposition. The main differences we have relate to the private capital allocation part, which we see fit in multiple isolated smart contract environments more than a central weighted governance-controlled place.

Nevertheless, the vision you shared is well thought out, and therefore we will support it instead of creating a parallel thread. The creation of a public liquidity market is an absolute necessity to us. It was part of our “Cosmos City” modeling taking inspiration from ancient city designs:


Source: Cosmos Ecosystem : A permissionless B2B2C network.
Your PoL allocation system would match the public liquidity market (1), secured by the Hub’s governance (the blue coloring influence), in contrast to the city’s free-market place (Osmosis). @Neutron serves the administration (5) with its smart contract capabilities and the forthcoming AATs currently built by @Noam and Binary Builders. The temple (4) would be @Stride, where the political representatives are elected (interchain governors which we will soon propose a model in this forum). The docks (6) are expected to be Noble, connecting the city to the rest of the world via its asset issuance. The sub-set more “private” vaults we mentioned in this post corresponds to the craftsmen (3), building more complex financial products. Lastly, there’s the patriciate (8) which is entitled to high net-worth gated managed money, something we’ll touch on in the future.

To conclude, we think this proposition is a perfect fit. We proposed a few modifications in the design and some weights. We hope the proposer will take them into account. We also look forward to other contributors’ feedback on this crucial matter for the Hub. The more people get involved with this proposed system, the brighter the future for ATOM, the AEZ, and also the general Cosmos Ecosystem city!


On behalf of the entire PRO Delegators’ team, we thank you for reading!
pro-delegators-sign

17 Likes

Very interesting. My biggest question is how much demand there will be outside of the AEZ, but I can definitely see where this would be valuable for bootstrapping new protocols and bring in Atom demand, especially those within the ICS realm.

Curious if anyone from Osmosis, Kujira, etc. have been approached for their thoughts on this.

3 Likes

What is the intention with the liquidity provided in props 800, 853 and 858?

Is the intention to withdraw the liquidity and provide it via Atom Wars?

5 Likes

I like the proposal but I can’t follow your math in the example diagrams provide. I must be missing something?

In the diagram “Example of a round (finished)” The OSMO bid is 7k Osmo. There’s 525 (80.8%) vATOM votes for OSMO and the “Expected Pay Per Vote” is 2.0

Where did you get 2.0 as the expected pay per vote?

I thought Expected pay per vote would be the bid (7000 Osmo) divided by Osmo support (525) which would be 13.33 Osmo per vote. What am I missing?

Thank you for helping clear this up.

The ATOM Wars proposal for the Cosmos hub is a forward-thinking approach, leveraging ATOM’s governance capabilities to potentially enhance value for stakeholders.
In my opinion, a critical aspect that warrants emphasis is the importance of comprehensive data transparency and analysis regarding all operations within this framework.

Thank you for this realy great topic !

2 Likes

Where is the demand for this? I’m trying very hard to figure out who would pay for temporary ATOM liquidity.

New projects would overpay and not receive usership or distribution (as most of the incentives will get compounded as Gov layers are built on top a la Convex). The usership & distribution point is for everyone.

Mature projects are currently paying for ATOM liquidity, that if paired with their token, may cost less than this temporary ATOM POL. Let’s assume it IS cost effective, LPs who are incentivized don’t programmatically pull their liquidity if incentives are reduced, whereas ATOM POL go poof the moment the DEX loses.

The Curve demand makes sense, projects can pay to bootstrap any kind of liquidity. The core parties are LSDs and stablecoins, neither of which benefit in ATOM Wars. LSDs can & should be provided for free (see all the past POL proposals). Stablecoins minting using ATOM is more useful than incentivizing a stableswap? Doubt it.

1 Like

This would be my recommendation. But I think that before that, we’ll want to ensure that the community actually supports the ATOM wars vision, so we’ll probably start with a governance vote to start the liquidity bucket

1 Like

Using stATOM as proposed would sacrifice ATOM’s sovereignty and radically centralize governance of liquidity provisioning.

The locked stATOM could be put up as collateral to be used as insurance. If the tranch value cant be higher than 1/4 the value of assets locked by voters, this would eliminate the risk of liquidity being lost or not returned before the next round starts.

1 Like

Love to hear it. Learn from Ethereum, the ATOM Wars will make more incentive for ATOM hodler to stake and lock your ATOM.

1 Like

stATOM is a good way to get started simply and IMO it is relatively safe given that it is administered by a consumer chain. We have plans to also take raw LSM TokenizedDelegations but that’s a bit more complicated.

I like this idea. Supplying liquidity can definitely end up with a loss of all principal so it’s good to think about how to mitigate that. I think the community pool should take a little bit more risk on than voters, but they should also have skin in the game.

I don’t know what to make of this. I don’t like long term lockups even though larger voting power for a long term lockup makes sense. Generally speaking in the crypto industry today, long term lockups haven’t worked out particularly well. The industry is too Wild West and stuff changes every month.

Don’t like doing this through stATOM. I think a lot of people will object to that if for no other reason than the fees that Stride charges.

I just don’t see how a marketplace is relevant at this point. I think the issue at play is whether liquidity is well provisioned and worries that some earlier projects will take all the liquidity from better projects that show up later. There are a couple of ways to break this down:

  1. If you want to manage liquidity provisioning risk, you need to set limits on how many ATOMs you give to a given project. For example, if you have 1 million ATOMs and you thikn you want to allocate this to 10 projects then you allocated max 1 million /10 = 100,000 ATOMS to each project. Each project is evaluated by ATOM stakers and they say yes or no depending on what they think. Using this approach you also guard yourself against heat-of-the-moment decision - you love this project so much that you will give it 1 million ATOMs (or everything). Believe me nothing costs everything. If it costs you everything then you don’t exist anymore. Biddings and auctions is not a good way to allocate resources. I will give you an example - I got into a bidding war on a house and at some point the house was more than the average price and I backed out. Why? Because today there is a buyer against me, but in 5 years there may not be 2 buyers bidding on the house and I will realize instant loss (assuming the average market price remainst he same). As such auctions result in misallocation of resources. There was no better example than this than Polkadot Parachain auctions - people bid massively on Astar and Moonbeam and they turned out to be duds and uncompetitive against Solana and Avalanche. A lot overy smart people made very intelligent bets and overpaid for proof-of-stake blockspace by locking DOT for 2 years. 99% losses all around. Gavin Wood created the perfect liquidity auction provisioning system (making people bid for scarce computing power vs scarce liquidity as we do here) and it bombed spectacularly. Why? Because auctions actually misallocate resources as people overbid. The misallocation was the notion that Polkadot computing power is scarce. Here it might be that access to ATOM liquidity is scarce and ATOM gets printed at the rate of 10% per year so not sure how scarce that is actually. It is certainly not as scarce as Bitcoin.
  2. You don’t know what project will show up in the future and whether it will be a better one. So you can’t make plans today for an unknown future. Software developers make this mistake often building a framework for a functionality that nobody asked for thinking that people will ask for it in the future and nobody ever asks. In other words, you have smart devs trying to predict how other people will behave and often times this is a very bad bet. As such you don’t want to write code based on himera but only based on what your spec is in front of you today. Later when you have a chance to modularize, then you modularize. You can’t build an Ethereum or a Celestia in 2008. You need the usage patterns to emerge first before you build the solution. In other words, you need the demand to lead you to the supply. As such, I don’t see a reason why investors need to be forced into projecting the future and making bets. People should just make chains and whenever a chain is good enough for liquidity it applies and gets a fixed portion and that’s that. And yes, later entrants are unlucky and that’s that. They will find their luck in some other way.

I am fairly convinced doing Polkadot parachain auctions model for allocating ATOM protocol owned liquidity is a titanically bad idea.

1 Like

I disapprove of V-TOM

The reason is that staking voting should be simple, fair, and consistent for everyone

Otherwise, the difference in the number of votes due to the selection results will be very large.

It will become a governance platform for a few people and turn into a complex investment

2 Likes

it also provides an unfair advantage to older stATOM as they have become more expensive and would require a 10% fee to vote. How long will it take for the fair version using TokenizedDelegations?

when the LSM TokenizedDelegations are able to be used, will users be able to freely recall the tokenized delegation into their custody afterwards? or will they be forced to choose an LSD provider to exit through?

what will be the CP budget for this? How much risk are the few stATOM holders going to be able to saddle the chain with? will AAdao be able to vote with their stATOM to direct CP liquidity spends on top of their already substantial budget?

Thanks for the question!

The expected payment per vote is expressed in ATOM (we should have been more clear about this), allowing voters to compare and decide which project to support.

Since, for the example, we used the prices 10 USD/ATOM and 1.5 USD/OSMO, then 7’000 OSMO = 10’500 USD (= 7’000*1.5) , or 1’050 ATOMs. This gives a payment per vote of 2 ATOM / vote (= 1050/525)

1 Like

Thanks for your valuable discussion!

That’s why we have multiple rounds. The scheme auctions X ATOMs now, and the same X ATOMs will be auctioned again in one month. This gives later entrants the opportunity to compete.

Yes. The design with several tranches and the fact that each project can only win one tranche aims to limit how many ATOMs we give to each project, and to allocate ATOMs between different projects.

Regarding this point and your view against auctions. Notice that in the current auction design, the auction is not really a “standard auction” in the sense that the one who bids more wins the auction. Bidders (projects) have to describe their project besides offering a payment. Thus, voters can evaluate the quality of the project in their decision. It is possible that a low-quality project with the largest bid does not get support to win a tranche. This aligns with your idea that “each project is evaluated by ATOM stakers…”

The long-term lockups here differ from the Polkadot auction. In Polkadot, DOT holders who support a project lock them up for the duration of the lease (2 years??). In this case, an ATOM holder has several options for locking up. If ATOM holders see long-term lockups as too risky, they can simply lock their ATOMs for 1 month and still participate in the auction. Those who are risk-takers can lock them up for a longer period and be compensated with larger rewards. Additionally, if you lock up your token, you do not need to support the same project all the time (as in Polkadot). You can vote for another project in the next round if you realize that the one you supported in the previous round is not a good one.

2 Likes

I have one reminder: All stakeholders should keep in mind that long term lockups favors big bag holders. If you have 1 million ATOMs, you can lock up 300k to get extra voting powers and still have some liquidity to profit if/when appropriate. When you have a smaller stash, you are less likely to put some into long term lockup to have some minimal influence over some project which could bring some price appreciation to the rest of your stash.

And one question: how many projects have been funded by ATOM (from any source, via any decision mechanism) and have brought tangible economic benefits (price appreciation, token utility, active users) to the hub? The teams involved surely have benefitted, but most chains grow by adding users not projects (even if indirectly).

1 Like

If let say I lock up my stATOM for a year, I can use my voting tokens again every month when each Tranches period ends?

Exactly. Locking your stATOM will give you, e.g., 100 votes. In round 1, you have the right to use these 100 votes to support a project. When round 2 comes, voters need to decide how to allocate tranches again. So, you have the right to use your 100 votes in round 2 again, and so on.

By comparison to Polkadot’s conviction voting, this is indeed what we’re seeing:

Small voters tend to use 0x or 1x conviction the majority of the time (i.e. those with less than 100k DOT), while voters with 100k-1M DOT are more willing to use higher convictions. As for the largest whales (voters with >1M DOT), they never vote with 0x conviction but are also cautious about using high convictions (4x-6x).

We’ve also seen a dramatic increase in the concentration of exercised voting power in the top 1%, despite an overall increase in governance participation.

Worth keeping in mind

4 Likes