Build Zcash applications

Zcash application integration recipes

Zerynex is a developer integration toolkit, not a single-purpose website or a replacement wallet. These patterns show how to use the tested, composable building blocks in real Zcash products. They address reusable needs across the Zcash ecosystem, including wallet infrastructure, private payments, cross-chain integrations, policy tooling, and automated testing.

Building blocks you can use now

Shielded Payments: guard checkout infrastructure

On your private backend, require a correct and sufficiently synchronized chain before polling for a deposit or generating a wallet handoff:

from zerynex_py import inspect_node_local

node = inspect_node_local(expected_network="test", port=8232)
if not node.ready:
    raise RuntimeError("Checkout temporarily unavailable: node sync/network check failed")

# Next: call the REAL wallet/payment provider that your application controls.
# Zerynex does not construct invoices, confirm deposits or authorize spends.

The wallet or checkout application can additionally use ZIP-321 request validation to parse supported ZEC requests and exact zatoshi amounts before handing them to a trusted wallet. It remains responsible for selecting supported Unified Address receivers, constructing ZIP-321 payment requests, confirming deposits and handling chain reorganizations. Don't expose the customer's payment details or an RPC cookie to the browser.

Private Markets: test policy boundaries before signing

If your wallet backend passes a PCZT from builder → prover → signer, run each intermediate PCZT through local Rust checks. Deny transparent components for a shielded-only product policy, not because Zcash prohibits them. The checked-in synthetic vectors exercise both clean and violating cases.

zerynex synthetic-before.pczt --compare-with synthetic-after.pczt \
  --deny-transparent --sarif > local-findings.sarif

Use synthetic fixtures in public CI; run checks on confidential actual PCZTs only within your own trusted deployment. This does not prove a market's privacy, commitment correctness, escrow rules, or solvency.

Cross-Chain: prevent wrong-network assumptions

A bridge adapter or relayer can check the Zcash side's expected network and sync status before considering a cross-chain transfer ready for subsequent processing:

import { evaluateZcashNodeStatus } from '@zerynex/sdk'
const status = evaluateZcashNodeStatus(zcashChainInfoFromYourTrustedBackend, {
  expectedNetwork: 'test',
  maxHeaderLag: 2,
})
if (!status.ready) throw new Error('Zcash leg not ready for relayer processing')

A Zebra node may omit the required initial-sync field; in that case ready remains false until an independently verified readiness policy is available. See Node readiness. This is a precondition, not cross-chain settlement or proof of finality. Bridging needs independent light-client, confirmation, proof and replay-protection design.

Core & Tooling: reusable SDKs, CI and integrations

Use the Node.js-compatible normalizer and Python loopback probe in indexers, explorer backends, monitoring tools, developer dashboards, GitHub Actions runners and local integration tests. Pair it with Zerynex's CLI capability discovery and versioned privacy rule registry so your tooling can reject unsupported protocol versions.

For a runnable integration contract and security model, see Node readiness, TypeScript SDK, Python SDK, GitHub Action, and Privacy rule registry.

Composable developer workflows: verify boundaries independently

Prototype merchant tooling, privacy monitors, AI-assisted development or wallet workflow automation by combining offline structural checks, read-only node state, and application-owned signing/payment systems. Keep MCP agents restricted to approved synthetic fixtures. A passed preflight or rule report must never become an unconditional wallet-signing instruction.

Compatibility evidence: Local parsing and normalization are tested against shared synthetic Zebra/zcashd response fixtures; a mock local HTTP node is used to exercise the transport and authentication. Production Zallet/Zebra nodes, live wallet handoff, private payments and bridge contracts have not been validated by this page.

Wallet-provider integration boundary

Use the wallet handoff coordinator to combine local ZIP-321 validation, exact-zatoshi and expected-network policies, declared trusted-provider capabilities, and an explicit host authorization callback. Handing a URI to a wallet is not confirmation of payment. Never grant autonomous agents access to the host authorization or provider-presentation methods.

Read-only transaction confirmations for checkout and relayers

Use Transaction observations to normalize an existing trusted backend’s getrawtransaction(txid, 1) and getblockchaininfo results. Your app chooses the expected network, expected transaction ID, and confirmation threshold. The SDK reports whether the node's own confirmation values are internally consistent and can flag possible reorganizations across observations. This does not verify who received funds, wallet ownership, finality or cross-chain settlement.

Cross-chain refund and viewing-key isolation metadata

Use the offline swap refund privacy auditor to check explicitly declared refund-address and viewing-scope reuse across exchange flows and flag direct lookup/custody concerns. A public refund identifier and a reused viewing scope can be a long-term privacy concern; this tool does not obtain keys, verify cryptographic isolation or implement quantum resistance. No Zcash address, memo or wallet secret belongs in audit manifests.