Atom Wars: an alternative take


The purpose of this post is to follow up on the idea of Atom Wars introduced by Thyborg here. Due to its length, I thought it would be better to post this on a separate blog.

The post explores the risks and limitations of the original iteration proposed and suggests a few adjustments that could improve the value proposition of Atom Wars.

Disclaimer: To be clear, these are merely observations and some of them could be inaccurate/ incomplete so please take everything you read with a grain of salt and feel free to point out any statements which are incorrect.


I. Risks and limitations

  1. Stride’s stATOM instead of LSM shares
  2. Loss of funds
  3. Allocation duration
  4. Purpose for the loan

II. Proposed adjustments
III. Conclusion

Risks and limitations

  1. Stride’s stATOM instead of LSM shares:

The original post proposes selecting stATOM, Stride’s LST for $ATOM, as the only collateral to mint vATOM in order to acquire voting power and participate in ATOM Wars. Thyborg’s reasoning behind the choice is both technically and financially driven:

  • It allows for shipping a quicker version of ATOM Wars: LSM shares are more difficult to implement.
  • It creates additional benefits for $ATOM stakers: arguing that using stATOM increases revenues since Stride pays 15% from all its LSTs fees to the Hub (More demand on stATOM → More fees to $ATOM stakers).

In the case of Atom Wars, Time-To-Market is not crucial. As far as I understand it, the idea of ATOM Wars is to improve POL deployment ( and not to compete with another project for market share…). In which case, there isno reason for the Hub to prioritise speed.
Historically, the Hub has always put security first by enshrining things in the protocol: Interchain security, LSM module… Selecting an out-of-protocol LST ( even one secured by the Hub itself) for Atom Wars undermines that. Especially now that the LSM is live.

On the financial side, favouring Stride does indeed bring additional revenue for $ATOM stakers as it will drive demand for stATOM. However, it’s worth pointing out that this increased demand on stATOM hinges on the success of Atom Wars and one could argue that sidelining other LSTs to favour stATOM gets in the way of that success, considering that LSD providers represent the majority of the demand side ( bidders) of Atom Wars.

  1. Loss of funds:

The proposal refers to the risk of the loss of funds, which could happen when a winning project doesn’t return the borrowed capital in time/ at all, as minimal.

While the loss of funds is an unlikely scenario for Tranche 1 and Tranche 2 as most projects bidding for $ATOM loans have skin in the game, it could still happen in Tranche 3. In which case, the loss is significantly reduced ( currently only 50k $ATOM which represents 5% of the proposed liquidity bucket).

Still, this is a risk that the community pool is not protected against:

Community Pool vATOM
Risk 100% 0%
Revenue 10% 90%

The CP takes all the risk by fully financing the liquidity bucket and in return only benefits from 10% of the rewards. This creates a scenario, unlikely but still possible, where vATOM holders focus less on bidders’ reputation and more on potential gains from bribes, causing the loss of funds.
Thyborg argues that the Community Pool is exposed to the same risks when voting on Community Pool Spends, which is true. However, with CPS voters’ rationale isn’t influenced by bribes/ bids ( at least not on-chain).

Below I propose a few solutions to mitigate such risks and align incentives between vATOM holders and CP:

  • A dynamic CP/ vATOM holders reward ratio based on the riskiness of each tranche:
Community Pool vATOM
Tranche 1 (High reputation) 10% 90%
Tranche 2 (Medium reputation) 30% 70%
Tranche 3 (Low reputation) 50% 50%
  • Introduce slashing risks for vATOM holders in the unlikely scenario of voting for a malicious project.
  • Escrow bids: The release of payment to voters is conditional to the safe return of funds:
Community Pool additional tax
On-time return of funds 0%
Delayed return of funds 20% (Could be dynamic based on the delay)
No return of funds 100%

In its current version, vATOM holders get to benefit significantly from locking their staked $ATOM without exposing themselves to any additional risk while the community pool takes all the risk, by financing the liquidity bucket, for very minimal returns.

→ This creates a misalignment between vATOM holders and the community pool that the solutions proposed above might help fixing.

  1. Allocation duration:

The original proposal suggests a renting duration of 1 month for bidders. After which, liquidity is reallocated again based on a new voting round.

Given that most use cases will involve some form of $ATOM staking ( providing liquidity for $ATOM based pairs will require liquid staking half of the liquidity borrowed for example), It might be beneficial to increase the duration.
This is because, use cases involving staking of $ATOM will require an un-bonding period of 21 days leaving very little room to benefit from the borrowed liquidity.

This is more important in the case of Tranche 1 & 2 as on-chain liquidity cannot handle swaps between ATOM <> ATOM LSDs without significant slippage.

→ A period of 2 months might be more suitable as it allows projects to benefit from borrowed capital and gives them enough time to un-bond.

  1. Purpose for the loan

One of the criteria of participating in the Atom Wars as a project seeking to rent liquidity is Purpose, where the projects have to specify what they aim to do with the funds if they win.

Below is a list of possible purposes mentioned in the original post:

  1. Providing liquidity for a pool that has $ATOM/ $ATOM LSD pair (ex: stATOM/ATOM) → For example: any LSD provider looking to deepen their LST liquidity…
  2. Lending out $ATOM on money markets → For example Mars Protocol depositing $ATOM into its $ATOM pool to reduce $ATOM borrowing costs and boost the yield of its ATOM/stATOM HLS and attract more deposits…
  3. Using $ATOM as collateral for CDPs → For example Inter Protocol using $ATOM as collateral to mint $IST and borrowing $USDC on Mars to deepen liquidity on its IST/ USDC pool…

One thing all mentioned use cases have in common is that the expected return is variable, and in some cases it could be negative:
In case N°1, the LPing might not provide enough fees to cover bribes paid to vATOM holders. In case N°2 profitability/ breaking even hinges on attracting enough demand for borrowing…

This requires bidders to take on risky positions which could result in low demand for liquidity in the long term from projects because a bidding war is less likely when the expected returns are unpredictable.

It’s important to mention here that originally bids, bribes or rewards (however you want to call them0 only work because of their profitability: For every 1$ spent on bribes, protocols know that they’re getting more than 1$ worth of $CRV in return. In other words, protocols are taking advantage of an arbitrage opportunity that allows them to acquire more $CRV. Which, in the case of Atom Wars, cannot exist if the expected return isn’t predictable.
For context, bribes and their sustainability are explored in detail by Delphi here.

The only use case (purpose) that could have high-demand for Atom Wars is staking farming for LSD providers such as Stride, Quicksilver, pStake by minting their own $ATOM LST:

  • The expected return is predictable ( $ATOM staking yield),
  • It is virtually risk-free for the Community Pool as all LSDs have skin in the game ( The main source of revenue for all LSD providers is their $ATOM LST)

There is an argument here that this use case adds no value to the Hub and is simply a dilution of native stakers’ yield in favor of vATOM holders/ bidding LSD providers. This is because it uses Community Pool funds (a tax to native stakers) to earn $ATOM staking rewards (which lowers the staking yield as more $ATOMs are staked) that are distributed between vATOM holders and bidders.

Note: This argument doesn’t concern use cases like the deployment of $ATOM LSTs liquidity (eg, ATOM/stkATOM) as they contribute to giving $ATOM a monetary premium by deepening its liquidity and increasing DeFi utility instead of just passively extracting staking yield.

In the following section, I propose adjustments to the original Atom Wars design that takes into consideration the limitations and challenges mentioned above in order to improve Atom WARS value proposition.

Proposed Adjustments

The primary purpose of Atom Wars should be to solidify $ATOM’s position as interchain money.
Creating a liquidity marketplace where $ATOM stakers opt in for longer lock-up periods in exchange for voting power that directs short-term loans from the Community Pool has the potential to achieve that purpose. However I find that the bidding design suggested in the original post, for reasons mentioned above, could benefit from adjustments that better align incentives between the Community Pool/ Native stakers, vATOM holders and bidding projects:

First I’d like to point out a few differences between the original Curve Wars and Atom Wars designs as they help understand the reasoning behind the adjustment suggested.

  1. Renting vs owning: In Curve Wars, protocols get to own the $CRV they are bidding for. While in Atom Wars protocols are merely renting $ATOM.
  2. Weighted distribution vs limited number of winner: In Curve Wars, protocols are guaranteed emissions pro-rata to their voting power. While in Atom Wars there is a limited number of winners.
  3. Supply and demand sides: In the Curve Wars, the supply and demand side are mostly the same (Liquidity Provider & CRV Staker/ briber). In Atom Wars, that is unlikely to be the case mainly due to the two reasons mentioned above.

→ Adjustment 1: Revenue sharing bids

projects renting liquidity aren’t looking to be profitable as their end goal is to attract more users for their product. Therefore, the bids they pay are considered a cost to acquire customers/ improve product. This makes projects less likely to bid continuously if there is a risk of the cost exceeding the benefits of the loan.
At the same time projects seeking ATOM liquidity via “POL Community Pool Spening props” isn’t favorable for the Hub: the project gets a guaranteed increase of revenue vs non-guaranteed revenue for the Hub.

When protocols make their bid, they should offer up a portion of their revenue in addition to the full revenue generated from the use case.
A good example of this already exists in Prop 853, where pStake offered to waive protocol fees and share 15% of all stkATOM revenue in return for POL from the community pool.

Implementing this adjustment in Atom Wars will:

  • Increase the number of projects bidding for liquidity as the costs become predictable.
  • Competitive bidding from protocols racing to acquire the allocation will drive up the percentage of fees they are willing to give away.
  • Unlike CPS proposals where a governance proposal is required to claw back funds, the Atom Wars allocations have an expiration date. This would push projects to offer better conditions to retain liquidity and allow the Hub to see returns on allocated capital more regularly ( This could encourage more stakers to lock their vATOM).

→ Adjustment 2: Weighed distribution instead of a fixed number of winners

The goal of this adjustment is to incentivise the demand side ( bidding projects) to lock up their $ATOM as vATOM in order to acquire voting power and influence future allocations, just like with Curve Wars.

While the renting-instead-of-owning design of Atom Wars makes projects less likely to lock up their vATOM, the reasoning here is that giving a guaranteed allocation pro-rata to their voting power could incentivise protocols to lock up $ATOM for the longest period possible which, in turn, could result in more competitive biddings.

This could also contribute to reducing the risk of loss of funds: it incentivizes bidding projects to become long-term vATOM holders as they increasingly lock up $ATOM to gain more voting power.

Note: This is why it is important to not sideline other LSD providers by making stATOM the only collateral, simply because LSD providers represent the majority of the demand side. And with this adjustment, they are incentivised to become the supply side as well (vATOM holders) as they already hold significant positions of staked $ATOMs that could be leveraged to obtain more $ATOMs at favourable terms for them as well as the Hub.

Just like the original post proposed, vATOM holders receive only the revenues from projects they voted for while non-voting vATOM holders do not receive any.


veTOKEN economics has proven to be a powerful mechanism for incentive alignment in the case of Curve. But the same design was inefficient for other protocols. Simply because, in the case of Curve, the veTOKEN was tailor-made for its product.

Atom Wars is a step in the right direction for the Hub but it’s important to make sure that the proposed design is purpose-built for $ATOM and the Hub’s needs: $ATOM as interchain money.
My opinion is that a marketplace where vATOM holders are rewarded via revenues generated from loans allocated to projects which increases $ATOM monetary premium has a better chance at achieving this.

I hope the observations and suggestions made in this post contribute to shipping an optimal version of Atom Wars.

Tagging contributors who might be interested in providing feedback on the prop @zaki_iqlusion @dneorej-persistence @effortcapital @Elijah


@JohnMontagu Great write-up. I agree with some of your points. @jBQ is currently collating a lot of the good feedbacks we receive after publishing the original post, and we’ll get back to you after we settle on the updates. Thanks!


Thanks for this @JohnMontagu - mostly aligned with these propositions. Even if it makes everything a bit more complex to implement, I believe they should seriously be considered as they would be beneficial for ATOM and ATOM holders.

I think this is a very good observation.

I agree on this and would even dare to go further saying that the duration could be part of the proposal. For some things, even 2 months might not make a lot of sense. Renting liquidity for a year for example should be possible. Always keeping in mind it’s better to play long-term games with long term people.

Makes a lot of sense to me!

1 Like

@JohnMontagu , many thanks for your comments and suggestions!

I find very intersting your mitigation schemes to reduce the risk if loss funds. They make a lot of sense.

Yeah, we were talking about how long the allocation should last. We decided on 1 month because we think it should be longer than 21 days. But we agree that this is something we should talk about with the community. The duration of the allocation has pros and cons. Longer allocations are more valuable, but if we want to have ATOM Wars more often, we might need to shorten the duration. Two months seems like a good option to consider.

This is another good option. It simplifies things for projects, but it could complicate matters for voters because it adds uncertainty/noise to the value of the bid. In other words, many voters might struggle to determine if they’ll earn more from project A or project B. The upside is that since this is an evolving process, over time, this uncertainty may decrease.

This is one of the options we looked at (among others). As always, there are advantages and disadvantages to weigh. The tranches design offers flexibility; we can easily add more tranches if needed, based on the level of competition or participation we observe. Furthermore, having multiple tranches with a substantial number of ATOMs in each presents attractive opportunities for small to intermediate projects. This is critical if our goal is to provide adequate funding for these smaller initiatives to kick-start their projects. On the other hand, the weighted distribution might allocate too much to strong projects, but, as you pointed out, it can also increase competition. Additionally, it allows even very small projects to access a (tiny) fraction of the funds available. We are opened and happy to consider and discuss this and other auction designs.

Thanks again for your thoughts.


Thanks for feedback @jBQ ! A few comments:

Agreed. Shorter allocation periods are more beneficial for Atom Wars. And when factoring in the un-bonding period a duration of 2 months seems like a good start.

That’s an interesting point to bring up. Personally, I see this ‘struggle’ as a positive thing for the following reason:
While it is normal for vATOM holders’ decision-making to be driven by yield, it can’t be the only factor influencing the vote. Thus, a scenario where voters are incentivized to do additional research on bids instead of only looking at the expected vote-per-pay is more beneficial for the Hub as it builds a better informed base of voters over time. This reduces the risk of malicious projects winning bids and ensures capital flows to projects aligned with the Hub’s vision.

Both designs have trade-offs, I agree. But don’t you think that allocating 70% of total available liquidity to a single project and 95% to 2 projects while leaving only 5% to the small projects category is allocating too much to strong projects?

In addition to increasing demand and competition between projects, I think that weighted distribution gives a higher chance for small projects to compete. I also think that a higher number of tranches with a better distribution of liquidity could address this issue as the reasoning behind my suggestion of weighted distribution ( as well as onboarding bidders as vATOM holders) is the highly unbalanced distribution between tranches in the current design.

1 Like

We are particularly aligned with the concerns you raised here. That’s the main topic we wanted to discuss with @Thyborg as this pose a critical asymmetry in the risk/reward balance. This is probably the only critic we have regarding the proposed design. The identified issue essentially mirrors an uncollateralized loan offering, where the borrower pays a modest upfront fee, yet the capital itself faces substantial financial risk contingent on the deployment.

In navigating this challenge, we perceive limited maneuvering space. It boils down to either accepting that private rewards can coexist with public risk (privatized reward alongside socialized risk), or they cannot. From our standpoint, there are only two tenable compromises for such a disparity in risks and rewards:

  1. Financial Risk Committee: A body comprising financial risk managers and individuals with ample experience, tasked with monitoring proposed offers and possessing the authority to veto those falling below the minimum acceptable risk profile. This committee would be answerable to the entire Hub community in case of failure, necessitating a public report for every veto.

  2. Skin in the Game: In the event of non-repayment or partial repayment, the protocol should have the capability to freeze the LST deposits of all accounts that voted for the compromised allocation. If there’s a partial loss of capital, the difference should be deducted from the holders, with the degree of loss proportionate to their vote. Those who voted ‘Yes’ for this allocation should bear the most significant loss, ‘Abstains’ a lesser loss, while ‘No’ voters should remain unaffected as they opposed the initial risk.

Both solutions present substantial drawbacks. One relies on the competence of identifiable individuals for filtering, while the other necessitates increased protocol complexity. It also requires voting capital to remain under protocol custody throughout the entire allocation, releasing only when fully returned. This would bring about multiple changes to the proposed design, where the user is bonded for a duration of their choosing.

Before the AtomWars proposition, we intended to unveil our vision for PoL allocation. We encountered this issue during our design research and were unwilling to compromise on this situation of private risk and social loss. To achieve a balanced risk/reward mechanism, each liquidity bucket must be isolated in a separate contract. Cross-collateralization can be assumed to a certain extent to guarantee minimal community fund risks.

Certainly, we are open to exploring any alternative options the community deems suitable to address this asymmetry problem.

Thanks for reading,