Frontier-Compute/zcash-mcp

ZAP1 receipts for Zcash agents: verify workflows without trusting the server.
ZAP1 is an attestation and proof rail for Zcash workflows. Frontier Compute
maintains the reference ZAP1 implementation.
A wrapper makes you trust the server. ZAP1 makes the server unnecessary to
trust.
Core rule: observe state, bound the claim, hash evidence, issue a receipt,
verify later.
MCP is the standard way for AI agents to call external tools. zcash-mcp
exposes the ZAP1 attestation layer for agents that need verifiable receipts
around Zcash workflows: create ZAP1 attestation leaves, query anchor state,
and verify proof receipts.
This is not a full wallet MCP. Balance scanning, private key custody, seed
handling, PCZT signing, shielded spend construction, and lightwalletd or Zaino
wallet synchronization are complementary wallet-layer work, not this server's
scope.
Why ZAP1
Wallet MCPs can move value. ZAP1 proves the workflow around the value, and the
counterparty can verify the proof without trusting Frontier.
Tool servers expose what a backend says right now. ZAP1 produces a receipt that
another party can verify later from the schema, proof material, and Zcash anchor.
ZAP1 is the proof rail for Zcash agent workflows:
1. attest: create a typed event leaf.
2. anchor: commit leaves into a Merkle root anchored to Zcash.
3. prove: return a receipt packet for a leaf.
4. verify: let another party check the receipt without trusting the original
agent.
Agent systems need more than a payment or a transaction lookup. They need a
receipt that another agent, user, auditor, or service can verify later:
- what event was asserted
- which agent or workflow asserted it
- which ZAP1 leaf records it
- which Merkle root includes it
- which Zcash transaction anchored that root
- how to verify the proof without trusting the original agent
That is the lane for this server. It gives Zcash agents a receipt layer that can
sit beside any wallet, signer, custody system, lightwalletd stack, Zaino stack,
or application-specific payment flow.
See ZAP1 Proof Rail for the category boundary,
receipt model, integration pattern, and red-team rejects. See
ZAP1 Conformance for the receipt contract agents
and integrations should satisfy. See
Wallet Receipt Integration for the
wallet-action handoff pattern. See
External Rail Receipts for generic
external-action receipt requests, and
Receipt Disclosure Profiles for
public, counterparty, auditor, grant, compliance, and internal packet shapes.
Capability Boundary
The zcash_capability_manifest tool gives agents a machine-readable scope map:
- covered here: ZAP1 receipts, lifecycle attestations, proof verification, anchor
state, memo decoding, and public chain context
- excluded here: custody, seed handling, balance scanning, PCZT signing,
shielded spend construction, and wallet-server synchronization
- composition rule: use this server before or after wallet-layer actions to
create, query, and verify receipts
Good fits:
- agent action receipts
- payment and invoice proof packets
- wallet action receipts
- external action receipts
- operator lifecycle events
- grant proof packets
- compliance audit packets
- policy and reputation attestations
- public anchor verification for private workflows
- cross-agent handoffs where the receiver needs proof, not custody
Poor fits:
- holding keys
- scanning wallet balances
- signing PCZTs
- broadcasting shielded spends
- replacing a wallet SDK
Customer Flow
Use zcash_receipt_template first when you are wiring ZAP1 into a product. It
returns a customer-ready workflow for the receipt type you want:
- agent_action: prove an agent performed a named action with specific input
and output hashes
- payment_receipt: bind invoice or payment metadata to a ZAP1 leaf and later
prove inclusion under an anchored root