> ## Documentation Index
> Fetch the complete documentation index at: https://docs.intention.xyz/llms.txt
> Use this file to discover all available pages before exploring further.
# IntentionKernel
> La capa de ejecución: un conjunto cerrado de instrucciones de operaciones financieras, ejecutado como una secuencia fija de etapas sobre un bloque confirmado por el consenso.
IntentionKernel es donde un bloque confirmado se convierte en estado de trading. No es una máquina virtual de propósito general que ejecuta programas arbitrarios: su conjunto de instrucciones es el conjunto enumerado de operaciones financieras que necesita un exchange de derivados, y cada una de ellas tiene un efecto definido que el protocolo entiende.
Esa distinción es la razón por la que la red puede afirmar algo sobre el trading. Una cadena de propósito general puede decirte que una transacción se firmó y no abortó. No puede decirte que la transacción era la cancelación de una orden concreta en una posición concreta del libro, porque el significado de la llamada le resulta opaco. Aquí el significado es la instrucción.
Ejecución de mundo cerrado
Cerrar el conjunto de instrucciones es solo una instancia de un movimiento que el kernel hace cuatro veces. Cada vez, el espacio de lo que puede ocurrir se enumera de antemano, y lo que queda fuera se rechaza en lugar de gestionarse.
Operaciones
Una carga que no pertenece al conjunto enumerado: rechazada en la validación, no en tiempo de ejecución
Qué se pidió realmente
Verdad
Tratar el conjunto de trabajo del bloque como autoritativo. Es un diario; la fuente es el estado del motor
Qué es cierto ahora mismo
Entradas
Todo lo que puede diferir entre dos máquinas: reloj, entropía, coma flotante, orden de hash
Si otro nodo obtiene los mismos bytes
Causalidad
Un cambio de estado sin dueño. Los efectos que no pertenecen a ninguna transacción van por un canal de sistema, no por una excepción
Por qué ocurrió justo este cambio
Cerrado
Rechazado
Así el ledger puede responder
Cuatro cierres, un solo movimiento: enumerar el espacio de antemano y rechazar lo que queda fuera.
No son cuatro virtudes independientes. Cada una sostiene a la siguiente: cerrar las operaciones es lo que hace recuperable el *significado* de una instrucción; un único estado autoritativo es lo que da sentido a la palabra «resultado»; cerrar las entradas es lo que hace ese resultado reproducible fuera de esta máquina; y cerrar la causalidad es lo que permite remontar de un resultado a la petición que lo produjo. Quita una y la cadena de responsabilidad se rompe justo en ese eslabón.
Lo que las cuatro compran juntas merece un nombre, porque los mercados tradicionales compran lo mismo mucho más caro. La pista de auditoría de una bolsa se ensambla **al lado** del sistema de negociación y se reporta aguas abajo: por eso puede discrepar del sistema, por eso la conciliación es un oficio permanente, y por eso la sincronización de relojes entre mercados es un requisito regulatorio y no un detalle de implementación. Aquí no hay un segundo registro con el que conciliar. La pista de auditoría es la ejecución.
El resto de esta página son esos cuatro cierres en detalle.
El conjunto de instrucciones
Todo lo que un participante o un validador puede hacer es una de un conjunto fijo de operaciones tipadas:
| Grupo | Operaciones |
| ------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Órdenes** | Colocar, cancelar, reemplazar y modificar — en las formas límite, de mercado y condicional, con vigencia de la orden, solo reducción y estructuras vinculadas de take-profit / stop-loss |
| **Configuración de la cuenta** | Creación de subcuentas, selección de apalancamiento, modo de margen, modo de posición |
| **Transferencias** | Entre subcuentas, entre cuentas, y de entrada y salida a través del [puente](/es/protocol/architecture/bridge) |
| **Autorización de agentes** | Autorizar y revocar un agente que opera en nombre de una cuenta |
| **Operaciones de bóveda** | Creación, depósitos, retiros, configuración |
| **Configuración del sistema** | Listado de mercados, configuración de comisiones, tramos de apalancamiento, parámetros de riesgo — autorizados por la gobernanza |
| **Emitidas por validadores** | Actualizaciones de precios certificados y reconfiguración |
Una transacción cuyo payload no pertenece a este conjunto se rechaza en la validación. El conjunto solo cambia mediante una actualización del protocolo, nunca desplegando algo nuevo.
Ejecutar un bloque
La ejecución es una secuencia fija de etapas. El orden no es un detalle de implementación: es lo que determina si una liquidación ve el precio que la activó y si una cancelación le gana a una orden agresora entrante.
Preciofijar las marcas del bloque
Cargaingerir cuentas y órdenes del bloque
Financiaciónsaldar los flujos
Riesgodesapalancar bóvedas → liquidación → ADL
Casaciónprevia → casación → posterior
Finalizarrecoger salidas, purgar estado muerto
Cada etapa posterior razona sobre un único precio por instrumento, no sobre uno móvil
Saldada contra las posiciones como se cargaron, no como acaban
El flujo forzoso se resuelve antes de admitir flujo discrecional nuevo
Al ir después de Riesgo, ninguna orden del mismo bloque puede adelantarse a una liquidación
Las posiciones a cero y las cuentas vacías no persisten
Un bloque, seis etapas
Lo que depende de ese orden
Las órdenes condicionales se revisan y avanzan en esta secuencia: una activación por las marcas de este bloque surte efecto en este bloque, no en el siguiente.
**Precio** se ejecuta primero y fija las marcas que usará el resto del bloque, de modo que cada etapa posterior razona sobre un único precio por instrumento y no sobre uno en movimiento. **Carga** ingiere las cuentas y órdenes del bloque. **Financiación** salda la financiación contra las posiciones tal y como se cargaron. **Riesgo** ejecuta tres fases en orden (desapalancamiento de bóvedas, luego liquidación, luego desapalancamiento automático) para que el flujo forzoso quede resuelto antes de admitir flujo discrecional nuevo. **Casación** ejecuta entonces sus propias tres fases y produce ejecuciones. **Finalizar** recoge lo que cambió y purga el estado que ya no necesita existir, como las posiciones a cero y las cuentas vacías.
Las órdenes condicionales se revisan y avanzan por su ciclo de vida dentro de esta secuencia, de modo que una activación provocada por las marcas de este bloque surte efecto en este bloque y no en el siguiente.
Que la liquidación se ejecute antes que la casación es la razón por la que ninguna orden del mismo bloque puede adelantarse a una liquidación. El flujo de liquidación ya está resuelto cuando se casan las órdenes discrecionales.
Dos clases de estado
El kernel mantiene una separación estricta entre lo que persiste y lo que es temporal.
al ejecutarse un bloque
Estado del motormercados · cuentas · libros · posiciones · cámara de compensaciónvive entre bloques
Conjunto de trabajomarcas · cuentas tocadas · ejecuciones · salida preparadavive un solo bloque
Estado confirmado de la cadenaversionado · autenticadola autoridad
Es fácil confundir el seguimiento de cambios con la autoridad. Lo que cambió en un bloque construye la salida determinista — no es donde vive el estado.
la autoridad de la que se reconstruye el motor
lectura
aplicar
materializar
**El estado del motor** vive entre bloques: metadatos de mercado, cuentas, libros de órdenes, estado de los instrumentos, estado de la cámara de compensación. Es la respuesta a “qué es cierto ahora mismo”.
**El conjunto de trabajo por bloque** existe solo mientras se ejecuta un bloque: las entradas del bloque, las marcas fijadas al inicio, las cuentas y órdenes tocadas y las salidas que se están ensamblando. Es un diario, no una fuente de verdad.
La distinción importa porque el seguimiento de cambios se confunde con facilidad con la autoridad. Lo que cambió durante un bloque sirve para construir la salida determinista; no es donde vive el estado. Invertirlo produce un sistema en el que la respuesta depende de cómo preguntaste.
Por qué el resultado es reproducible
Aquí el determinismo se impone, no se espera. Todo nodo honesto que ejecuta el mismo bloque contra el mismo estado previo produce el mismo resultado byte a byte, porque nada en la ruta de ejecución puede leer algo que difiera entre nodos:
* **Aritmética de punto fijo en todo el recorrido.** Los cálculos de compensación se hacen en punto fijo entero con semántica de redondeo explícita: redondeo hacia arriba en los exponentes negativos del margen, truncamiento (floor) y techo (ceiling) en las comisiones. No hay punto flotante en la ruta de compensación, porque una diferencia de redondeo entre dos máquinas es una bifurcación.
* **Sin reloj de pared.** El orden dentro de un bloque usa la posición canónica confirmada por el consenso y la marca de tiempo del bloque, nunca la hora local.
* **Sin aleatoriedad en tiempo de ejecución.** Todo lo que requiere aleatoriedad la deriva de forma determinista del estado de la cadena.
* **Iteración determinista.** Toda colección cuyo orden de iteración sea observable en la salida está ordenada, no aleatorizada por hash.
Una consecuencia que conviene nombrar: como el “tiempo” dentro de un bloque es la posición intrabloque confirmada, no existe ninguna ventaja de colocation (proximidad de servidores) por debajo del milisegundo *dentro* de un bloque. Combinado con el calendario de prioridad, que ejecuta las cancelaciones antes que las colocaciones agresivas, esto es una defensa estructural frente a que una orden llegada en el mismo bloque le arrebate una cotización que está en el libro.
Las fórmulas de riesgo son puras
Las fórmulas que deciden los requisitos de margen, los precios de liquidación, la selección para el desapalancamiento, las comisiones y los límites de interés abierto están implementadas como **funciones puras y sin estado**. Toman valores y devuelven valores; no leen ni modifican el estado del ledger.
Los cambios de estado los dirige exclusivamente la [cámara de compensación](/es/protocol/architecture/clearinghouse), que llama a esas funciones y aplica los resultados. Los módulos que guardan estado (cuentas, posiciones, libros de órdenes) almacenan datos y exponen mutadores, pero no dirigen ellos mismos el flujo de negocio.
Es un límite deliberado. Significa que un cálculo de margen se puede comprobar de forma aislada contra una tabla de entradas y salidas, y significa que hay exactamente una ruta de código por la que puede cambiar el saldo de alguien.
La salida
La ejecución produce escrituras de estado y eventos, cada uno ligado a la transacción que lo causó, más un canal para los efectos de nivel de sistema que no pertenecen a ninguna transacción de usuario concreta: financiación, movimientos del seguro, contadores de bloque. Esos se convierten en las salidas de transacción que la [capa de estado](/es/protocol/architecture/state/model) confirma y el [indexador](/es/protocol/architecture/indexer) sirve.
Nada de lo que ocurre dentro del kernel es invisible aguas abajo. Si cambió el estado, está en la salida de alguien o en el canal del sistema.
Qué leer a continuación
El libro de órdenes, la prioridad precio-tiempo y cómo se resuelven la vigencia de la orden y la prevención de autoejecución.
La única ruta por la que cambian los saldos, las posiciones y el margen.
En qué se convierte la salida del kernel una vez confirmada.
De dónde vinieron el orden y los precios.