Different algorithms, different jobs
The intended security goal is post-quantum protection at every mandatory trust boundary. Replacing one signature algorithm does not establish that property.
| Candidate | Intended role | Does not establish |
|---|---|---|
| ML-DSA | Private spend authorization and validator vote authentication. | Note encryption or overall protocol security. |
| ML-KEM | Shared key material for recipient note encryption. | Sender authentication or correct payload construction by itself. |
| Versioned KDF + AEAD | Context-bound key derivation and authenticated note encryption. | Ciphertext availability or safe recovery. |
| Transparent STARK family | Computational integrity under a registered relation. | Zero knowledge without witness hiding, consensus ordering or a fixed quantum-security level. |
| SLH-DSA | Possible hash-based alternative in selected key-management settings. | A selected or benchmarked ZOIY implementation. |
Final parameters, hashes, witness masking and circuits remain open. Proving ML-DSA verification inside a STARK may be expensive and needs comparison against alternative authorization designs.
What stays private, what is observable
Private transaction details and public verification data have different roles. Understanding what remains visible is essential to understanding the privacy target.
| Boundary | Information |
|---|---|
| Private witness | Note openings, secret amounts, Merkle paths, nullifier secrets, hidden verification material and signatures. |
| Chain-visible data | Commitments, nullifiers, encrypted envelopes and sizes, proof data, fees, roots, version IDs, expiration and public-call information. |
| Network observations | Timing, IP addresses, relay reuse, RPC requests, note-discovery patterns and confirmation timing. |
A privacy comparison must use valid transactions with the same permitted leakage. A one-output payment, a three-output payment and a transparent withdrawal need not look alike.
Four capabilities in the wallet
Spend authorization
Controls the right to authorize consuming a note.
Nullification
Derives its one-time public spend marker from independently held secret material.
Viewing
Decrypts incoming note data within an explicitly defined scope.
Recovery
Restores access after loss, under a mechanism whose authority and risks must be specified.
Derived relationships require purpose-specific key derivation and versioning. Wallets should verify roots and note openings locally rather than trust an RPC server's reported balance.
Selective disclosure cannot make a recipient forget shared data. Viewing capabilities should be narrow and separate from spending authority; their exact delegation and revocation format remains future work.
Failures the design must reject
- Payer predicts the nullifier: later spending becomes linked to the original payment.
- Ciphertext changes after authorization: acceptance would refute transcript binding.
- A nullifier is finalized twice: the ordered state-transition invariant has failed.
- A public call reverts after private inputs commit: settlement has lost atomicity.
- An accepted output cannot be decrypted: baseline binding is insufficient for recoverability.
The baseline proof does not prevent an unusable encrypted output. Stronger delivery checks are needed to establish that an accepted note can actually be recovered.
Upgrades must preserve ownership
Algorithm changes need explicit versions, verifier IDs and upgrade epochs. Unknown versions must be rejected, not interpreted heuristically.
Owners need defined rules for moving old notes into new ones. An emergency upgrade must not introduce a special spending key or quietly expand viewing access. Conservation, authorized spending and one-nullifier invariants must survive the transition.
Governance, old-note compatibility and emergency processes remain design work. The security of the upgrade process cannot be inferred from the correctness of a replacement circuit.