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:
- 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.
- 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:
- The tranche: Which tranche the project is bidding for
- The bid: How much the project pays to its supporters (conditional on winning)
- The purpose: A description of how the project will use these funds
- 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
- Earn an APR from the Protocol-Owned-Liquidity
- 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.
