Context
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.
Structure:
I. Risks and limitations
- Strideâs stATOM instead of LSM shares
- Loss of funds
- Allocation duration
- Purpose for the loan
II. Proposed adjustments
III. Conclusion
Risks and limitations
- 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.
- 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.
- 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.
- 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:
- 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âŚ
- 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âŚ
- 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.
- 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.
- 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.
- 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.
Solution:
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.
Conclusion
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