Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Arb pool: time based rewards and splitting into 2 contracts #69

Spreek opened this issue Dec 20, 2019 · 0 comments

Arb pool: time based rewards and splitting into 2 contracts #69

Spreek opened this issue Dec 20, 2019 · 0 comments


Copy link

@Spreek Spreek commented Dec 20, 2019

Time based rewards for arb pool

Currently, the arb pool is not accomplishing its goals. There have already been two sets of improvements suggested by @kaiynne and @AndrewK respectively. However, in my opinion, neither solution really gets to the heart of the problem. I propose a time based rewards scaling method that achieves a more efficient use of inflation while also heavily discouraging manipulation. Implementing this as a starting point will also untie our hands when it comes to a number of other design choices that were previously discarded due to risk of manipulation.


The way the current arb pool works is that when the conditions are met (sETH/ETH uniswap pool price <0.99 and SNX is currently in the contract), a user can send ETH to the contract, The contract then converts the ETH to sETH via uniswap (until the price is back to 0.99), stores the sETH, and sends back to the user (sETH received *(SNX/ETH market rate)) in SNX (as well as any unconverted ETH).

Currently, arb bots are heavily manipulating this system, see this comment by @nocturnalsheet. Ultimately, the issue is that the system is too generous and allows a large amount of slack which enables manipulation. Arb bots are competing based on speed and insider information (the fastest to send will often be the one who knows exactly when the arb pool condition will be triggered), rather than price.


The way to solve both the problem of inefficient use of inflation as well as manipulation is to force arbers to compete based on price. Clearly, someone manipulating incurs non-zero costs in order to do so. As long as he is very likely to collect the arb pool rewards, these attacks may be very profitable indeed. However, given the chance, an honest arber that has no such costs will be willing to outbid them, earning a profit while denying profitability to these attacks.

The easiest and most elegant way to do this is by implementing increasing rewards over time, similar to an auction. I propose the following mechanism. A user sends ETH to the contract when the arb pool conditions are met and receives (ETH sent * SNX/ETH rate) + multiplier*SNX/ETH rate. So the user receives SNX at some discount determined by the multiplier. Note that in the current system, this multiplier is set to (sETH stored in contract - ETH sent by user) always. Instead, we should set this multiplier as an increasing function of both peg deviations and time.

A few possible multiplier function choices (see this google doc for a visualization):

  1. constant*(sETH stored in contract - ETH sent by user)*number of consecutive X minute periods in which pool is arbable

  2. constant*sum of deviations from peg in consecutive X minute periods in which pool has been arbable

  3. constant*(area under curve of deviations)

  4. constant*log(1+area under curve of deviations)

  5. some other function

The key idea is that the multiplier should start significantly lower than the current one to start with and gradually scale up (possibly to a cap at a certain level, either the current reward or a slightly higher one). I favor something that considers both the length of time and the severity of deviations. In this way, SNX should be sold at a much better rate than currently, and manipulation should be seriously diminished. Another benefit is that the system will be more robust to the contract becoming arbable at a price far away from the threshold (for example, if a user makes a large market sale with high slippage or if new SNX is added to the contract when the sETH price is far from 0.99)

Open questions:

  1. Should we introduce such a time based system?

  2. If so, what multiplier function should be used?

  3. Should we combine this proposal with any other proposed arb pool improvements (such as those proposed by Kain or AndrewK, or the multiple arb pool concept described below)?

Multiple arb contracts

This is not a new proposal, @gmgh/DegenSpartan has suggested this concept many times in the discord. Instead I want to lay out my vision for how such a system could work. First, I think there are two major goals of the arb pool: to help traders sell quickly at a price near 1:1 and to reassure traders, uniswap LPs, and other synth holders that their synths will not become worthless overnight.


I would like to see two separate arb contracts that focus on one of these goals at a time. The maintenance contract would focus on goal 1, and would mostly be focused on smoothing demand for synths and keeping price largely in the .99-1.01 range. This contract's arb threshold would probably be set at 0.99 similar to the current contract. It should be expected that the vast majority of inflation dedicated to this contract will be used on a weekly basis, but there should be a focus on capital efficiency. So methods like locking SNX rewards, sending users mostly sETH instead of mostly SNX, etc can be considered.

A second contract, what I would call an assurance contract, is focused on the second goal of helping synth holders and arbers feel secure that the peg will hold up. A big problem with peg maintenance in the history of stablecoins has been the problem that arbers become less and less comfortable arbing as price gets further away from the peg. It may be a very good trade to buy a stablecoin at 0.97 intending to sell it at 1.00 and a very bad trade to buy a stablecoin at 0.87 intending the same thing. Often, getting off peg leads to a bank run type situation where many people start selling off in expectation of others selling off. In our current model, this would be especially dangerous as a large portion of synths are actually being used as uniswap liquidity. A panic situation could lead to liquidity being removed and synths being sold back to the pool, which makes the selling have even more of a market impact.

In order to avoid this, it is desirable to have an arb pool that builds up a large amount of SNX that becomes available only in rare cases. I propose a pool that becomes arbable only if sETH/ETH price goes down below 0.95, chosen because price has rarely if ever dropped that far in recent months. This should be optimized for maximum liquidity, so it should be paid entirely in (unlocked) SNX. If necessary to use this pool, we want arbers to be absolutely confident in getting paid.

It is likely that the pool would build up a sizable amount of SNX at this level, which would make a bank run type situation less likely. It also makes the game theory more desirable for arbers that don't go through the contract. If I want to buy sETH at 0.96 and sell when price gets back to 0.99, I am primarily concerned about the likelihood that price continues to drop down. If they know that there is a sizable supply waiting to support at 0.95, I will likely have a good risk/reward to begin buying sETH before it gets to that level. This mechanism means it is even less likely that this pool needs to be actually tapped into

The two major concerns with this idea in the past have been the prospect of manipulation and the risk of needing additional inflation. I believe that combining this with the time based rewards described above solves most of the manipulation risk. It's true that this may require additional inflation -- however, one important consideration is that inflation that sits in the arb pool indefinitely does not dilute holders until it is actually released. In the case that the peg breaks that hard, it is likely much better for SNX holders to be diluted than to allow a bank run type scenario to play out.

Open questions:

  1. Should we implement 2 or more contracts to achieve these dual goals?

  2. What should thresholds and inflation allocations be?

  3. What exact design tools should we use to achieve maintenance and assurance?

  4. Is there a serious risk of manipulation caused by creating an assurance contract?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.