ZIP Draft: Orchard Address Signatures

[emersonian]

This ZIP proposes extending the Sapling address signature mechanism (ZIP 304) to the Orchard shielded pool, enabling users to prove control of an Orchard address without performing an on-chain transaction.

This is a draft, community review and feedback are welcomed.

Motivation

Cryptographic message signing has become the standard approach for authenticating users to web applications in the cryptocurrency ecosystem. Ethereum's "Connect Wallet" flow is now ubiquitous across decentralized applications. Zcash users deserve equivalent functionality.

ZIP 304 specifies message signing for Sapling addresses. With the deployment of Orchard in NU5, users increasingly hold funds in Orchard addresses or Unified Addresses containing Orchard receivers. These users currently cannot prove control of their addresses without performing an on-chain transaction.

This proposal enables use cases including:

• Off-chain authentication for Zcash-native applications ("Connect Wallet")
• Message signing for legal or attestation purposes
• Code and binary signing by contributors' known Orchard addresses
• Proof of address control for exchanges and auditors
• Signed voting in public governance (DAOs, etc.)

Technical Approach

The specification reuses the existing Orchard Action circuit with fixed, deterministic inputs to create a "synthetic spend" proof. This proof cryptographically binds the spending key to the address and a message digest.

Open Question: Signature Size

The proposed signature is approximately 5,120 bytes, substantially larger than comparable mechanisms in other ecosystems. For off-chain authentication and "Connect Wallet" flows this may be acceptable, but I'm interested in ideas for safely reducing the size. Adapting ZIP 304's mechanism is quite possibly the wrong approach here, but it felt like the path of least resistance.

Review Requested

This specification involves non-trivial cryptographic constructions. I am not a cryptographer by training and welcome rigorous review from domain experts.

Per ZIP 0 requirements for ZIPs with significant security implications, independent security review is requested before this specification advances beyond Draft status.