Skip to content

[Feature] Single-sided Asset LPs without RUNE exposure

Related #1340 (closed)

Goal

To attract more layer1 assets on external blockchains into the continuous liquidity pools of THORChain. The biggest blocker to this is a lack of interest to sell half their assets into RUNE and taking on RUNE price exposure. Ie, BTC maxis want to earn BTC on their BTC, but not be exposed to RUNE.

Accomplishing this goal will significantly increase the liquidity of the network and increase its pool depths.

Solution: Yield Bearing Synths

Synthetics is a feature launched on the network a month or two ago. It has since proven itself to be very successful as it significantly increases the capital-efficiency of the network, while also allowing for faster and more efficient arbitrage.

These synths, while contributing to the pool depths, are NOT yield-bearing. Any yield generated by the synth's ownership of the pool is passed on to the liquidity provider (LP) today.

The proposal here is that someone can acquire a synth, and "lock it up" into a vault. Locked synths will then generate a yield, which the network will mint more synths into the vault. This conceptually would follow the ERC-4626 tokenized vault standard.

Synth Yield Algorithm

Since synths are singled-asset exposed, and thus, shouldn't be affected by IL. So any yield generated should exclude any IL losses. To accomplish this, we can use LUVI. LUVI is an equation that helps determine the yield of a pool, irrespective of pool depth, asset price, and LPs. The equation is

R = rune depth
A = asset depth
units = lp units
LUVI = sqrt(R*A)/units

To calculate the yield between T1 and T2, calculate the LUVI at each point (T), then the difference between them (as a percentage).

Since locked synth holders take on significantly less risk than an LP, yield should be reflected. The yield of a saver would be 50% of their position (other half goes to double-sided LPs).

Controlling Leveraged RUNE Exposure for LPs

Due to the math of synths, regular LPs are taking a leveraged position on the RUNE asset today. This can help them earn more rewards if RUNE outperforms the asset, but can also go the other way as well.

The higher the percentage of synths that exist on the network relative to pool depth, the higher the leveraged position LPs are taking. Because of this, synths as they are implemented today, are limited to 15% of the asset pool depth. Since their use case primarily is to arb the pools efficiently, this is more than enough for most pools.

But now that synths can be yield-bearing, the demand for them will obviously explode, ensuring that the A) synth cap will be hit, and B) not allow more asset deposits into the pools (even if there is space in the pools). This is solved by protocol-owned liquidity.

Protocol Owned Liquidity (PoL)

Today the reserve has approximately 170m RUNE. This RUNE is primarily used for block rewards but can be available for other purposes.

The network can monitor the synth utilization on a per-pool basis, and add liquidity if utilization is greater than cap - 5% (if economic security allows). If synth utilization is under this figure, then the reserve would remove liquidity (if the PoL has an LP position in this pool).

cap = 5500 (in basis points)
range = 500 (in basis points)
PA = pool asset depth * 2
S = synth supply

utilization = S / PA * 10000

// RUNE added or removed should "step" in the right direction, not leap. Every X blocks, it should add/remove 1% of how much is needed to level synth utilization. This limits PoL losses via slippage.

if utilization < cap - range {
  if pooledRune <= bondedRune { // ensure we respect the hard pool caps / economic security
    // add rune to pool from the reserve
  }
} else {
 // remove rune from pool to the reserve
}

By having the reserve add rune, it de-risks LPs from over RUNE leverage, as the reserve takes on some of that risk. Which the reserve is happy to do since it's long its own (and only) asset. This, in turn, creates synth space in the pool, for more single-sided asset deposits in the form of synths to enter.

Note: ILP still stands to downside-protect LPs to their deposit. The PoL is acting to dilute the risk back down.

Conclusion

This approach allows asset maxis to add assets to the pool WITHOUT taking on RUNE exposure. This change is relatively easy, as most of it is already implemented. Just need to:

  1. Create a synth vault/module, be able to lock/unlock, and pay rewards routinely
  2. Create a mechanism for the reserve to add/remove RUNE from the pools

Pros

  1. Community can earn asset on asset (BTC on BTC) without exposure to RUNE
  2. No significant changes to UIs. LP'ing is the same as it was before. The only change needed is a means to lock and unlock synths
  3. Reserve takes on part of the leveraged rune price risk instead of LPs, and earns a yield to counter that risk.
  4. No changes to pool structure, ownership, yield/reward systems, or mathematics.
  5. Reserve earns a yield and tops up its own vault, giving it more longevity

Additionally

  • Synth-savers pay a small slip-based fee to enter-exit, this means utilization of the vault creates volume and fees over the pools
  • The fee prevents mass-exits which could dislocate prices on the pools, and encourages arbitrage to keep prices tight
  • The RESERVE is only becoming an LP to the amount that the synth-vault scales AND LPs don't take up the opportunity (LP of last resort).

Cons

  1. Deployed RUNE from the reserve will cause block rewards to decrease
  2. The reserve is "buying" all other assets in the network and taking on that price risk. I suspect the reserve's capital may shift to being partially a crypto ETF of sorts.
  3. The reserve entering and exiting a given pool will cause buy/sell pressure on the rune asset. Furthermore, when rune's price drops the reserve asym adds rune into each pool, causing a sell pressure on the rune asset. When rune's price increases, the reserve withdraws its LP position to rune, causing buy pressure on the rune asset.
Edited by Son of Odin