Avalanche, poder de los stakers y Tonalli Core

Una discusión pública sobre quién controla los distintos descendientes de Bitcoin llevó a una pregunta más concreta: si los Avalanche stakers de eCash cambian de implementación, ¿puede cambiar el poder de coordinación de la red en segundos y sin producir una división persistente de la cadena?

La respuesta exploratoria es sí, pero dentro de límites técnicos precisos. Los stakers eligen qué software ejecutar. Ese software valida localmente los candidatos y participa en el polling de Avalanche. Cuando existen bloques o transacciones válidos en conflicto, el protocolo ponderado por stake converge rápidamente sobre la opción que será finalizada. Sin embargo, Avalanche no contiene una urna que elija nombres de proyectos, repositorios o equipos.

1. Qué decide Avalanche en eCash

eCash combina el consenso Nakamoto basado en Proof of Work con Avalanche. La documentación oficial distingue dos funciones complementarias. Post-Consensus, activo desde 2022, permite que los nodos alcancen acuerdo sobre bloques observados y bloqueen la punta válida de la cadena, reduciendo la posibilidad de reorganizaciones. Pre-Consensus, activado el 15 de noviembre de 2025, extiende esa coordinación a transacciones antes de su inclusión en un bloque y ofrece finalización aproximada de dos a tres segundos.

La propia portada técnica de eCash resume el efecto de Post-Consensus de manera directa: un bloque finalizado queda fijado como punta válida y no puede retirarse después. También explica que la red de nodos participantes está ponderada por la cantidad de XEC comprometida en sus pruebas de stake y que Avalanche selecciona la cadena sobre la que los mineros construirán.

La secuencia conceptual puede representarse así:

Hay una frontera que no debe perderse: la explicación protocolaria publicada por eCash establece que los elementos sometidos a votación deben cumplir primero las reglas de consenso. Avalanche ayuda a resolver conflictos entre opciones válidas; no transforma por mayoría de stake un bloque inválido en válido para un nodo que aplica reglas incompatibles.

2. Dónde entra la elección del software

Bitcoin ABC es actualmente la implementación de nodo completo que desarrolla y publica el software de eCash. Un operador puede descargarlo, auditarlo, modificarlo o construir otra implementación, porque el código es abierto. Pero para permanecer dentro de la misma red, una alternativa debe reproducir correctamente las reglas de consenso, la validación, los mensajes de Avalanche y el comportamiento esperado frente a los mismos datos.

Si un conjunto de stakers migra hacia otra implementación compatible, su stake no desaparece: esos operadores siguen participando en el quorum desde el software que eligieron. Si esa implementación expresa una preferencia distinta ante un conflicto que continúa siendo válido bajo las reglas compartidas y alcanza mayoría ponderada, el resultado de Avalanche puede reflejar ese cambio con rapidez.

Ése es el sentido defendible de la metáfora de “contratar” o “despedir” una implementación: los operadores pueden retirar adopción, infraestructura y stake a un proveedor de software y trasladarlos a otro. El poder no cambia por una resolución corporativa; cambia porque la red corre otro código compatible.

Lo que esta capacidad no significa

• No existe una votación protocolaria llamada “Bitcoin ABC vs. Tonalli Core”.
• Una mayoría de stake no convierte automáticamente reglas incompatibles en una actualización aceptada por todos.
• Los cambios obligatorios de consenso siguen requiriendo coordinación de versiones. La actualización de mayo de 2026, por ejemplo, exigió a los operadores pasar a Bitcoin ABC 0.33 o posterior para conservar sincronía.
• Una segunda implementación no produce descentralización por existir: necesita compatibilidad, reproducción independiente, operadores reales y mantenimiento sostenido.

Por eso la frase “el poder cambia en segundos” debe aplicarse al consenso vivo sobre el estado válido, no a una supuesta facultad instantánea para reescribir el protocolo.

3. Por qué una implementación alternativa sigue importando

Aun con esa precisión, la diversidad de software tiene valor estratégico. Una red con una sola implementación dominante concentra conocimiento, procesos de release, interpretación de especificaciones y capacidad de respuesta ante fallos. Otra implementación compatible puede funcionar como verificador independiente, revelar supuestos no documentados, reducir monocultura y ofrecer a los operadores una salida creíble.

eCash añade un elemento distintivo: los operadores de nodos Avalanche no son observadores pasivos. Participan en la finalización rápida. Si en el futuro pueden elegir entre implementaciones maduras y compatibles, la posibilidad de migrar stake e infraestructura tendría consecuencias operativas reales sobre la coordinación de la red.

Pero ése es precisamente el punto en el que una narrativa atractiva debe someterse a evidencia. Una implementación alternativa necesita pruebas diferenciales, fixtures de consenso, reproducibilidad, compatibilidad con Avalanche, manejo correcto de reorgs, actualizaciones coordinadas y una historia verificable de mantenimiento. Sin eso, “alternativa” es solo una etiqueta.

4. Tonalli Core: horizonte público y distinción interna

xolosArmy Network ha comenzado a utilizar públicamente el nombre Tonalli Core para describir el horizonte de una futura implementación alternativa de nodo eCash. El objetivo no sería crear una moneda rival ni forzar una división, sino ofrecer a los Avalanche stakers otra base de software compatible que puedan elegir.

El roadmap canónico obliga, sin embargo, a distinguir ese horizonte de dos repositorios actuales:

Esta diferencia es más que semántica. En el roadmap estratégico, tonalli-core define el idioma contractual del ecosistema; Tonalli Wallet conserva la autoridad criptográfica; y la investigación de infraestructura profunda —fork de Bitcoin ABC, futuro nodo y Tonalli Shield— aparece al final de la secuencia. El nodo alternativo no debe anunciarse como ya construido solo porque existe un paquete llamado tonalli-core.

El horizonte Tonalli Core se encuentra, por tanto, en una fase anterior a la ingeniería de una implementación independiente: primero debe demostrarse que el fork de Bitcoin ABC puede mantenerse sincronizado y reproducible, después definir el alcance del delta, y finalmente construir compatibilidad y pruebas suficientes para que un staker pueda usarlo sin aceptar garantías inventadas.

5. Lo que el roadmap dice que está ocurriendo hoy

La hoja maestra xolosArmy Network — Roadmap Status no es un tablero promocional. Separa estrategia, estado operativo y evidencia. Al último corte disponible registra 22 proyectos: cinco activos, tres bloqueados, uno en revisión, uno congelado, siete planeados, dos en mantenimiento, dos en investigación y uno en preingeniería. Ninguno aparece como COMPLETE.

La prioridad de ingeniería continúa siendo RMZWallet / Tonalli Wallet, porque funciona como raíz de autoridad criptográfica para Memo, agentes, x402 y Commerce Relay. Su estado al corte es REVIEW / CONDITIONAL. La infraestructura profunda de nodo permanece en investigación y no debe quitar foco al cierre de los gates de autorización, recuperación durable y separación entre firma y broadcast.

El corte diario ocurre a las 18:00, hora de Ciudad de México. La regla central es sencilla: progreso narrado sin HEAD exacto, PR, prueba, gate, documento o artefacto observable no cuenta como hito cerrado.

6. Se crea una subpágina pública del roadmap

xolosArmy Network anuncia la creación de xolosarmy.xyz/roadmap, una subpágina destinada a mostrar al público el estado sanitizado del roadmap, sus dependencias, gates y evidencia confirmable. La página no expondrá la hoja maestra privada ni la consumirá directamente.

La arquitectura prevista establece una frontera fail-closed:

Cada snapshot público podrá incluir referencias como repositorio, rama o PR, HEAD, tree, hash del artefacto, pruebas y resultado del gate. Un lector podrá comprobar que el estado mostrado corresponde a un objeto exacto del repositorio y no a una descripción mutable.

Qué prueba un hash —y qué no

Un hash puede vincular una afirmación con bytes exactos. Si cambia el archivo, el árbol o el patch, cambia la huella. Esto permite detectar sustituciones, reconstruir el objeto revisado y comparar si el código visible es el mismo que recibió una prueba o auditoría.

Pero un hash no demuestra por sí solo que el código sea correcto, seguro, remoto, mergeado o desplegado. Tampoco convierte una prueba verde en equivalencia de consenso. Por eso la página separará campos como Status, Security Status, HEAD, Active PR, Current Gate, Blocker y Evidence.

7. El primer contrato público fue sometido a una prueba adversarial

La subpágina todavía no está desplegada. Antes de conectar la hoja privada, xolosArmy diseñó un contrato de salida pública y lo sometió a revisiones independientes. El candidato más reciente quedó fijado por tres identificadores deterministas:

La revisión comprobó 22 de 22 archivos, obtuvo 64 de 64 pruebas verdes, pasó git diff --check y validó el esquema con AJV 8.17.1 bajo Draft 2020-12. Aun así, el gate no cerró.

Este resultado ilustra el propósito de la futura subpágina mejor que un lanzamiento apresurado: 64 pruebas verdes no vencen un finding material en la frontera de divulgación. La huella criptográfica identifica con exactitud el candidato rechazado; el veredicto impide confundirlo con uno aceptado.

8. Hipótesis abiertas de esta investigación

El trabajo exploratorio deja preguntas que deberán resolverse antes de que Tonalli Core pueda describirse como una alternativa real para stakers:

1. ¿Puede una implementación independiente reproducir todas las reglas de consenso y el comportamiento de Avalanche sin depender de supuestos implícitos de Bitcoin ABC?
2. ¿Qué suite diferencial permite detectar divergencias antes de que lleguen a mainnet?
3. ¿Cómo se actualiza una segunda implementación durante la cadencia semestral sin crear una cadena accidental?
4. ¿Qué porcentaje de stake y qué diversidad de operadores constituirían una salida creíble, no meramente nominal?
5. ¿Cómo se demuestra que una decisión de Avalanche fue observada de la misma forma por implementaciones distintas?
6. ¿Qué claims pueden publicarse automáticamente sin filtrar información interna ni permitir autoatestación narrativa?

La subpágina pública no responderá esas preguntas por decreto. Su función será mostrar qué evidencia existe, qué gate sigue abierto y qué objeto exacto fue revisado.

Conclusión: poder verificable, no poder proclamado

La arquitectura híbrida de eCash ofrece algo que otros descendientes de Bitcoin no tienen en la misma forma: stakers que ejecutan nodos y participan directamente en una convergencia rápida sobre transacciones y bloques válidos. Esa capacidad permite que una migración de operadores hacia otra implementación compatible tenga consecuencias reales en la coordinación de la red.

Sin embargo, la implementación alternativa no nace del slogan. Requiere equivalencia demostrada, reproducibilidad, mantenimiento y adopción. El roadmap de xolosArmy coloca correctamente esa ambición detrás de gates más inmediatos: estabilizar contratos, cerrar la autoridad de Tonalli Wallet, madurar regtest y verificar una base de nodo sincronizada.