I have an attestation protocol running on mainnet that writes typed lifecycle events to Orchard shielded memos. Three anchors confirmed since March 27. The system works, but the memo format is currently defined only by my implementation.
The reason I’m proposing a ZIP rather than just shipping code: there are now at least two applications writing structured data to Orchard memos (coinvoting is the other one I know of). If more follow, they’ll each invent a memo layout. A light client or block explorer that wants to parse structured memos would have to guess what format it’s looking at.
I’m aware of ZIP 302 (@str4d’s TVLV structured memo container, PR #638). The NSM1 attestation format should sit on top of that container, not replace it. The draft currently defines its own envelope because ZIP 302 is still in draft, but the right end state is: NSM1 registers a partType under ZIP 302 and encodes attestation data as a TVLV value. The attestation-specific parts - event typing, BLAKE2b hash construction, Merkle tree rules, verification procedure - are what this ZIP actually standardizes.
The draft proposes a minimal header (version byte, type byte, payload hash) so a parser can route to the right decoder without inspecting the full 512 bytes. Each protocol keeps its own type space. The header is the only shared surface.
Spec is intentionally narrow. It covers the memo envelope, hash construction, Merkle tree rules, and verification procedure. Nothing about wallets, scanning, or transport.
The full stack is live and checkable:
- Repo: GitHub - Frontier-Compute/nsm1: NSM1 structured memo protocol for Zcash. BLAKE2b Merkle commitments, Orchard shielded anchoring, verification SDK. Reference implementation. · GitHub
- Verification SDK: crates.io: Rust Package Registry
- Test vectors: nsm1/TEST_VECTORS.md at main · Frontier-Compute/nsm1 · GitHub
- Live proof: https://pay.frontiercompute.io/verify/075b00df286038a7b3f6bb70054df61343e3481fba579591354a00214e9e019b/check
If the consensus is that this doesn’t need a ZIP and applications should just document their own memo formats, that’s a valid answer too. But if more structured-memo applications are coming, a 3-byte shared header now is cheaper than reverse-engineering collisions later.
Feedback on the byte layout, versioning, or anything that would complicate wallet/scanner integration is welcome.
Related: https://forum.zcashcommunity.com/t/nordic-shield-has-a-live-on-chain-proof-on-zcash