Skip to main content
A una red en funcionamiento llegan tres tipos de cambio: cambios de parámetros (un límite de riesgo, un esquema de comisiones, un tope de financiación), cambios de comportamiento (cómo funciona la propia ejecución) y cambios de mercado (listados y retiradas). Se diferencian en cómo se anuncian. Comparten una propiedad, y es la que importa: un cambio entra en vigor en un punto concreto de la historia de la cadena, y la historia anterior a ese punto no se ve afectada.

Cambios de parámetros

Los parámetros de riesgo, los tramos de apalancamiento, los topes de financiación, los límites de posición y los esquemas de comisiones son configuración on-chain. Cambiar uno es una transacción de protocolo que se ejecuta en un bloque, en lo más alto de la prioridad del bloque. Como el valor es estado de la cadena, el cambio se observa, no se comunica. No hace falta que nadie te diga que la tasa de margen de mantenimiento de un mercado se ha movido: puedes leer cuál es, y puedes leer cuál era en cualquier bloque pasado. Las claves de configuración además están versionadas. Cuando lo que cambia es la forma de un valor y no su número, la forma nueva se escribe bajo una clave nueva y la vieja sigue siendo legible. Un cliente que resuelve la configuración en vivo sigue funcionando a través del cambio; un cliente que codificó a fuego una ruta de clave se entera de inmediato en vez de leer en silencio algo obsoleto. Consulta Modelo de estado.

Cambios de comportamiento

Cambiar cómo se comporta la ejecución es un problema más difícil que cambiar un número, porque todos los validadores deben hacer el cambio exactamente en el mismo instante. Un cambio que aterriza en distintos nodos en distintos momentos no es un despliegue: es un fork. Intention lo resuelve con interruptores de funcionalidad on-chain (feature gates). Cada interruptor es una clave de estado que guarda una altura de bloque: la altura a la que empieza el comportamiento nuevo.
Comportamiento nuevo, apagadoen el binario, no activo
Se escribe un interruptoruna clave de estado con una altura futura
Todos los validadores leen la misma altura
El comportamiento cambia justo en ese bloque
La altura debe estar en el futuroUn interruptor no puede fijarse a una altura que ya ha pasado. Esa única regla es lo que hace simultáneo el cambio.
Un interruptor ausente es inactivoUn nodo que reejecuta no lee clave alguna a esas alturas y toma la ruta antigua: la reejecución sigue siendo correcta sin matriz de compatibilidad.
Se lee en la versión que se ejecutaNunca de una caché. Leer un valor actual al reejecutar un bloque antiguo aplicaría las reglas de hoy a la historia de ayer.
De ahí se siguen tres propiedades, y cada una sostiene el diseño: La altura debe estar en el futuro cuando se escribe. Un interruptor no puede fijarse a una altura que ya ha pasado. Esa única regla es lo que hace simultáneo el cambio: todos los validadores llegan a ese bloque con la misma clave ya visible. Un interruptor ausente significa inactivo. Un nodo que reejecuta la historia no lee ninguna clave a esas alturas y toma exactamente la ruta de código antigua. La reejecución histórica sigue siendo correcta sin coste alguno, sin que nadie mantenga una matriz de compatibilidad. El interruptor se lee en la versión que se está ejecutando, nunca de una caché. Leer un valor actual mientras se reejecuta un bloque antiguo aplicaría las reglas de hoy a la historia de ayer y produciría una raíz de estado distinta. Por eso el valor se lee siempre desde la vista de ejecución del bloque que se está ejecutando. El mismo mecanismo admite la activación gradual: un flag puede introducirse inactivo, comprobarse contra tráfico real y encenderse a una altura programada, en vez de enviarse como una actualización binaria de golpe.

Periodos de preaviso

El preaviso es proporcional a lo que un cambio puede hacerle a una posición que ya tienes. La última fila es una excepción real, no un resquicio. Un límite de posición que tiene que esperar una semana para endurecerse es un límite de posición que no hace nada durante justo la semana en que hacía falta. Cuando se usa, el cambio y su motivo se publican con él.
Un cambio en los requisitos de margen o en los tramos de apalancamiento cambia tu precio de liquidación en posiciones que ya tienes. No cierra nada y no te avisa individualmente. Si mantienes posiciones a través de un cambio anunciado de parámetros de riesgo, recalcula tu distancia a la liquidación contra los valores nuevos y no contra los que regían cuando abriste. Consulta Apalancamiento.

Lo que no puede cambiar

Las reglas que se aplicaron a un bloque que ya se ha confirmado. Todo cambio de regla entra en vigor a una altura que estaba en el futuro cuando se registró, así que reejecutar un bloque antiguo aplica siempre las reglas que estaban activas entonces. Preguntar si una regla concreta estaba en vigor en alguna versión pasada tiene una sola respuesta, y es la misma hoy que dentro de un año. Es una garantía más fuerte que una política publicada. No se trata de que el protocolo no vaya a reescribir la historia: es que el mecanismo no tiene forma de representar una regla que empezó en el pasado. Consulta Modelo de estado.

Anuncios

Los compromisos de preaviso de esta página empiezan con la testnet pública el 20 de septiembre de 2026. La testnet privada cambia parámetros y comportamiento sin preaviso: existe para ajustarlos.
Una vez que empiecen los periodos de preaviso, todo cambio queda registrado en el registro de cambios del protocolo con la fecha en que entró en vigor, y se anuncia antes de esa fecha cuando la tabla de arriba lo exige. Las entradas se fechan por cuándo entró en vigor el cambio en la red, no por cuándo se anunció.

Qué leer a continuación

Registro de cambios del protocolo

El registro fechado de lo que se ha publicado.

Listados y retiradas de mercados

Los cambios de mercado y sus periodos de preaviso.

Modelo de estado

Por qué las claves de configuración están versionadas y se resuelven en vivo.

Apalancamiento

Qué le hace a una posición abierta un cambio de parámetros de riesgo.