Kman/update v.9 updates (#409)

* move vocs-docs files to the root

* updating old vocs-docs path

* Remove pnpm action setup from lint workflow

* Update lint workflow to install pnpm globally

* Update lint command in package.json to use glob pattern for documentation files

* Update fee

* set C factor to 0

* Update PK example for Typescript

* Update guide for OEGS testnet

* Update guide for OEGS testnet info

* Update description on PK's

* Update PK example fromwallet

* Put typescript implementation on first tab for now

* Fix revshare tpyo

---------

Co-authored-by: alexeykichin <[email protected]>

Author: gaonip

.gitignore

@@ -1,2 +1,3 @@
 dist
-/node_modules
+/node_modules
+vocs-docs/

docs/pages/concepts/architecture/oegs.mdx

@@ -1,21 +1,17 @@
 
 # OEGS
 
-## What is the Order Entry Gateway Service (OEGS) ?
+## What is the Order Entry Gateway Service (OEGS)
 The Order Entry Gateway represents the next step in dYdX’s multi-stage performance evolution:
 
-1. Today — full node gossip across all validators.
-2. Designated proposers — predictable topology for faster routing (available in v9 software upgrade).
-3. Order Entry Gateway Service (OEGS) — specialized nodes for direct, one-hop delivery to proposers (available after v9 upgrade).
+1. Designated proposers — A governance-selected subset of validators responsible for proposing blocks. This creates a predictable topology for faster routing (available in v9 software upgrade).
+2. Order Entry Gateway Service (OEGS) — specialized nodes for direct, one-hop delivery to proposers (available after v9 upgrade).
 
-This staged evolution ensures each layer builds on order latency improvements while keeping the protocol’s decentralized governance and consensus guarantees intact.
+The Order Entry Gateway Service (OEGS) is open-sourced infrastructure that provides a direct, optimized path from traders to the proposer set, reducing latency, increasing throughput, and lowering barriers for professional and retail traders alike.
+OEGS is now live on testnet, reach out to us for more information.
 
-At dYdX, the mission is clear: make perpetuals trading as fast, fair, and reliable as possible — without compromising the decentralization that defines DeFi. As the protocol scales, the infrastructure that routes and processes orders must evolve alongside it.
-
-That’s why we’re introducing the Order Entry Gateway Service (OEGS) — open-sourced infrastructure that provides a direct, optimized path from traders to the proposer set, reducing latency, increasing throughput, and lowering barriers for professional and retail traders alike.
-
-## 1. Current State
-In today’s dYdX architecture (original blog post [here](https://www.dydx.xyz/blog/v4-technical-architecture-overview)), orders from traders — whether via the web app, mobile, API, or third-party integration — are submitted to full nodes, which then gossip them across the network until they reach the current block proposer.
+## 1. Previous State
+In dYdX previous architecture (original blog post [here](https://www.dydx.xyz/blog/v4-technical-architecture-overview)), orders from traders — whether via the web app, mobile, API, or third-party integration — are submitted to full nodes, which then gossip them across the network until they reach the current block proposer.
 
 **Pros**: Fully decentralized, no single point of routing.
 
@@ -43,7 +39,7 @@ Historically, traders relying solely on the public Indexer have faced reliabilit
 ## 2. Designated Proposers
 We recently introduced the concept of designated proposers (blog post [here](https://www.dydx.xyz/blog/governance-controlled-path-reliability-and-performance)) — a governance-selected subset of validators responsible for proposing blocks. This change to the open-source software creates a predictable topology, making it possible to route transactions directly to the next proposer instead of broadcasting widely. This is a fully deterministic enhancement to CometBFT that brings increased resilience, network performance, and operational clarity — while preserving the full validator set, stake-based voting power, and decentralized governance of the network.
 
-## 3. Enter the Order Entry Gateway Service (OEGS)
+## 3. The Order Entry Gateway Service (OEGS)
 The OEGS builds on the designated proposer model by creating a specialized set of gateway nodes that:
 
 Peer directly with all designated proposers.

docs/pages/concepts/architecture/overview.mdx

@@ -32,6 +32,13 @@ In service of building an end-to-end decentralized experience, dYdX has built th
 
 - **Mobile**: The iOS and Android apps are built in native Swift and Kotlin, respectively. The mobile apps interact with the Indexer in the same way the web application does, and will send trades directly to the chain. The mobile apps have been open sourced as well, allowing anyone to deploy the mobile app to the App Store or Play store. Specifically for the App store, the deployer needs to have a developer account as well as a Bitrise account to go through the app submission process.
 
+### Order Entry Gateway Service (OEGS) ?
+The Order Entry Gateway represents the next step in dYdX’s multi-stage performance evolution and is made possible by the following 2 designs:
+
+1. Designated proposers — A governance-selected subset of validators responsible for proposing blocks. This creates a predictable topology for faster routing (available in v9 software upgrade).
+2. Order Entry Gateway Service (OEGS) — open-sourced infrastructure that provides a direct, optimized path from traders to the proposer set, reducing latency, increasing throughput, and lowering barriers for professional and retail traders alike (available now on testnet).
+
+
 ### Lifecycle of an Order
 
 Now that we have a better understanding of each of the components of dYdX Chain, let's take a look at how it all comes together when placing an order. When an order is placed on dYdX Chain, it follows the flow below:

docs/pages/concepts/trading/rewards/index.mdx

@@ -21,13 +21,17 @@ There are several reward mechanisms available with the protocol software.
 
 See more on [Staking Rewards](/concepts/trading/rewards/staking-rewards).
 
-## Trading Rewards
+## Trading Rewards (Note that C factor has been set to 0)
 
 - Rewards distributed to `Traders` after each successful trade
 - Based on a specified `formula` with several inputs
 - Distributed automatically every block with successful trades
 - Claimed automatically
 
+:::note
+Note that traders now earn 50% trading rebates directly after each trade as trading rewards via C factor have been set to 0 via governance.
+:::
+
 See more on [Trading Rewards](/concepts/trading/rewards/trading-rewards).
 
 ## Fees
@@ -44,12 +48,10 @@ The basic structure for fees have been developed to reflect the following charac
 | 1     | < $1M                                  | 5.0             | 1.0                                    |
 | 2    | ≥ $1M                                  | 4.5             | 1.0                                    |
 | 3   | ≥ $5M                                  | 4.0             | 0.5                                    |
-| 4    | ≥ $25M                                 | 3.5             | —                                      |
-| 5     | ≥ $125M                                | 3.0             | —                                      |
-| 6    | ≥ $125M and ≥0.5% exchange mkt. share  | 2.5             | -0.5                                   |
-| 7   | ≥ $125M and ≥1% maker mkt. share       | 2.5             | -0.7                                   |
-| 8  | ≥ $125M and ≥2% maker mkt. share       | 2.5             | -0.9                                   |
-| 9    | ≥ $125M and ≥4% maker mkt. share       | 2.5             | -1.1                                   |
+| 4    | ≥ $25M                                 | 3.5             | 0                                      |
+| 5     | ≥ $50M                                | 3.0             | 0                                      |
+| 6    | ≥ $100M                                | 2.5             | -0.7                                   |
+| 7   | ≥ $200M                                 | 2.5             | -1.1                                   |
 
 ## Parameters
 

docs/pages/concepts/trading/rewards/trading-rewards.mdx

@@ -94,12 +94,17 @@ Below is an example using the given formula to calculate the trading reward base
 - `Taker Fee Revenue Share`: the taker fee revenue share is 60% or 0.6 including 50% to MegaVault and 10% to Treasury subDAO, as well as 0% to market mapper for a given market.
 - `C`: A constant multiplier that is currently set to 0.5 by the dYdX governance, but subject to change through dYdX governance.
 
+:::note
+Note that the community has voted to set the C parameter to 0
+:::
+
 ```
-Trading Reward from Taker Fee = 1,000,000 * (0.0004 − 0.00011 − 0.0002) * 0.5 * (1−0.6)
-Trading Reward from Taker Fee = 1,000,000 * 0.00009 * 0.5 * 0.4 = 18
+Trading Reward from Taker Fee = 1,000,000 * (0.0004 − 0.00011 − 0.0002) * 0.4 * (1−0.6)
+Trading Reward from Taker Fee = 1,000,000 * 0.00009 * 0.4 * 0.4 = 18
 ```
 
 For this example, the Trading Reward would be equivalent to $18 in DYDX for an approximate Taker Fee of $400 paid by the user.
+Note that however since the C factor has been reduced to 0, traders now get rebates directly instead of C constant trading rewards
 
 
 ## FAQ

docs/pages/interaction/deposits-withdrawals/overview.mdx

@@ -2,6 +2,10 @@
 
 This guide provides a **step-by-step** explanation of deposit and withdrawal processes on the dYdX Chain. It includes instructions for Skip Go Fast (`Instant`), Skip Go (`regular`), Coinbase deposits, and direct IBC transfers, along with troubleshooting methods and best practices to ensure seamless transactions.
 
+:::note
+Note that for deposits > $20, skip go fast is the default option.
+:::
+
 ## Deposit & Withdrawal Methods
 
 | Method                                           | Description                                                               | Finality      | Chains Supported                                                                                | Fee Range (USD)                                                                                                                         |

docs/pages/interaction/integration/integration-revshare.mdx

@@ -52,7 +52,7 @@ To update the revenue share percentage for an existing order router, create a go
 		"authority": authority,
 		"order_router_rev_share": {
 			"address": {{your existing address}},
-			"sharePpm": {{your new requested ppm}},
+			"share_ppm": {{your new requested ppm}},
 		}
 	}
 ]
@@ -78,7 +78,7 @@ Submit a governance proposal with the following message structure:
 		"authority": authority,
 		"order_router_rev_share": {
 			"address": {{your existing address}},
-			"sharePpm": 0,
+			"share_ppm": 0,
 		}
 	}
 ]

docs/pages/interaction/permissioned-keys/index.mdx

@@ -9,11 +9,32 @@ This section will guide you through authenticators use and management. We show t
 
 ## Owner
 
+There are 2 ways to setup Permissioned API Keys:
+1/ Via the Trade interface (default permissions to trade on all cross-margin pairs)
+2/ Via API (customisable)
+
+
 ::::steps
 
+### Setup Permissioned API Keys via Trade Interface
+
+![Setup Permissioned API Key](/APIKey.png)
+
+On the dYdX.trade, after signing in with your wallet or socials:
+- click `More → API Trading Keys`.
+- Click `Generate New API Key`. This generates a new keypair:
+    - API Wallet Address
+    - Private Key
+    :::note
+    This is a one-time view, make sure to save your Private Key immediately. It will not be shown again and is not stored by dYdX
+    :::
+- Check the `terms` and click `Authorize API Key`.
+- Now you can go to [Import private key](/interaction/permissioned-keys#trader) to start trading via API keys.
+
+
 ### Create an authenticator
 
-Lets create an authenticator which allows only the **trader** to place orders.
+Alternatively, you can create a custom authenticator which allows only the **trader** to place orders.
 
 To create this authenticator, we use two sub-authenticators: `signatureVerification` and `messageFilter`:
 - the `signatureVerification` authenticator must be present in all authenticator sets and contains the **trader**'s public key;
@@ -170,20 +191,53 @@ client
 
 ::::steps
 
-### Get the authenticator ID
 
-Grab the authenticator ID created by the **owner** in [**Owner**::Step 2](/interaction/permissioned-keys#add-the-authenticator), either by: 
-- request to the **owner** through other channels, or;
-- by using the list authenticators method to fetch the last authenticator (see [**Owner**::Step 3](/interaction/permissioned-keys#last-authenticators)).
+### Get the authenticator ID and permissioned API Key
+
+Grab the `authenticatorId` created by the **owner** in [Add authenticator](/interaction/permissioned-keys#add-the-authenticator), either by: 
+- request the **owner** for the `authenticatorId` or by using the list authenticators method to fetch the to be used authenticator (see [list authenticators](/interaction/permissioned-keys#last-authenticators)).
+- Get the private key `DYDX_TEST_PRIVATE_KEY` from the owner in [via the Trade Interface](/interaction/permissioned-keys#get-the-private-key).
+
+
+### Setup the permissioned wallet
+If you got a private key from the trading interface load in via `fromPrivateKey`, otherwise use `fromMnemonic` if you didn't create via the trading interface by assigning to mnemonic.
+
+```typescript
+  const fromWallet = await LocalWallet.fromPrivateKey(DYDX_TEST_PRIVATE_KEY, BECH32_PREFIX);
+  const authenticatedSubaccount = SubaccountInfo.forPermissionedWallet(
+        fromWallet,
+        address, //owner dydx address
+        subaccountNumber, //subaccount to trade onbehalf of
+        [authenticatorId],
+      )
+```
+
 
 ### Using the authenticator
 
-Having the authenticator ID, the **trader** can now use it to perform the allowed actions.
+The **trader** can now use the permissioned API key to perform the allowed trading actions.
 
 In this example, the **trader** can use the authenticator to issue orders on the behalf of the **owner**.
 
 :::code-group
 
+```typescript [TypeScript]
+const client = await CompositeClient.connect(network);
+// Place an order using the authenticator.
+const tx = await client.placeShortTermOrder(
+  authenticatedSubaccount,
+  'ETH-USD',
+  side,
+  price,
+  0.01,
+      clientId,
+      goodTilBlock,
+      timeInForce,
+      false,
+      undefined,
+    );
+```
+
 ```python [Python]
 id = ... # authenticator ID # [!code focus]
 # Create the order ID, using the owner address # [!code focus]
@@ -204,31 +258,6 @@ tx_options = TxOptions([id], wallet.sequence, wallet.account_number) # [!code fo
 place = await node.place_order(wallet, order, tx_options) # [!code focus]
 ```
 
-```typescript [TypeScript]
-const client = await CompositeClient.connect(network);
-const wallet = await LocalWallet.fromMnemonic(DYDX_TEST_MNEMONIC_2, BECH32_PREFIX);
-const subaccount = new SubaccountInfo(wallet, 0);
-const ownerSubaccount = ...;
-const id = ...; // authenticator ID
-const currentBlock = await client.validatorClient.get.latestBlockHeight();
-// Place an order using the authenticator. // [!code focus]
-const tx = await client.placeShortTermOrder( // [!code focus]
-  subaccount, // [!code focus]
-  'ETH-USD',
-  OrderSide.BUY,
-  1000,
-  0.01,
-  Math.floor(Math.random() * 10000), // client ID
-  currentBlock + 10,
-  Order_TimeInForce.TIME_IN_FORCE_UNSPECIFIED,
-  false,
-  undefined,
-  { // [!code focus]
-    authenticators: [id], // [!code focus]
-    accountForOrder: ownerSubaccount, // [!code focus]
-  }, // [!code focus]
-); // [!code focus]
-```
 
 ```rust [Rust]
 // Create a `PublicAccount` representing the owner. // [!code focus]