Request: ZAP1 experimental partType allocation in ZIP 302 structured memos

[Zk-nd3r]

Request

Requesting an experimental partType allocation in the 65530-65535 range for the ZAP1 attestation protocol, as defined in the ZIP 302 structured memos draft (PR #638).

Background

ZAP1 is a deployed attestation protocol that commits typed lifecycle events to a BLAKE2b Merkle tree and anchors roots on Zcash mainnet via shielded memos. It is live on mainnet with 5 anchored roots and 15 event types.

• ZIP draft: ZIP: Structured Attestation Protocol for Application-Layer Lifecycle Events (ZAP1) #1243
• Reference implementation: Frontier-Compute/zap1
• Verification SDK: zap1-verify on crates.io
• Protocol spec: ONCHAIN_PROTOCOL.md (v3.0.0)

Current memo encoding

ZAP1 currently uses a transitional text encoding in the memo field:

ZAP1:{type_hex}:{payload_hash_hex}

This is a 73-byte ASCII string that fits in any shielded memo. The ZIP draft (#1243) documents this encoding and notes that ZAP1 payloads should migrate to a ZIP 302 part type when structured memos ship.

Requested allocation

• Range: experimental (65530-65535)
• Requested partType: any available value in this range
• partVersion: 0
• partValue encoding: type_byte (1) || payload_hash (32) = 33 bytes
• Purpose: pre-standardization testing and interop validation
• Deployment scope: Zcash mainnet (already deployed with text encoding)

Long-term path

Once the experimental allocation is validated in production, we intend to request a stable assignment in the assigned private-use range (10000-19999) or submit a ZIP 302 amendment for a public standardized partType.

Contact

• GitHub: @Zk-nd3r
• Project: Frontier Compute

[linear]

COR-1174