El debate importante no es si una sidechain necesita smart contracts. Es quién autoriza el regreso del valor a la capa base, bajo qué reglas y con qué evidencia. Ahí se decide el verdadero modelo de seguridad.
Las discusiones sobre drivechains suelen comenzar por su atractivo: extender una red tipo Bitcoin sin convertir la capa base en una máquina general de contratos. Eso es correcto, pero incompleto. El problema realmente difícil aparece cuando los fondos deben volver.
En BIP-300, ese regreso se resuelve mediante un hashrate escrow. Los retiros de la L2 a la L1 no dependen de una federación fija ni de un smart contract estilo Ethereum: dependen de señalización de prueba de trabajo. El diseño exige que un bundle de retiro acumule al menos 13,150 ACKs, mientras dispone de una ventana de 26,300 bloques. El propio documento describe el proceso como deliberadamente lento y sitúa la votación del bundle en un horizonte de 3 a 6 meses.
Eso no significa que cada usuario de una drivechain deba permanecer inmóvil durante meses. El mismo BIP contempla que, una vez establecido el bridge, puedan existir swaps que den liquidez inmediata y que BIP-300 quede como capa de liquidación final. La distinción es crucial: liquidez de mercado y liquidación protocolaria no son la misma cosa.
El reverse peg es la frontera de confianza
Mover valor de L1 hacia una segunda capa suele ser conceptualmente más sencillo: la capa base bloquea o compromete fondos y la otra red reconoce ese hecho. Volver es distinto. La L1 necesita una razón verificable para aceptar que cierta salida es legítima.
En BIP-300, esa razón es una historia prolongada de ACKs de mineros. El modelo no es una custodia tradicional, pero sí deposita una parte central de su seguridad en la conducta agregada del hashpower durante una ventana extensa. Ésa es su elección de diseño.
eCash parte de otra arquitectura. La red mantiene Nakamoto consensus y añade Avalanche como una segunda capa de consenso. Desde noviembre de 2025, Avalanche Pre-Consensus permite finalidad de transacciones en menos de tres segundos; documentación posterior de eCash suele resumirla alrededor de dos segundos. Ese hecho ya está en producción sobre la capa base.
Además, el roadmap público de eCash mantiene una EVM Subnet y una Zero-Knowledge Subnet como proyectos en Planning. La portada tecnológica de eCash describe las subnets como redes personalizables y permissionless impulsadas por su tecnología Avalanche.
También existe desde hace años una motivación pública muy concreta: usar Avalanche para abordar mejor el problema del reverse peg que ha limitado a sidechains y drivechains en arquitecturas tipo Bitcoin. Esa intención importa, pero una intención de arquitectura no es todavía una especificación de bridge.
Tres segundos no responden la pregunta del bridge
Aquí aparece la confusión más peligrosa. Si eCash finaliza una transacción L1 en dos o tres segundos, es tentador concluir que una salida de una futura subnet debería tardar lo mismo. No podemos afirmarlo.
La finalidad de L1 responde una pregunta: ¿la red eCash ya decidió que esta transacción es válida y final? Un bridge responde otra: ¿qué evidencia debe presentar una segunda máquina de estados para que la L1 acepte un cambio de custodia o desbloqueo asociado con esa red?
Ese bridge puede aprovechar Avalanche y puede terminar siendo radicalmente más rápido que BIP-300. También puede imponer reglas propias, checkpoints, umbrales, pruebas criptográficas o mecanismos que hoy no conocemos. Mientras la especificación no sea pública, asignarle “segundos”, “minutos” u “horas” es convertir un hueco documental en una garantía inventada.
| Propiedad | BIP-300 Drivechain | Futura subnet eCash |
|---|---|---|
| L1 | Nakamoto PoW de Bitcoin. | Nakamoto PoW + Avalanche en eCash. |
| Reglas de L2 | Pueden diferir de la capa base. | El objetivo declarado es permitir redes personalizables. |
| Reverse peg | Bundles gobernados por ACKs de hashpower. | La arquitectura pública apunta a aprovechar Avalanche, pero el mecanismo final no está especificado públicamente. |
| Latencia de liquidación | El BIP define una ventana prolongada; los bundles se ACKean durante 3–6 meses. | Desconocida hasta que exista especificación verificable. |
| Smart contracts en L1 | No son el mecanismo de seguridad del peg. | No debemos presuponer que sean necesarios para el bridge. |
Lo que esto cambia para Tonalli Shield
Para Tonalli Shield, esta diferencia no es académica. Shield investiga una superficie privada y verificable alrededor del ecosistema eCash. Si en el futuro una subnet ZK se convierte en infraestructura real, podría ser una pieza natural a evaluar. Pero diseñar Shield hoy como si esa subnet ya existiera, como si su bridge ya tuviera propiedades conocidas o como si una prueba ZK resolviera automáticamente la custodia sería exactamente el tipo de salto que el proyecto debe evitar.
El expediente público de Tonalli Shield mantiene el trabajo en PRE-ENGINEERING, con mainnet y fondos reales fuera de alcance y con sus decisiones de arquitectura todavía propuestas. Esa cautela cobra más sentido frente a las subnets: Shield debe poder incorporar una tecnología futura sin depender hoy de propiedades que todavía no han sido demostradas.
La regla que proponemos es sencilla: cada afirmación relevante debe entrar a uno de tres estados.
Existe especificación, implementación o evidencia reproducible. Ejemplo: finalidad L1 de eCash mediante Pre-Consensus.
Existe una dirección pública de arquitectura, pero no una capacidad desplegada. Ejemplo: EVM Subnet y ZK Subnet en el roadmap.
No hay base suficiente para asignar una propiedad. Ejemplo: tiempo exacto del reverse peg de una subnet futura.
Tonalli Shield debería rechazar cualquier transición de PROPUESTO o DESCONOCIDO a CONFIRMADO que no venga acompañada por evidencia. No basta una presentación, una inferencia por analogía o una cifra que “suena razonable”.
La consecuencia arquitectónica: Shield debe ser subnet-agnostic mientras no exista una interfaz verificable. La verdad de L1 sigue perteneciendo al nodo eCash; la autoridad de gasto sigue perteneciendo a la wallet; y cualquier futura subnet deberá aportar pruebas y reglas explícitas antes de convertirse en una dependencia de seguridad.
La velocidad importa; el modelo de evidencia importa más
La comparación con drivechains ayuda precisamente porque evita un argumento superficial. BIP-300 no es “malo” por ser lento: su lentitud es parte de la defensa que eligió para un sistema donde el hashpower gobierna la salida. El costo es capital menos eficiente y una dependencia fuerte de ese proceso de señalización. A cambio, evita una federación fija y mantiene una filosofía muy cercana a Bitcoin.
eCash tiene la oportunidad de construir otra respuesta porque dispone de Avalanche como mecanismo de coordinación adicional. Si esa ventaja se extiende correctamente al reverse peg, podría reducir de forma drástica la fricción que históricamente ha acompañado a las sidechains tipo Bitcoin. Pero la ventaja real no será poder escribir “2 segundos” en una gráfica. Será poder describir con precisión quién valida, qué se vota, qué se prueba, qué se finaliza y bajo qué condición la L1 libera valor.
Ése es también el estándar que debe perseguir Tonalli Shield. Una arquitectura de privacidad no se vuelve segura por llamarse ZK, subnet o Avalanche. Se vuelve defendible cuando sus fronteras de autoridad pueden señalarse, sus supuestos pueden enumerarse y sus fallos pueden reproducirse sin poner fondos reales en riesgo.
Una buena arquitectura sabe decir “todavía no sabemos”
En criptografía aplicada y sistemas monetarios, admitir una incógnita es una propiedad, no una debilidad. Permite que el diseño conserve espacio para aprender sin convertir cada expectativa en deuda técnica.
Hoy sabemos que eCash ya tiene finalidad L1 en segundos. Sabemos que las subnets EVM y ZK están en el roadmap. Sabemos que Avalanche fue concebido como una pieza para mejorar la extensibilidad y enfrentar el reverse peg. Y sabemos cómo BIP-300 elige resolver ese problema mediante hashpower y una ventana deliberadamente larga.
Lo que todavía no sabemos públicamente es la especificación final del bridge de las subnets de eCash. Por eso tampoco sabemos su latencia exacta de salida.
Mi conclusión para Tonalli Shield es simple: no diseñar alrededor de una cifra. Diseñar alrededor de una frontera de confianza. Cuando llegue la subnet, que entre por evidencia.