Resumen: xolosArmy revisó técnicamente la rama starsquid/xec-client de THORNode. La conclusión es contundente: XEC entra como una cadena UTXO real dentro del stack compartido de THORChain, no como un string decorativo.
La rama todavía no significa aceptación oficial ni merge garantizado, pero sí representa desarrollo activo del lado THORChain. La tarea correcta ahora es validar, documentar, comparar y alinear Tonalli/Teyolia alrededor de la arquitectura que el upstream parece preferir.
La integración nativa de eCash (XEC) en THORChain acaba de cruzar una frontera importante. Hasta hace poco, la narrativa pública giraba alrededor del Draft MR de xolosArmy: una prueba de trabajo comunitaria que abrió la puerta técnica. Ahora el foco se movió hacia una rama del propio entorno THORChain, starsquid/xec-client, que implementa una versión más upstream-style de la integración.
La diferencia no es menor. El MR comunitario empujaba una integración amplia: cadena XEC, cliente UTXO, mocknet, Docker, wallet/regtest, tests y wiring de simulación. La rama de starsquid se ve más quirúrgica: mete XEC dentro del stack UTXO existente, trabaja precisión y conversión de montos, endurece fees, normaliza CashAddr, deja la configuración desactivada por defecto y agrega tests focalizados.
XEC entra al cliente UTXO compartido
El primer hallazgo importante aparece en el mecanismo de carga de chains. En la rama revisada, XEC entra junto con BTC, BCH, LTC, DOGE y ZEC dentro del cliente UTXO compartido. Eso significa que la cadena no se registra como un símbolo aislado, sino como parte del mismo camino técnico que THORNode usa para observar, construir y firmar transacciones UTXO.
También se observó que en la lógica de signing/building, XEC se trata como cadena no-SegWit junto con BCH, DOGE y ZEC, y usa una configuración propia para construir scripts de pago. Esa es una señal técnica clave: el branch no solamente declara XEC; lo conecta a paths reales de construcción de transacciones.
La contabilidad respeta la naturaleza de eCash
Uno de los riesgos más importantes de integrar XEC en software heredado de Bitcoin/BCH es la unidad base. En eCash, 1 XEC equivale a 100 base units. La rama revisada introduce una arquitectura de conversión que conserva precisión explícita para XEC de 2 decimales mientras mantiene compatibilidad con cadenas UTXO tradicionales de 8 decimales.
El test clave valida que 100 native base units de XEC se convierten correctamente a common.One dentro de la representación de THORChain y que los decimales de XEC se preservan como 2. También se revisó soporte para montos extremadamente grandes, incluyendo el caso de 20 trillones de XEC, donde la representación 1e8 puede exceder uint64 pero el monto nativo todavía se puede convertir correctamente al wire amount.
CashAddr se maneja por red y sin confundir BCH con XEC
El segundo bloque crítico es direcciones. En common/ecash.go, XEC define prefijos por red: ecash para MainNet/StageNet/ChainNet, ectest para TestNet y ecregtest para MockNet.
La decisión de diseño es que una dirección externa puede existir como ecash:q..., pero THORChain trabaja internamente con forma canónica sin prefijo. Esa normalización prefixless evita romper la gramática de memos, donde el carácter : ya tiene significado como separador.
Protecciones observadas
- Una bare BCH CashAddr no se clasifica como XEC.
- Una dirección bitcoincash: no pasa como XEC.
- Una dirección ecregtest: no pasa en mainnet.
- Una dirección ecash: no pasa en mocknet.
- Mixed-case se rechaza y uppercase completo se acepta bajo las reglas esperadas.
El candado contra THORName es una pieza clave
Uno de los hallazgos más importantes es la protección contra colisión con THORName. El problema es sutil: un memo con dirección XEC prefijada, como +:XEC.XEC:ecash:q..., puede partirse por el separador : y provocar que ecash se intente resolver como un THORName.
La rama agrega un bloqueo explícito en FetchAddress(): si la primera parte coincide con el prefijo reservado de XEC para la red actual, se devuelve error y se exige usar una dirección XEC sin prefijo dentro de memos.
Este candado es importante porque convierte un edge case peligroso en una regla explícita. No deja que una dirección mal formateada se transforme silenciosamente en una búsqueda de THORName.
XEC está apagado por defecto
Otro punto correcto desde la perspectiva upstream es que XEC aparece en la configuración, pero con disabled: true. Esto permite que el código exista, se revise y se pruebe sin activar la cadena hasta que haya decisión de red, infraestructura, endpoints, pruebas y configuración adecuada.
Esta decisión separa el merge técnico de la activación operativa. Para una integración de cadena nativa, esa separación es sana: primero el código, luego las pruebas, después la configuración, y solo al final la activación.
El único punto pendiente: DustThreshold
La revisión dejó un punto que conviene confirmar con starsquid: el valor de DustThreshold() para XEC parece representar aproximadamente un umbral económico de 100 XEC, mientras que el DustLimit() técnico parece compartir un valor más bajo de 546 native units.
Qué significa para Tonalli y Teyolia
La revisión también tiene consecuencias directas para Tonalli Wallet. Si THORChain quiere direcciones XEC prefixless dentro de memos, Tonalli debe preparar un builder especializado para ADDLP y swaps que respete esa semántica. El soporte OP_RETURN genérico es útil, pero no reemplaza todavía un builder específico para THORChain.
Para Teyolia, el despliegue de 2.1-G Governance-Bridge encaja con esta dirección: una campaña exitosa puede liquidar hacia una multisig de gobernanza durable y desde ahí coordinar ADDLP posterior, en lugar de depender de un covenant efímero como ruta final de retorno LP.
Próximas validaciones
- Confirmar el DustThreshold económico de XEC.
- Agregar o validar tests explícitos para prefijos ecash/ectest/ecregtest en memos.
- Probar daemon XEC, wallet load/create, importaddress, listunspent y broadcast en entorno habilitado.
- Validar observación inbound, outbound, refunds y quotes cuando haya mocknet o CI oficial disponible.
- Alinear Tonalli Wallet con direcciones XEC prefixless dentro de memos THORChain.
El objetivo final sigue siendo simple: XEC nativo en THORChain. No wrapped XEC. No bridge custodial. No token sintético como sustituto del L1. La diferencia es que ahora la conversación ya tiene arquitectura concreta, paths de código reales y preguntas técnicas específicas.
En una frase: XEC ya no está solamente tocando la puerta. Dentro del branch xec-client, XEC ya camina como una cadena UTXO real dentro de THORNode.
Branch de starsquid: gitlab.com/thorchain/thornode/-/tree/starsquid/xec-client
Draft MR inicial de xolosArmy: gitlab.com/XolosRMZ/thornode/-/merge_requests/2
Artículo previo: XEC en THORChain: el branch de starsquid cambia la partida
← Volver a primera plana