Payment Request and Memo Standards

Implementing ZIP 321 requires robust parsing of zcash: URIs with strict validation of address formats, amount parameters, and memo fields. A failure to correctly parse or reject malformed URIs can lead to silent payment failures or funds being sent to an incorrect address type. Integrators must ensure their parser handles all valid address types—transparent, Sapling, Orchard, and Unified Addresses—and correctly decodes base64-encoded memos. Chainscore can review your URI parsing logic against the ZIP 321 specification to identify edge cases and validation gaps.

The memo field is a critical but fragile component of shielded transactions. Incorrectly formatted or unencrypted memos can cause permanent data loss or leak sensitive information. Wallets must enforce UTF-8 encoding for text memos, handle the 512-byte limit for shielded pools, and correctly implement ephemeral key agreement for memo encryption. A common integration risk is a wallet failing to decrypt a memo sent from a different wallet implementation due to a divergence in the encryption scheme. Chainscore can audit your memo encryption and formatting logic against the active shielded pool specifications.

Exchanges and custodians face unique risks when processing inbound shielded transactions. A deposit may require a specific memo format (e.g., a user ID) for internal crediting. If the exchange's parser cannot decrypt or interpret the memo from a Sapling or Orchard transaction, the funds may be lost or require manual recovery. Furthermore, outbound withdrawals must correctly generate encrypted memos for user-provided addresses. Chainscore can perform an exchange-specific readiness review to ensure your shielded deposit and withdrawal flows are compliant and resilient.

A ZIP 321 payment request using a Unified Address (UA) can contain multiple receivers across transparent, Sapling, and Orchard pools. The sending wallet must implement a selection algorithm to choose the 'best' receiver based on user preferences and available funds. A naive implementation might always default to a transparent receiver, degrading user privacy. The risk is that a wallet's UA resolution logic is incompatible with the sender's intent, leading to an unexpected transaction type. Chainscore can assess your UA resolution and payment construction logic for correctness and privacy preservation.

Mobile wallets using light client protocols face bandwidth and privacy constraints when processing payment requests. Fetching full transaction details to verify a memo or resolve a UA can be slow and leak information to the lightwalletd server. Implementers must balance the convenience of ZIP 321 features with the privacy and performance profile of compact filters. A poorly optimized implementation can render a mobile wallet unusable on slow networks. Chainscore can help infrastructure teams assess the security and performance trade-offs of their light client deployment for payment request handling.

The Zcash ecosystem includes multiple wallet implementations (e.g., Zashi, Ywallet, zcashd) and libraries (e.g., librustzcash, zcash_client_sqlite). A payment request generated by one wallet must be correctly parsed and executed by another. Subtle differences in URI encoding, memo padding, or UA handling can break interoperability. Proactive cross-implementation testing against a reference test vector set is essential before launch. Chainscore can design and execute an interoperability test plan to validate your integration against the canonical ZIP 321 test vectors and other major ecosystem wallets.

ZIP 321 is the primary specification for encoding Zcash payment requests as URIs. Implementers should validate the URI scheme, recipient addresses, amounts, memo parameters, percent-encoding, duplicate or unsupported fields, and multi-payment behavior defined by the ZIP. Wallets should present decoded values for user confirmation rather than treating a scanned QR code or opened link as trusted input. Test parsers against malformed values, unknown parameters, conflicting requests, and receiver types the wallet cannot spend to. Merchants should also verify that generated requests remain compatible with wallets supporting transparent, Sapling, Orchard, and Unified Address workflows.

ZIP 302 defines conventions for interpreting the Zcash memo field, including how its leading byte distinguishes text from other content. Wallets and payment processors should apply these semantics only after successful note decryption and must not assume every 512-byte memo contains UTF-8 text. Implement explicit handling for empty memos, invalid text encoding, reserved formats, and application-specific binary data. User interfaces should avoid rendering untrusted memo content as executable markup or links without sanitization. Custody and merchant systems should preserve raw memo bytes where required for reconciliation while separating protocol-valid memos from application-level business instructions.

ZIP 316 is required context when a payment request contains a Unified Address rather than a single transparent or shielded address. Sending wallets must parse the container correctly, reject malformed encodings, and apply supported receiver-selection rules without silently degrading privacy. Payment-request implementations should test combinations of Orchard, Sapling, and transparent receivers, including cases where the wallet supports only a subset. Merchant systems should retain the original requested address for auditability while recording the receiver actually used for settlement. Avoid extracting and displaying individual receivers as interchangeable deposit addresses unless the integration explicitly supports that behavior.

The Zcash Protocol Specification is the canonical reference for transaction structures, shielded note plaintexts, memo placement, encryption, address types, and consensus behavior. Use it to verify assumptions that ZIP-focused application code makes about Sapling and Orchard outputs. Memo confidentiality depends on shielded transaction encryption and recipient-key handling; the URI itself is not a confidential transport. Review the active network specification when testing transaction construction, decryption, note scanning, and serialization. Teams maintaining independent wallets, hardware signers, custody systems, or transaction parsers should map their implementation to the applicable protocol version instead of relying solely on SDK behavior.

The official ZIP repository provides source files, revision history, pull requests, and discussion context for Zcash standards. Engineering teams should monitor changes affecting ZIP 321, ZIP 302, Unified Addresses, wallet behavior, and memo conventions rather than treating an earlier local copy as permanently authoritative. Before release, record the ZIP revision or commit reviewed, compare normative language with the deployed library behavior, and identify unresolved proposal discussions that could affect interoperability. Repository history is also useful during incident analysis when two wallets interpret the same payment request differently or when a previously accepted edge case changes during specification review.