SIP-7: Oracle Trading Locks

Simple Summary

SIP-6 was effective in removing several front-running bots, but these bots have rapidly adapted to the mechanism implemented in SIP-6. SIP-6 was always intended to be a short term deterrent. This SIP intends to be a longer term solution to front-running. It enables the oracle service to perform three functions:

1. Pause exchanges
2. Prevent trades while an oracle update is in progress
3. Removes the destination param in an exchange so that exchanges only go to the messageSender

Abstract

There is an attack vector that allows front-running the oracle by observing exchange rate update transactions after they are broadcast, then attempting to trade into a currency that will shift in favour of the trade. This front-running attack is extremely effective if well constructed and provides almost risk free profits. This SIP will likely render this method ineffective, as it will halt trading when the oracle detects a change in price. Once the trading halt is in place the oracle will push a price update and re-enable trading. This means that a trade broadcast right as an oracle update occurs will likely be rejected and have to be resubmitted, which impacts usability but we are planning UI updates to prevent this from impacting users on Synthetix.Exchange.

Any trades / exchanges during the lock period will revert and no balances be affected. The balance of the gas paid for the transaction will be returned the wallet, about 90+ %.

Motivation

The motivation for this change is the same as for SIP-6, it is critical that users of the exchange do not have the ability to exploit the latency of the blockchain to make profit at the expense of SNX holders. While we welcome trading bots using valid strategies we believe the network must be able to prevent and punish users attempting to exploit this latency.

Specification

The oracle code is currently closed source, so we will not be publishing the exact spec of the mechanism. But before the Oracle submits an exchange rate transaction it will submit a flag to halt trading, and only remove this flag once the price update has been confirmed on-chain.

Rationale

While SIP-6 was a slashing condition to punish front-running, this SIP address the root cause of the attack which is the ability to submit a trade before the oracle can reset rates. A bot could attempt to avoid slashing using several methods that would have reduced the efficacy of SIP-6 over time. This SIP combined with SIP-6 should change the calculus for a bot owner because the likelihood of profitability has been significantly reduced while still incurring the risk of slashing via SIP-6.

Test Cases

https://github.com/Synthetixio/synthetix/blob/master/test/ExchangeRates.js#L1027

Implementation

https://github.com/Synthetixio/synthetix/blob/master/contracts/ExchangeRates.sol#L308

Copyright

Copyright and related rights waived via CC0.