ak is a FROST group key, so the full spending key never exists anywhere.
Signers
Any two can authorize a batch. One alone is refused, by the code and by the cryptography.
corridor-frost
A Rust service (services/zcash-frost) built on the reddsa FROST(RedPallas) ciphersuite with frost-rerandomized.
1
keygen
Produces three shares and the vault’s public material. The group verifying key must have a positive-y encoding to be a valid Ironwood
ak, so keygen retries until it does. The full viewing key ak ‖ nk ‖ rivk is built with FullViewingKey::from_bytes (a public API, no crate fork), and from it the unified full viewing key and the vault address.2
build (zcash-devtool)
The view-only wallet imports the UFVK, builds the batch as an unsigned PCZT and proves it.
3
sign
For every unsigned Ironwood action in the PCZT: read its randomizer
alpha; check rk == ak + [alpha]G, so only this vault’s spends are signed; run both FROST rounds rerandomized by alpha over the approving signers; aggregate; verify the RedPallas signature against rk; apply it with Signer::apply_ironwood_signature. A signer set below the threshold is refused.4
combine and send (zcash-devtool)
Merge the proven PCZT with the signed one and broadcast.
corridor-frost inspect lists the Ironwood actions in a PCZT and whether each is signed.
Why rerandomized
Ironwood (like Orchard) randomizes the spend validating key per action (rk = ak + [alpha]G) so spends cannot be linked to a vault on-chain. A threshold signature must therefore be produced under rk, not ak. FROST rerandomized signing does exactly that, so threshold control costs no privacy.
Approval flow
Tests
Scope
The PCZT interface and the cryptography are unchanged between the two.