(feat) Add delayed settlement section #396
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
pages/price-feeds/best-practices.mdx
Outdated
| @@ -70,6 +73,18 @@ This analogy suggests two simple solutions to races: | |||
| The protocol can require a short delay between the two transactions, and the user's request gets fulfilled at the Pyth price as of the second transaction. | |||
| This technique gives the protocol extra time to observe price changes, giving it a head start in the latency race. | |||
|
|
|||
| ### Latency Mitigations for Derivative Protocols | |||
|
|
|||
| To mitigate the risk of latency, derivative protocols should consider the following strategies: | |||
There was a problem hiding this comment.
I think it's good if you emphasize why even the slightest latency can affect derivatives. (leveraged markets)
Also, "derivative protocols are encouraged to consider the following strategies"
There was a problem hiding this comment.
It was mentioned above in the latency section.
pages/price-feeds/best-practices.mdx
Outdated
| @@ -70,6 +73,18 @@ This analogy suggests two simple solutions to races: | |||
| The protocol can require a short delay between the two transactions, and the user's request gets fulfilled at the Pyth price as of the second transaction. | |||
| This technique gives the protocol extra time to observe price changes, giving it a head start in the latency race. | |||
|
|
|||
| ### Latency Mitigations for Derivative Protocols | |||
There was a problem hiding this comment.
why derivatives in particular? I think these tips are applicable to any protocol right?
There was a problem hiding this comment.
I believe derivatives are getting impacted by this issue the most.
pages/price-feeds/best-practices.mdx
Outdated
| 1. **Use a Delayed Settlement**: Derivative protocols can introduce a delay between the time a ordere is created and the time it is executed. This delay gives the protocol time to observe price changes and reject trades/transactions that profit over latency. | ||
| Moreover, As mentioned above the protocol can introduce a short delay (~5 seconds) between the time a user submits the tx to the application and the keeper submits the tx to the blockchain. | ||
| The keeper can use Pyth Benchmark to get the price of `t - 5` seconds, where `t` is the current time and `t - 5` is the time when the user submitted the tx to the dApp. | ||
| Now the keeper can use [`parsePriceFeedUpdates()`](https://api-reference.pyth.network/price-feeds/evm/parsePriceFeedUpdates) to parse the prices and submit to prevent price frontrunning. |
There was a problem hiding this comment.
This description of delayed settlement is confusing. The core idea of delayed settlement is that when a user places an order at time t, the trade executes using the pyth price at time t. (Now, this price is only available from pyth after a short delay, hence the name.) We should explain delayed settlement in these terms though because it's much clearer why this works.
There was a problem hiding this comment.
Rewrote it. Still feel it could be better. 🤔
| Now the keeper can use [`parsePriceFeedUpdates()`](https://api-reference.pyth.network/price-feeds/evm/parsePriceFeedUpdates) to parse the prices and submit to prevent price frontrunning. | ||
|
|
||
| 1. **Use a Confidence Interval**: Pyth provides a confidence interval for each price update. Derivative protocols can use this confidence interval to determine the range in which the true price probably lies. | ||
| By using the lower bound of the confidence interval, derivative protocols can protect themselves from price manipulation that drives the price down. By using the upper bound of the confidence interval, derivative protocols can protect themselves from price manipulation that drives the price up. |
There was a problem hiding this comment.
Are there other mitigations we should list? I've seen some protocols that require positions to be held for X minutes or something. Do we think that's a good idea?
There was a problem hiding this comment.
Not having to hold position for X minutes is a feature that some protocols want to have, so I believe we shouldn't mention that.
There was a problem hiding this comment.
Well i think that's also a good measurement against potentially other things and it's definitely good to mention it, but probably not here.
It can be converted to a guide when we move towards solution based document sections. In the meantime, we can share this to our existing perps.