GATEWAY Y MODELO DE LECTURA
El gateway es el límite público entre cada cliente de trading y el runtime. Las órdenes del challenge durante la ventana de evaluación de $49 a $299, los fills financiados bajo el reparto 90 / 10, las lecturas de la tabla de clasificación, las solicitudes de retiro — todos pasan por el mismo ingreso y leen del mismo estado persistido. Un bot de copy-trading, una app móvil retail y un cliente de API institucional ven la misma superficie, por lo que terceros pueden construir dashboards sobre Dexter sin pedir permiso, y por lo que las reglas no pueden relajarse silenciosamente para un solo consumidor.
El gateway sirve respuestas estables a partir de la salida persistida del runtime, nunca del estado en memoria del proceso de runtime. Eso es lo que le permite cachear, versionar, hacer fallback y mantenerse determinista bajo carga — cada lectura pasa por la misma ruta de código tanto si el runtime está ocupado, inactivo o reiniciando. En producción también es el límite de ingreso estrecho para el flujo de trading firmado: la autorización de agentes, las comprobaciones de tiempo, la imposición de IOC y el envío de order-commit ocurren todos aquí antes de que un solo byte llegue al bucle de matching.
| Superficie expuesta por el gateway | Fuente de respaldo |
|---|---|
| Resúmenes de mercado y libros de órdenes | Snapshots del runtime, registros del libro de órdenes, estado de marca e índice |
| Cuenta, fills, historial de funding | Resúmenes de cuenta persistidos, logs de fills, registros de settlement de funding |
| Publicación y liveness | Historial de raíces, ventanas de freshness, metadatos de commitment de secuencia y configuración |
| Señales de postura de la plataforma | Snapshots de salud, salidas de estado de mercado, salud de fuentes de oracle |
| Ingreso de trading firmado | Política de firmante POST /agent/authorize; ventanas createdAtTs / goodTilTs; disciplina IOC; envío obligatorio de order-commit |
#Lo que el gateway realmente posee
El gateway posee la presentación, la normalización y la política de admisión sobre el ingreso firmado. No posee el matching, la construcción de marca, la custodia ni la finalidad del settlement — esos viven en el runtime y en los contratos de Base. Su trabajo es exponer una única interfaz estable sobre el estado ya persistido y mantener la puerta de entrada del trading lo suficientemente estrecha como para que las reglas de entrada sean explícitas e inspeccionables.
La división entre lecturas públicas de mercado, vistas de cuenta autenticadas y rutas de servicio restringidas se aplica como tres modelos de permisos distintos, no uno. Una wallet que puede leer sus propias posiciones no puede leer las posiciones de otra wallet; un consumidor no autenticado puede leer el libro de órdenes pero no puede leer el historial de fills; una ruta de servicio interna no puede invocarse en absoluto desde el ingreso público. El gateway forma parte por tanto del límite de seguridad, no solo de la capa de UI.
Las superficies de terceros — vías de copy-trading, clientes móviles, consumidores de API institucionales — leen los mismos registros bajo el mismo modelo de permisos que la app interna. Son consumidores aguas abajo de un único límite, no capas de protocolo paralelas. No hay un nivel "partner" con acceso silencioso a endpoints privados.
#El papel del modelo de lectura persistido
El runtime escribe continuamente snapshots, fills, registros de funding, resúmenes de mercado, resúmenes de cuenta y señales de salud en un almacén persistido. El gateway lee de ese almacén, nunca de la memoria del proceso del runtime. Se siguen dos consecuencias: cada consumidor ve el mismo estado en el mismo punto de secuencia, y un reinicio del runtime nunca produce una lectura obsoleta o de cerebro dividido.
flujo firmado del usuario
-> POST /agent/authorize establece la política de firmante
-> el gateway comprueba createdAtTs / goodTilTs / IOC / política de secuencia
-> el gateway envía el order commitment requerido
-> el runtime actualiza el estado del exchange
-> snapshots, fills, funding y salud se persisten
-> el gateway normaliza esos registros
-> cada app y consumidor de API lee una superficie estable únicaLas plataformas híbridas se vuelven irrevisables cuando cada pantalla está respaldada por una fuente invisible distinta. El modelo de lectura es lo que evita eso en Dexter. El gateway explica la plataforma; no decide la plataforma. Cualquiera que reproduzca el PnL de un trader, un rango de la tabla de clasificación o un saldo de seguros puede hacerlo a partir de los mismos registros persistidos que sirve el gateway.