Oracle
Last updated
Last updated
Need:
Source
Timeframe
contracts affected by oracle
functions of oracle, as seen above.
In terms of prices, communicated to the user, there are 2 protection mechanisms in place:
Slippage - set by the user themselves in the UI. The slippage function reduces the risk of a user paying more for a currency than they are comfortable paying.
Safe Deviation (SD) - SD is an internal price protection mechanism that varies depending on whether DEXs/Pools or CEXs are used for execution. In general, SD exists to secure execution even when slippage was set to 0 by the user.
The essence of SD is the “deterioration” of available prices (bids or asks depending on the direction of a given trade) by a certain coefficient. SD is calculated by the Aggregator and addressed in the following manner with CEXs and DEXs:
On CEX USDT pairs; we consider the SD to be 0 - normally, there is enough USDT liquidity on various levels on most pairs to ensure execution without applying the SD.
On CEX non-USDT pairs (for instance, ETH/BTC,) we’ve been applying an SD of 0.4% - complex swaps require more steps and higher risk of price deviation during complex swap execution.
On DEXs, we apply a uniform 0.15% safe deviation for simple swaps. Where complex swaps are involved, the SD is multiplied by the number of steps/transactions - i.e., with two steps within a complex swap (maximum we do now is two steps, anyway) is 0.15% x 2 = 0.3%.
Sometimes this happens to be enough, however.
Example: Recently, we had a situation where a complex swap failed, like so:
Complex swap BNB -> BUSD -> USDT, tx sent on Oct 1, 2022, @ 21:48:43.942 to Orion Blockchain. Approximately 700 ms before the trade on PCS, somebody swapped ¬2,5M USD on BNB-BUSD, which caused the reserves to change ¬2.5% on this pool. In this case, the SD of 0.15% was insufficient, and the trade failed, with the Aggregator not catching the quick and drastic change.
Internal logic of the SD application relies on three price benchmark levels for a given trade:
Unexecutable trades/levels (i.e., somebody trying to buy BTC for 10 cents).
Executable, not safe - for instance, if BTC’s market price is 24 000 USD, an order between 20 000 and 24 000 would be deemed executable but unsafe. This would most likely cause the protocol to keep the order in the internal order book until it is able to execute safely.
Executable, safe - for instance, if somebody is trying to purchase BTC very close to market price levels, i.e., 24 000, which would be sent for execution right away with the applicable SD.
There are plans for modifying the logic of SD application on DEXs, moving away from adjusting prices and on to adjusting presentation of reserves.
Of note, all of the above does not cover Orion’s fee (i.e., actual commission + network fee), which are added on top of users’ orders and depend on the order volume and not the available reserves/price levels, etc.
