BEPSwap Pool Ownership Issue and Fix

THORChain

2020-09-16 — 5 min read

Report

After a large CAP raise, users began reporting two issues to do with their liquidity ownership. The team deep-dived the problem, identified the issue, and prepared a fix.

Issue

BEPSwap users reported two things:

When adding liquidity it appeared to them they got a “bonus”

When being in a pool for a while their ownership was eroded.

The team investigated and identified two issues in how pool ownership was allocated; the “bonus” and the “erosion”.

Response:

The team firstly confirmed the issue, then took the following steps:

Reduce the CAP to a low number to prevent new stakers entering.

Increase the RESERVES to pay out a higher amount to existing stakers in order to help them recover any erosion.

Analysis

Bonus

The team found UniswapV1 to not have any issues. A fix, based on UniswapV1’s methodology, was prepared and analysed. This fixed the Bonus problem.

Erosion

Erosion of liquidity is caused by asymmetric stakers swinging the pool’s price significantly and being allocated more of the pool than if they had swapped their assets and staked. When swapping their assets they pay a slip-based fee, but the existing pool ownership function did not take this into account. To address this, the pool ownership equation is modified to include a “slip adjustment factor”, which applies a discount to inbound liquidity when it creates a change in the pool’s price before and after adding liquidity, which is the same as if they had swapped and staked. Symmetric liquidity providers do not create a slip, so receive the full allocation of ownership.

Existing Methodr = rune staked;
a = asset staked
R = Rune Balance (after)
A = Asset Balance (after)
units = ((R + A) (r A + R a))/(4 R A)

Amended Method

Assign the first liquidity provider units equal to the amount of RUNE contributed

Assign subsequent liquidity providers units equal to the following equation:r = rune staked;
a = asset staked
R = Rune Balance (before)
A = Asset Balance (before)
P = Existing Pool Units

slipAdjustment = (1 - ABS((R a - r A)/((2 r + R) (a + A))))
units = ((P (a R + A r))/(2 A R))* slipAdjustment

Uniswap V1

Uniswap’s algorithm mints pool ownership based on the proportion of ETH deposited, compared to the existing depth, multiplied by the existing number of pool tokens.

The team found this algorithm to not cause any Bonus issues, and because only symmetrical liquidity provision is allowed, Erosion did not apply.

THORChain

Bonus Problem

THORChain has to tolerate asymmetric liquidity provision since it cannot pull funds from wallets, so must deal with whatever is sent to it, and asymmetric liquidity provision is a valid arb strategy. The original algorithm took the mean of the deposited assets to find the share of the pool, then multiplied that each side, then took the mean of that. This method works fine if there is no price change.

After the same scenario as above, it can be seen that the final LP gains an unfair “bonus”. This bonus is more noticeable the more drastic the price changes for a pool over the course of the liquidity being added.

Fixing Bonus

To address the issue found, the algorithm for assigning pool ownership is amended as follows:

The first minter is assigned pool units simply equal to the amount of RUNE deposited. This creates P.
The subsequent minters are as follows:

Capital Erosion

The second issue is that of capital erosion from existing liquidity providers. The root cause is that the original algorithm did not take into account the slip generated by large asymmetric liquidity providers.

In this scenario, the second LP conducts two large assymetric stakes.

They can then claim back more than what they put in, at the detriment to existing LPs.

Fixing Capital Erosion

To fix this, slip must be accounted for and “virtualised”. The intent is to transfer an equivalent amount of assets from the asymmetrical liquidity provider to all previous liquidity providers to be equivalent to the fees that would have been retained had the incoming liquidity provider done a swap instead. The pool ownership algorithm is then modified to included this slip adjustment.

Running the scenario again, the problem is now fixed. The existing providers now *benefit* at the expense of a liquidity provider that conducts a large asymmetrical stake. The accumulate fees they would have accumulated if the LP had done a swap and stake first.

Conclusion

The team did discover two issues relating to pool ownership, causing a “bonus” and liquidity erosion. The issues were separate and the root causes for them were from different reasons. The bonus was caused by incorrectly deriving pool ownership during dynamic price changes, and the erosion was caused by not factoring in slip during an asymmetrical stake. The team derived a final pool ownership equation that has addressed both issues, and should stop the bonus and erosion from occurring again.

Full Report:

https://github.com/thorchain/Resources/blob/master/Audits/BEPSwap-PoolOwnershipIssueAndFix-Sep2020.pdf

Fix:

The team will upgrade the state machine with the new logic and roll it out to the network this week as Version 0.14.0. Once the network is upgraded, the CAP can be raised again.