Skip to main content

frZEC

Coming soon: there is no frZEC yet

frZEC is being built and tested. It is not deployed. There is no frZEC alkane, no vault address and no gateway yet, and every id and address on this page is a placeholder written in angle brackets, like 4:<TBD> for the alkane id or <ZEC-VAULT>. Anything claiming to be frZEC today is not ours. Don't send ZEC or buy "frZEC" until this page lists the real ids and its own launch transactions, the way the frXRP page does.

frZEC brings ZEC to Bitcoin as an alkane, just like frSOL and frXRP. One frZEC unit is one zatoshi held in custody on Zcash, and frZEC has the same 8 decimals as ZEC. Hold it, trade it in the alkanes ecosystem, and redeem it for real ZEC.

What makes frZEC different is that it is built for a vault anyone can audit, with privacy at the edges.

A vault you can check yourself​

  • One transparent Zcash address holds every frZEC's ZEC. <ZEC-VAULT> is a plain t1… address controlled by the signer group's threshold-ECDSA key. Its balance is public, so anyone can compare it with frZEC's supply on Bitcoin at any block, without asking SUBFROST.
  • The group checks solvency every round. The signer group's admin program checks that the vault holds at least frZEC's supply, plus every unpaid burn, plus every held deposit. If it doesn't, the group raises a public alarm.
  • Every transaction into or out of the vault is tagged.
    • A deposit sweep carries the deposit's intent in an OP_RETURN, so anyone can match a mint to the ZEC that backs it.
    • A payout carries the id of the burn it pays.
    • A vault spend that isn't one of the group's tagged transactions raises an alarm and is public evidence of misbehaviour.
  • frZEC is only minted once the ZEC is in the vault. Deposits still on their way in are never counted as backing.

How it will work​

1. Get a deposit address​

Your deposit intent names the Bitcoin script that should receive your frZEC, in the same byte format frXRP uses. Version 2 adds a Zcash refund address and a refund height. Use version 2.

A SUBFROST gateway turns the intent into your own transparent deposit address: P2PKH(P + t·G), where P is the group's key and t is derived from the group key and your intent. The gateway holds no keys. Every signer re-derives your address from the intent before it signs anything, so a gateway that lies can't redirect your deposit. Derive the address yourself and compare before you send.

2. Send ZEC​

Send at least 0.01 ZEC to your deposit address from any wallet. A shielded wallet can pay it too, because the payment lands in a transparent output. Smaller amounts wait at the address until it is topped up.

3. The group sweeps and mints​

Once every read provider agrees on your deposit at a pinned block height, the signer group sweeps the address into <ZEC-VAULT>:

  • out0 pays the vault;
  • out1 is an OP_RETURN carrying "frzS" followed by your whole intent.

Then the group mints frZEC on Bitcoin to your recipient script, less the mint fee. Because the intent is on-chain, the mint doesn't depend on a gateway being up.

Direct deposits work too. A wallet that pays <ZEC-VAULT> at output 0 with the same frzS marker and an intent at output 1 is minted, with no gateway involved.

4. Refunds and held deposits​

  • Version-2 intents: if your deposit can't be minted (for example, your recipient script can't be paid), or it reaches its refund height unswept, the group sends it to your refund address with a "frzR" marker. Nothing is minted.
  • Version-1 intents with a recipient that can't be paid: the ZEC is moved into the vault with a "frzH" marker and recorded as held. It is never minted. It stays a refundable liability in the solvency check until SUBFROST's operator approves a refund, which is paid at most once.

5. Burn frZEC for ZEC​

Burn frZEC on Bitcoin (opcode 88 on 4:<TBD>) with a release intent that names a Zcash address. As with every fr* burn, the burn protostone burns everything it receives, so use one of the exact-amount shapes in Getting the amount right.

After the burn has 3 Bitcoin confirmations, the group pays it from the vault. Each payout spends the previous payout's change output and carries a "frzP" marker with the burn id. Two payouts for one burn can never both confirm, so every burn is paid at most once.

paid = burned − flat payout fee   (0.0002 ZEC by default; it covers the Zcash fee)

A burn the group can't pay is voided, recorded with a "frzV" marker. That includes an undecodable intent, the vault itself as destination, or an amount below the minimum output.

Privacy, in stages​

frZEC launches with the transparent lane: transparent deposit addresses and payouts to t1… addresses. Shielded senders can already deposit, as above. Two shielded stages follow:

  • Shielded payouts. Burn frZEC and name a Zcash unified address (u1…), and the vault pays you into the shielded pool, so your recipient stays private. The amount leaving the vault stays public, so the books still balance. The release-intent format for unified addresses is already built. Until this stage is switched on, the alkane refuses shielded burns, so none can be stranded.
  • Shielded deposit addresses. Every deposit gets its own private shielded address, and the group sweeps it into the vault using K-RP, SUBFROST's threshold scheme for shielded keys (below). It targets Zcash's current shielded pool, Ironwood (NU6.3).

The MPC behind frZEC​

Zcash has two kinds of money, and frZEC needs the signer group to control both without any machine ever holding a whole key. SUBFROST built a new threshold signing scheme for the shielded side, and uses CGGMP21 threshold ECDSA for the transparent vault.

K-RP: a shielded key no one holds​

Shielded ZEC lives in Zcash's Orchard pool and its successor Ironwood (NU6.3). An Orchard spend is authorized by a RedPallas signature under a re-randomized key, so every spend looks unrelated to the last. Off the shelf threshold schemes don't produce one, and a shielded address needs more than a signing key: it needs viewing and nullifier keys that every signer derives the same way.

K-RP is how the signer group owns a shielded address together:

  1. Distributed key generation. The nine seats run a Pedersen DKG for the spend authorizing key over the Pallas curve. Each seat ends with a share, and the group with its public key ak. Any output that Orchard can't use is refused.

  2. Shared key agreement. The rest of the Orchard key material is agreed by a commit and reveal protocol we designed, following ZIP 2005 ("Usage with FROST"):

    • every seat commits to a random contribution, bound to the ceremony and to ak;
    • every seat reveals its contribution;
    • the shared secret is the hash of all of them;
    • every seat confirms the same transcript and the same full viewing key.

    No seat can choose the result. Equivocation, a reveal before every commit is in, or a reveal that doesn't open its commitment aborts the ceremony.

  3. Re-randomized FROST signing. For each spend, the randomizer is derived from the signers' own round-one commitments, so no coordinator can pick it. Every signer then checks the following against the transaction it verified itself before it releases a share:

    • the randomized key;
    • the sighash;
    • its own commitment.

    A bad share is caught and blamed on the exact seat that sent it.

The result is a group full viewing key and a unified address (u1…) per deposit, derived from your intent. The signatures verify under Orchard's own RedPallas code, and the spends are accepted by Orchard's own Halo2 batch validator. In tests, 6 of the 9 seats sign and any 5 can't. Proving a two-action spend takes about three and a half seconds.

The trade-off is privacy, not custody. The spending key is split 6 of 9, but ZIP 2005 has every seat keep the viewing material, so a single leaked seat would reveal the shielded deposits it can see. It still couldn't move them. Custody stays in the transparent vault below.

K-RP powers the shielded deposit addresses stage under Privacy, in stages. It is built and tested against Orchard's own code, and it ships after the transparent launch.

K-EC: the transparent vault​

The vault itself is a transparent t1… address. Zcash's transparent pool signs with ECDSA over secp256k1, so the vault key is a threshold ECDSA key built on CGGMP21, in its audited open source implementation.

  • No dealer. The nine seats create the key in a distributed ceremony:

    1. they commit to fresh randomness, which fixes a ceremony id;
    2. they run the threshold keygen;
    3. each seat generates its own Paillier keys;
    4. every seat confirms the same public key.

    Nothing is saved until all nine confirm, and a signer refuses any single-party or dealer-made key.

  • An address per deposit, one key. Your transparent deposit address is P2PKH(P + t·G), where t comes from your intent. The same shares sign for it, shifted by t, with no new ceremony. The tweak is bound into:

    • the signing session;
    • its execution id;
    • every approval.

    An approval for one deposit can't sweep another.

  • Tested on a real Zcash node. A 9-seat key's tweaked sweep and its v6 payout were accepted by a Zcash regtest node, with txids matching SUBFROST's own encoder. A wrong key and an underpaid fee were refused. The full cycle of deposit, sweep, mint, burn and payout ran end to end.

Under the hood​

  • Signer group: 6-of-9, like every fr* asset. frZEC adds the two keys described in The MPC behind frZEC: K-EC for the transparent vault and K-RP for shielded addresses. Minting uses the group's taproot key on Bitcoin, as for frSOL and frXRP.

  • Reads: three independent Zcash data providers, read at one pinned block height, which must all agree. A disagreement or a missing answer means no progress that round.

  • Every transaction is checked before it is signed: inputs, the exact fee, the network upgrade in force and every signature, against the providers' agreed view.

  • The same safety model as every fr* asset:

    • a separate AUTH token for minting and SIGIL token for limits;
    • per-window mint and payout caps;
    • public 24-hour delays on any limit raise;
    • an emergency pause.

    See What you trust.

What's next​

frZEC follows frADA. When it launches, this page will list the real alkane id, the vault address, the gateway, the fees and limits, and its first mainnet transactions. Until then, every id and address here is a placeholder.