Skip to main content
Estas páginas hacen cuatro afirmaciones una y otra vez: que un cálculo de margen se puede comprobar de forma aislada, que cualquiera puede recalcular una selección de desapalancamiento automático, que la financiación se deriva en lugar de decidirse, y que dos nodos honestos producen resultados idénticos byte a byte. Una afirmación de esa forma no vale nada hasta que alguien ajeno al protocolo la ha ejecutado. Esta página es el cómo. Cada comprobación nombra las entradas, de dónde vienen y —igual de importante— qué es lo que no establece.
Solo aritmética
Datos públicos, cualquier nodo
Tu propio nodo completo
Un requisito de margen
Un precio de liquidación
Una selección de ADL
Un pago de financiación
Un bloque, byte a byte
Dos de los cinco no necesitan red alguna: son funciones puras sobre un registro de tramos publicado.

1 · Un requisito de margen

Qué necesitas: un registro de tramos de apalancamiento y un tamaño de posición. Nada más. Ni nodo, ni red, ni cuenta. El margen inicial y el de mantenimiento son funciones puras del nocional y del registro de tramos; las fórmulas y el redondeo exacto están en Apalancamiento: IM=nocional×im_leverage×10exponent\text{IM} = \text{nocional} \times \text{im\_leverage} \times 10^{\text{exponent}} MM=max⁡ ⁣(nocional×mm_leverage×10exponent−deduccioˊn,  0)\text{MM} = \max\!\left(\text{nocional} \times \text{mm\_leverage} \times 10^{\text{exponent}} - \text{deducción},\; 0\right) Los registros de tramos se publican en el grupo DEX Config de la referencia de la API: im_leverage, mm_leverage, el exponent compartido y el deduction de cada tramo. Elige un nocional, evalúa ambas expresiones sobre el papel y compáralas con lo que el mercado cobra a la misma posición. Qué demuestra: el requisito es una función publicada de parámetros públicos, no un criterio cuenta por cuenta. Qué no demuestra: que el registro de tramos esté bien elegido. Eso es una cuestión de gobernanza, no de aritmética.
El redondeo forma parte de la especificación, no es una tolerancia. Si tu entero difiere en una unidad del del mercado, uno de los dos está mal: mira las reglas de redondeo en la página Cámara de compensación antes de decidir cuál.

2 · Un precio de liquidación

Qué necesitas: el mismo registro de tramos, más tu saldo y tu posición. El umbral es un ratio, definido en Liquidaciones: uso=margen de mantenimientocolateral neto\text{uso} = \frac{\text{margen de mantenimiento}}{\text{colateral neto}} El colateral neto es el saldo más el P&L no realizado, menos lo que hayan reservado las órdenes en el libro. Despeja el precio de marca al que el ratio alcanza su disparador y tendrás el precio al que actuará el protocolo, antes de que actúe. Qué demuestra: el disparador se puede derivar de antemano a partir de tus propios números. Qué no demuestra: el precio al que realmente te cerrarán, que depende del libro en ese momento y está acotado por el precio de bancarrota.

3 · Una selección de desapalancamiento automático

Qué necesitas: las posiciones abiertas y los precios de marca de un mercado, desde cualquier nodo completo. La selección es una puntuación, definida en Desapalancamiento automático: puntuacioˊn=% de beneficio no realizado×apalancamiento efectivo\text{puntuación} = \text{\% de beneficio no realizado} \times \text{apalancamiento efectivo} Toma las posiciones de un mercado del grupo Accounts y el precio certificado del grupo Oracle, calcula la puntuación de cada posición del lado en ganancia y ordena. Ese orden es la cola. Compara la cabeza de tu cola calculada con el indicador de ADL que muestra la interfaz. Qué demuestra: la cola es una función de estado público. Nadie elige, y no hay en ella ninguna posición que tu propia aritmética no pueda encontrar. Qué no demuestra: que el desapalancamiento no vaya a alcanzarte. Una cola que sabes calcular sigue siendo una cola en la que puedes estar.

4 · Un pago de financiación

Qué necesitas: el libro de órdenes y el índice certificado de la ronda de liquidación, más tu posición. La tasa se construye en tres pasos en Financiación: una prima ponderada por profundidad, escalada al intervalo del mercado y luego acotada: P=max⁡(0,  compra DW−ıˊndice)  −  max⁡(0,  ıˊndice−venta DW)ıˊndiceP = \frac{\max(0,\; \text{compra DW} - \text{índice}) \;-\; \max(0,\; \text{índice} - \text{venta DW})}{\text{índice}} F=F8h×segundos del intervalo28,800Ffinal=clamp⁡ ⁣(F,  Fmin⁡,  Fmax⁡)F = F_{8h} \times \frac{\text{segundos del intervalo}}{28{,}800} \qquad F_{\text{final}} = \operatorname{clamp}\!\left(F,\; F_{\min},\; F_{\max}\right) Y después el cargo en sí: pago de financiacioˊn=taman˜o de la posicioˊn×precio de marca×tasa de financiacioˊn\text{pago de financiación} = \text{tamaño de la posición} \times \text{precio de marca} \times \text{tasa de financiación} El libro sale del grupo Markets, el índice certificado de Oracle, y el pago que el protocolo realizó de verdad del endpoint de pagos de financiación en el grupo Accounts. Recalcula y compara. Qué demuestra: la tasa se derivó del libro y del índice, no la fijó un operador. Qué no demuestra: que el índice fuera correcto. Consulta qué garantiza y qué no garantiza el oráculo.

5 · Un bloque, byte a byte

Qué necesitas: un nodo completo tuyo. Cualquiera puede ejecutar uno; consulta Ejecutar un nodo.
Es la única comprobación de esta página que hoy no está disponible. La red está en una testnet privada hasta que se abra el acceso público, así que las cuatro primeras se pueden hacer ya y esta lo será entonces. Aparece aquí porque las otras cuatro valen lo que valga esta.
Es la comprobación sobre la que se apoyan las otras cuatro. Toma un bloque confirmado y su estado previo, ejecútalo y compara tu resultado con el de la red. Aquí el determinismo se impone, no se espera: la ruta de ejecución no lee reloj, ni entropía en tiempo de ejecución, ni coma flotante, ni órdenes de iteración aleatorizados por hash, así que una divergencia es un defecto y no una tolerancia. Consulta Por qué el resultado es reproducible. Dos propiedades hacen de esto una prueba real y no una ceremonia. El ordenamiento es un objeto confirmado por el consenso, así que la secuencia que reejecutas es la que firmó un cuórum y no la que dedujo tu nodo. Y los precios están confirmados por las mismas firmas, de modo que no existe ventana alguna en la que pudieras reejecutar contra un precio que la red no certificó. Qué demuestra: que el estado que se te sirve fue producido por las reglas tal como están publicadas, sobre entradas que la red confirmó. Qué no demuestra: que las reglas estén libres de defectos. Reproducir un fallo exactamente sigue siendo reproducir un fallo, y por eso junto a esto existen las auditorías y el programa de recompensas.

Lo que nada de esto cubre

La verificación acota lo que hay que dar por bueno; no lo elimina. Lo que queda —el conjunto de validadores, el cuórum de precios, el alcance de la gobernanza sobre los parámetros y el puente— está enumerado en Supuestos de confianza. Lee esa página a continuación si viniste a buscar los límites y no las garantías.

Qué leer a continuación

Supuestos de confianza

Lo que queda cuando ya se ha comprobado todo lo comprobable.

Ejecutar un nodo

Hardware, sincronización y qué ejecuta realmente un validador.

IntentionKernel

Los cuatro cierres que dan sentido a la reejecución.

Referencia de la API

Detalle a nivel de campo de cada entrada mencionada arriba.