A human funds a wallet once. An agent can then pay for an API, a file, or a tool without a company card. A seller publishes a pay link. If the agent hits that link unpaid, Rill returns HTTP 402 with how to pay. After payment, Rill unlocks a receipt. Humans fund. Agents pay. Sellers get paid.
Today those pays use MPP and x402. This grant adds a shielded ZIP-321 option. The 402 includes a zcash: URI (unified address, amount, memo = resource_id). A human in Zashi pays shielded. The seller watches with a viewing key and cannot spend from the server.
What it is not: not a ZEC checkout, not a Wave exchange, not quests, not a local wallet plugin. Last mile on lomi. is later, not this grant. Privacy is on the pay.
Could you explain what concrete functionality this grant would deliver that does not already exist in CipherPay?
More specifically, which technical capabilities need to be developed from scratch rather than integrated or reused from existing Zcash payment infrastructure?
Thanks for the question. You are right to ask it. CipherPay covers more of the Zcash side than our application made clear.
What we would reuse, not build
Detection. CipherPay already does viewing-key trial decryption, mempool plus confirmation, and per-invoice diversified addresses. It is MIT; self hosting still needs a CipherScan endpoint. nerdcash ships the same job as a single-merchant sidecar. Milestone 2 as written was a lightwalletd plus UFVK scanner. That is a duplicate, so we dropped it. Detection sits on CipherPay or nerdcash, whichever the seller prefers.
ZIP-321 URIs. CipherPay, zpay, nerdcash, and our lab all emit them. Not grant-worthy on its own.
HTTP 402 on Zcash. The cipherpay/x402 package already verifies x402 v2 and MPP. zpay already speaks GET /x402/v2/supported, POST /verify, and POST /settle with a PCZT binding. We will call one of those, not write a third facilitator.
Nothing in this proposal requires new Zcash protocol or wallet infrastructure.
What we would build
CipherPay is a Zcash processor. A seller uses it to accept ZEC. zpay and x402-zcash are facilitators with different exact payloads, so an agent has to pick one dialect and stay there.
Rill is a payment control plane for software agents, not tied to one chain. A seller publishes one pay link. The 402 lists MPP and x402 on Base and Tempo. The agent pays on whichever rail it has. The seller gets one receipt shape and one balance.
The work is to add shielded ZEC as one of those rails, without forcing the seller onto a Zcash-only stack:
Accept adapter. A Zcash term in the same HTTP 402 and the same Accept middleware (userill/accept on npm) as MPP and x402. Use whichever facilitator dialect the seller already chose: txid after broadcast (CipherPay), PCZT before broadcast (zpay), signed raw tx (x402-zcash); we consume all three. Normalize to one receipt { resource_id, receipt_id, txid, status } (final for depth, settled for reorg-safe unlock). Sellers who would never sign up for a Zcash processor get shielded pay next to the rails they already offer.
Spend rail. A human funds a capped Rill wallet. The agent never holds a Zcash spending key. Rill pays the shielded 402 under that cap. Preferred dialect is zpay’s PCZT binding (verify before broadcast). CipherPay’s agent path is a Zipher wallet running beside the agent with a local spend policy; the seed lives on that machine. Rill keeps the seed off the agent side entirely: a human funds the wallet by card, Rill’s policy caps it, and a Zallet sidecar signs the PCZT. Same shape as our Base and Tempo Spend today. Custody is the same as our existing Spend path: Rill signs from a server-held shielded wallet under per-agent caps. Sellers do not give Rill a viewing key beyond what their facilitator already needs. We are not asking anyone to move funds through a new Zcash processor.
Directory. Mark which listed endpoints accept shielded ZEC, including CipherPay merchants, so agents have a reason to hold ZEC.
We will update the GitHub issue so the milestones match: reuse detection and the Zcash-side facilitator; build the adapter, the Spend rail, and the directory. If a Rill rail on the CipherPay facilitator is useful to its team, we would rather wire that than run anything parallel.
Thank you for the submission. The committee has reviewed it alongside community feedback gathered on the forum, and after consideration, ZCG has decided against moving forward. We value the energy you invested here and hope you’ll continue participating in the Zcash community. Meeting minutes.