Seguridad y contratos

Esta página explica quién puede cambiar los contratos, cómo se tramitan esos cambios y qué límites tiene la salida del DEX. Consulta también Salir sin la web, Cómo leer los proxies de BotRadix y Compilación reproducible.

Estado de referencia#

Referencia: 11 de octubre de 2026. Los contratos v2.2 están activos; los componentes administrables siguen OPEN, sin sellado. El administrador del router es AvisoPrevio, 0x3a3273Df1c640D2625Bcc0f378Fc571D371f0dEd. Los avisos de código y operaciones y el suelo comprometido son de 0 horas. Existen claves de solo pausa.

Publicación del código: está prevista conjuntamente en BaseScan cerca del cierre, antes del sellado. Los enlaces de direcciones de esta página no implican que el código ya esté verificado.

Fondos, permisos y riesgos#

El colateral se registra en CrossMargin a nombre de tu wallet. Con el código descrito, las retiradas de usuario requieren la autorización correspondiente de la wallet y se pagan a su titular; una clave de trading o de sesión no tiene permiso de retiro. Eso no convierte el sistema en una garantía de custodia absoluta: las direcciones que mantienen el estado pueden conservarse mientras se sustituye la lógica que aplica esos permisos.

Mientras una pieza siga OPEN, su autoridad puede cambiar código, rutas, parámetros o dependencias dentro de sus mecanismos de actualización. Los poderes incluyen configurar mercados y reporters, pausar, declarar una emergencia y retirar liquidez libre del vault bajo las comprobaciones del código vigente. Una dirección estable o una firma de usuario no eliminan el riesgo de administración, de errores, de oráculo, de liquidación o de falta de liquidez.

La puerta de aviso previo#

AvisoPrevio es un contrato sin proxy que tramita llamadas de administración mediante execute(target, data, salt). Su ADMIN() es el coordinador autorizado por la administración de BotRadix. La existencia de la puerta no convierte esa autoridad en una administración descentralizada o multifirma.

La puerta clasifica cada llamada por destino, función y, cuando corresponde, argumentos. classify() permite consultar esa clase; delays() devuelve los avisos vigentes y el suelo mínimo.

Con un aviso positivo, la administración programa los datos exactos con schedule(). El identificador vincula destino, datos y sal. execute() comprueba el aviso vigente al ejecutar, por lo que una subida también protege operaciones pendientes. La ventana de ejecución dura 14 días desde que la operación queda lista. operationState() permite consultar sus fechas y estado; los eventos registran programación, ejecución y cancelación. Con aviso cero se puede ejecutar sin una programación previa: no hay un plazo obligatorio para reaccionar.

raiseDelay() solo sube avisos y lo hace inmediatamente. lowerDelay() debe pasar por la propia puerta y esperar el mayor aviso vigente entre los que reduce. commitMinimumDelay() eleva un suelo que ya no se puede bajar. Estas reglas no hacen que toda actualización del sistema tenga que pasar por la puerta.

Lo que la puerta no retiene#

La sustitución de la implementación del proxy de CrossMargin y de las lógicas de negocio dispone de caminos de autoridad propios, ligados al coordinador. Mientras estén abiertos, la puerta no impone por sí sola una espera a esos caminos. Tampoco retrasa la actuación directa de las claves autorizadas exclusivamente para pausar.

announce() deja el evento público CambioAnunciado para un cambio que la puerta no puede retener. No ejecuta el cambio ni bloquea su ejecución antes de una fecha. Un anuncio operativo no equivale a un periodo de espera exigido por el contrato. Para evaluar una protección hay que comprobar la autoridad y el ciclo de vida de cada pieza, además de la puerta.

Pausadores y reanudación#

El mecanismo admite hasta ocho claves de solo pausa. Pueden activar pausa, solo reducir, parada del trading o pausa de retiros; ese permiso no permite reanudar, actualizar contratos ni retirar fondos de usuarios. Reanudar corresponde a la administración y se clasifica como operación en la puerta.

En el mecanismo v2.2, la pausa de retiros de CrossMargin caduca a las 72 horas, requiere 24 horas sin pausa antes de la siguiente y no se aplica durante una emergencia confirmada. Se puede consultar su estado efectivo y vencimiento. La pausa no garantiza un cobro al vencer: siguen contando las posiciones, órdenes, deudas, precios y liquidez. Las restricciones a nuevas aperturas no sustituyen los controles de cierre y liquidación. Mientras el código sea actualizable, también pueden cambiar estas reglas.

Sellado por partes#

Un sellado afecta a una pieza y a sus permisos concretos. Sellar el router no sella automáticamente CrossMargin, el hub del oráculo, sus reporters ni la automatización. Tampoco basta con un indicador sealed: hay que revisar si quedan rutas modulares actualizables, autoridades con aviso y parámetros modificables bajo sus límites.

El plan consiste en comprobar y cerrar por separado las superficies de actualización, publicar el código y su receta de compilación y documentar, para cada pieza, qué queda fijo y qué sigue administrable. Un cierre total y un cierre que conserve cambios mediante una puerta con aviso ofrecen permisos distintos; se deberá indicar el perfil aplicado. Las pausas, los parámetros permitidos y los riesgos externos no desaparecen por sellar código.

Condición pendiente en la referencia indicada: antes de subir el aviso o sellar deben corregirse y volver a probarse dos hallazgos de la revisión interna sobre gobierno. No se presenta ese sellado futuro como una protección ya disponible.

Revisiones realizadas y sus límites#

Se ha realizado revisión interna, no auditoría externa. El trabajo documentado incluye lectura de caminos de fondos y permisos, pruebas de contratos e invariantes, ensayos de actualización y vuelta atrás, revisión de salida y emergencia, y comprobaciones de compilación y de correspondencia entre fuentes y artefactos. Cada comprobación cubre su versión y sus escenarios, no todos los estados posibles.

La revisión final de los caminos del dinero y la revisión de textos para la publicación son trabajos distintos. Revisar comentarios no añade una revisión de seguridad independiente. Los hallazgos pendientes anteriores siguen siendo una condición para el sellado; ni las pruebas ni la verificación de código en un explorador garantizan ausencia de fallos.

Estado de auditoría en la referencia indicada: no se ha publicado una auditoría externa. No se atribuye a estos contratos una certificación de seguridad.

Direcciones oficiales#

Todas las direcciones siguientes corresponden a Base mainnet, chain ID 8453. Se contrastan con el mapa de despliegue v2.2 y el manifiesto público de la referencia indicada. Un inventario es una instantánea: las implementaciones y rutas pueden cambiar mientras estén abiertas. Comprueba la dirección completa y distingue los puntos de entrada de sus implementaciones; no envíes tokens directamente a una faceta o módulo.

Puntos de entrada y control#

Inventario de las 57 piezas de la entrega v2.2#

Son las 54 piezas del mapa v2.2 más Salida, AvisoPrevio y su fábrica. Las direcciones de lógica no son puntos de depósito.

Salida y aviso#

Despacho y administración modular#

Facetas del router#

Componentes del DEX#

Módulos y parámetros del router#

Margen cruzado#

Lógicas, extensión y políticas de negocio#

Facetas conservadas en el despliegue#

El manifiesto también mantiene estas piezas anteriores, fuera de las 57 de la entrega. Se incluyen para poder seguir las rutas completas.

Contacto y textos relacionados#

Comunica problemas de seguridad a support@botradix.com, con el asunto Security, la red, la dirección afectada y los pasos para reproducir el problema. Incluye solo información necesaria para investigarlo; nunca claves privadas, frases semilla ni credenciales.

Consulta los Términos, secciones 21–26, sobre protocolo, salida, poderes administrativos, pagos diferidos, parámetros y vuelta atrás, y la página de Riesgos. Esta explicación del mecanismo no elimina esos riesgos.