# Cómo leer los proxies de BotRadix

> Seguir facetas, rutas modulares, CrossMargin y controles de negocio sin asumir EIP-1967.

Source: https://docs.botradix.com/es/proxies/

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](https://docs.botradix.com/es/security-contracts/), 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:

```text
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.

1. Consulta `BUSINESS_CONTROL()` en el anfitrión.
2. En el control devuelto, consulta `current()`, `revision()` e `isSealed()` para conocer la lógica, su revisión y el sello de esa vía.
3. 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.
4. Cuando el anfitrión exponga el registro modular, consulta también `moduleRegistryInfo()` y `moduleRoute(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](https://docs.botradix.com/es/security-contracts/) para interpretar OPEN, los límites de AvisoPrevio y el sellado por partes, y [Compilación reproducible](https://docs.botradix.com/es/reproducible-build/) para relacionar fuentes y bytecode.