> ## 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. # Casación > El libro de órdenes, cómo se representa la prioridad precio-tiempo y cómo se resuelven contra ella la vigencia de la orden y la prevención de autoejecución. La casación es una etapa dentro de la [ejecución del kernel](/es/protocol/architecture/kernel), no un servicio con el que la cadena habla. Toma las órdenes del bloque en su secuencia confirmada, las recorre contra el libro y produce ejecuciones. No mueve el saldo de nadie: de eso se encarga la [cámara de compensación](/es/protocol/architecture/clearinghouse), y ocurre después de que la casación termine. Mantener las dos separadas es lo que permite probar el motor. La casación responde *qué se cruzó con qué*. La cámara de compensación responde *cuánto cuesta eso y quién le debe ahora a quién*.

El libro

Cada instrumento tiene su propio libro, mantenido en memoria como tres estructuras que cooperan:

Slab arena — una región preasignada de slots de órdenes

Niveles de preciomapa ordenado, precio → nivelel primer nivel se halla caminando al final, no escaneando

Índice de órdenesid de orden → slotcancelar y modificar: tiempo constante

orden

Cadena doblemente enlazada en secuencia de llegada: la prioridad dentro de un nivel es posicional, no calculada.

Por qué el orden de reúso es fijoLos slots liberados se reutilizan en un orden fijo y el índice tiene semilla fija. No es rendimiento: dos validadores que reutilicen slots en distinto orden bifurcarían.

cabeza de cada nivel

búsqueda directa

| Estructura | Función | | --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Niveles de precio** | Un mapa ordenado de precio a nivel, de modo que la mejor compra y la mejor venta se encuentran caminando hasta el extremo en lugar de escaneando | | **Cadena de órdenes** | Una lista doblemente enlazada que enhebra las órdenes en su secuencia de llegada, de modo que la prioridad dentro de un nivel es posicional y no calculada | | **Índice de órdenes** | Un mapa directo del ID de orden a su slot, de modo que cancelar y modificar son de tiempo constante en lugar de una búsqueda | Las órdenes viven en un **slab arena**: una región preasignada con reserva y liberación en tiempo constante. Las operaciones del libro de órdenes no reservan memoria en la ruta caliente, y los slots liberados se reutilizan en un orden fijo y no allí donde el asignador decida ponerlos. Ese último detalle no es una decisión de rendimiento: si dos validadores reutilizaran los slots en órdenes distintos, cualquier cosa que observara la disposición de los slots divergiría. La misma disciplina se aplica al índice de órdenes, cuya semilla es fija y no aleatoria. Un mapa hash con semilla por proceso es una defensa estándar contra los ataques de colisión; en una ruta de ejecución de consenso es una bifurcación. Los precios son enteros en todo el recorrido: unidades de subtick, no decimales. Consulta [Precisión](/es/trading/precision) para ver cómo se corresponde eso con lo que envías.

La prioridad

La prioridad es primero el precio y después la posición en la cadena a ese precio. El “tiempo” es la posición canónica de la orden en la secuencia confirmada del bloque, no el momento en que llegó a un nodo. Esto es lo que elimina la carrera de latencia dentro del bloque. Dos órdenes del mismo bloque tienen una precedencia definida que todos los validadores calculan igual, y ninguna cantidad de proximidad a un nodo concreto la cambia. Entre bloques, la llegada sigue importando, pero la unidad de competencia es el bloque, no el microsegundo. El orden de etapas del kernel refuerza esto: las cancelaciones se ejecutan antes que las colocaciones agresivas dentro de un bloque, de modo que ninguna orden que llegue en el mismo bloque que su cancelación puede llevarse una cotización que está en el libro.

Casar una orden

Orden entrante

¿Cruza el libro?

Consumir el mejor nivel opuesto

Emitir ejecución

Fin

Dejar en el libro o rechazar, según la vigenciaGTC deja el resto · IOC lo cancela · FOK no ejecuta nada si no se ejecuta entera · post-only se rechaza en vez de cruzar

resto — tomar el siguiente nivel

no queda nada

El motor de casación consume repetidamente la cabeza del lado opuesto y emite una ejecución por cada maker que toma, hasta que la orden entrante se agota o el libro deja de cruzar. Qué ocurre con el resto lo decide la vigencia de la orden: * **GTC** — deja el resto en el libro. * **IOC** — cancela el resto. * **FOK** — si la orden no puede ejecutarse por completo, no se ejecuta nada. * **ALO** — solo maker (post-only): si la orden fuese a tomar liquidez, se rechaza en lugar de cruzar. Las ejecuciones llevan atribución desde que se producen. Cada ejecución registra dónde se sitúa en la secuencia de ejecuciones de su instrumento, y esas posiciones por instrumento se resuelven en un único orden a lo largo del bloque cuando se ensambla la salida. Esto es lo que permite que, más tarde, un evento se pueda rastrear hasta la transacción exacta y el punto exacto del bloque que lo causó.

Prevención de autoejecución

Si una orden entrante fuera a casar contra liquidez del mismo propietario que ya está en el libro, la casación se suprime en lugar de ejecutarse. Qué lado cede es configurable: | Modo | Comportamiento | | ----------------- | ------------------------------------------------------------ | | **Expirar taker** | Se cancela la orden entrante | | **Expirar maker** | Se cancela la orden en el libro y la orden entrante continúa | | **Expirar ambas** | Se cancelan las dos | Los makers cancelados de este modo se recogen durante la casación y se eliminan dentro del mismo bloque, de forma que el libro no se queda con una orden que ya está suprimida. La propiedad para esta comprobación se resuelve en el nivel de cuenta que el libro sigue. Consulta [Prevención de autoejecución](/es/trading/self-trade-prevention) para la visión desde el lado del trading.

Lo que la casación no hace

No calcula comisiones, no realiza pérdidas y ganancias, no ajusta posiciones ni comprueba el margen. Eso ocurre después de la casación, en la [cámara de compensación](/es/protocol/architecture/clearinghouse), impulsado por las ejecuciones que la casación produjo. Tampoco decide si una orden tenía permiso para existir. La suficiencia de margen, los límites de órdenes abiertas, las restricciones de solo reducción y la conversión de mercado a límite se resuelven antes de que una orden llegue al libro. Cuando el motor de casación ve una orden, la única pregunta es dónde encaja en el libro.

Qué leer a continuación

Qué les ocurre a los saldos y a las posiciones una vez que existen ejecuciones. La visión desde el lado del trading: qué puedes enviar y cómo se comporta cada tipo. Profundidad, niveles y cómo leer el libro como trader. Dónde encaja la casación en la ejecución del bloque.