ADMISIÓN, FIRMAS Y COMMITMENTS DE ÓRDENES

Seis requisitos gobiernan cada orden. Se ejecutan en un orden fijo y cualquier fallo aborta la petición antes de que la capa de pricing la vea. Los tres primeros son comprobaciones de firmante y payload; los tres últimos son políticas de timing, commitment y forma de ejecución.

#Flujo firmado autorizado

Un cliente no puede firmar una orden y esperar que la plataforma la acepte. La cuenta primero registra una autopolítica a través de POST /agent/authorize, que registra la clave específica de firmante autorizada a actuar en su nombre. Esa separación importa en la práctica: la clave de retiro de la cuenta, el binding de KYC y el efectivo por referidos nunca necesitan tocar una sesión de trading — una hardware wallet, una clave de sesión o un cliente API se hace cargo de la superficie de firma sin que el resto de la wallet se exponga.

Una vez que existe la autorización, cada orden llega como un payload tipado EIP-712 en lugar de una instrucción sin firmar. La estructura firmada lleva el mercado, el lado, el tamaño, el precio límite, la ventana de validez (createdAtTs, goodTilTs) y el seq monotónico de la cuenta. El motor rechaza firmantes no autorizados, seq que falta, timestamps expirados o con futuro-sesgado y payloads no-IOC en la puerta — ninguno de esos fallos alcanza la capa de pricing o de riesgo. En producción esto se aplica mediante GATEWAY_REQUIRE_IOC en el gateway y mediante el validador de payloads del runtime, por lo que la misma regla se comprueba dos veces en rutas de código independientes.

#Secuenciación y evidencia de commit on-chain

La secuenciación monotónica da al runtime un orden de eventos determinista. El seq de cada cuenta avanza estrictamente hacia arriba, por lo que dos observadores independientes que reproducen la misma cadena ven el mismo orden de fills. El runtime rechaza cualquier payload cuyo seq no sea mayor que el seq previamente aceptado para esa cuenta — un replay, una re-ordenación de red o un reintento duplicado se colapsan todos en un único evento aceptado.

Cuando el commit guard está activo en producción, el gateway ancla el hash de la orden en el contrato OrderCommitRegistry en Base a través de commitOrder (individual) o commitOrders (en lote) antes de que el runtime pueda hacer matching. Eso consigue dos cosas distintas en un paso. Estrecha la admisión: el runtime no valorará una orden cuyo commit falta. Y produce un registro on-chain público con timestamp de que la orden existió en la forma a la que el firmante dio fe, antes de que cualquier fill pudiera haberse generado — que es contra lo que se comprueba la revisión de disputas posterior.

 POST /agent/authorize
   -> la política de firmante se activa para la cuenta
   -> el cliente firma un payload IOC EIP-712 (mercado, lado, tamaño, precio, createdAtTs, goodTilTs, seq)
   -> el gateway aplica GATEWAY_REQUIRE_IOC y valida la forma del payload
   -> commitOrder(orderHash) aterriza en OrderCommitRegistry en Base
   -> el runtime revisa firmante, monotonía del seq, timestamps y presencia del commit
   -> sólo entonces se ejecuta la lógica de pricing y fill del vAMM

#Revisando el límite de admisión

El stack de admisión no es una ceremonia. Existe para que un revisor técnico pueda responder a tres preguntas sólo a partir del estado público: qué firmante estaba autorizado a actuar para esta cuenta en el momento de la orden, en qué orden llegaron las peticiones unas respecto a otras, y si el runtime matcheó un payload que ya había sido anclado on-chain. Si alguna de esas respuestas es "no podemos decirlo", la plataforma está operando fuera de su propio contrato de admisión. Con la autorización del agente, el seq monotónico y el ancla OrderCommitRegistry, las tres respuestas vienen de datos que un revisor puede obtener sin confiar en la palabra de la plataforma.

#Por qué esto importa para la tabla de clasificación y los pagos

• El historial de operaciones está anclado en Base. El hash de cada orden golpea el OrderCommitRegistry a través de commitOrder antes de que el runtime la matchee. Un puesto del podio o un pago financiado 90 / 10 puede reproducirse desde la cadena — la plataforma no puede reescribir la historia contra la que se calculó un pago, porque el timestamp de cada commit es más antiguo que el fill que justificó.
• El seq monotónico evita el doble conteo. Un reintento de red, una carrera de relayer o un bug de cliente que reenvía un payload se colapsan todos en un evento aceptado porque el seq ya ha avanzado. La tabla de clasificación no puede contar dos veces un fill, y un retiro de reparto de beneficios no puede ser disputado por una reclamación de fill duplicado que llegue después.
• La autorización del agente aísla la superficie de trading. La wallet que mantiene las entradas del challenge, los pagos financiados y el stake de DXTR no necesita firmar operaciones. POST /agent/authorize vincula un firmante separado — hardware wallet, clave de sesión, cliente API — a la política de la cuenta. Si la clave de trading se filtra, los retiros, el binding de KYC y el efectivo por referidos permanecen en la wallet original y fuera del alcance del atacante.
• createdAtTs / goodTilTs bloquean las ventanas de replay. Una firma sólo es válida dentro de su ventana de validez declarada. Un payload firmado capturado hace 10 minutos no puede ser replayed hoy, incluso si la clave del firmante se compromete después — el runtime lo rechaza en la guarda de timestamp antes de cualquier comprobación adicional.
• La misma puerta para todos. Un cliente de copy-trading, una integración API institucional y una wallet retail autorizan, firman, hacen commit y envían a través del mismo límite. No hay un carril privilegiado que permita a la plataforma admitir una clase de orden bajo una regla distinta.