XEC en THORChain: el branch de starsquid cambia la partida

Durante semanas, el camino de XEC hacia THORChain vivió en una zona incómoda: demasiado técnico para ser entendido como campaña comunitaria, demasiado temprano para ser tratado como integración oficial. Ese periodo produjo una tensión sana. La comunidad preguntó si el trabajo era realmente complejo o si bastaba con copiar la integración de Bitcoin Cash. Los desarrolladores respondieron con matices: sí, la base UTXO compartida reduce el alcance; no, eso no elimina la responsabilidad de manejar correctamente unidades, prefijos de dirección, fees, validaciones y configuración por cadena.

En ese contexto, xolosArmy Network abrió un fork de THORNode y un Draft MR para añadir soporte inicial de eCash (XEC) usando el cliente UTXO compartido. Ese fork fue el primer artefacto público y revisable de la integración. A partir de ahí, el proyecto dejó de girar alrededor de una pregunta abstracta —“¿debería XEC estar en THORChain?”— y empezó a girar alrededor de una pregunta concreta: “¿cuál es el camino más limpio para que XEC sea revisable por upstream?”

De fork comunitario a punto de coordinación

El primer valor del Draft MR no fue prometer un merge. Su valor fue hacer visible el trabajo. En lugar de presentar una idea sin código, xolosArmy puso sobre la mesa una implementación inicial que permitió comentarios técnicos concretos. PiRK revisó el enfoque desde el lado eCash/Bitcoin ABC y señaló ajustes precisos: usar el mismo camino de getblockstats cuando aplique, generalizar el manejo de CashAddr, validar explícitamente los prefijos ecash, ectest y ecregtest, y remover supuestos obsoletos sobre límites de ancestros en mempool.

Ese tipo de feedback es más valioso que un like o una frase de apoyo. Reduce riesgo. Hace el MR más pequeño. Evita que la integración introduzca una biblioteca eCash dedicada antes de tiempo. Y, sobre todo, alinea la ruta de XEC con el principio más importante para entrar a un protocolo como THORChain: tocar lo menos posible, reutilizar lo que ya existe y hacer explícito únicamente lo que sea propio de la cadena.

La señal de starsquid

El nuevo dato importante es que starsquid, un contribuidor del lado THORChain que ya había recomendado mantener la integración lo más cerca posible del cliente UTXO genérico, compartió una rama de trabajo llamada starsquid/xec-client dentro del repositorio de THORNode.

La frase pública fue sencilla: había estado quieto por varias razones, pero no había olvidado el tema. Para cualquier lector externo, eso puede parecer un comentario casual. Para quien entiende cómo se mueven los proyectos de infraestructura, el significado es mayor: alguien del lado THORChain no solo miró la conversación, sino que preparó una rama con una posible ruta de implementación.

Ese matiz importa. En infraestructura abierta, los saltos reales no siempre son anuncios. A veces son ramas, commits, revisiones y pequeños cambios de dirección. La integración de XEC empieza a entrar en esa etapa: menos campaña, más código; menos narrativa, más comparación de diffs.

El rol correcto de xolosArmy ahora

El trabajo de xolosArmy no debería entenderse como competencia contra el branch de starsquid. Al contrario: el Draft MR inicial sirvió como proof of work y como disparador público. Si la rama de starsquid resulta más limpia o más cercana al estilo upstream, lo correcto es alinear el trabajo alrededor de ella.

El mérito técnico no desaparece porque otro contribuidor refine el camino. En proyectos abiertos, abrir la puerta también es contribución. El fork de xolosArmy convirtió una idea en objeto revisable. El feedback de PiRK corrigió supuestos específicos de eCash. La rama de starsquid puede convertir esa exploración en una ruta más aceptable para THORChain.

Teyolia, Tonalli y la siguiente fase

La campaña Teyolia original funcionó menos como mecanismo inmediato de recaudación y más como mecanismo de coordinación pública. Sirvió para ordenar el objetivo, presentar el trabajo, justificar el outreach y demostrar que xolosArmy estaba dispuesto a construir antes de pedir financiamiento serio.

Si la campaña actual expira sin fondearse, el proyecto no desaparece. El MR, el feedback y las ramas públicas quedan. Lo razonable sería relanzar una Teyolia más pequeña y basada en hitos, enfocada en el sprint que realmente siga después de la revisión: documentación, pruebas, preparación MockNet, especificación para Tonalli Wallet y coordinación con el camino upstream.

Tonalli Wallet sigue siendo la capa de usuario de esta historia. THORChain puede abrir la ruta de liquidez; Tonalli puede convertir esa ruta en una experiencia usable para quienes tienen XEC. Entre ambas capas aparece el punto central: liquidez nativa, sin wrapped tokens, sin bridge custodial y sin depender por completo de exchanges centralizados.

Qué observar a partir de ahora

El balance de esta etapa es claro: eCash todavía no está en THORChain, pero XEC ya tiene una puerta técnica visible. Esa puerta comenzó con un fork comunitario y ahora está siendo examinada desde ambos lados. Eso no garantiza el destino, pero cambia la naturaleza del camino.

La integración dejó de ser un deseo. Ahora es una conversación de código.