feat: add new rust methods from V9 update, fix linter

.lintignore

@@ -0,0 +1,23 @@
+# Files to ignore from remark linting
+# One pattern per line
+
+# Ignore component files (TSX not MDX)
+docs/components/*.tsx
+
+# Ignore files that have formatting issues
+resources.mdx
+docs/pages/nodes/full-node-streaming/example.mdx
+docs/pages/node-client/public/query_transaction.mdx
+docs/pages/node-client/public/query_transaction_result.mdx
+docs/pages/nodes/full-node-streaming/index.mdx
+docs/pages/interaction/endpoints.mdx
+docs/pages/interaction/data/market.mdx
+docs/pages/interaction/client/quick-start-ts.mdx
+docs/pages/interaction/client/quick-start-py.mdx
+docs/pages/interaction/client/quick-start-rs.mdx
+
+# You can add more patterns here
+# Example patterns:
+# test-*.mdx
+# **/draft/*.mdx
+# docs/pages/temp/*.mdx

docs/components/Details.tsx

@@ -0,0 +1,59 @@
+import React, { useState } from 'react';
+
+interface DetailsProps {
+  title?: string;
+  open?: boolean;
+  children: React.ReactNode;
+}
+
+/**
+ * Details component - A collapsible section with a title
+ * 
+ * Usage in MDX:
+ * <Details title="Unification Plan">
+ *   - Content goes here
+ *   - More content
+ * </Details>
+ * 
+ * Or with default open state:
+ * <Details title="Example" open>
+ *   Content that's visible by default
+ * </Details>
+ */
+export function Details({ title, open = false, children }: DetailsProps) {
+  const [isOpen, setIsOpen] = useState(open);
+
+  return (
+    <details className="details-container" open={isOpen}>
+      {title && (
+        <summary 
+          className="details-summary"
+          onClick={(e) => {
+            e.preventDefault();
+            setIsOpen(!isOpen);
+          }}
+        >
+          {title}
+        </summary>
+      )}
+      <div className="details-content">
+        {children}
+      </div>
+    </details>
+  );
+}
+
+// Alternative syntax-friendly version without state management
+export function SimpleDetails({ title, children }: { title?: string; children: React.ReactNode }) {
+  return (
+    <details className="details-container">
+      {title && <summary className="details-summary">{title}</summary>}
+      <div className="details-content">
+        {children}
+      </div>
+    </details>
+  );
+}
+
+// Export as default for easier importing in MDX
+export default Details;

docs/pages/concepts/architecture/oegs.mdx

@@ -87,4 +87,4 @@ DOS does not (i) provide, operate, or make available the Service, (ii) exercise
 Without limiting the generality of the foregoing, under no circumstances shall DOS be held liable or responsible to any person or entity for any claim, demand, cause of action, damages, losses, liabilities, costs, or expenses of any kind, whether direct, indirect, incidental, punitive, special, consequential, exemplary, or otherwise, arising out of or in connection with: (a) access to, reliance upon, use of, or inability to use the Service; (b) any information or content made available through the Service; or (c) any activities, transactions, or conduct undertaken via the Service.
 
 Access to and use of the Service is undertaken solely at the risk of the user and is subject exclusively to the terms, conditions, policies, and practices established and maintained by Imperator, all of which are independent of, and not reviewed, approved, or enforced by, DOS.
-:::
+:::

docs/pages/concepts/onboarding-faqs/index.mdx

@@ -356,4 +356,4 @@
 
 - Liquidity provider rewards in v4 are not controlled by dYdX. dYdX recommends that liquidity provider rewards should cease to exist in v4. Makers could be rewarded with a maker rebate ranging from 0.5bps to 1.1bps, based on their nominal volume and volume share. The full proposed fee schedule can be found [here](/concepts/trading/rewards).
 
-</details>
+</details>

docs/pages/concepts/trading/governance.mdx

@@ -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/v0.47/modules). dYdX Chain inherits the same governance properties of any standard CosmosSDK modules that are present on dYdX Chain.

docs/pages/concepts/trading/isolated-markets.mdx

@@ -64,4 +64,4 @@ An example of how each type of market looks when queried using the `/dydxprotoco
     "open_interest": "0"
   }
 }
-```
+```

docs/pages/concepts/trading/limits/equity-tier-limits.mdx

@@ -39,17 +39,18 @@ Here is an example response:
 
 Read as:
 
-| Net Collateral            | Long-term / Conditional orders   | 
-| ------------------------- | -------------------------------  |
-| < $20                     |  0                               |    
-| >= $20 and < $100         |  10                              |  
-| >= $100 and < $1,000      |  20                              | 
-| >= $1,000 and < $10,000   |  40                              | 
-| >= $10,000 and < $100,000 |  100                             | 
-| >= $100,000               |  200                             |
+| Net Collateral            | Long-term / Conditional orders |
+| ------------------------- | ------------------------------ |
+| < $20                     | 0                              |
+| >= $20 and < $100         | 10                             |
+| >= $100 and < $1,000      | 20                             |
+| >= $1,000 and < $10,000   | 40                             |
+| >= $10,000 and < $100,000 | 100                            |
+| >= $100,000               | 200                            |
 
 For example up to 20 open stateful orders across all markets for a subaccount with a net collateral of $2,000.
 
 Note:
+
 - Short term orders, including limit `Immediate-or-Cancel`, `Fill-or-Kill`, and market orders on the frontend do not have this limitation.
-- Only the `stateful_order_equity_tiers` field is in effect -- short term order equity limits under the `short_term_order_equity_tiers` key are no longer in effect.
+- Only the `stateful_order_equity_tiers` field is in effect -- short term order equity limits under the `short_term_order_equity_tiers` key are no longer in effect.

docs/pages/concepts/trading/limits/rate-limits.mdx

@@ -65,4 +65,4 @@ V4_CANDLES_CHANNEL_LIMIT: 32
 V4_MARKETS_CHANNEL_LIMIT: 32
 V4_ORDERBOOK_CHANNEL_LIMIT: 32
 V4_TRADES_CHANNEL_LIMIT: 32
-```
+```

docs/pages/concepts/trading/limits/withdrawal-limits.mdx

@@ -14,4 +14,4 @@ These rate limit parameters can be updated by governance.
 
 All subaccount transfers and withdrawals will be gated for 50 blocks if a negative collateralized subaccount is seen in state and/or can't be liquidated or deleveraged
 
-All subaccount transfers and withdrawals will also be gated for 50 blocks if a 5+ minute chain outage occurs.
+All subaccount transfers and withdrawals will also be gated for 50 blocks if a 5+ minute chain outage occurs.

docs/pages/concepts/trading/liquidations.mdx

@@ -3,63 +3,70 @@
 As part of the default settings of the v4 open source software (”dYdX Chain”), accounts whose total value falls below their maintenance margin requirement may have their positions automatically closed by the liquidation engine. Positions are closed via protocol-generated liquidation matches where a protocol-generated liquidation order uses a calculated “Fillable Price” as the limit price to match against liquidity resting on the order book.  
  Profits or losses from liquidations are taken on by the insurance fund.
 A liquidated subaccount may have its position partially or fully closed. v4 open source software includes a liquidations configuration which — as determined by the applicable Governance Community — will determine how much of the position is liquidated.
- 
+
 ## Liquidation Penalty
 
 As part of the default settings of the v4 open source software, when an account is liquidated, up to the entire remaining value of the account may be taken as penalty and transferred to an insurance fund.
- 
+
 The liquidation engine will attempt to leave funds in accounts of positive value where possible after they have paid the Maximum Liquidation Penalty of 1.5%. The 1.5% fee contemplated in the default v4 software will be subject to adjustments by the applicable Governance Community.
-
-
+
 ## Isolated Liquidation Price
 
 This is the price at which a specific position reaches the point of liquidation.
-1. __Formula Explanation:__
-  - The liquidation price `p'` is calculated using:
-  ```
-   p' = (e - s * p) / (|s| * MMF - s)
-  ```
-  - Here:
-    - `e` is the current equity in the account.
-    - `s` is the size of the position.
-    - `p` is the original price of the position.
-    - `MMF` is the maintenance margin fraction, a percentage that indicates the minimum equity required to keep the position open.
-
-2. __Example:__
-  - Suppose a trader deposits $1,000 (`e = 1000`).
-  - The trader shorts 3 ETH contracts (`s = -3`) at $3,000 per contract, with a maintenance margin fraction of 5% (`MMF = 0.05`).
-  - The formula becomes: `p' = (1000 - (-3 * 3000)) / (3 * 0.05 - (-3))`
-  - This simplifies to: `p' = (1000 + 9000) / (0.15 + 3) = 10000 / 3.15 ≈ 3174.60`
-  - This means if the price of ETH rises to $3,174.60, the position will reach the liquidation threshold. 
-  - At this price, the trader's remaining equity would be 5% of the notional value of the position or $476.2 based on the calculation `(3 * 3174.6 * 0.05 ≈ 476.2)`.
-
+
+1. **Formula Explanation:**
+
+- The liquidation price `p'` is calculated using:
+
+```
+ p' = (e - s * p) / (|s| * MMF - s)
+```
+
+- Here:
+  - `e` is the current equity in the account.
+  - `s` is the size of the position.
+  - `p` is the original price of the position.
+  - `MMF` is the maintenance margin fraction, a percentage that indicates the minimum equity required to keep the position open.
+
+2. **Example:**
+
+- Suppose a trader deposits $1,000 (`e = 1000`).
+- The trader shorts 3 ETH contracts (`s = -3`) at $3,000 per contract, with a maintenance margin fraction of 5% (`MMF = 0.05`).
+- The formula becomes: `p' = (1000 - (-3 * 3000)) / (3 * 0.05 - (-3))`
+- This simplifies to: `p' = (1000 + 9000) / (0.15 + 3) = 10000 / 3.15 ≈ 3174.60`
+- This means if the price of ETH rises to $3,174.60, the position will reach the liquidation threshold.
+- At this price, the trader's remaining equity would be 5% of the notional value of the position or $476.2 based on the calculation `(3 * 3174.6 * 0.05 ≈ 476.2)`.
+
 ## Cross Liquidation Price
 
 For cross-margining (multiple positions sharing the same margin), the calculation is adjusted to account for the margin used by other positions.
 
-1. __Key Terms:__
-  - __Total Maintenance Margin Requirement (`MMR_t`):__ Calculate the maintenance margin needed for all positions at current prices: `MMR_t = |s| · p · MMF`
-  - __Other Positions' Margin Requirement (`MMR_o`)__: Subtract the margin requirement of the position in question from MMR_t: `MMR_o = MMR_t - |s| * p * MMF`
-  - __New Margin Requirement at Price `p'`__: Add `MMR_o` to the margin requirement of the position at the new price: `MMR_o + |s| * p' * MMF`
-  - __Liquidation Price Formula__: Substitute into the equation to find the liquidation price for the position: `p' = (e - s * p - MMR_o) / (|s| * MMF - s)`
-
-2. __Example:__
-  - Suppose a trader deposits $1,000 (`e = 1000`).
-  - The trader shorts 1.5 ETH (`s = -1.5`) at $3,000 and buys 1,000 STRK contracts at $1.75 (`MMF = 10%` for STRK).
-  - __Calculate Other Positions' Margin Requirement__: `MMR_o = 1000 * 1.75 * 0.10 = 175`
-  - Compute the Liquidation Price for ETH: `p' = (1000 - (-1.5 * 3000) - 175) / (1.5 * 0.05 + 1.5)`
-  - This simplifies to: `p' = (1000 + 4500 - 175) / 1.575 ≈ 3380.95`.
-  - If the ETH price reaches $3,380.95, the equity would fall to the required margin level.
-
+1. **Key Terms:**
+
+- **Total Maintenance Margin Requirement (`MMR_t`):** Calculate the maintenance margin needed for all positions at current prices: `MMR_t = |s| · p · MMF`
+- **Other Positions' Margin Requirement (`MMR_o`)**: Subtract the margin requirement of the position in question from MMR_t: `MMR_o = MMR_t - |s| * p * MMF`
+- **New Margin Requirement at Price `p'`**: Add `MMR_o` to the margin requirement of the position at the new price: `MMR_o + |s| * p' * MMF`
+- **Liquidation Price Formula**: Substitute into the equation to find the liquidation price for the position: `p' = (e - s * p - MMR_o) / (|s| * MMF - s)`
+
+2. **Example:**
+
+- Suppose a trader deposits $1,000 (`e = 1000`).
+- The trader shorts 1.5 ETH (`s = -1.5`) at $3,000 and buys 1,000 STRK contracts at $1.75 (`MMF = 10%` for STRK).
+- **Calculate Other Positions' Margin Requirement**: `MMR_o = 1000 * 1.75 * 0.10 = 175`
+- Compute the Liquidation Price for ETH: `p' = (1000 - (-1.5 * 3000) - 175) / (1.5 * 0.05 + 1.5)`
+- This simplifies to: `p' = (1000 + 4500 - 175) / 1.575 ≈ 3380.95`.
+- If the ETH price reaches $3,380.95, the equity would fall to the required margin level.
+
 ## “Fillable Price” for Liquidations
 
 As part of the default settings of dYdX Chain, the “fillable price” (or the limit price of a liquidation order) for a position being liquidated is calculated as follows. For both short and long position:
- 
+
 ```
 Fillable Price (Short or Long) = P x (1 - ((SMMR x MMF) x (BA x (1 - Q)))
 ```
- 
+
 Where (provided as genesis parameters):
+
 - `P` is the oracle price for the market
 - `SMMR` is the spread to maintenance margin ratio
 - `MMR`= `Config.FillablePriceConfig.SpreadToMaintenanceMarginRatioPpm`
@@ -68,28 +75,28 @@ Where (provided as genesis parameters):
 - `A` = `Config.FillablePriceConfig.BankruptcyAdjustmentPpm`. Is ≥ 1.
 - `Q = V / TMMR` where `V` is the total account value, and `TMMR` is the total maintenance margin requirement
 
-On the other hand, the “Close Price” will be the sub-ticks of whatever maker order(s) the liquidation order matches against. 
- 
+On the other hand, the “Close Price” will be the sub-ticks of whatever maker order(s) the liquidation order matches against.
+
 For more information on Margin fractions and calculations, see [Margin](/concepts/trading/margin).
- 
+
 ## FAQ
 
 > What price is used to determine liquidations?
 
 As part of the default settings, Oracle Price is used to estimate the value of an account’s positions. If the account’s value falls below the account’s maintenance margin requirement, the account is liquidatable.
- 
+
 > Who receives the liquidation fees?
 
 The insurance fund would receive liquidation fees / penalty. Please note that the applicable Governance Community needs to initially fund the insurance fund from the applicable community treasury.
- 
+
 > How liquidation engine works?
 
 Our liquidation engine automatically closes positions that fall below the maintenance margin.
- 
+
 > Does dYdX apply a penalty in the event of liquidation?
 
-Yes. The liquidation engine will attempt to leave funds in accounts of positive value where possible after they have paid the Maximum Liquidation Penalty of 1.5%. The 1.5% fee contemplated in the default v4 software will be subject to adjustments by the applicable Governance Community. 
- 
-> How to avoid liquidation? 
+Yes. The liquidation engine will attempt to leave funds in accounts of positive value where possible after they have paid the Maximum Liquidation Penalty of 1.5%. The 1.5% fee contemplated in the default v4 software will be subject to adjustments by the applicable Governance Community.
+
+> How to avoid liquidation?
 
-In order to avoid liquidation, you can deposit more assets to your account, as while opening a position the key point is to have enough assets to cover the maintenance margin requirements. You can also close the part of the position and the liquidation price will change. 
+In order to avoid liquidation, you can deposit more assets to your account, as while opening a position the key point is to have enough assets to cover the maintenance margin requirements. You can also close the part of the position and the liquidation price will change.