{"componentChunkName":"component---src-pages-sips-sip-markdown-remark-frontmatter-sip-tsx","path":"/sips/sip-264/","result":{"data":{"markdownRemark":{"fileAbsolutePath":"/vercel/path0/content/sips/sip-264.md","frontmatter":{"sip":264,"sccp":null,"title":"Update Atomic Pricing","network":"Ethereum","author":"kaleb (@kaleb-keny), Afif (@aband1)","type":"Governance","proposal":null,"implementor":"TBD","release":null,"created":"2022-07-28T00:00:00.000Z","updated":null,"status":"Rejected"},"html":"\n

Simple Summary

\n\n

This SIP proposes improvements to the atomic pricing methodology incorporating an in-block spot price (i.e. the live price).

\n

Abstract

\n\n

Update the atomic price methodology as to incorporate the in-block live price into the computation of atomic price (specified in the specification below).

\n

Motivation

\n\n

The current implementation of atomic swaps uses the spot price at the previous block. This exposes the debt pool to latency attacks, as the spot price at the previous block does not incorporate the latest updated information. Hence using the live spot helps reduce the latency considerably as shown in the scatter plot. The scatter plot shows the delta between centralized exchange prices and uniswap prices when considering same block price (orange) versus previous block pricing (blue).\nIt is important to mention that the updated computation would use the worse between live price, price at the previous block, twap and chainlink.

\n

Latency arbitrageurs can still push their transactions at the head of the block via flashbots or high gas prices, as to front-run a uniswap pool arbitrage and updated oracle pricing. The protocol would need to lean against this by increasing fees and incorporating slippage (using uniswapInputAmount).\nuniswapInputAmount is the amount used as an input to measure the price obtained by trading on uniswap.

\n

It is also worth pointing out out that this does expose the protocol to the ability of arbitrageurs to manipulate the uniswap price as to sandwish users or take advantage of latency. Therefore the minReturn is necessary to protect users and fees need to be high enough as lean against such oracle manipulation, the damage however is constrained to the use of the worse price with previous block price, twap and chainlink.

\n

The live price usage would add around 100k units of gas to the transaction per trade.

\n

Specification

\n\n

Technical Specification

\n\n

Update to the atomic price methodology

\n
Computation Methodology in Atomic Pricing Updated
\n

Atomic exchanges 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. This sip updates the computation laid out in SIP-258, incorporating a UniLive price which is the in-block price from uniswap.

\n
    \n
  1. PureChainlink Vs Not Pure Chainlink:
    2. \n
\n\n
    \n
  1. Naming Convention:
    2. \n
\n\n
    \n
  1. Below are the different scenarios that could arise for trading currencies that have or don't have the Pure Chainlink tag:
    2. \n
\n\n

Test Cases

\n\n

Configurable Values (Via SCCP)

\n\n

The same configurable values as those set out in SIP-120, SIP-198 and SIP-258.\nuniswap.

\n

uniswapInputAmount is an amount that should be specified per atomicEquivalent that allows for the calculation of the live uniswap price.\nIn case uniswapInputAmount is not specified on the atomicEquivalent being traded, then the amount being traded is used to fetch the uniswap live price (i.e. using the same amount of slippage one would obtain by trading on uniswap).

\n

Rejected by author

\n

Copyright

\n

Copyright and related rights waived via CC0.

"}},"pageContext":{"id":"6748da92-bef2-56c5-b55a-ef5f6518d95a","frontmatter__sip":264,"__params":{"frontmatter__sip":"264"}}},"staticQueryHashes":[]}