(feat) Add delayed settlement section

pages/price-feeds/best-practices.mdx

@@ -20,6 +20,9 @@ The confidence interval is `1500 * 10^(-5) = $0.015`, and the price is `12276250
 Sometimes, Pyth will not be able to provide a current price for a product.
 This situation can happen for various reasons.
 For example, US equity markets only trade during certain hours, and outside those hours, it's not clear what an equity's price is.
+Pyth price feeds follow the traditional market hours for each asset class. \
+Consult [Market Hours](./market-hours.md) to know the market hours for each asset class.
+
 Alternatively, a network outage (at the internet level, blockchain level, or at multiple data providers) may prevent the protocol from producing new price updates.
 (Such outages are unlikely, but integrators should still be prepared for the possibility.)
 In such cases, Pyth may return a stale price for the product.
@@ -32,15 +35,15 @@ The SDK provides a sane default for the staleness threshold, but users may confi
 
 ## Adversarial selection
 
-Pull updates gives users of Pyth Network some ability to select which price to use in a transaction.
+Pull updates give users of Pyth Network some ability to select which price to use in a transaction.
 This ability is highly circumscribed by various constraints: on-chain prices must move forward in time and cannot be from too far in the past.
-However, users can still chose any price update that satisfies these constraints.
+However, users can still choose any price update that satisfies these constraints.
 This ability is functionally equivalent to latency: it allows users to see the price in the future before using a price from the past.
 
-The simplest way to guard against this attack vector is to incorporate a staleness check to ensure that the price used in a transaction is sufficiently recent.
-The Pyth Network SDKs include this check by default, where queries for the price will fail if the on-chain time differs from the price's timestamp by more than a threshold amount.
-The default threshold is set per-chain, but is typically around 1 minute.
-Highly latency-sensitive protocols may wish to reduce this threshold to a few seconds to better suit their needs.
+The simplest way to guard against this attack vector is to incorporate a **staleness check** to ensure that the price used in a transaction is sufficiently recent.
+
+The Pyth SDK provides the [`getPriceNoOlderThan()`](https://api-reference.pyth.network/price-feeds/evm/getPriceNoOlderThan) method to help users guard against this attack vector. This method returns the most recent price update that is not older than a specified threshold.
+Highly latency-sensitive protocols may wish to reduce the threshold to a few seconds to better suit their needs.
 Please also see the section below on [latency mitigations](best-practices.md#latency) for additional ideas on how latency-sensitive protocols can minimize the impact of oracle latency.
 
 ## Latency
@@ -51,24 +54,20 @@ The threat model for integrating protocols should assume that adversaries see pr
 In this threat model, protocol designers should avoid situations where a Pyth price update must race against an adversary's transaction.
 Adversaries are highly likely to win these races, as they have a head start, and sophisticated adversaries can additionally optimize their network latencies or pay miners for priority blockspace.
 
-This situation is analogous to market making in traditional finance.
-Market makers place resting orders on exchanges with the hope of earning the bid/ask spread.
-When the “true price” moves, these market makers get picked off by adverse “smart flow” that is faster than they are.
-The smart flow is balanced by two-way flow, that is, people wanting to trade for other reasons besides a price change.
-
-This analogy suggests two simple solutions to races:
-
-1. Configure protocol parameters to balance the losses from smart flow against the gains from two-way flow.
-   Market makers in traditional finance implement this approach by offering a bid/ask spread and limited liquidity.
-   The limited liquidity caps the losses to smart flow, while still earning profits from the two-way flow.
-   A successful market maker tunes the spread and offered liquidity to limit adverse selection from smart traders while still interacting with two-way flow.
-2. Give the protocol a "last look" to decide which transactions to accept.
-   In traditional finance, some exchanges give market makers a chance to walk back a trade offer after someone else has requested it.
-   Protocols can implement this technique by splitting transactions into two parts: a request and a fulfillment.
-   In the first transaction, the user requests to perform an action.
-   In the second transaction, the protocol chooses whether or not to fulfill the user's request; this step can be implemented as a permissionless operation.
-   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[^1]
+
+Derivative protocols are encouraged to consider the following strategies to mitigate the impact of oracle latency:
+
+1. **Use Delayed Settlement**: Derivative protocols can introduce a delay between the time an order 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.
+   Suppose a user submits a trade transaction at a time `t`. The protocol should execute the trade by using the price at the time `t`, which will be available to the protocol after a short delay.
+   The protocol can fetch this price update of a specific timestamp from [Hermes](https://hermes.pyth.network/docs/#/rest/timestamp_price_updates) and 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 Spread**: 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.
+
+1. **Enforce Position Holding**: Derivative protocols can enforce hold times on positions to prevent users from exploiting oracle latency.
+   For example, a protocol could require users to hold an asset or a position for a certain period before they can trade or close it.
+   This hold time gives the protocol time to observe price changes and reject trades that profit over latency.
 
 ## Confidence Intervals
 
@@ -92,3 +91,9 @@ The same principle would apply if you wrote a derivative contract. If someone wa
 1. Using Pyth's exponential moving average price, which represents estimates of the average price of the asset over a specified time period (e.g., over the past 1 hour). The exponential moving average price is computed such that it lessens the influence of prices with wide confidence intervals. You may find more details in [EMA Price Aggregation](./how-pyth-works/ema-price-aggregation.md).
 2. Using the aggregate price, which is Pyth's best estimate of the price at a single point in time. The quality of this estimate depends on the width of the confidence interval at settlement time and on occasion, it may be imprecise. However, it is the best you can do with Pyth data if you need a single price at that exact point in time.
 3. Defining the contract to depend on confidence. For example, you could create an option that refunds the option premium to the buyer (so both sides of the transaction are even) if the strike price is within the confidence interval at settlement time. You could also create a contract that delayed settlement until the confidence interval was sufficiently small. If you choose this second option, you should ensure that your contract is guaranteed to eventually settle even if the confidence interval never narrows.
+
+##
+
+[^1]:
+    _The strategies and methodologies outlined in this page, including those addressing price latency mitigation, are provided solely for informational purposes and might not fully eliminate the discussed problems. Do your own research before using them. \
+    Refer to [Terms of Use](https://www.pyth.network/terms-of-use) for more information._