Zcash Providers

LI.FI offers bridging of native ZEC in both directions between Zcash and EVM chains, Solana, Bitcoin, Tron, Stellar and Hyperliquid. Zcash carries a single asset, so there are no same-chain swaps and every Zcash route is a bridge.

Zcash chainId in LI.FI is 20000000000005. The chain key is zec and the chain type is UTXO.GET /v1/chains returns EVM chains only by default. Pass chainTypes to include Zcash, for example GET /v1/chains?chainTypes=EVM,UTXO.Native ZEC is addressed as zcash with 8 decimals. Amounts are always expressed in zatoshi (1 ZEC = 100,000,000 zatoshi).

Requesting a quote

A quote for Zcash can be requested using the same endpoints as EVM. Only the chain ids, the token address and the transaction data differ.

Addresses

LI.FI sends from a transparent address, or from a unified address that carries an Orchard receiver. It pays out to a transparent address, or to a unified address that carries an Orchard receiver.

Address form	Prefix	As `fromAddress`	As `toAddress`
Transparent, pay-to-public-key-hash	`t1`	Yes	Yes, on both bridges
Transparent, pay-to-script-hash	`t3`	Yes	Yes, on both bridges
Unified, with an Orchard receiver	`u1`	NearIntents only, as a shielded source	NearIntents only
Unified, without an Orchard receiver	`u1`	No	No
Unified, with a receiver type other than transparent, Sapling or Orchard	`u1`	No	No
Sapling	`zs1`	No	No

fromAddress when the source chain is Zcash accepts:

A single transparent address: t1cSswzBCTiKZ9XwEUCurkfGSQFGunU5CDM
Several transparent addresses, separated by a semicolon: t1address1;t1address2;t3address3
A single unified address with an Orchard receiver, for a shielded source: u1...

A semicolon-separated list must contain transparent addresses only. Extended public keys (xpub) are not supported on Zcash. Pass explicit addresses.toAddress when Zcash is the destination chain accepts a t1 or t3 address, or a u1 unified address with an Orchard receiver. When bridging out of Zcash, toAddress is a regular address on the destination chain.

Unified destinations. A unified address bundles several receivers into one address. NearIntents pays the Orchard receiver, even when the address also carries a transparent receiver. A unified address without an Orchard receiver is refused, because a bridge would pay its transparent receiver and the payout would not be shielded.Unit pays out to transparent addresses only. For a unified toAddress, /v1/quote returns no Unit route, and /v1/advanced/routes lists the Unit route in unavailableRoutes.filteredOut with the reason. A step posted to /v1/advanced/stepTransaction that pays a unified address through Unit is refused.

Refused addresses. A refused Zcash address returns HTTP 400 with error code 1011 (ValidationError). The message names the field, the reason and the accepted forms, for example:

Invalid toAddress: Sapling (zs1) addresses are deprecated on Zcash and no bridge pays out to or accepts one; use a transparent (t1 or t3) address, or a unified (u1) address with an Orchard receiver

UTXO collection. For a transparent sender, LI.FI pools the UTXOs of every address in fromAddress and selects them largest-first until they cover the transfer plus the network fee. The pooled set must cover both, otherwise no quote is returned.Two kinds of UTXO are never selected:

A UTXO with zero confirmations. Wait for one confirmation.
A coinbase (mining reward) output. Zcash requires a coinbase spend to move the value into a shielded pool, which a transparent transaction cannot do.

Change goes back to the address that contributed the largest value among the selected inputs.Signing. Every address that contributes an input must sign the transaction.

Token approvals

Zcash needs no token approval. Zcash is a UTXO chain with one asset, so a transfer is authorized by the signature on the transaction itself. Ignore approvalAddress on a Zcash step.

NearIntents integration

Registered as the tool key near (“NearIntents”). It bridges native ZEC between Zcash and 15 chains: Ethereum, Arbitrum, Base, Optimism, Polygon, Avalanche, BNB Smart Chain, Gnosis, Berachain, Monad, X Layer, Bitcoin, Solana, Tron, and Stellar.

14 of those chains route in both directions. Stellar is a destination only: LI.FI can bridge ZEC to Stellar, but not from Stellar to Zcash.

NearIntents is the only bridge that pays out to a unified (u1...) address. The payout goes to the address’s Orchard receiver, so the ZEC arrives in a shielded balance. NearIntents is also the only bridge that accepts a unified fromAddress. See Shielded source.

Contract receiver for a unified address. A unified address does not fit in 32 bytes. When the source chain is an EVM chain, the LI.FI contract call therefore carries sha256(toAddress) as the non-EVM receiver, and the BridgeToNonEVMChainBytes32 event emits that digest. NearIntents pays the full toAddress, which the quote binds to the deposit address.

Unit integration

Registered as the tool key unit (“Unit”). It bridges native ZEC in both directions between Zcash and Hyperliquid.

Unit enforces a minimum transfer of 0.07 ZEC (7000000 zatoshi) on both sides. A smaller amount returns no quote.Unit pays out to transparent (t1 or t3) addresses only. A Hyperliquid to Zcash transfer to a unified toAddress gets no Unit route.Unit also accepts transparent senders only. A Zcash to Hyperliquid transfer from a unified fromAddress gets no Unit route.

Executing a transaction

Transaction data

This section covers a transparent sender. For a unified fromAddress, see Shielded source. transactionRequest.data is not a PSBT. Zcash transparent transactions are signed with the ZIP-243 signature hash, which is personalized by the consensus branch id and by the transaction’s versionGroupId and expiryHeight. No Bitcoin PSBT library can produce it, so LI.FI returns a structured unsigned transaction instead. The payload is a JSON object describing a v4 (ZIP-243) transaction:

{
  "version": 4,
  "versionGroupId": 2301567109,
  "consensusBranchId": 933566043,
  "expiryHeight": 3475269,
  "lockTime": 0,
  "inputs": [
    {
      "txid": "c56bbe3e...5ade",
      "vout": 0,
      "valueZat": "403860",
      "address": "t1cSswzBCTiKZ9XwEUCurkfGSQFGunU5CDM"
    }
  ],
  "outputs": [
    { "address": "t1SdGayz4D5oEbc9wm5RLTP6Do8TRMLdHrf", "valueZat": "388860" },
    { "scriptHex": "6a0a3d7c6c69666920e6552d", "valueZat": "0" },
    { "address": "t1cSswzBCTiKZ9XwEUCurkfGSQFGunU5CDM", "valueZat": "..." }
  ]
}

Field notes:

consensusBranchId is read live from the node for every quote. It changes at every Zcash network upgrade and it personalizes the signature hash, so never cache it and never substitute a constant.
inputs[].address is the address the UTXO belongs to. Derive that input’s previous output script from it. inputs[].valueZat is required by the ZIP-243 signature hash, so keep it.
outputs[].address is set on a payment output (transfer, fee collection, change). Build the standard P2PKH or P2SH script for it yourself.
outputs[].scriptHex is set on the OP_RETURN output instead, and its valueZat is always "0". Encode that script verbatim.
All amounts are zatoshi strings. Parse them as big integers, never as floating-point numbers.

Output order is fixed: the transfer to the bridge, then the OP_RETURN tracking memo, then any fee-collection outputs, then the change output when there is one. To execute the transaction:

Request the transaction data through the regular quote flow.
Serialize the transaction as Zcash v4 (ZIP-243) from the fields above.
Sign every input with the key of its address.
Broadcast the signed transaction to the Zcash network.

Risk of modifying Zcash transaction dataDo not add, remove, reorder or re-value any input or output, and do not edit the OP_RETURN script. The amounts balance to an exact ZIP-317 fee, and the OP_RETURN memo is how LI.FI identifies your transfer. A modified transaction can lose the funds, or complete on chain while /status never resolves it.

Envelope validity windowexpiryHeight is set about 40 blocks ahead of the chain tip, which is roughly 50 minutes. The network drops the transaction once that height passes.

Sign and broadcast promptly after receiving the transaction data.
Request a new quote if the transaction is stale.
Request a new quote if any selected UTXO was spent in the meantime.

Shielded source

A unified fromAddress with an Orchard receiver is a shielded source. Spending shielded ZEC needs the keys of the wallet, so LI.FI cannot build the transaction. The quote returns a deposit instruction instead of a transaction artifact:

"transactionRequest": {
  "to": "t1ttqhrd...jriwk",
  "value": "400000"
}

to is a transparent NearIntents deposit address.
value is the amount to pay, in zatoshi.
There is no data field, and estimate.gasCosts is empty.

To execute the transfer:

Request the transaction data through the regular quote flow, with the unified address as fromAddress.
From the shielded balance of that wallet, send exactly value zatoshi to to.
Poll /status with the hash of that transaction and fromChain=zec.

The wallet builds the transaction and pays the ZIP-317 network fee on top of value.

Fees. NearIntents collects the integrator fee out of value. The deposit carries no fee outputs.

Refunds. Pass refundAddress to choose where NearIntents returns the ZEC if the transfer cannot complete. It must be a transparent address, or a unified address with an Orchard receiver. Without refundAddress, the refund goes to the unified fromAddress.

Deposit deadlineThe deposit address is valid for 1 hour after the quote. A shielded wallet must sync before it can spend.

Sync the wallet before you request the quote.
Pay promptly after receiving the deposit instruction.
Request a new quote if the deadline has passed.
Do not change the amount or the deposit address.

Gas

For a transparent sender, the network fee is returned in the step’s estimate.gasCosts in zatoshi (ZEC, 8 decimals). For a shielded source, estimate.gasCosts is empty, because the wallet builds the transaction and pays the fee. Zcash has no fee market. The fee follows the ZIP-317 formula:

fee = 5000 zatoshi x max(2, logicalActions)

logicalActions is derived from the shape of the transaction, so the network minimum is 10,000 zatoshi (0.0001 ZEC) and there is no fee rate to bid. gasCosts[0].price is reported as 0 for that reason, and paying more does not confirm the transaction faster. Change below 5,000 zatoshi is added to the fee rather than paid out, because such an output costs more to spend later than it is worth.

Status tracking

Transaction status can be tracked using the regular status tracking flow.

When polling /status for a transaction that originates on Zcash, always pass fromChain=zec (or the Zcash chain id 20000000000005). Zcash transaction hashes are 64-character hex strings and are otherwise indistinguishable from Bitcoin transaction hashes.

Shielded sources. A deposit that the wallet builds carries no OP_RETURN memo. LI.FI matches it to the quote by the deposit address that it pays. sending.amount is the amount paid to the deposit address, and sending.gasAmount is the network fee that the wallet paid.

Shielded payouts. A payout to a unified address goes into the shielded pool, and the amount of a shielded output is not public. For that payout, receiving.amount is the amount that NearIntents reports.receiving.txLink points to CipherScan, which shows the shielded (Orchard) part of a payout. Some other Zcash explorers show a shielded payout as 0 ZEC.

Learn About LI.FI

Supported Systems

LI.FI Architecture

User Flows and Examples

Learn More

Changelog

Zcash Providers

Requesting a quote

Addresses

Token approvals

NearIntents integration

Unit integration

Executing a transaction

Transaction data

Shielded source

Gas

Status tracking

​Requesting a quote

​Addresses

​Token approvals

​NearIntents integration

​Unit integration

​Executing a transaction

​Transaction data

​Shielded source

​Gas

​Status tracking

Requesting a quote

Addresses

Token approvals

NearIntents integration

Unit integration

Executing a transaction

Transaction data

Shielded source

Gas

Status tracking