docs: replace dead Cosmos SDK doc links and unlink defunct MEV dashboard

Cosmos SDK docs reorganized to a /sdk/<version>/... layout, leaving prior
/main/... and /v0.47/modules/... paths returning 404. Repoint all references
to verified successors under /sdk/v0.50/ and /sdk/v0.47/build/.

The observatory.zone/dydx/mev dashboard origin returns 503 consistently
(not transient); remove the linkout while keeping the surrounding text.

Affects both the live docs and the legacy old-docs content.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: alexey-kichin

.idea/.gitignore

@@ -309,7 +309,7 @@
 <details>
 <summary>1. How will dYdX Chain handle MEV?</summary>
 
-- Unlike general-purpose smart contract environments, the Cosmos infrastructure enables unique MEV solutions to be built that align a validator’s incentives with a user’s incentives. dYdX Chain has a framework where MEV is measured via a [dashboard](https://observatory.zone/dydx/mev). The first step would be to punish validators with slashing. Further proposed solutions are still being considered, and will be announced once finalized.
+- Unlike general-purpose smart contract environments, the Cosmos infrastructure enables unique MEV solutions to be built that align a validator’s incentives with a user’s incentives. dYdX Chain has a framework where MEV is measured via a dashboard. The first step would be to punish validators with slashing. Further proposed solutions are still being considered, and will be announced once finalized.
 
 </details>
 

.idea/aws.xml

@@ -155,4 +155,4 @@ The Community Treasury is an account controlled by governance and can be funded
 
 ## CosmosSDK Default Modules
 
-For more information on default modules, head to the [Cosmos SDK official documentation](https://docs.cosmos.network/v0.47/modules). dYdX Chain inherits the same governance properties of any standard CosmosSDK modules that are present on dYdX Chain.
+For more information on default modules, head to the [Cosmos SDK official documentation](https://docs.cosmos.network/sdk/v0.47/build/modules). dYdX Chain inherits the same governance properties of any standard CosmosSDK modules that are present on dYdX Chain.

.idea/inspectionProfiles/profiles_settings.xml

@@ -12,7 +12,7 @@ An order is the way a trader manages positions in the dYdX markets. Different ty
 
 | | Short-term | Stateful |
 | ------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| purpose | Short-lived orders which are meant to placed immediately (in the same block the order was received). These orders stay in-memory up to 20 blocks, with only their fill amount and expiry block height being committed to state. Intended for use by market makers with high throughput, or for market orders. IoC and FoK orders are also considered short-term orders. Short-term orders do not survive a network restart.<ul><li>&bull; User would send a short-term transaction to a validator</li><li>&bull; The transaction needs to contain exactly one Cosmos msg, and that msg is a [MsgPlaceOrder](https://github.com/dydxprotocol/v4-chain/blob/c092bf0166d1a111dcd9c2e4153334865c8fe553/proto/dydxprotocol/clob/tx.proto#L78)</li><li>&bull; Each validator has a [MsgProposedOperations](https://github.com/dydxprotocol/v4-chain/blob/c092bf0166d1a111dcd9c2e4153334865c8fe553/proto/dydxprotocol/clob/tx.proto#L68), which is one validator’s view of the operations queue</li><li>&bull; In the context of short-term orders, the block proposer should eventually be gossiped the short-term order and have it in their MsgProposedOperations</li><li>&bull; The block proposer would then optimistically place the short-term order in [CheckTx](https://docs.cosmos.network/main/basics/tx-lifecycle)</li><li>&bull; Matches that short term orders were included in block during MsgProposedOperations would be included in block for all the validators in the network during [DeliverTx](https://docs.cosmos.network/main/basics/tx-lifecycle)</li></ul> | Long-lived orders which may execute far in the future. These orders should not be lost during a validator restart (placed in the block after the order was received). In the event a validator restarts, all stateful orders are [placed back onto the in-memory orderbook](https://github.com/dydxprotocol/v4-chain/blob/95b59028af247c0a93ef72de9bfd09a645d30eb1/protocol/app/app.go#L1125). Likely to be used primarily by retail traders. The front end would be sending stateful orders for all order types other than market orders.<br/><br/>Two types of stateful orders: <br/><br/>1. Long-Term Orders <br/>&bull; meant to be added to the orderbook as soon as possible. Due to certain technical limitations, long-term orders are placed in the block after they are written to state. E.g. if `MsgPlaceOrder` is included in block N, taker order matching would occur for the long-term order in block N+1.<br/>&bull; Order types requiring immediate execution such as fill-or-kill / immediate-or-cancel are disallowed as these should be placed as short term orders; Long-term FoK/IoC orders would never be maker orders, so there is no benefit to writing them to state. <br/><br/>2. Conditional Orders<br/>&bull; execute when the oracle price becomes either LTE or GTE to specified trigger price, depending on the type of conditional order (e.g. stop loss sell = LTE, take profit buy = GTE)<br/>&bull; orders are placed in the block after their condition is met and they become triggered<br/>&bull; it is possible for a conditional order to become triggered in the same block they are initially written to state in. Conditional orders are placed in block ≥ N+1. |
+| purpose | Short-lived orders which are meant to placed immediately (in the same block the order was received). These orders stay in-memory up to 20 blocks, with only their fill amount and expiry block height being committed to state. Intended for use by market makers with high throughput, or for market orders. IoC and FoK orders are also considered short-term orders. Short-term orders do not survive a network restart.<ul><li>&bull; User would send a short-term transaction to a validator</li><li>&bull; The transaction needs to contain exactly one Cosmos msg, and that msg is a [MsgPlaceOrder](https://github.com/dydxprotocol/v4-chain/blob/c092bf0166d1a111dcd9c2e4153334865c8fe553/proto/dydxprotocol/clob/tx.proto#L78)</li><li>&bull; Each validator has a [MsgProposedOperations](https://github.com/dydxprotocol/v4-chain/blob/c092bf0166d1a111dcd9c2e4153334865c8fe553/proto/dydxprotocol/clob/tx.proto#L68), which is one validator’s view of the operations queue</li><li>&bull; In the context of short-term orders, the block proposer should eventually be gossiped the short-term order and have it in their MsgProposedOperations</li><li>&bull; The block proposer would then optimistically place the short-term order in [CheckTx](https://docs.cosmos.network/sdk/v0.50/learn/beginner/tx-lifecycle)</li><li>&bull; Matches that short term orders were included in block during MsgProposedOperations would be included in block for all the validators in the network during [DeliverTx](https://docs.cosmos.network/sdk/v0.50/learn/beginner/tx-lifecycle)</li></ul> | Long-lived orders which may execute far in the future. These orders should not be lost during a validator restart (placed in the block after the order was received). In the event a validator restarts, all stateful orders are [placed back onto the in-memory orderbook](https://github.com/dydxprotocol/v4-chain/blob/95b59028af247c0a93ef72de9bfd09a645d30eb1/protocol/app/app.go#L1125). Likely to be used primarily by retail traders. The front end would be sending stateful orders for all order types other than market orders.<br/><br/>Two types of stateful orders: <br/><br/>1. Long-Term Orders <br/>&bull; meant to be added to the orderbook as soon as possible. Due to certain technical limitations, long-term orders are placed in the block after they are written to state. E.g. if `MsgPlaceOrder` is included in block N, taker order matching would occur for the long-term order in block N+1.<br/>&bull; Order types requiring immediate execution such as fill-or-kill / immediate-or-cancel are disallowed as these should be placed as short term orders; Long-term FoK/IoC orders would never be maker orders, so there is no benefit to writing them to state. <br/><br/>2. Conditional Orders<br/>&bull; execute when the oracle price becomes either LTE or GTE to specified trigger price, depending on the type of conditional order (e.g. stop loss sell = LTE, take profit buy = GTE)<br/>&bull; orders are placed in the block after their condition is met and they become triggered<br/>&bull; it is possible for a conditional order to become triggered in the same block they are initially written to state in. Conditional orders are placed in block ≥ N+1. |
 | placement message | MsgPlaceOrder | `MsgPlaceOrder`, long term or conditional order flag enabled on `MsgPlaceOrder.Order.OrderId.OrderFlags`<br/>&bull; valid OrderFlags values are 32 (conditional), 64 (long-term), and 128 (TWAP) for stateful orders |
 | cancellation message | MsgCancelOrder<br/><br/><i>Short term cancellations are handled best-effort, meaning they are only gossiped and not included in MsgProposedOperations</i> | `MsgCancelOrder`, long term or conditional order flag enabled on `MsgCancelOrder.OrderId.OrderFlags` |
 | expirations | Good-Till-Block (GTB)<br/><br/>Short term orders have a maximum GTB of current block height + [ShortBlockWindow](https://github.com/dydxprotocol/v4-chain/blob/4eb219b1b726df9ba17c9939e8bb9296f5e98bb3/protocol/x/clob/types/constants.go#L9). Currently this value is 20 blocks, or about 30 seconds. Short term orders can only be GTB because in the interest of being resilient to chain halts or slowdowns. | Good-Till-Block-Time (GTBT)<br/><br/>Stateful orders have a maximum GTBT of current block time + [StatefulOrderTimeWindow](https://github.com/dydxprotocol/v4-chain/blob/4eb219b1b726df9ba17c9939e8bb9296f5e98bb3/protocol/x/clob/types/constants.go#L17). Currently this value is 95 days.<br/><br/>GTBT is used instead of GTB to give a more meaningful expiration time for stateful orders. |