Update guide for OEGS testnet

Author: gaonip

docs/pages/concepts/architecture/oegs.mdx

@@ -4,18 +4,14 @@
 ## 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.
 
-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: