Where Paralock works

Building on Zcash means picking a network, a node, a wallet and a chain for the other side, and they all have to agree. This page lists what Paralock works with today, so you can set up the right combination on the first try.

At a glance

Zcash: what Paralock builds and reads

• Transactions: Paralock builds transparent v5 transactions (ZIP 225) and signs them with ZIP 244 signature hashes. Its locks are P2SH: a hashlock HTLC in htlc mode, a 2-of-2 multisig in adaptor mode.
• Consensus branch id: it is never hardcoded. Paralock signs with the branch id your backend reports for the next block, so the same code works on regtest, either testnet chain and mainnet.
• Network upgrades: refunds and claims in adaptor mode are signed before they are broadcast, and a signature commits to a branch id. If an upgrade would activate before a swap's refund height, the engines refuse the swap (unsafe_timeouts) instead of creating a refund that could never be mined.
• v6 transactions: wallets from the NU6.3 (Ironwood) era send v6 transactions. Paralock reads them in address histories (the lightwalletd client gets their txids from the server's compact blocks), and keeps building v5 for its own locks, claims and refunds.

The Zcash testnet split

Zakura 2.2.0 activated NU7 on testnet at block 4,465,026. Zebra, the Zcash Foundation's reference node, did not. Since that block the testnet has two chains:

To check which chain a server follows, read its branch id:

import { LightwalletdClient } from "@paralock/lightwalletd";

const server = new LightwalletdClient("testnet.zec.rocks:443");
const info = await server.getLightdInfo();
console.log(info.consensusBranchId, info.blockHeight); // "77190ad9" → the NU7 chain
server.close();

With a node's JSON-RPC, read consensus.chaintip from getblockchaininfo. To check where a faucet pays, look its transaction up on each chain: it exists on only one.

Paralock doesn't prefer either chain. The ecosystem is moving to NU7: faucets that send with older wallets have paused until those wallets support it. For the testnet guide we use the NU7 chain, because it has a public lightwalletd server, so the swap needs no node of your own.

Getting testnet ZEC

Zcash backends

Paralock talks to Zcash through the ZcashNode interface, so you choose the backend.

zcashd is end of life and isn't tested.

Wallets

The ZEC for a swap comes from a transparent address: tm… on testnet and regtest, t1… on mainnet. Any wallet that can send to a transparent address can fund one. Shield the ZEC before the swap, send only the swap amount to the swap address, and shield change and refunds again afterwards. Privacy explains why.

• Paralock never sees your wallet's seed. It only uses the key of the swap address.
• If your TAZ arrived in a shielded wallet, send it to your tm… address. The wallet has to follow the same chain and sign for it: on the NU7 chain, a wallet built on upstream librustzcash still signs with the NU6.3 branch id, and the node rejects the transaction ("incorrect consensus branch id") until it supports NU7.

EVM chains

The escrows are plain Solidity. Tempo's fee tokens are the only chain-specific part, and they're handled by the client. Other EVM chains work once you deploy the two contracts with contracts/script/Deploy.s.sol. The SDK names six chains today (EvmChain); adding one is a small change, described in the repository's AGENTS.md.

Runtimes

The local devnet needs macOS or Linux with Docker or OrbStack, ths and Foundry's anvil. Windows isn't tested.

Not supported yet

• Mainnet on either side. The code isn't audited.
• A shielded Zcash lock. The Zcash leg is transparent in both modes; a fully shielded leg (FROST) is in research.
• Stablecoins to ZEC. Only ZEC to stablecoins today.
• Solana. On the roadmap: an HTLC program, and private mode through secp256k1_recover.