Grant Application - Zcash MCP Server for AI Agent Integration

Community Grants Applications
1

GitHub Application: Grant Application - Zcash MCP Server for AI Agent Integration · Issue #300 · ZcashCommunityGrants/zcashcommunitygrants · GitHub (Issue #300)

The Model Context Protocol (MCP) is the emerging standard for AI agents to interact with external tools. Anthropic Claude, Cursor, Windsurf, and Trezor Suite all use MCP for agent-tool integration. Bitcoin, Ethereum, and Solana already have MCP servers. Zcash does not.

This grant builds a production-ready MCP server that enables AI agents to interact with Zcash natively — checking balances, generating addresses, constructing shielded transactions, and querying network state through standardized tool calls. No full node required. It connects to the modern light client stack (lightwalletd/Zaino) and supports Orchard and Sapling shielded pools.

What it does

The MCP server exposes 11 tools for AI agents:

  • Wallet Operations: Check balances across transparent, Sapling, and Orchard pools. Generate unified addresses. List transactions with pool filtering.
  • Shielded Transactions: Construct and submit shielded Orchard/Sapling sends with memo support. Shield transparent funds (coinbase shielding). Track async operation status.
  • Network State: Query network height, sync status, fee estimation (ZIP-317), and lightwalletd/Zaino server health.
  • PCZT Integration: Build Partially Created Zcash Transactions for hardware wallet signing workflows (Keystone, OneKey, Ledger).
  • Viewing Key Support: Import viewing keys for read-only wallet monitoring without spending capability.

Architecture: TypeScript MCP interface + Rust wallet engine (child process via stdio IPC). The Rust engine wraps canonical Zcash crates (zcash_client_backend, orchard, sapling, pczt) and connects to lightwalletd/Zaino via gRPC. This is the same pattern used by Ywallet, Zingo, and Zecwallet.

Why now

Three factors make this urgent:

  1. OWS (#255**) opened the door.** The Open Wallet Standard already includes Zcash with an MCP interface for agent wallet signing. But OWS manages keys and signs transactions — there is no standalone MCP server that provides comprehensive Zcash network interaction for AI agents.

  2. zcashd deprecation. The existing coin_daemon_mcp community project wraps zcashd RPC directly, which requires a full node being actively deprecated in favor of Zebra/Zaino. Our server uses the modern light client stack — no full node needed.

  3. AI agent ecosystem is maturing fast. Agentic payments are moving from experimental to production (x402, MPP, A2A). The chains with MCP servers get distribution through AI agents. The chains without don’t. If Zcash isn’t in the standard when it matures, adding it later gets harder.

What already exists

The proposal is technically validated against the actual codebase:

  • @modelcontextprotocol/sdk (npm v1.29.0, 35.7M weekly downloads) — confirmed available
  • lightwalletd CompactTxStreamer gRPC — all RPCs confirmed in service.proto
  • Zaino uses identical proto (packages/zaino-proto/) — backend compatibility verified
  • pczt crate in librustzcash (v0.6.0, MIT/Apache-2.0) — PCZT construction confirmed
  • ZIP-317 fee mechanism (StandardFeeRule::Zip317 in fees.rs) — fee calculation confirmed
  • zcash_client_backend structure (18 source files) — wallet engine integration path clear

Budget & Timeline

$20,000 — 8 weeks — 3 milestones

  • M1 ($8K, 3 weeks): Core MCP server + Rust wallet engine scaffold. 5 read-only tools (balance, address generation, transaction listing, network info, fee estimation). npm + Smithery publishing.
  • M2 ($6K, 3 weeks): Shielded transactions via Rust engine. Note selection, ZK proof generation, transaction submission. Tools: send_shielded, shield_funds, get_operation_status.
  • M3 ($6K, 2 weeks): PCZT construction, viewing key import, subtree root queries. Resources and prompts. Security review. Documentation.

Full application details with technical architecture, risk assessment, success metrics, and detailed acceptance criteria are in the GitHub issue linked above. Questions welcome.

@ZcashGrants

1 Like
Zcash Community Grants Meeting Minutes 05/25/2026
2
1 Like
3

This is for ZAP1 though it is not stated very clearly.

2 Likes
4

Thanks @artkor for the reference, good catch @hanh on the ZAP1 focus.

Just to clarify the difference between the two:

Frontier Compute’s MCP server is focused on the attestation layer - writing ZAP1 attestations to Zcash memos and querying attestation state. Pretty cool for proving off-chain data on-chain.

Ours is focused on the wallet layer - actual Zcash wallet operations:

  • get_balance queries real blockchain balances across transparent, Sapling, and Orchard pools (not attestation history)
  • send_shielded constructs and submits actual shielded transactions via zcash_client_backend (not just generating a zcash: URI)
  • no full node needed - connects to lightwalletd/Zaino via gRPC
  • PCZT construction for hardware wallet signing (Keystone, OneKey, Ledger)
  • viewing key import for read-only monitoring

They’re complementary and could even integrate nicely - an agent could use ours to send ZEC and then use Frontier Compute’s to attest the tx on-chain.

We mentioned their work in the proposal and see it as a building block in the broader Zcash + AI agent ecosystem rather than competing.

1 Like
5

Hey, just want to flag that Zipher already ships most of this and more. Our MCP server has 29 tools today, balance queries across all pools, shielded sends with memos, fund shielding, sync status, address validation, plus things this proposal doesn’t cover: x402/MPP paywall payments, cross-chain swaps via NEAR Intents, spending policy enforcement, human-in-the-loop approval flows, wallet lock/unlock, prepaid sessions, CipherPay merchant tools, and audit logging.

It’s pure Rust (no TypeScript wrapper), connects to lightwalletd/Zaino, uses the same canonical crates (zcash_client_backend, orchard, sapling), and is already in open beta.

The three tools in this proposal that we don’t have yet (PCZT construction, viewing key import, subtree roots) are straightforward additions, the crates and architecture are already there.

1 Like
6

You also can easily map a GraphQL (Zkool’s for ex) to MCP with a lib.

from graphql_api import GraphQLAPI, field
import uvicorn
from graphql_mcp import GraphQLMCP

server = GraphQLMCP.from_remote_url(
    url="http://localhost:8000/graphql",
    name="Zcash",
    headers={}  # Optional: auth headers
)

app = server.http_app()

if __name__ == "__main__":
    uvicorn.run(app, host="0.0.0.0", port=8001)
1 Like
7

Thank you for the mention. Quick clarification: Frontier’s zcash-mcp is intentionally not a wallet MCP, it exposes ZAP1 attestation and proof-verification primitives for agents that need verifiable receipts around Zcash workflows, wallet ops, PCZT signing, and lightwalletd/Zaino sync are complementary wallet-layer work, and I’ve tightened the README to make that boundary clearer.

8

Thank you for your submission. After consideration from ZCG and sufficient time for the community to provide feedback on the forum, the committee has decided to reject this proposal.

The committee appreciates your grant submission efforts and encourages you to continue as an active member of the Zcash community going forward!