Las cadenas compatibles L3 de ADI Chain son Rollups de conocimiento cero de capa 3 que se liquidan en ADI Chain (L2), mientras que L2 se liquida en la red principal de Ethereum (L1). Las instituciones pueden operar cadenas independientes según la jurisdicción o la línea de negocio y definir políticas de cumplimiento adaptadas. De acuerdo con el modelo de seguridad dual descrito en el resumen de ADI Chain, L3 hereda garantías criptográficas tanto de L2 como de L1, aislando los entornos de ejecución y los dominios de cumplimiento del estado compartido de L2.
Para gobiernos, bancos y consorcios industriales, L3 permite "un ecosistema, reglas diferentes": los activos regulados circulan en cadenas dedicadas, las aplicaciones abiertas funcionan en otra L3 o en L2, y todas las capas se interconectan mediante el puente de L2.
ADI Chain utiliza una jerarquía de liquidación de tres niveles: L3→L2→L1. Las cadenas L3 ejecutan transacciones localmente y mantienen estados independientes; L2 (ADI Chain) verifica las pruebas de validez por lotes de L3 y almacena las raíces de estado de L3; L1 (Ethereum) verifica las pruebas por lotes de L2 y finaliza el estado global. Cada capa transmite seguridad hacia arriba mediante pruebas de validez de conocimiento cero, impidiendo que transiciones de estado inválidas sean aceptadas por una capa superior.
A diferencia del despliegue de DApps directamente en L2, L3 ofrece un aislamiento físico de ejecución: cada L3 tiene su propio Sequencer, Prover y contrato Diamond Proxy, cuyos estados no interfieren entre sí. Varias L3 pueden desplegarse en el mismo ecosistema, compartiendo contratos de infraestructura como Bridgehub (registro de cadenas) y StateTransitionManager (STM). ADI L2 alcanza un rendimiento aproximado de 2 000–10 000 TPS; la incorporación de múltiples L3 permite escalar aún más la capacidad por aplicación o jurisdicción.
| Capa | Ubicación de ejecución | Destino de envío de pruebas | Latencia típica de confirmación |
|---|---|---|---|
| Cadena L3 | Sequencer local de L3 | ADI Chain (L2) | Segundos (confirmación suave) |
| ADI Chain (L2) | Sequencer de L2 | Red principal de Ethereum (L1) | Minutos (confirmación L2) |
| Ethereum (L1) | Contratos verificador | Finalización de raíz de estado | Horas (finalidad L1) |
La tabla muestra que L3 no es una cadena pública independiente, sino un dominio de ejecución personalizable integrado en ADI L2 y Ethereum L1. ADI L2, como zkRollup, hereda la seguridad económica de Ethereum; L3 añade una capa adicional de cumplimiento institucional.
Figura 1. Posición de las cadenas compatibles ADI Chain L3 en la arquitectura por capas L3→L2→L1 y relación entre los componentes principales.
El ecosistema L3 despliega infraestructura compartida en la capa de liquidación L2 y contratos específicos de cadena y nodos operativos en cada L3. Bridgehub actúa como registro central, gestionando la correspondencia entre ID de cadena y direcciones de contrato, el enrutamiento de mensajes entre cadenas y la configuración a nivel de ecosistema. StateTransitionManager se encarga del registro de nuevas cadenas, las actualizaciones de protocolo y la gestión de parámetros de verificación compartidos. Cada cadena L3 cuenta con un contrato Diamond Proxy bajo el patrón Facet para actualizaciones modulares, gestionando el envío y verificación por lotes, almacenamiento de raíces de estado y administración de validadores.
En la operación de L3, cada cadena ejecuta un Sequencer, un Prover y un conjunto de billeteras Operator (responsables de Commit, Prove y Execute respectivamente). En L2, el Prover de L2 agrega transacciones nativas de L2 y liquidaciones de L3 en pruebas enviadas a L1. Validator Timelock impone un retraso entre Commit y Execute, permitiendo detectar anomalías.
El diseño Facet de Diamond Proxy permite actualizar de forma independiente la lógica de ejecución, consulta y gestión. La combinación de infraestructura de registro compartida en L2 con estado de ejecución aislado en cada L3 es una característica distintiva de ADI Chain frente al modelo general de L2 "una sola cadena, muchas aplicaciones"; en la comparación ADI Chain vs Arbitrum y Base, el soporte nativo de L3 y el modelo Bridgehub son diferenciadores clave.
ADI Chain L3 admite modelos gestionados por ADI, operados por el cliente y híbridos, cubriendo necesidades institucionales desde cero operaciones hasta control total.
| Modelo | Sequencer | Prover | Claves de contrato | Mejor para |
|---|---|---|---|---|
| Gestionado por ADI | Operado por ADI | Pruebas generadas por ADI | ADI mantiene claves de gobernanza y operación | Instituciones que buscan despliegue llave en mano sin carga de infraestructura |
| Operado por cliente | Cliente ejecuta nodos | Cliente opera nodos GPU de prueba | Claves transferidas a billeteras del cliente | Instituciones que requieren control total sobre operaciones y soberanía de datos |
| Híbrido | Cliente o ADI (configurable) | Cliente o ADI (configurable) | Gobernanza al cliente; operaciones pueden delegarse a ADI | Instituciones que buscan control de gobernanza con operaciones externalizadas opcionalmente |
El despliegue de contratos utiliza control de acceso basado en roles: Governor gestiona actualizaciones de protocolo, Admin gestiona acciones de emergencia, Operator ejecuta Commit por lotes, Prove Operator envía pruebas y Execute Operator ejecuta lotes verificados. La propiedad puede transferirse completamente a un multisig del cliente o entregarse en fases. El ecosistema L3 sigue un patrón de "desplegar una vez, añadir cadenas incrementalmente": Bridgehub y STM se despliegan una vez a nivel de ecosistema y nuevas cadenas L3 se incorporan como contratos independientes.
En modo operado por cliente, el Prover requiere GPU NVIDIA H100 o H200 (70–140 GB VRAM) y memoria del sistema de 64 GB o más; el Sequencer requiere al menos 8 núcleos de CPU, 32 GB de RAM y un endpoint público de transacciones. Las billeteras Operator deben tener $ADI tokens como gas de L2 para operaciones on-chain en Commit, Prove y Execute.
Cuando los lotes de L3 se liquidan en L2, pasan por Commit, Prove y Execute. El Sequencer empaqueta las transacciones de L3 en lotes; el Operator envía una transacción Commit a L2 que lleva diferencias de estado (cambios en slots de almacenamiento), información de despliegue de contratos y hashes de mensajes L2→L3—no instantáneas completas de estado—para reducir el coste de datos.
En la fase Prove, el Prover genera una prueba de validez utilizando el sistema Airbender (FRI/STARK → FFLONK SNARK pipeline), garantizando criptográficamente que las transiciones de estado cumplen las reglas de ejecución de L3. En la fase Execute, activada tras la verificación de la prueba en L2, la nueva raíz de estado de L3 se escribe en el contrato Diamond Proxy y el lote se marca como finalizado.
| Fase | Operator | Contenido enviado | Resultado en L2 |
|---|---|---|---|
| Commit | Operator | Diferencias de estado, info de despliegue, hashes de mensajes | Datos del lote on-chain, esperando prueba |
| Prove | Prove Operator | Prueba de validez ZK | Prueba verificada por contrato verificador |
| Execute | Execute Operator | Ejecutar lote verificado | Raíz de estado de L3 actualizada, lote finalizado |
Un ciclo completo de liquidación consume aproximadamente 747 000 Gas en total (Commit ~136 000, Prove ~494 000, Execute ~117 000), cada fase pagada en $ADI desde billeteras Operator. En producción, los Provers FRI y SNARK pueden ejecutarse en paralelo en particiones GPU separadas, mejorando el rendimiento de lotes en aproximadamente 15 %–20 %; un solo Prover en la configuración objetivo soporta unos 15–20 TPS.
Figura 2. Flujo desde el empaquetado de transacciones hasta Commit, Prove y Execute de liquidación en L2 para un lote L3.
La configuración recomendada de Prover es NVIDIA H200 (140 GB VRAM), con 2 Provers FRI en paralelo y 1 Prover SNARK dedicado (~33 GB VRAM). Las instituciones en modo operado por cliente deben planificar clústeres GPU y conexiones RPC L2 de baja latencia con antelación para mantener la cadencia de envío de lotes.
Los tipos de confirmación de transacciones L3 evolucionan a lo largo de L3→L2→L1 conforme avanza la liquidación. Tras incluir el Sequencer de L3 una transacción en un bloque, los usuarios reciben confirmación suave en segundos y pueden utilizar los activos transferidos de inmediato; la confirmación suave depende de la honestidad del Sequencer y aún no tiene finalidad criptográfica.
Tras el Commit de un lote L3 en L2, entra en la etapa de confirmación L2 (normalmente minutos). Una vez completados Prove y Execute en L2, la raíz de estado de L3 se escribe en el contrato de la cadena L2 y no puede revertirse. El Prover de L2 prueba el estado de L2—including liquidaciones de L3—a Ethereum L1; tras la confirmación por contratos verificador en L1, la cadena de liquidación completa alcanza finalidad L1 (normalmente horas).
Las liquidaciones grandes o los retiros entre cadenas deben esperar confirmación L2 o L1; las interacciones cotidianas pueden basarse en confirmación suave. Validator Timelock introduce un retraso configurable entre Commit y Execute, reservando tiempo para detección de anomalías.
L3 responde a la lógica de "aislamiento de reglas, seguridad compartida": los bancos operan vías soberanas de stablecoin, los gestores de activos despliegan contratos RWA con acceso KYC, y los gobiernos pueden tokenizar datos por jurisdicción. Los despliegues operados por cliente implican responsabilidad por clústeres GPU y listas blancas RPC; los gestionados por ADI trasladan operaciones a ADI.
Las cadenas compatibles L3 de ADI Chain utilizan una arquitectura ZK Rollup de tres capas (L3→L2→L1) para que las instituciones hereden la seguridad de Ethereum y obtengan dominios de ejecución independientes con reglas de cumplimiento adaptadas por jurisdicción. Bridgehub y StateTransitionManager proporcionan infraestructura de registro y actualización compartida; cada L3 mantiene aislamiento de estado mediante Diamond Proxy, un Sequencer y Prover independientes. Los lotes se liquidan en L2 mediante Commit, Prove y Execute; el sistema de pruebas Airbender y la infraestructura GPU (H100/H200) permiten la generación de pruebas de validez; la finalidad se propaga desde la confirmación suave de L3 hasta la finalidad criptográfica de L2 y L1. Los tres modelos de despliegue cubren diferentes necesidades operativas y de gobernanza, adecuados para stablecoins soberanas, RWA, pagos transfronterizos y tokenización de datos gubernamentales.
Un L3 es un ZK Rollup de capa 3 que se liquida en ADI Chain (L2), permitiendo a instituciones, gobiernos o consorcios industriales operar cadenas independientes por jurisdicción con políticas de cumplimiento personalizadas. Cada L3 tiene su propio Sequencer, Prover y contrato Diamond Proxy, hereda seguridad de doble capa vía L2 y Ethereum, y comparte infraestructura de registro Bridgehub con otras L3 del ecosistema.
ADI Chain funciona como un zkRollup de L2 en Ethereum; las transiciones de estado por lotes en L2 requieren que los contratos verificador de L1 validen pruebas ZK antes de la finalización. Las cadenas L3 se liquidan adicionalmente en ADI L2, formando una cadena de pruebas de validez de tres capas L3→L2→L1. Los activos pueden moverse entre L1, L2 y L3 mediante puentes, con el modelo de seguridad heredando la seguridad económica de Ethereum en cada nivel.
ADI Chain utiliza pruebas de validez ZK, por lo que el estado inválido no puede ser aceptado en L1; los lotes de L3 también deben pasar verificación L2 antes de la finalización. El Sequencer proporciona confirmación suave en segundos; la finalidad criptográfica requiere verificación de pruebas en L2 y L1. Usuarios e instituciones deben considerar riesgos residuales en contratos de puente, gestión de claves operativas, infraestructura GPU autogestionada de L3 y la ventana entre confirmación suave y finalidad L1.
ADI Chain L3 admite tres modelos: gestionado por ADI (ADI opera Sequencer, Prover y contratos), operado por cliente (la institución ejecuta nodos e infraestructura de pruebas GPU y mantiene las claves) y híbrido (la gobernanza permanece con el cliente, mientras que Sequencer y Prover pueden asignarse de forma flexible). La elección depende de cómo la institución equilibre carga operativa, soberanía de control y flexibilidad de cumplimiento.
El Sequencer de L3 empaqueta transacciones en lotes; el Operator envía diferencias de estado a L2; el Prover genera una prueba de validez ZK mediante el sistema Airbender y envía una transacción Prove; tras la verificación en L2, el Execute Operator activa la ejecución, escribiendo la raíz de estado de L3 en el contrato de cadena y finalizando el lote. Las tres fases consumen aproximadamente 747 000 Gas, pagados en $ADI.
Los entornos de producción requieren GPU NVIDIA H100 o H200 con al menos 70 GB VRAM (140 GB recomendados), 64 GB o más de memoria del sistema y almacenamiento NVMe SSD para datos de testigos. La configuración recomendada incluye 2 Provers FRI en paralelo y 1 Prover SNARK dedicado (~33 GB VRAM), apuntando a unos 15–20 TPS. El Sequencer requiere al menos 8 núcleos de CPU, 32 GB de RAM y un endpoint público de transacciones.





