Los proxies y el router de BotRadix no usan EIP-1967. El router tampoco ofrece el loupe de EIP-2535. Que un explorador no detecte un proxy, o que una ranura estándar esté vacía, no demuestra que la lógica sea fija. Hay que seguir las lecturas propias de cada familia.
Dirección, estado y lógica#
El anfitrión o proxy conserva su dirección y estado. Al delegar una función, ejecuta código de otra dirección sobre ese estado. Una implementación puede cambiar sin trasladar los fondos ni cambiar la dirección que ve el usuario.
Para reconstruir una ruta, parte de las direcciones oficiales, identifica el selector de la función y consulta los contratos en el mismo bloque. Conserva número y hash del bloque, direcciones, revisiones y hashes de código: mezclar lecturas anteriores y posteriores a una actualización puede producir una ruta que nunca existió.
Una ABI de implementación ayuda a interpretar las funciones delegadas, pero las lecturas de estado y las transacciones de usuario corresponden al anfitrión. Llamar directamente a una implementación puede revertir o leer un estado distinto. Las lecturas de identidad que se indican expresamente sobre la implementación son una excepción.
Router: facetas, núcleo de despacho y módulos#
El router combina una tabla del anfitrión, extensiones y un núcleo de despacho que puede dar prioridad al registro modular. Una faceta es una pieza de lógica a la que se dirige una función.
| Lectura | Qué permite comprobar |
|---|---|
routerLifecycle() en el router | Preparación, sello de configuración, época, manifiesto y propuesta pendiente |
getFacetManifest() en el router | Las 17 facetas del manifiesto y sus hashes de código |
facetForSelector(bytes4) en el router | La ruta del anfitrión para ese selector; por sí sola no refleja una sustitución del registro |
dispatchLifecycle() en el router | Dirección, hash de código, revisión y propuesta del núcleo de despacho |
moduleRegistryInfo() en el router | Modo de búsqueda, época, manifiesto, congelación, aviso y tamaño del registro |
moduleRoute(bytes4) en el router | Destino efectivo reportado para ese selector, identidad, revisión y origen de la ruta |
TRADE_FACET() y después dexModule(0..12) sobre esa faceta | Componentes internos del DEX a los que delega la faceta de trading |
Con un núcleo que habilite el registro, una ruta modular puede tener prioridad sobre la ruta del anfitrión. En moduleRoute(), el origen 1 indica ruta fija o extensión, 2 registro y 3 registro que sustituye una ruta fija; 0 indica que no hay ruta efectiva. Un selector nuevo puede apuntar en la tabla del anfitrión al hub: ese hub revierte si no existe la ruta modular necesaria. Un núcleo que ignore el registro cambia esa interpretación; por eso se consulta también dispatchLifecycle() y el modo de búsqueda.
Los eventos DexExtensionInstalled ayudan a reconstruir cambios de extensiones, pero un evento histórico no acredita la ruta vigente. Contrástalo con las lecturas del bloque elegido. Comprobar solo las 17 facetas deja fuera extensiones y sustituciones modulares.
CrossMargin: ranura propia y módulos#
En el proxy de CrossMargin, implementation() devuelve la lógica y lifecycle() muestra el sello, propuesta, revisiones y hashes. La raíz de almacenamiento de su ciclo de vida es:
bytes32(uint256(keccak256("botradix.cross.proxy.v1")) - 1)Se trata de Keccak-256 de Ethereum, no de SHA3-256. No es la ranura EIP-1967. El primer campo es la dirección de implementación; comparte una palabra con el booleano de sellado, por lo que no se debe interpretar toda la palabra como una dirección. Es preferible usar las funciones de lectura.
Después consulta implementationModules() en la dirección de implementación devuelta, para identificar sus ocho piezas internas. Las consultas de cuenta siguen haciéndose al proxy. Consulta además moduleRegistryInfo() y moduleRoute(selector) sobre el proxy para distinguir esas piezas de las rutas del registro modular. Sellar el proxy y congelar todas las rutas o parámetros son cuestiones diferentes.
Proxies de negocio: control separado#
El hub del oráculo (PairForge), Registry, Automation y el adaptador de Uniswap usan un contrato de control separado. La misma familia se emplea en otras piezas de negocio, como CrossVerifier.
- Consulta
BUSINESS_CONTROL()en el anfitrión. - En el control devuelto, consulta
current(),revision()eisSealed()para conocer la lógica, su revisión y el sello de esa vía. - Consulta
openPolicyLifecycle()en el anfitrión para la política de actualización correspondiente. Una política y la lógica de negocio no son la misma pieza. - Cuando el anfitrión exponga el registro modular, consulta también
moduleRegistryInfo()ymoduleRoute(selector)en él. La lógica principal por sí sola no describe todas las funciones.
Ejemplo de referencia#
Instantánea documental: 11 de octubre de 2026. Estas relaciones sirven para orientarse, no sustituyen una lectura actual:
| Punto de partida | Lectura | Resultado en la referencia |
|---|---|---|
Router 0x740E207d90ec9D82fce040F8DA0268dB761F364E | dispatchLifecycle() | BotradixDispatchKernelV2 0x95DC9EFbff26Acb8B9509d68dd73E712c4541093 |
CrossMargin 0x79ED1002F842DE2A9E25d353F2627206483b2b3B | implementation() | BotradixCrossMargin 0xc1030c90C644Df556c5fe311601B55B84387f6d7 |
PairForge 0x55Ec5A8DFEb6ab71BCAE98D833b4E1d96a6c871C | BUSINESS_CONTROL() | Control 0x255DdF4313FC5D547c3925748f30A8008676551f |
| Ese control de PairForge | current() | BotradixPairForgeLogic 0x0744e9a3f4ad391414FA2d1443de2259bB1620e6 |
Qué acredita una verificación#
Verificar el código de un anfitrión no verifica automáticamente sus implementaciones, módulos, políticas o controles. Una ABI combinada tampoco prueba qué ruta estaba activa en un bloque. Para una comprobación completa se relacionan dirección, bytecode, fuentes reproducibles, rutas, autoridades y sellos de cada pieza.
Estado de publicación en la referencia indicada: el código se publicará conjuntamente en BaseScan cerca del cierre. No se presupone que ya existan botones de lectura o escritura para todas las funciones. El mecanismo anterior también puede inspeccionarse con herramientas que dispongan de las ABI correctas, sin enviar transacciones.
Lee Seguridad y contratos para interpretar OPEN, los límites de AvisoPrevio y el sellado por partes, y Compilación reproducible para relacionar fuentes y bytecode.