Arb Pool Upgrade Proposal

[RewKang]

Abstract

So right now our arb pool is working OK, but it is a bit inefficient in the way it utilizes capital and there are concerns that it might not be able to stand up to acute system stressors. This proposal on how we can improve the arb pool consists of three parts which I'll break down separately:

1. Modification of Arb Loop
2. Dynamic Arb Incentives
3. sETH Pool Migration

1) Modification of Arb Loop

Situation - The way the current arb contract works is that it allows users to buy SNX with ETH proportional to the current sETH:ETH peg rate if the peg is below 0.99. In the backend, the arb contract converts the ETH to sETH and provides newly minted SNX to the arber. Based on this current design, we're essentially conducting a dilutive share offering every week - even though new SNX is being minted, 99% of the value of that SNX will eventually go back to SNX holders in sETH form. Therefore we aren't leaking much value out of the system compared to Uniswap LP rewards where the SNX system does not receive any assets in return for the airdrops.

The problem with this model is that its not an efficient use of inflation. Assume for example the following scenario: A new fee period starts with 72,000 newly minted SNX dropped into the arb contract. One trader buys out the entire contract with an average peg price of 0.99. Assuming SNX = 0.01 ETH, he put 712.8 ETH worth of buying pressure on the sETH/ETH pool for this trade.

Solution - Imagine if instead of receiving SNX from the contract, the trader receives sETH at a 1:1 rate to ETH. They then receive a proportional amount of SNX based on the sETH discount they bought in at. So if a trader were to put in 712.8 ETH @ 0.99 peg, they would receive 712.8 sETH + 712.8 SNX.

WOW! The trader still receives 1% arb and you get the same net effect on the sETH/ETH pool with only 1% of the inflation required in the current model. Overall, the NET value outflows from the system that SNX holders bear are the same in both models.

Benefits:

• Positive for synth supply (old system essentially lowers synth supply based on how much sETH is used for arb)
• Significantly lower inflation rate (helps us hit the 2-4% total inflation target)
• Solves the problem of figuring out what we do with leftover sETH in contract

2) Dynamic Arb Incentives

Situation - Right now the arb rewards keep the peg within a range of 0.97 to 1.00, with a tendency to fall off towards the end of the week. Noone is raising large concerns about this right now, but if we wanted to attract any serious traders to the platform, they should have absolute confidence that they should be able to enter and exit out of synths 1:1 almost all the time.

Another problem is that we don't have any disaster protection, we are using 72,000 SNX per week which looks like it will always get quickly drained. If the pressure on the peg increases even a little bit from the current state, we could see the peg deviating very widely (5%+) or see minor peg deviations (2%-4%) for sustained periods - both are bad.

Solution - Adjust the amount of arb incentives supplied every week depending on how off the peg was on average the previous week.

My proposal is to have a base 5,000 SNX dedicated to the contract every week. For every 0.001 deviation from 0.99, the arb incentive increases by 10% with a cap at 0.95. The reasoning is that the more we are off the peg, the more dire the situation is, and the more resources we should be using.

Here's a graph of how the numbers look and what % of inflation is reflected (based on 150M SNX Supply & 250M SNX Supply)

3) sETH Pool Migration

Situation - The arb pool is currently being exploited via large sETH holders smashing the peg of the sETH pool. However, they are currently limited by the fact that it is hard to sell large SNX positions that they gain from the sETH sale. The modification of the sETH loop to a more capital efficient manner as proposed above makes it easier for the arb pool to be exploited through sandwich attacks. Uniswap trade fees are static (0.30%) and don't protect against sandwich attacks which only costs attackers 0.60% total.

Solution - Fork the uniswap contract and implement the CLP formula for liquidity pools. In addition, set a minimum base fee of 0.30%. The CLP formula replaces the fixed rate fee with a variable fee based on how much slippage a trade results in. This makes sandwich attaks prohibitively expensive.

Given a pool with assets X and Y, and an input x and output y the CLP formula is:

y = (x * Y * X) / (x + X)^2 where P = X/Y.

More info here: [(https://medium.com/thorchain/thorchains-immunity-to-impermanent-loss-8265a59066a4)]

[kaiynne]

Thanks Andrew, this is a very interesting proposal!

One concern I have with part 1 is the current attack vector may not be closed. An attacker can still sell the sETH pool down below .99 and then buy it back up to get the SNX reward. The cost of this is higher than with the current arb contract, but if my math is correct the roundtrip cost is .6% + slippage and the attacker gets 1% of their trades back as a rebate in SNX. So assuming the total cost including slippage is 1.1% they essentially pay 10% over spot for SNX with sETH. This is probably not rational but it is still a fairly efficient way to leverage a lot of sETH into SNX at the spot rate because if you bought 72k SNX on market right now you would probably have 5%+ slippage anyway.

On 2 would we take the average peg deviation over the period?

[RewKang]

For Part 1, the attack vector is solved by either Part 3 (sETH migration to CLP Pool) and/or increasingly efficient arb bots. For large scale attacks, the slip based fee incurred by the attacker will exceed the current fee and gets increasingly larger, the larger the trade sizes are. If an attacker were to split this into smaller lots, in the future they still need to compete with other arb bots that are also monitoring the arb pool for arb opportunities (I believe you can't do this exploit atomicly, so others would be compete with you after you knock the peg down with the first tx). I would expect that we see bots competing with each other and monitoring tx in the mempool such that they pay out almost all of the arb revenue to gas costs. Therefore, game theory dictates that these attacks would not be attractive as the initial attacker always has higher costs.

For Part 2, yes we would take the average peg deviation. Potentially with hourly lookbacks/snapshots to prevent manipulation if this is not too gas intensive.