(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](https://www.cmegroup.com/trading-hours.html) 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.
+
+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,7 +54,7 @@ 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.
+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.
@@ -61,7 +64,7 @@ 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.
+   A successful market maker tunes the spread and offers liquidity to limit adverse selection from smart traders while still interacting with the 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.
@@ -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:
+
+1. **Use a Delayed Settlement**: Derivative protocols can introduce a delay between the time a contract is executed and the time it is settled. This delay gives the protocol time to observe price changes and reject transactions that are based on manipulated prices.
+   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.
+
+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.
+
 ## Confidence Intervals
 
 At every point in time, Pyth publishes both a price and a confidence interval for each product. For example, Pyth may publish the current price of bitcoin as \$50000 ± \$10. Pyth publishes a confidence interval because, in real markets, there is _no one single price for a product_. For example, at any given time, bitcoin trades at different prices at different venues around the world. While these prices are typically similar, they can diverge for a number of reasons, such as when a cryptocurrency exchange blocks withdrawals on an asset. If this happens, prices diverge because arbitrageurs can no longer bring prices across exchanges into line. Alternatively, prices on different venues can differ simply because an asset is highly volatile at a particular point in time. At such times, bid/ask spreads tend to be wider, and trades on different markets at around the same time tend to occur at a wider range of prices.