ARC-16: bLUNA-stLUNA Virtual Pool

Proposals
1

References

Summary

Enable the bLUNA <> stLUNA swaps with no slippage on Astroport via a pool-like API.

Abstract

Make Astroport the main hub for bLUNA <> stLUNA swaps by creating a virtual pool that leverages the Lido Hub to enable zero-slippage conversion.

Motivation

The demand for bLUNA, Anchor’s first collateral type, has skyrocketed with the rise of Terra’s saving protocol. Today, more than 46M bLUNA (worth ~4.6B$) are deposited into Anchor. As a result, deeper and deeper bLUNA liquidity is needed to keep the money market solvent and maintain a tight peg.

Unfortunately, bLUNA’s design makes it unwieldy to DeFi: bLUNA is hard to bridge and LPs are forced to forgo their staking rewards, unless additional code is implemented. These issues evaporate with stLUNA, which can be bridged or provided to a pool without any additional code nor loss of yield.

As a result of a more composable design, stLUNA liquidity on Astroport quickly picked-up to reach one-third of bLUNA’s. Current liquidity is thus fragmented between bLUNA liquidity, crucial to Anchor’s collateral market, and stLUNA liquidity, used in the rest of TeFi (e.g. on Edge or on Mars).

What if we could unite these assets and combine their liquidity on Astroport somehow? Surely, this would give the protocol an edge.

Enter the bLUNA <> stLUNA virtual pool

Because bLUNA and stLUNA are two representations of the same thing (LUNA staked with Lido), it is possible to leverage Lido’s smart-contracts to burn one and mint an equivalent value of the other. In effect, such a conversion is akin to a swap through an AMM pool with infinite liquidity.

To integrate this conversion mechanism into Astroport, a special pool can be created. It is ‘virtual’ because liquidity is sourced from the Hub, not from LPs, and deposits are disabled. To the user, it functions as any other pool, but in the background, tokens and messages are forwarded to the Hub and the proceeds returned to the user, in a single transaction.

The benefits of such a pool are numerous:

  • Improved UX: Astroport’s Router and users will benefit from the best bLUNA/stLUNA trade execution possible without having to leave Astroport for terra.lido.fi/convert.
  • Improved liquidity: because stLUNA and bLUNA are made freely interchangeable, one token’s liquidity becomes the other’s. Both assets become more liquid, more robust to manipulation and their pegs tighten. Concentrating liquidity and incentives around the more composable and LP-friendly stLUNA now directly bolsters collateral markets rather than undermining them.
  • Improved competitiveness: ss liquidity and UX improves relative to competing venues, Astroport should capture a larger share of trades, increasing churn and fee collection for LPs and ASTRO stakers.

Specification

  • The virtual pool functions just like a regular one, but ProvideLiquidity and WithdrawLiquidity are disabled.

Proposed Code

  • The code can be found here.

Test Cases

Tests covering swap transactions, simulations and the logic for accumulated price queries can be found here (bLUNA-stLUNA converter) and here (integration contract).

Because the price of stLUUNA increases every hour, even when no swaps occur, calculating an accurate TWAP for the converter contract could be problematic. We made a script to simulate the TWAP’s calculation using three different methods, and used the results to inform the development of the converter contract. More info here.

Security Considerations

  • No drainage risk: virtual pools don’t hold assets, so liquidity can’t be drained.
  • Ownership overtake: configuration can be modified by the owner. If ownership is overtaken, swapped assets could be routed through a malicious contract instead of the Hub.
  • Erroneous price diffusion: external services could be fed wrong prices if the contract’s calculations are faulty.
  • Overall, the contract’s risk profile is low. Nonetheless, we believe an audit is still required.

Auditor Information and Report

  • Lido on Terra created the code, which Astroport will deploy, own and manage the risk of. Astroport will thus bear most of the risk associated with this code, which is why we believe it should be responsible for the code’s external audit, so as to be aware of every security considerations. Lido on Terra cannot provide Astroport with security guarantees and the code “as is”, however, we are open to collaborating on the audit’s issue, and at Astroport’s disposal should any assistance be required.

Licensing

5 Likes
2

I think this would be a good addition. It is usually is more profitable to use the conversion mechanism and trade in the bluna pool than to trade in the stluna pool, due to the higher liquidity of the bluna pool. Even more so since the recent change of the AMP parameter at the bluna pool.

Once this is in place, once could question if it makes sense to keep liquidity split in the two pools or just concentrate the liquidity in one of them and use the conversion mechanism to swap to the other token.

2 Likes
3

I worry that once we implement it we introduce a feedback loop that will kill Luna-stLuna-LP pair.

Meaning:

  1. Luna-bLuna have more liquidity. So swaps will go through Luna-bLuna-LP and convert instead of Luna-stLuna-LP.
  2. Less swap fees on Luna-stLuna-LP
  3. Because there are less swap fees on Luna-stLuna-LP, LP providers withdraw their position and move to Luna-bLuna instead.
  4. Repeat from point 1.

And I don’t like that scenario. StLuna is better suited for ‘delegate to smart contracts’ cases and IMHO stLuna should be default staked Luna asset used in smart contracts (like LP).

BLuna should just be considered a ‘special anchor-specific flavor of staked Luna’ and that’s it. If anything I would prefer Luna-bLuna-LP pair to die off.

Perhaps we should consciously decide which pair should prevail (via some incentivizing) instead of letting the feedback-loop do its thing.

2 Likes
4

I agree with the premise that we don’t need two pools for essentially the same thing splitting out incentives and liquidity causing worst swaps for both. But I disagree with the idea that Luna-stLuna will die off.

If anything the implication of a metastabe pool for the stLuna-Luna would in my opinion make it the default pair.

Anchor is also in the plans of adoption the V2.1 borrow model and wants to phase out bLuna.

With the Anchor phase out, metastable pools, and the stLuna-Luna virtual pool makes stLuna the default choice of Liquid Staking derivative when compared to bLuna.

In my opinion the upcoming changes will slowly make bLuna less relevant and so more users will start joining the stLuna-Luna pool. That’s why I support the implementation of this proposal unless there is a big security risk (which will be reveled when audits are done).

1 Like
5

Hey @DefiCruncher and @Archkiwi, thank you for your pertinent takes!

The feedback loop @DefiCruncher describes is likely to play out, except we will make sure it plays out in reverse, with liquidity eventually migrating from bLuna to stLuna. Btw, allowing this migration of liquidity to benefit the protocols which rely on bLuna was one of the guiding principles for the virtual pool’s implementation.

As @Archkiwi mentioned, the metastable pool, the deprecation of bLuna in Anchor (and thus, Nexus too?) and the concentration of incentives on the stLuna-Luna pool will help steer liquidity towards stLuna.

Moreover, pending the bLuna-Luna pool’s upgrade, bLuna LPs are forced to forgo their staking yield, where stLuna LPs are not. All else being equal, this makes stLuna 7% more profitable than bLuna to LPs. Even after the upgrade, manually claiming rewards from Anchor’s UI will make harvesting and auto-compounding more tedious than it currently is with stLuna.

TL;DR Don’t worry, stLuna-Luna liquidity isn’t going away anytime soon :grin:

2 Likes