Update the atomic exchange functionality, laid out in SIP-120, to include the following changes:
\nThe SIP proposes to incorporate into the atomic exchanges the ablity to configure a pure chainlink price feed for certain synths. Furthermore, the SIP proposes to remove the restriction on the source or destination currencies being sUSD.
\nCurrently in order to add a synth into Atomic Exchanges, we need the following:
\nHowever, it is impossible to configure some forex stable synths due to the lack of an equivalent dex token that has deep persistent liquidity. One example is the recent EUR addition where we configured sEUR to take on the EURT token price. But TVL had dried up on the EURT/USDC pair, and liquidity flowed towards the EURT/USDT pool. This resulted in atomic prices being quoted at uncompetitive prices with respect to the fill that can be obtained elsewhere.\nAn analysis run on both EUR and GBP, whereby we looked at the price differential between the pure chainlink price against the prices seen on centralized exchanges reveals that a fee of 20 bp would more than sufficient to cover the latency gap related to pushing prices on ETH by an oracle.\nIn fact, chainlink push threshold on all forex synths is around 15 bp, which allows us to provide really competitive pricing without incurring the risk of oracle front-running.
\nRegarding the use case, synth stables on ETH have gained significant market share, due to the integration with FixedForex project and demand for these synths on curve for farming purposes. At the time of writing, the synth-forex market cap is around $220m and distributed as follows:
\nHence, we should expect some volume with atomic forex trading across different curve pools, for curve farming, as well as different integration with other partners.
\nThe restriction on the source currency or destination currency being in sUSD was incorporated in SIP-120 as a safety precaution. However, this can be relaxed as to accomodate for crypto to FX trades without exposing minters to additional risk.
\nThe implementation includes the following major sections:
\nWith SIP-120 any asset can be configured to trade atomically, however, the the downside is that it requires that a uniswap v3 pool be available with enough liquidity to make arbitrages on the uniswap pools align with real world prices. The lack of liquidity on those forex pools, resulted in prices drifting away on the EUR pools from prices on exchanges by hundreds of basis points. Furthermore, the lack of relevant uniswap liquidity pool for exotic forex assets makes this solution untenable.\nThe alternative specified in this sip, is to tag assets to trade at the pure chainlink price and allow for these assets to utilize the chainlink price for the fill. Although this does expose the staking pool to the risk of latency arbitrage, since the oracle used might drift away with from real world prices for a short period of time, that said, raising fees to a certain level (since stables drift by only a few bp at a given time) and incorporating off chain circuit breakers SIP-231 allows us to cover both the tail and non-tail latency risks.
\nsetPureChainlinkPriceForAtomicSwapsEnabled is a method in SystemSettings that allows assets to be tagged to trade at the pure chainlink price.getPureChainlinkPriceForAtomicSwapsEnabled is an internal function in MixinSystemSettings that returns True if an asset has been tagged to trade at purely the chainlink price and False otherwiseThe price of an exchange when a trade materializes from a source (SRC) currency to a destination (DEST) currency can be broken down into two price components:
SRC/USD, for example BTC/USD is at 38k$ per bitcoin.DEST/USDSRC currency, called SRC_Amount and he receives DEST_Amount.SRC/DEST is the trade price, being the amount of destination currency received per source currency. It is obtained by dividing SRC/USD by DEST/USD. For example trading 1 bitcoin into eur, with destination EUR/USD 1.05$ and source BTC/USD at 38k$. Applying the previous formula will lead to 38k/1.05 , resulting in 36,190 EUR received, assuming 0 fees.DEST_Amount is given by SRC_Amount * SRC/DEST * (1- fee).SRC or DEST is the US Dollar, the same logic still applies, where one of the components is USD/USD or 1. An example of this is a trade of 1 USD into BTC, in such a situation the trade price SRC/DEST is obtained by dividing USD/USD 1 by BTC/USD (38k$) which leads to 0.0000263 btc received.SIP-198, leads to combinations that involve the usage of chainlink in certain situations and the usage of uniswap in others or a combination of the two sources of prices.
\nDEST_Amount._Uni is denoted on a currency, it means the price is from the uniswap V3 based DexPriceAggregatorUniswapV3 contract_Chainlink is denoted on a currency, the chainlink price is usedSRC and DEST are both set to trade at the PureChainlinkPrice, in such a case, both SRC/USD_Chainlink and DEST/USD_Chainlink are used to compute SRC/DEST by dividing SRC/USD_Chainlink by DEST/USD_Chainlink.SRC is NOT set to PureChainlinkPrice and DEST is set to PureChainlinkPrice. Therefore, SRC/DEST is obtained by dividing min(SRC/USD_UNI,SRC/USD_Chainlink) by DEST/USD_Chainlink.SRC is set to PureChainlinkPrice and DEST is NOT set to PureChainlinkPrice. Therefore, SRC/DEST is obtained by dividing SRC/USD_Chainlink by max(DEST/USD_Chainlink,DEST/USD_Uni).SRC and DEST are NOT set to PureChainlinkPrice, in such a case, SRC/DEST is obtained by dividing min(SRC/USD_UNI,SRC/USD_Chainlink) by max(DEST/USD_Chainlink,DEST/USD_Uni) .Because prices could move by the time a trade lands on chain, minReturnAmount is incorporated, whereby a trade that leads to an amount lower than minReturnAmount would revert.
The CL_BUFFER is the buffer to be applied against the current Chainlink price in the direction detrimental to the trade, specified in bps and per-synth. This parameter had always been set to zero, given that controlling fees in order to offset latency was easier to reason about. Therfore, this parameter will be dropped from with current implementation of atomic exchanges.
Given that a trader intends to trade 10 sBTC to sEUR, with fees set to 0 bp
EUR/USD_Chainlink is at 1.1 while EUR/USD_Uni is at 1.2.\nBTC/USD_Uni is 37,000 BTC/USD_Chainlink is at 38,000.\nsEURand sBTC are NOT set to trade at the pure chainlink price\n300,000\n308,333 sEUR is sent to the user, and 10 sBTC is burned310,000\nsBTC and sEUR are both set to trade at the pure chainlink price\n300,000\n345,455 sEUR is sent to the user, and 10 sBTC is burned350,000\nsBTC is set to trade at the pure chainlink price and sEUR is NOT set to trade at the pure chainlink price\n300,000\n316,667 sEUR is sent to the user, and 10 sBTC is burned320,000\nsEUR is set to trade at the pure chainlink price and sBTC is NOT set to trade at the pure chainlink price\n330,000\n336,364 sEUR is sent to the user, and 10 sBTC is burned340,000\nGiven that a trader intends to trade 10 sBTC to sEUR, with fees set to 50 bp
EUR/USD_Chainlink is at 1.1 while EUR/USD_Uni is at 1.2.\nBTC/USD_Uni is 37,000 BTC/USD_Chainlink is at 38,000.\nsEURand sBTC are NOT set to trade at the pure chainlink price\n300,000\n306,791 sEUR is sent to the user, sUSD 1,696 is sent to the fee pool and 10 sBTC is burned307,000\nAside from the SCCP configurable variables specified in SIP-120, the Spartan Council can assign that an asset can be traded at the pure chainlink price via SIP with setPureChainlinkPriceForAtomicSwapsEnabled.
Copyright and related rights waived via CC0.
"}},"pageContext":{"id":"96ba2ddc-5a55-5db0-a731-5e136175c4bd","frontmatter__sip":198,"__params":{"frontmatter__sip":"198"}}},"staticQueryHashes":[]}