In This Article
On 2 October, the cross-chain protocol THORChain launched its own liquidity pool for Zcash (ZEC) after completing an update of the network's nodes, which now track Zcash. The next step will be the launch of trading.
THORChain said the update process was complete and every node is watching the Zcash network, with trading to begin once the pool is launched. The protocol characterized the venue as decentralized and warned users that liquidity remains low at the opening stage.
The THORChain ZEC pool launched ahead of the start of main trading
The new ZEC pool provides the THORChain network with a functioning venue for Zcash liquidity ahead of the activation of swaps. In its statement of 2 October, THORChain noted:
"Trading is the next step".
Liquidity remains limited. THORChain warned:
"Liquidity is still small and will grow over time, so trade with caution at the initial stage".
The 2 October statement did not provide data on pool depth or an exact time for the start of trading.
On the active nodes page of the THORChain network explorer, ZEC is currently listed as "OK" in the blockchain information section, alongside Bitcoin, Ethereum and several other networks tracked by the displayed node.
Zcash support arrived after months of work on the code
In its protocol update of 4 March, THORChain reported that the Zcash integration added UTXO processing specific to that network and RPC logic. A separate change included ZEC in the protocol's core oracle, enabling price tracking directly within the THORChain protocol logic.
In March, changes were made in GitLab fixing reporting of ZEC network fees and solvency calculations. The developers said the previous implementation could overstate the allowable gas level, because the full ZIP-317 fee was treated as a per-byte rate during one of the solvency calculations. As a result of the fix, the way transaction size input data was processed for ZEC was changed.
Development continued into September. A THORNode merge request documented signature inconsistencies arising because the expiry of ZEC transactions was calculated based on data from different local chain points, resulting in different signature digests between nodes.
As a result of combining the changes, the transaction expiry was tied to an agreed ZEC height at a fixed THORChain height and retained its value across retries and restarts. Periodic updates of the agreed ZEC height were introduced via network fee reports, and the handling of expired signing attempts was also changed.
On 17 September, the official THORChain blog announced that Zcash would be next in the queue for mainnet launch, as blockchain launches resumed after a period devoted to ensuring network stability. At the time, the project clarified the sequence, stating that the launch would take place before nodes began tracking Zcash, and that the liquidity pool would then be launched.
ZEC trading will begin at an early stage with low liquidity
THORChain's warning of 2 October was directly related to the liquidity available at the opening stage. The protocol urged users to exercise caution while the pool remains small and trading still awaits the next stage of activation.
In THORChain's documentation, the swap model is described as a set of continuous liquidity pools that handle native assets without the need for wrapped versions. RUNE serves as the network's settlement asset and sits in its liquidity pools, providing the routing asset for swaps between supported chains.
Supporting Zcash required several adjustments related to its UTXO architecture. In an earlier THORNode change, ZEC was classified as a UTXO-based blockchain, and configurations were added for address validation, gas units, dust thresholds, block creation times, coinbase parameters and incoming transaction requirements.
Further work continued shortly before the launch. In September, a fix was made concerning transaction signing, which required nodes to use an agreed ZEC height for transaction expiry, as well as to retain the same unsigned transaction information across retries instead of recalculating the expiry based on a newer local point.
Read also:
