RUNTIME Y PUBLICACIÓN
El runtime es el motor de un único escritor que posee el estado de trading en vivo — posición, equity, devengo de funding, fills, pasadas de liquidación. La publicación es la disciplina que convierte ese estado en vivo en raíces confirmadas contra las que liquidan los contratos de Base. Juntos son la razón por la que el historial de un trader, un rango en la tabla de clasificación y el importe de un pago 90 / 10 no pueden reescribirse silenciosamente a posteriori: cada transición de estado aterriza en una secuencia ordenada única, cada raíz está vinculada a la secuencia y a la postura de configuración y oracle que la produjo, y cada retiro liquida contra una raíz que cualquiera con un explorador puede verificar.
El runtime valida el flujo firmado desde el gateway, aplica las reglas de riesgo y de estado de mercado, actualiza saldos y posiciones, avanza el funding (peer-to-peer con una porción de admin del 1% por encima de $1.000 por ventana de 8h), y ejecuta rutinas forzadas — liquidación, ADL, la división residual 50/50 keeper-y-seguros. Cada transición de estado produce las referencias contra las que la capa de contratos liquida después. La tabla siguiente es lo que se publica con cada commit; una raíz sin estos bindings es rechazada por el vault.
| Ítem publicado | Lo que vincula |
|---|---|
| Raíz de estado | Ancla el estado de cuenta para las pruebas de settlement y retiro en Base |
| Id de raíz y timestamp | Coloca el estado dentro de un historial de publicación explícito; ambos monotónicos |
| Commitment de secuencia | Vincula el orden de eventos al estado confirmado — sin fills reordenados |
| Hash de fuente del oracle | Vincula la postura de la fuente de precios usada mientras el estado avanzó |
| Commitment del batch de órdenes | Vincula el batch admitido alrededor de ese estado — sin órdenes insertadas o eliminadas |
| Hash y versión de configuración | Vinculan las reglas activas de riesgo y de plataforma — esquema de comisiones, nivel de margen, lista de mercados |
#Estado de exchange de un único escritor
Dexter ejecuta una sola ruta de escritura. Las actualizaciones de funding, las pasadas de liquidación, las rutinas de desequilibrio, los cambios de estado de mercado y la publicación se mueven todos a través de un flujo de runtime ordenado único — nunca a través de escritores en competencia. En una plataforma de derivados, el ordenamiento incorrecto es tan costoso como un pricing incorrecto: un tick de funding aplicado fuera de orden puede falsificar el equity, una liquidación corriendo contra un fill puede liquidar contra la marca equivocada. El modelo de un único escritor elimina ambas clases de bug haciendo que un runtime sea el único autor de la secuencia de transición de estado que el resto del sistema lee.
El mismo runtime que actualiza los saldos prepara el material que la publicación ancla después. Por eso el contexto de settlement y el estado de trading no pueden discrepar — provienen del mismo proceso, en el mismo orden, detrás del mismo commitment.
orden IOC firmada
-> comprobaciones de admisión y riesgo
-> decisión de pricing y fill
-> actualizaciones de libro mayor, posición, comisión y funding
-> escritura de snapshot y modelo de lectura
-> precommitSequencerCommitment(seqCommitment, oracleSourcesHash, orderBatchCommitment)
-> commitStateRootWithConfig(root, schemaVersion, configHash, configVersion)
-> el vault acepta la raíz solo mientras las guardas de publicación permanezcan satisfechas#La publicación como contexto de settlement
La publicación existe para que la capa de contratos nunca tenga que confiar en una afirmación vaga del operador sobre el estado del runtime. Cuando el runtime envía una raíz junto con referencias de secuencia, oracle, batch y configuración, el vault en Base recibe una descripción concreta de lo que la plataforma creía en el momento en que el estado avanzó. Esa descripción es de lo que dependen todos los retiros, disputas, pruebas de fraude, reconciliación y revisión a posteriori. Sin ella, el contrato sólo sabría que un proceso off-chain afirmó un saldo; con ella, el contrato puede anclar una vista específica del runtime, preservarla en el historial y exigir que cada acción de settlement apunte de vuelta a algo concreto.
La publicación no se trata como una acción exclusiva del runtime. Antes de que el vault acepte una raíz, el commitment del sequencer, el hash de la fuente del oracle y el commitment del batch de órdenes deben estar ya precommiteados mediante precommitSequencerCommitment(seqCommitment, oracleSourcesHash, orderBatchCommitment). La raíz se envía después a través de commitStateRootWithConfig(...), que la vincula al configHash y configVersion activos. Si el material precommiteado no coincide con la raíz, o si el bloqueo de gobernanza del lado del contrato no se cumple, la publicación se rechaza y la raíz nunca se convierte en contexto de settlement.
La postura de producción es más estricta que un commit de raíz por sí solo. El bloqueo de gobernanza requiere que el anclaje de auditoría esté activo, que setOrderCommitRequired(true) esté vigente, y que la ruta de publicación mantenga al menos una vía de evidencia duradera — ya sea un requisito de archivo o un requisito de attestor de DA. Una raíz que existe en aislamiento no es de calidad de producción; tiene que permanecer atada a la cadena de auditoría que explica cómo se publicó el estado y a la misma disciplina de admisión que produjo el flujo de órdenes que la generó. Eso es lo que hace seguro anclar el runtime off-chain contra la custodia on-chain.