ZIP: Structured Attestation Protocol for Application-Layer Lifecycle Events (ZAP1)#1243
ZIP: Structured Attestation Protocol for Application-Layer Lifecycle Events (ZAP1)#1243Zk-nd3r wants to merge 10 commits into
Conversation
|
Clarifying scope: ZAP1 is intentionally proposed as an application-layer attestation format, not a wallet-transport standard. The goal of this draft is to standardize the structured memo envelope, event typing, hash construction, Merkle anchoring rules, and verification procedure for application commitments written to Zcash. It does not attempt to standardize:
Those can vary across implementations. The reason for the narrow scope is interoperability: an operator, verifier SDK, browser widget, or wallet-integrated client should be able to agree on what a ZAP1 commitment means and how to verify it on-chain, without first agreeing on how the commitment was transported or which wallet stack produced it. In other words: wallet transport is one possible producer/consumer path; ZAP1 is the attestation layer those paths can share. |
|
After looking at ZIP 302 (PR #638, TVLV structured memo container), the right relationship is clear: ZAP1 attestation should be a payload type carried inside ZIP 302, not a competing envelope. The current draft defines its own memo layout because ZIP 302 is still in draft. Once 302 lands, ZAP1 would register a partType and encode attestation data as a TVLV value. The parts of this draft that are actually novel are the event type registry, BLAKE2b hash construction rules, Merkle tree aggregation, and verification procedure - not the memo container itself. I will update the draft to make this layering explicit. The transitional encoding (raw memo) can coexist with the target encoding (ZIP 302 partType) since the first byte distinguishes them. |
Zk-nd3r
changed the title
|
Posting a concrete progress note here so review has a clear target for the next revision. Current direction:
What remains protocol-specific even under that layering:
What I plan to tighten next in this draft:
As of March 31, 2026, the reference stack is live on Zcash mainnet with 4 confirmed anchors, 14 leaves and public proof artifacts. The remaining work is mostly hardening and interoperability work: freezing semantics, publishing stronger vectors, and making the ZIP 302 relationship unambiguous. If the right end state is "ZIP 302 partType for ZAP1 attestation payloads + application-layer documentation for the attestation rules", that is the direction I am aiming for. |
|
Noting the relationship to ZIP 302 (PR #638) for the next revision. ZAP1 attestation payloads should be carried as a ZIP 302 partType rather than as a standalone memo format. The current raw encoding (ZAP1:09:{root_hex}) is a transitional format for the live deployment. The target is a registered partType with a TVLV-encoded attestation value. What maps cleanly to a partType:
What stays application-layer regardless of container:
Per ZIP 302's allocation process, I plan to request an assigned-private-use partType (range 10000-19999) from the ZIP Editors for initial deployment, then propose a standard partType via ZIP modification once the format stabilizes at v3.0. The unknown-reject default in ZIP 302 makes this registration necessary for interoperability. Without a registered partType, compliant readers will reject ZAP1 memos instead of routing them to an attestation-aware parser. |
| bytes 6..37 : payload_hash = 32 bytes | ||
| bytes 38..45: timestamp = u64 big-endian unix seconds | ||
| bytes 46..77: serial_hash = 32 bytes, or 32 zero bytes when unused | ||
| bytes 78..n : note = UTF-8 human-readable note, optional |
There was a problem hiding this comment.
The term "note" clashes with the technical term for a shielded TXO used in Zcash. "Memo" also clashes because it would be confusing to use it for both the protocol-level item and this field.
There was a problem hiding this comment.
Fixed in 1c6969e.
"note" (the free-form text field in the attestation payload) is now "label" throughout. Avoids collision with the shielded TXO term.
For "memo" - I went through every use and separated them. Where the draft was talking about ZAP1's own data structure, it now says "attestation payload" or "payload." Where it refers to the Zcash 512-byte memo field, it says "shielded memo" explicitly. No ambiguous uses remain.
Also updated the title to "Structured Attestation Protocol for Application-Layer Lifecycle Events" since "Memo Protocol" was itself part of the confusion.
…Zcash memo terminology
Zk-nd3r
changed the title
|
I updated this draft in commit 0537ce5 to sharpen the Motivation section around the protocol boundary. The key distinction is now explicit: API and MCP wrappers expose backend responses and therefore require the consumer to trust that backend. ZAP1 is narrower. It defines a receipt and proof artifact: a typed event committed into a BLAKE2b Merkle tree, anchored in Zcash memo data, and verifiable from the public schema, proof material, and chain anchor without trusting the issuer server. That keeps the draft focused on attestation semantics: event typing, hash construction, Merkle aggregation, anchor semantics, and verification. It does not attempt to standardize wallet UX, signing, balance scanning, client/server APIs, or payment transport. I would appreciate ZIP editor or reviewer feedback on whether this boundary is now clear enough for the draft to move into active review, and whether the next step should be assigning a ZIP number or tightening the ZIP 302 partType relationship first. |
2 participants
This PR proposes a draft ZIP for the ZAP1 (Zcash Attestation Protocol v1) structured memo protocol used for application-layer attestation.
Reference implementations and supporting artifacts:
The draft covers the memo envelope, event type registry, BLAKE2b hash construction, Merkle anchoring rules, and verification procedure. Review on naming, field encoding, and interoperability assumptions is welcome.