Reglas y gobernanza

Cada contrato compromete las reglas exactas por las que será juzgado — el evaluador que califica el resultado — con hash incorporado al acuerdo en el momento en que se firma. Esta es la garantía de fijación: un cambio posterior en las reglas se aplica solo a acuerdos nuevos. Nunca puede alcanzar hacia atrás y recalificar un valor ya bloqueado bajo sus propios términos comprometidos.

En términos simples: las reglas que liquidarán tu contrato son las que existían cuando lo aceptaste, y ninguna actualización futura puede mover esa meta después del hecho. Los cambios de reglas son prospectivos, nunca retroactivos sobre el valor bloqueado.

Un cambio en las reglas — o una actualización de software del sistema que las aplica — no entra en vigor en el momento en que alguien lo decide. Primero pasa por un proceso público y registrado:

El período de revisión existe para que un cambio nunca sea una sorpresa: puedes verlo venir, y puedes liquidar o salir de cualquier cosa en curso bajo las reglas antiguas antes de que apliquen las nuevas.

En concreto: la autoridad que puede reescribir la lógica de aplicación en cadena está protegida detrás de un multisig de 3 de 5 y un bloqueo temporal en cadena de 48 horas (Squads). Está en vivo en devnet y probado en cadena — en un simulacro de gobernanza, 3 de 5 oficinas independientes aprobaron un cambio y la ejecución siguió bloqueada por el bloqueo temporal — así que ninguna parte puede cambiar las reglas en silencio sobre valor bloqueado. Esto se ejecuta hoy en Solana devnet (sin auditar); el registro honesto de qué está en vivo frente a lo condicionado a auditoría está en Confianza y verificabilidad.

El período de revisión no es solo una sala de espera — es una ventana para objetar. Durante él, cualquiera puede plantear un desafío contra un cambio propuesto. Para mantener el canal libre de spam, un desafío está respaldado por una fianza: poner valor real detrás de una objeción es lo que le gana una audiencia.

Un desafío se decide entonces mediante el mismo proceso objetivo de disputas que liquida cualquier otro resultado impugnado — la misma evaluación fijada y reproducible, y la misma escalera de escalamiento descrita en Arbitraje y disputas. Un desafío confirmado bloquea el cambio. Impugnar un cambio de reglas pasa exactamente por la misma maquinaria que usarías para impugnar un veredicto — el derecho a disputar no se limita a tus propios contratos.

Una lista corta de protecciones centrales queda fuera del alcance de cualquier cambio de reglas ordinario. La más importante: el derecho a que tu disputa sea escuchada. Un cambio que intentara eliminarlo es rechazado por la propia lógica de aprobación, antes de contar un solo voto — así que ningún voto, y ninguna mayoría, puede eliminar tu derecho a llevar un resultado impugnado por el proceso de disputas. Es un piso fijo, no una cortesía que pueda revisarse mediante una votación.

Para ser precisos sobre cómo se sostiene ese piso hoy: está aplicado por la aplicación — la lógica de aprobación y liquidación desplegada que ejecutamos — que es lo que lo hace inmune a cualquier voto. Hacerlo inmune también a nosotros es el siguiente paso: una vez que esa lógica quede congelada en un programa en cadena, el piso queda aplicado por código que nadie puede cambiar en silencio, no por nuestro compromiso de ejecutar el código correcto. Decimos cuál de estas cosas es cierta hoy en lugar de dar a entender la más fuerte.

Una vez que una disputa se resuelve, su veredicto se escribe en un registro finalizado en cadena — una entrada confirmada, de escritura única, no una nota de disparar y olvidar. A partir de entonces no puede quedar sin resolver en silencio, recalificarse, ni editarse por un cambio de reglas o una actualización de software posterior. Los casos resueltos de ayer permanecen resueltos, así que un cambio en las reglas de hoy nunca puede reabrirlos.

La fuerza de esta garantía es la fuerza de ese registro: un veredicto queda protegido una vez que se finaliza en cadena, que es por qué los anclajes de liquidación se escriben para confirmar en lugar de disparar y olvidar.

Hoy estas protecciones están aplicadas por la aplicación — la lógica de aprobación y liquidación que ejecutamos — así que la afirmación precisa es que ningún voto puede eliminarlas, no que sean físicamente inamovibles. Congelar esa lógica en código en cadena es lo siguiente en la hoja de ruta, y aquí está todo el arco: