Architectural Report and Integration of eCash (XEC) on THORChain

Executive Summary

Cross-chain liquidity orchestration in truly decentralized architectures demands an extraordinary degree of fault tolerance, rigorous state determinism, and flawless synchronization of asynchronous events originating from external networks. The integration of new Layer 1 (L1) networks into the THORChain protocol relies on routing native transactions through the Bifrost subsystem. This subsystem acts as a bidirectional connectivity layer, bridging the local state machines of the various supported chains with THORChain's global state machine, which is built on Cosmos SDK infrastructure.

This document constitutes a comprehensive architectural study dissecting the technical, cryptographic, and operational requirements for the native integration of eCash (XEC) into the THORChain ecosystem. The analysis uses Merge Request (MR) !4696—corresponding to the integration of the Monero (XMR) network with FROST threshold signatures—as the primary reference and unavoidable standard dictating the current expectations of THORNode's core developers.

For the xolosArmy network development environment and the deployment of the Tonalli Wallet ecosystem, integrating eCash (XEC) offers a much more architecturally direct and predictable implementation path. Since eCash inherits the Unspent Transaction Output (UTXO) model structure from its direct predecessors (Bitcoin and Bitcoin Cash), the engineering effort does not require building a client from scratch. Instead, the technical strategy lies in extending and customizing the existing shared implementation found in the /bifrost/pkg/chainclients/utxo/ directory.

Critical vectors resolved by this research include: algorithmic adaptation for block finality handling under eCash's hybrid Avalanche consensus, deterministic validation of addresses with specific prefixes, fragmented orchestration of OP_RETURN fields for metadata (memos) exceeding standard network limits, and the integration of readiness queries and halt states. This study precisely aligns the Tonalli wallet Proof of Concept (PoC) with the rigorous demands of Bifrost's production environment.

Figure 1: Abstract representation of cross-chain liquidity and node infrastructure.

THORChain's Interoperability Architecture and the Bifrost Subsystem

To contextualize the engineering effort required by the xolosArmy network, it is imperative to understand THORChain's underlying mechanics. Unlike traditional bridges that rely on centralized validators or fragmented wrapped tokens, THORChain facilitates the exchange of native assets through a network of distributed vaults (Asgard Vaults). These vaults operate via a Threshold Signature Scheme (TSS), where protocol validator nodes collaboratively control assets without any individual participant holding the full private key.

The trust and connectivity boundary of this network is managed by Bifrost, the sentinel component of THORNode. Bifrost is designed under a dual, concurrent process paradigm: the Observer and the Signer.

• The Observer: A read daemon that continuously scans newly mined blocks across all supported L1 chains. It inspects every transaction looking for movements directed toward active or retiring THORChain vault addresses. Once it validates inputs, extracts the user ID (typically from VIN0), and decodes the intent via the embedded memo, it broadcasts a witness transaction to the validator network. Once 67% of nodes attest to the event, the transaction reaches ingress consensus.
• The Signer: Triggers when the THORChain state machine issues an egress directive (e.g., swapping or withdrawing liquidity). It assembles an unsigned outbound transaction, coordinates a TSS cryptographic ceremony using Secure Multiparty Computation (MPC), and once the signature threshold is met, broadcasts the raw transaction to the external network.

Dissecting Merge Request !4696: The Monero Standard as a Baseline

Merge Request !4696, documented in the THORNode repository, establishes a historical precedent regarding community acceptance standards for new integrations. Titled "Add Monero (XMR) chain support with FROST threshold signing", it encapsulates months of deep cryptographic design.

THORChain core developers dictate that a comprehensive integration must cover the following domains within the Bifrost code:

• Scanner (Block & Mempool Scanner): Infallible chain-reading routines with robust exception handling for deep re-orgs.
• Broadcaster: Asynchronous logic to inject signed transactions into the L1 network.
• Consolidation (UTXO Housekeeping): Automatic algorithms to group dust and prevent cryptographic signing bottlenecks.
• Solvency Reporting: Daemons that continuously cross-reference the L1 vault's mathematical balance against THORChain's internal ledger.
• Readiness Queries: Exposure of operational states to allow frontends (like Tonalli Wallet) to dynamically determine network availability.
• Address Derivation: Centralized functions in the common/ directory to validate and encode native chain addresses.
• Simulation & Regression (Mocknet Fixtures & CI): A complete simulated network environment representing all edge cases, fluidly integrated into CI pipelines.

The Shared UTXO Client: Extending Base Logic for eCash

Unlike the absolute architectural isolation required by Monero, the eCash (XEC) integration masterfully capitalizes on the object-oriented structure of Golang. L1 networks sharing analogous data architectures and underlying consensus do not require building clients from scratch. The existing robust core library natively processes complex flows for Bitcoin (BTC), Litecoin (LTC), Bitcoin Cash (BCH), and Dogecoin (DOGE).

Avalanche Consensus and the Redefinition of Block Finality

The most profound differential vector in integrating eCash is the management of network consensus and asynchronous transaction settlement. Historically, the primary friction in cross-chain liquidity has been the waiting time for probabilistic finality.

Figure 2: Avalanche consensus enables real-time transaction finalization, bypassing traditional mempool delays.

eCash resolves this bottleneck natively via its hybrid consensus architecture, superimposing an Avalanche-based structure over the traditional Proof-of-Work infrastructure:

Stage 1: Avalanche Post-Consensus

Activated in September 2022, Post-Consensus altered the semantics of mined block finality. Sub-sampled validator nodes instantly vote on a newly mined block header. Once quorum is reached, the block is deterministically locked as the canonical tip. This mechanism confers absolute 1-block finality, practically eliminating the deep re-orgs that plague traditional UTXO clients.

Stage 2: Avalanche Pre-Consensus

Activated at block height 923,347 (Nov 2025), Pre-Consensus transforms the mempool's temporal nature. Avalanche nodes execute real-time polling on raw transactions the moment they propagate. This resolves double-spend attempts in milliseconds, granting transactions irreversible sub-3-second finality before they are even mined.

Mempool Scanner Integration and Adaptations in Bitcoin ABC RPCs

To capitalize on this, Tonalli and xolosArmy developers must override the asynchronous state inspection sequences in Bifrost's Observer module.

Leveraging the getfinaltransactions Endpoint:
A conditional statement must be injected into the OnObservedTxIn and GetMemPool logical flows. The eCash client will query the new getfinaltransactions RPC command. When the Observer intercepts a TxID in this list, the bridge algorithmically assumes absolute finality, injecting it immediately as a MsgObservedTxIn message. This cuts user wait times from hours to mere seconds.

Advanced Verbosity in getblock:
The standard getblock command in Bitcoin ABC now supports verbosity level 3, embedding exhaustive prevout information directly within the vin data matrix. Parsing this nested JSON will severely decrease the node's I/O overhead.

OP_RETURN Memo Structuring and Metadata Pagination

Routing intent within THORChain relies on metadata attached via the OP_RETURN opcode. Bitcoin and eCash nodes enforce a strict 80-byte hard limit on standard OP_RETURN payloads.

Because the Tonalli ecosystem requires lengthy memos for full UX flows (target assets, slippage limits, affiliate fees), bypassing the 80-byte barrier is mathematically inevitable.

Multi-Script Extension Mitigation (> 80 Characters):

When the intent string exceeds 80 characters, Tonalli Wallet's logic must slice the message:

1. Extract the first 79 logical characters, adding the special delimiter ^ at the end. Register this as a standard OP_RETURN in VOUT2.
2. Convert the remaining string to hexadecimal encoding.
3. Fracture this hex body into exact 40-character sub-blocks (padding with 00 if needed).
4. Transmute each 40-character block into pseudo-valid script pub keys, emulating a P2WPKH structure (adding the 0014 prefix). Assign these dummy outputs the absolute minimum network dust limit to pass validation.

Solvency Reporting, Vault Consolidations, and Halt States

The Automatic Consolidation Protocol (ConsolidateUTXOs):
To prevent severe UTXO fragmentation, the ChainClient framework demands automatic routines. Whenever the sum of unspent outputs breaches a limit (usually 15), the Signer autonomously models and signs an internal transaction to unify the fragments. Because eCash features infinitely scalable block capacities and micro-cent fees, this routine operates with infinitesimal economic impact compared to Bitcoin mainnet.

Dynamic Readiness Queries:
The Tonalli Wallet frontend will utilize its QuoteInspector v2 architecture to poll readiness queries. Fortunately, the anti-mutation shield provided by the Avalanche engine massively mitigates the systemic fears of deep re-orgs that typically force PoW networks into prolonged halt states.

Conclusions on Architectural Synergy and Roadmap

The design to integrate eCash into THORChain's decentralized functional layers stands as a cross-chain optimization achievement. While the Cosmos SDK provides a global shield against centralized dependencies, eCash's microscopic network design eliminates the primary deficit of UTXO-based bridges: the suffocating latency imposed by stochastic finality.

By taming the mathematical variations of the ecash: prefix, parsing sub-routines for OP_RETURN metadata pagination, and leveraging sub-3-second Avalanche Pre-Consensus, xolosArmy developers will forge an industrial-grade L1 node. This establishes a new paradigm of speed and efficiency for the next iteration of immutable decentralized finance.