ZKIW: Zero-Knowledge Payment Proof Layer for Privacy and Compliance

Abstract

1. Introduction

Traditional payment systems require revealing detailed financial information—amounts, payer and payee identifiers, timestamps, and transaction references—whenever a payment needs to be audited or verified by a counterparty or regulator. This approach creates unnecessary data exposure, elevates privacy risks, and complicates regulatory compliance.

ZKIW addresses this problem by introducing a payment proof layer that sits alongside existing payment rails. Merchants continue to use their current payment gateways and processors. ZKIW captures payment attestations from those systems and transforms them into zero-knowledge proofs of payment validity. A proof can then be shared, verified, optionally anchored on-chain, and selectively disclosed to auditors or regulators, all without revealing the underlying sensitive data.

ZKIW is designed for:

• Merchants needing to prove payment completion for B2B relationships and compliance.
• Auditors and regulators requiring verifiable attestations without direct access to raw payment data.
• Developers integrating privacy-preserving payment verification into their products and workflows.

2. Design Goals

ZKIW is built around the following design goals:

1. Privacy by default
   Payment proofs must not expose sensitive financial data (amounts, identities, raw transaction IDs) unless explicitly disclosed through controlled mechanisms.
2. Compatibility with existing rails
   ZKIW must integrate with conventional bank transfers, card processors (e.g., Stripe/PayPal/Square), and on-chain stablecoins, without requiring changes to the underlying payment rails.
3. Strong cryptographic integrity
   Proofs must be backed by zero-knowledge circuits and cryptographic primitives that provide formal guarantees on correctness and soundness.
4. Auditability and compliance
   The system must support selective disclosure, structured audit trails, and regulator-oriented views, enabling compliance workflows without mass data exposure.
5. Production deployment
   ZKIW must be deployable in real-world environments: containerized services, on-chain registries, documented infrastructure, and observability tooling.
6. Formal verification support
   Critical invariants and cryptographic assumptions should be modeled and machine-checked in Lean, providing a formal layer of assurance supplementing conventional tests and audits.

3. System Overview

At a high level, ZKIW acts as an intermediary proof generation and verification layer between existing payment flows and consumers of payment evidence (merchants, counterparties, auditors, regulators).

3.1 Architecture

The high-level architecture is:

• Merchant Website and payment gateway
  Initiates payments via existing payment processors. Emits payment attestations after successful settlement.
• ZKIW Client SDK
  Captures attestations in the browser or backend. Sends them securely to ZKIW backend services. Receives and renders payment proofs for end-users.
• ZKIW Backend Services
  Ingestion APIs per payment rail. Proof generation and lifecycle management. On-chain registry integration and usage metrics.
• Zero-Knowledge Proof Generator
  Implements Circom-based circuits. Uses SnarkJS (or a comparable proving stack) for proof generation and verification.
• On-Chain Registry
  Solidity contracts to register and verify proof commitments. EVM-compatible deployment on mainnet and L2s.
• Auditor & Dashboard Frontends
  Merchant dashboards for analytics and configuration. Auditor portal for proof verification and selective disclosure.
• Formal Verification Layer
  Lean models for cryptographic assumptions and abstract protocol invariants. CI-integrated theorem checking to guard core properties.

3.2 Core Data Flow

The core steps for a payment are:

1. Payment Processing
   A user completes a payment using the merchant's existing payment gateway (bank, card, or stablecoin).
2. Payment Attestation
   The payment processor or gateway emits a signed attestation that encodes the relevant payment data in a structure defined by the specific rail adapter (bank, card, stablecoin).
3. SDK Capture
   The ZKIW Client SDK receives the attestation, validates its structure, and submits it to the ZKIW Backend over HTTPS/TLS.
4. Backend Validation
   The Backend validates the attestation, verifies signatures, and stores a normalized payment record in a PostgreSQL database. The payment record includes hashed or committed versions of sensitive fields.
5. Proof Generation
   The ZK Proof Generator service transforms the payment record into a witness compatible with the Circom circuit payProof.circom, runs proof generation with Groth16/PLONK, and stores the resulting proof and public inputs in a dedicated proof records table.
6. On-Chain Registration (Optional)
   If merchant configuration enables on-chain anchoring, the Proof Generator invokes the on-chain registry smart contract to register the proof commitment on an EVM-compatible network. The transaction hash and on-chain record are stored.
7. Proof Delivery & Receipt
   The SDK or dashboard retrieves the generated proof and presents it as a cryptographic receipt. Merchants and auditors can export this receipt in JSON or a portable file format for offline verification.
8. Verification & Audit
   Counterparties, auditors, and regulators use either ZKIW's verification endpoints and portals or client-side verification tooling (SDK / CLI) to verify the proof against the public circuit parameters and optionally the on-chain registry. Additional details can be selectively disclosed according to policy and regulator needs.

4. Components

ZKIW is organized as a monorepo with clear package boundaries and documentation.

4.1 Client SDK (@zkiw/payproof-sdk)

The Client SDK is a browser/Node.js TypeScript library that integrates ZKIW into merchant flows.

Responsibilities:

• Initialize with merchant credentials, configuration, and environment.
• Capture and validate payment attestations from payment gateways.
• Communicate securely with backend ingestion and proof services.
• Provide APIs to request proof generation, poll for proof status, trigger on-chain registry registration, and export proofs and verification bundles.
• Offer UI components (widgets) to present proof status and receipts.

Key features:

• Multi-rail support: bank, stablecoin, and card adaptors.
• Strong type definitions and validation.
• Error handling and retry policies for network workflows.
• Lightweight UI widget for proof receipts, embeddable in merchant UIs.

4.2 Backend Services

The Backend is a set of Node.js/TypeScript services exposed via HTTP APIs.

4.2.1 Ingestion API

Endpoints:

• POST /ingest/bank – Accepts bank payment attestations.
• POST /ingest/stablecoin – Accepts stablecoin transfer attestations.
• POST /ingest/card – Accepts card payment attestations.
• GET /health – Health check for monitoring.

Responsibilities:

• Verify structure and authenticity of attestations from banks, stablecoins, and card processors.
• Normalize and store payment records in PostgreSQL with hashed sensitive fields and cryptographic commitments.
• Enforce authentication (API keys), rate limiting, and request logging.
• Publish events to the Proof Generation service for asynchronous processing.

4.2.2 Proof Generation Service

Endpoints:

• POST /proof/generate – Trigger proof generation for a payment.
• GET /proof/:id – Retrieve full proof artifact and public inputs.
• GET /proof/:id/status – Inspect proof generation status.
• POST /proof/:id/register – Trigger on-chain registration.

Responsibilities:

• Construct the witness from stored payment records.
• Run Circom-based proof generation (Groth16/PLONK) using finalized circuits and keys.
• Validate the proof pre-storage using verifier keys.
• Store proof artifacts, public inputs, and registration status.
• Interact with smart contracts for on-chain registration when configured.

4.3 Zero-Knowledge Circuits (payProof.circom and helpers)

The main circuit payProof.circom encodes the constraints for payment validity without exposing raw details.

Public inputs:

• commitment: cryptographic commitment to the underlying payment data.
• rail: payment rail identifier (bank, stablecoin, card).
• processorRoot: Merkle root of authorized payment processors.

Private inputs:

• amount: payment amount.
• payerHash: hashed identifier of the payer.
• payeeHash: hashed identifier of the payee.
• timestamp: payment timestamp.
• settlement: settlement status flag.
• salt: random salt used in commitment generation.
• signature: EdDSA signature from the payment processor.
• processorPubKey: public key of the payment processor.
• merkleProof: Merkle proof path demonstrating the processor is authorized.

Constraints:

1. The payment amount is positive.
2. Settlement flag is valid (binary).
3. The rail identifier is within the allowed set.
4. Timestamp satisfies configured temporal bounds (staleness constraints).
5. Commitment is consistent with the hashed payment data and salt.
6. EdDSA signature is valid for the given processor public key and payment data.
7. Merkle proof confirms the payment processor is part of the authorized set.

Helper circuits provide Poseidon hashing, EdDSA verification, and Merkle tree membership checks.

4.4 Smart Contracts (PaymentProofRegistry)

The ZKIW registry is an on-chain contract deployed on Ethereum and selected L2 networks.

Core functions:

• registerProof(bytes32 commitment, uint8 rail, bytes proof)
  Stores proof metadata and links it to a commitment and rail type.
• verifyProof(bytes32 commitment, bytes proof)
  Verifies that a submitted proof matches a stored commitment and is valid according to the generated verifier contract.
• getProof(bytes32 commitment)
  Retrieves stored proof metadata or pointers to off-chain proof data.
• updateProcessorRoot(bytes32 newRoot)
  Maintains the Merkle root of authorized processors.

Events:

• PaymentProofStored(bytes32 indexed commitment, uint8 rail, uint256 timestamp)
  Emitted when a proof is registered on-chain.
• ProcessorRootUpdated(bytes32 indexed oldRoot, bytes32 indexed newRoot)
  Emitted when processor authorization state changes.

Smart contracts are integrated into a Hardhat/Foundry development and deployment workflow, with full unit and integration tests and external audits.

4.5 Database Layer

PostgreSQL stores:

• Merchant configurations and API keys.
• Payment records, including committed representations of sensitive data.
• Proof records and linkage to on-chain registrations.
• Processor keys and Merkle tree data.
• Usage metrics for the merchant dashboard.

The schema is designed for efficient retrieval of payment and proof histories for both merchant dashboards and auditor queries.

4.6 Developer Dashboard and Auditor Portal

ZKIW includes web frontends for:

Merchant Dashboard

• API key management.
• Rail configuration (bank, stablecoin, card).
• On-chain registration preferences.
• Usage analytics and proof histories.
• Monitoring and status views for backend and proof services.

Auditor Portal

• Upload and verify proof receipts.
• View proof details and selective disclosures.
• Request and track extended disclosures from merchants.
• Batch verification of large proof sets.
• Immutable audit logs of proof verification and disclosure events.

5. Privacy, Selective Disclosure, and Compliance

ZKIW is designed for privacy-preserving compliance in regulated environments.

5.1 Privacy Model

Sensitive payment data (amounts, identities, raw transaction IDs) remain off-chain and off-proof by default. The zero-knowledge proof only reveals:

• That a payment satisfying the circuit constraints took place.
• The rail and commitment.
• Any intentionally exposed attributes or ranges, where configured.

Raw data is committed using cryptographic hashes and never appears in the public inputs unless configured as part of selective disclosure.

5.2 Selective Disclosure

Selective disclosure allows merchants to reveal specific attributes—such as an amount range, a pseudonymous identifier, or particular regulatory flags—without disclosing the entire underlying payment details.

The selective disclosure mechanism encompasses:

• Extended circuit parameters or companion proofs that reveal controlled subsets of data.
• Policy-controlled access via the dashboard and auditor portal.
• Regulator "view keys" for highly controlled decryption or attestations in edge cases where complete visibility is legally mandated.

Disclosure flows are auditable: each disclosure event is recorded with enough metadata to trace who requested what and how it was granted.

5.3 Compliance Workflows

ZKIW supports common compliance scenarios:

• Providing proofs of payment completion and settlement for tax and accounting workflows.
• Providing regulators with assurances that certain classes of payments comply with predefined constraints, without revealing full transaction logs.
• Enabling cross-border or B2B partners to verify payment proofs instead of requiring duplicated bank statements or raw logs.

The system's logging and audit features create a verifiable trail of:

• Proof generation events.
• Proof registration on-chain.
• Verification requests and results.
• Disclosure and access grants.

6. Verification and Lean Formal Methods

A key differentiator of ZKIW is the use of formal verification techniques to model and check critical protocol invariants.

6.1 Formal Methods Objectives

The Lean-based verification package focuses on:

• Abstract modeling of the payment proof protocol, including commitments, proof validity, and Merkle membership for processors.
• Capturing and proving invariants around uniqueness and consistency of commitments, correct relationship between stored records and on-chain registrations, and preconditions for valid verification of a given proof.

The goal is not to mechanically prove the full implementation in a low-level language, but to maintain a mathematically precise, machine-checked specification that aligns with the production architecture and circuits.

6.2 Lean Verification Package

The dedicated verification package (implemented in Lean) includes:

Data structures mirroring key protocol elements:

• Abstract representations of commitments, payment records, proofs, and registry states.
• Merkle tree structures for processor keys and their update rules.

Propositions and theorems:

• Conditions under which a proof is considered valid with respect to a commitment.
• Safety properties ensuring that misconfigured or malicious processor keys cannot break registry invariants.
• Invariants capturing that the registry does not contain conflicting entries for the same commitment under the same rail.

Connections to circuit-level assumptions:

• Formalizing the abstract properties expected from Poseidon, EdDSA, and Merkle-verification components, as they are instantiated in the Circom circuits.
• Establishing that if the circuits satisfy certain properties, then the end-to-end protocol inherits desired security and correctness guarantees.

Lean code is structured as a standalone library that mirrors core constructs used in the circuits and contracts packages.

6.3 CI Integration and Production Use

Formal verification is integrated into the continuous integration (CI) pipeline:

• A dedicated CI job runs Lean checks on every change affecting circuit specs, smart contract interfaces, and protocol documentation.
• Changes that introduce inconsistencies or break proven invariants are rejected by CI, forcing developers to update the Lean models or adjust the implementation.

In production, this results in:

• A continuously maintained correspondence between the conceptual payment proof protocol, the Circom circuits, and the Solidity registry.
• A verifiable chain of trust from mathematical models to deployed system behavior, supplemented by tests and audits rather than replaced by them.

7. Security Considerations

ZKIW incorporates security at multiple layers:

API and Backend Security

• API key-based authentication for merchants.
• Rate limiting and request throttling.
• Input validation at all ingress points.
• Separation of roles across services and limited exposure of internal endpoints.

Cryptographic Security

• Use of well-established ZK tooling (Circom, SnarkJS or equivalent).
• Strong hashing (Poseidon) and EdDSA signatures on a circuit-friendly curve for attestations.
• Proper management of proving and verification keys, including key rotation strategies.

Smart Contract Security

• Rigorous unit and fuzz tests.
• External audits for contracts and on-chain interactions.
• Secure key management and deployment tooling.

Formal Verification and Specification

• Lean models verifying key invariants and raising the bar for logical and protocol-level errors.
• CI enforcement ensuring that changes cannot silently diverge from the proven properties.

Operational Security

• Containerized deployment and hardened infrastructure.
• Observability, alerting, and incident response workflows.
• Configurable data retention and compliance with data handling policies.

8. Deployment and Operations

ZKIW can be deployed in multiple configurations:

Self-hosted

• Enterprises deploy the backend, proof generator, and dashboards within their own infrastructure.
• On-chain registry deployment can be shared or partitioned per tenant.
• SDK is integrated into merchant websites and applications directly.

Managed / SaaS

• ZKIW is operated as a multi-tenant platform.
• Merchants receive API keys, configuration, and hosted dashboard access.
• On-chain registry deployment and key management are handled centrally, with per-merchant routing logic.

A typical production deployment includes:

• A container orchestration platform for the backend, proof generator, and supporting services.
• Managed PostgreSQL for data storage.
• Blockchain node access via providers for stablecoin verification and contract interactions.
• CDN distribution for the SDK.
• Monitoring and logging for health, performance, and security events.

9. Use Cases

ZKIW supports a variety of real-world scenarios:

B2B Payment Reconciliation

Provide cryptographic receipts instead of sending raw bank statements and card logs, reducing operational overhead and privacy risks.

Cross-Border Payments

Share proofs of payment settlement with regulators in multiple jurisdictions without exposing full transactional detail.

Stablecoin Treasury Management

Provide on-chain anchored proofs of stablecoin flows for accounting, while keeping detailed internal ledger data private.

Auditor and Regulator Access

Offer an auditor portal that can verify proofs, request selective disclosures, and export verification logs, reducing friction in compliance processes.

10. Conclusion

ZKIW delivers a complete, privacy-preserving payment proof layer that integrates seamlessly with existing payment systems. By combining:

• A TypeScript-based SDK,
• Robust backend and proof-generation services,
• On-chain registries on EVM-compatible networks,
• Selective disclosure and auditor tooling, and
• A Lean-based formal verification layer integrated into CI,

ZKIW provides a high-assurance foundation for compliant, privacy-preserving financial workflows.

The architecture is designed to support both current and future payment rails, to evolve with the zero-knowledge ecosystem, and to remain grounded in clearly specified, mechanically checked protocol properties. This enables merchants, auditors, and regulators to rely on cryptographic payment evidence while reducing systemic exposure of sensitive transactional data.