Privacy-Preserving Compliance on Public Ledgers via Selective Disclosure Authorization Schemes

Source: arXiv:2606.20760 · Published 2026-06-18 · By Supriya Khadka, Sanchari Das

TL;DR

This work addresses the tension between the radical transparency of public blockchains and the privacy requirements of regulatory compliance, especially for selective disclosure of identity attributes. Existing zero-knowledge proof (ZKP) approaches offer privacy but overlook adversarial risks like mempool front-running and proof reuse across transactions or chains. The authors formalize Selective Disclosure Authorization Schemes (SDAS), a cryptographic primitive that enables granular, revocable on-chain authorization checks without revealing private attributes, and introduces new security notions: Ledger-Bound Attribute Unlinkability and Context-Aware Sender Binding. These ensure that proofs are unlinkable across authorizations and cryptographically bound to specific on-chain execution contexts (e.g., msg.sender).

To instantiate SDAS, they build ZK-Compliance, an Ethereum smart contract prototype implementing a “Grant, Verify, Revoke” lifecycle. The core novelty lies in a 14-constraint Circom ZKP circuit that binds the proof to the caller’s on-chain address, neutralizing front-running and replay attacks. The Sepolia testnet evaluation demonstrates practical feasibility with sub-200 ms client-side proof generation latency and on-chain verification costing roughly 240k gas. Overall, the system shifts authorization from stateless ZKP presentation to verifiable, stateful on-chain access control, preserving privacy while supporting revocation and usage control in a hostile blockchain environment.

Key findings

• ZK-Compliance uses a 14-constraint Circom circuit to bind zero-knowledge proofs to the msg.sender address for sender-bound authorization.
• Client-side proof generation latency is 184 ms total (42 ms witness gen + 142 ms proof construction) on a standard consumer device in browser.
• On-chain verification costs 240,512 gas on Ethereum Sepolia, including cryptographic checks and state updates.
• Sender binding prevents proof reuse by different callers: an adversary replaying a valid proof from a different address causes immediate contract revert.
• The SDAS security model introduces Ledger-Bound Attribute Unlinkability, ensuring proofs reveal no identifying attribute info despite on-chain linkage to msg.sender.
• Context-Aware Sender Binding guarantees that proofs are invalid if executed in a mismatched context (different msg.sender), preventing mempool front-running and replay.
• Revocation support allows users to delete on-chain access records without revealing underlying identity attributes, although stale proof prevention requires future nullifier extensions.
• Current prototype binds proofs only to sender address; chain ID and contract address binding remain future extensions.

Threat model

A powerful active adversary in a permissionless blockchain environment who can fully observe the public mempool including pending transactions, front-run or reorder transactions, replay proofs across addresses, contracts, or chains, and generate ZK proofs if possessing secret witness data. The adversary cannot break cryptographic assumptions of ZKPs and cannot forge digital signatures of other users. The environment is an open public broadcast channel with no trusted intermediaries or secure communication.

Methodology — deep read

The authors first define a formal threat model for authorization on public ledgers, assuming a strong adversary who can observe pending transactions in public mempools, front-run or replay proofs across senders, contracts, or chains, and generate proofs if possessing the witness. To mitigate these, they treat authorization proofs as context-bound capabilities tied to the execution context tuple Γ = (msg.sender, chain ID, contract address).

The Selective Disclosure Authorization Scheme (SDAS) is a tuple of five algorithms that support setup, keygen, proof generation (ProveAuth), on-chain verification (VerifyAuth), and revocation. ProveAuth takes a private witness (user attributes) and current ledger state to produce a zero-knowledge proof cryptographically bound to the target execution context. VerifyAuth ensures proofs valid only in that exact context update the authorization state on-chain.

ZK-Compliance is an Ethereum prototype implementing the verification logic and lifecycle using a 14-constraint zero-knowledge circuit in Circom 2.1. The chosen relation proves an age predicate (age ≥ 18) without revealing birth year, incorporates a random salt for entropy, and binds the proof to the caller's Ethereum address as a public input. Proofs are generated locally in the browser using SnarkJS with the Groth16 proving system over BN128 curve.

The contract enforces sender binding by checking that the public input address equals the tx sender (msg.sender) before running cryptographic proof verification via Ethereum precompiled BN128 pairing checks. Authorization state is maintained on-chain as access records with expiration timestamps.

Revocation is supported by deleting access records explicitly from the contract, though the prototype lacks a nullifier scheme to prevent stale proof replay after revocation. The evaluation uses the Sepolia public testnet. They measure client-side proof generation latency on a MacBook Air with an Apple M2, finding 184 ms total end-to-end, and observe an on-chain verification cost of 240,512 gas.

A concrete example: a user locally generates a ZKP proving age ≥ 18 bound to their wallet address, encodes the proof in transact-to-contract input, and submits a grantAccess transaction signed by their wallet. The smart contract validates the sender binding, verifies the proof, and updates the access record. An adversary replaying the transaction from a different wallet fails due to sender mismatch.

Reproducibility is supported by open-source Circom circuits and usage of SnarkJS, though the proving keys and code release status are not specified explicitly. The prototype circuit and contract code form a minimally viable demonstration focusing on sender binding and front-running defense; extensions for chain/contract binding and nullifiers remain future work.

Technical innovations

• Formalization of Selective Disclosure Authorization Schemes (SDAS) capturing ledger-bound attribute unlinkability and context-aware sender binding in the blockchain threat model.
• Introduction of a compact 14-constraint zero-knowledge circuit binding proofs to the executing Ethereum sender address to prevent proof reuse and mempool front-running.
• Operationalization of a user-controllable 'Grant, Verify, Revoke' lifecycle integrated with Ethereum smart contract state, shifting authorization to verifiable state transitions.
• Mitigation of cross-sender, cross-contract, and cross-chain replay attacks by binding proofs cryptographically to execution context Γ = (msg.sender, chainID, contract address).

Baselines vs proposed

• Client proof generation latency: Prior general zk-SNARK applications typically exceed 200 ms; ZK-Compliance achieves 184 ms end-to-end on consumer hardware.
• On-chain verification gas cost: 240,512 gas using Groth16 and BN128 precompile; baseline non-binding proofs would be cheaper but vulnerable to replay.
• Proof reuse attacks by different sender: Without binding, replay successful; with sender binding, all replay attempts rejected (contract revert).

Limitations

• Prototype only implements sender address binding; chain ID and contract address binding are described but unimplemented.
• Revocation does not prevent replay of valid unexpired proofs after revocation (no nullifier scheme currently).
• SDAS framework assumes underlying consensus security and fixed execution environment; adversarial miner timestamp manipulation mitigated only within tolerance.
• Evaluation limited to a single age predicate use case; generality to complex predicates and scalability untested.
• Does not address integration with existing decentralized identity or credential issuance frameworks.
• No formal performance comparison against other ZKP-based selective disclosure systems under adversarial front-running.

Open questions / follow-ons

• How to efficiently extend SDAS proof binding to incorporate chain ID and contract address for stronger contextual binding across cross-chain and multi-contract use cases?
• How to integrate stateful nullifiers or other mechanisms into SDAS to prevent stale proof replay and fully close revocation security gaps?
• Can the SDAS approach generalize to more expressive predicate languages and complex attribute-based authorization on-chain without prohibitive gas costs?
• What are practical trade-offs applying SDAS in high-throughput dApps, and how to optimize multi-proof aggregation or batch verification?

Why it matters for bot defense

Bot-defense systems using CAPTCHAs often require privacy-preserving verification of user attributes or compliance conditions without exposing sensitive data publicly. The SDAS framework and its Ethereum prototype ZK-Compliance offer a viable cryptographic approach to proving eligibility predicates (e.g., age, residency) selectively and revocably, while binding proofs tightly to the request context to prevent replay attacks common in transparent blockchain environments.

For CAPTCHA engineers, this work demonstrates that zero-knowledge based proof systems can be integrated into public ledger authorization with explicit mechanisms to mitigate front-running and replay risks induced by asynchronous off-chain proof generation and public mempools. The architecture of treating authorization as a stateful, context-bound lifecycle rather than stateless proof presentation informs designs for CAPTCHA-backed token gating or decentralized identity compliance protocols that require privacy, revocability, and robust spam or bot prevention aligned with regulatory constraints.

Cite

@article{arxiv2606_20760,
  title={ Privacy-Preserving Compliance on Public Ledgers via Selective Disclosure Authorization Schemes },
  author={ Supriya Khadka and Sanchari Das },
  journal={arXiv preprint arXiv:2606.20760},
  year={ 2026 },
  url={https://arxiv.org/abs/2606.20760}
}

Read the full paper

• arXiv:2606.20760 (abstract)
• arXiv:2606.20760 (PDF)