💻 computer science

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

This paper introduces Selective Disclosure Authorization Schemes (SDAS) and their Ethereum instantiation, ZK-Compliance, to enable granular, revocable regulatory compliance on public ledgers by binding zero-knowledge proofs to specific on-chain senders, thereby mitigating front-running and proof-reuse risks while preserving data privacy.

Original authors: Supriya Khadka, Sanchari Das

Published 2026-06-23

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Supriya Khadka, Sanchari Das

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine a public ledger (like a blockchain) as a giant, transparent glass wall where everyone can see every transaction. This is great for honesty, but it's terrible for privacy. If you need to prove you are over 18 to enter a digital club, the current way forces you to shout your actual birthdate to the whole world. You either reveal your secret or you can't get in.

This paper proposes a new way to solve that problem using a "magic trick" called Zero-Knowledge Proofs (ZKPs), combined with a strict security rule to stop thieves from stealing your trick.

Here is the breakdown of their solution, ZK-Compliance, using simple analogies:

1. The Problem: The "Glass Wall" and the "Thief"

The Transparency Trap: In a normal blockchain, if you want to prove you are eligible (e.g., "I am over 18"), you usually have to post your real data on the wall. Once it's there, it's permanent and visible to everyone.
The Thief's Window: Even if you use a "magic trick" (a ZKP) to prove you are over 18 without showing your birthdate, there is a delay. You generate the proof on your computer, but it has to travel through a public waiting room (the "mempool") before it gets recorded.
The Attack: A thief standing in that waiting room can see your valid proof, grab it, and run to the club door first, pretending they are the one who generated the proof. This is called "front-running."

2. The Solution: The "Wristband" that Only Fits You

The authors created a system called SDAS (Selective Disclosure Authorization Scheme). Think of it as a smart wristband system for the digital club.

The Magic Trick (The Proof): Instead of showing your birth certificate, you use a special computer program (a "circuit") to generate a digital receipt. This receipt proves, "Yes, this person is over 18," but it contains zero information about who that person is or when they were born.
The Security Glue (Sender Binding): This is the paper's main innovation. The system takes that digital receipt and "glues" it to your specific digital wallet address (your unique ID).
- The Analogy: Imagine the receipt is a ticket. In the old system, anyone could pick up a dropped ticket and use it. In this new system, the ticket is printed with a hologram that says, "This ticket only works if held by Alice."
- If a thief tries to grab your ticket and use it with their own ID, the hologram doesn't match, and the club bouncer (the smart contract) immediately rejects it.

3. How It Works in Real Life (The "Grant, Verify, Revoke" Cycle)

The paper tested this on a test version of Ethereum (Sepolia) and created a three-step process:

Grant (The Magic Show): You go to your browser, and a small program (running in under 200 milliseconds—faster than a blink) creates your proof. It checks your birth year against the age limit, adds a secret "salt" (like a random spice to prevent guessing), and binds the proof to your wallet. You send this to the club.
Verify (The Bouncer Check): The club's smart contract checks two things:
- Is the math on the proof correct? (Did you really prove you are over 18?)
- Crucially: Does the proof match the person holding it? (Is the wallet address on the proof the same as the one sending the transaction?)
- If both match, you get in. If a thief tries to use your proof, the check fails because the "glue" doesn't match their wallet.
Revoke (The Cut): If you want to leave the club or stop the dApp from having access, you can press a button to "cut" your wristband. The system deletes your access record. The club knows you left, but they still don't know your birthdate.

4. The Results: Fast and Cheap

The authors built a prototype and tested it. Here is what they found:

Speed: Generating the proof on a regular laptop takes less than 200 milliseconds. It's fast enough for a normal website.
Cost: Checking the proof on the blockchain costs about 240,000 "gas" units (the currency used to pay for blockchain transactions). While not free, it is a fixed, predictable cost that proves the system is practical.
Security: In their tests, when they tried to simulate a thief stealing a proof and using it from a different wallet, the system successfully blocked the transaction every time.

Summary

This paper introduces a way to prove you follow the rules (like being old enough) on a public, transparent blockchain without revealing your secrets. The key innovation is binding the proof to the specific person sending it, so even if a thief steals the proof while it's waiting in line, they can't use it because the "lock" on the proof only fits the original owner's key.

The authors call this ZK-Compliance, and they show it works quickly and securely, turning a "transparency trap" into a privacy-preserving security system.

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

Problem Statement
Public distributed ledgers, such as Ethereum, enforce integrity through radical transparency, which conflicts with data minimization principles required for regulatory compliance. While Zero-Knowledge Proofs (ZKPs) theoretically allow users to prove statements (e.g., age or residency) without revealing underlying data, existing constructions face critical adversarial constraints in smart contract environments. Specifically, the asynchronous nature of blockchain transactions creates a vulnerability: proofs generated off-chain are submitted to a public mempool before inclusion. This delay allows adversaries to observe valid proofs and "front-run" or replay them in different transaction contexts (e.g., from a different sender address or to a different contract). Standard ZKPs guarantee witness knowledge but do not inherently bind the proof to the specific on-chain sender, creating a "transparency trap" where over-disclosure or proof reuse compromises privacy and authorization integrity.

Methodology: Selective Disclosure Authorization Schemes (SDAS)
To address these gaps, the authors formalize Selective Disclosure Authorization Schemes (SDAS), a cryptographic primitive designed for granular, revocable compliance checks that do not reveal underlying witnesses. The framework treats authorization not as a stateless proof presentation, but as a verifiable state transition bound to a specific execution context.

Formal Model: The SDAS model defines an execution context tuple $\Gamma = (\chi_{addr}, \chi_{chain}, \chi_{contract})$ , corresponding to the Ethereum Virtual Machine variables msg.sender, block.chainid, and address(this). A valid authorization proof must attest to a relation $R(w, \Gamma)$ , ensuring the proof is cryptographically bound to this coordinate space.
Security Definitions: The paper introduces two core security properties:
- Ledger-Bound Attribute Unlinkability: Ensures that an on-chain authorization record reveals no information about the specific underlying witness (e.g., birth year), distinguishing between transactional linkability (the address) and attribute linkability.
- Context-Aware Sender Binding: Ensures a proof generated for a specific context cannot be reused in a different context or by a different sender.
ZK-Compliance Prototype: The authors instantiate SDAS as ZK-Compliance, an Ethereum-based system implementing a user-controlled "Grant, Verify, Revoke" lifecycle.
- Circuit Design: The system uses a 14-constraint Circom circuit (AgeCheck) based on the Groth16 scheme over the BN128 curve. The circuit takes public inputs (current year, age threshold, requesting address) and private witnesses (birth year, random salt). Crucially, it constrains the public address input ( $x_{addr}$ ) such that the circuit consumes the sender's address, making the proof invalid if submitted by a different msg.sender.
- Execution Flow: The client generates the proof locally using SnarkJS, binds the public input to the wallet address, and submits a signed transaction. The on-chain verifier first checks if the bound address matches msg.sender before performing cryptographic verification, immediately reverting if a mismatch occurs.

Key Contributions

Formalization of SDAS: The paper introduces a new authorization architecture that separates attribute validity from stateful on-chain authorization, modeling authorization as a verifiable state transition.
Context-Aware Binding: The authors define and implement Context-Aware Sender Binding, a mechanism that anchors zero-knowledge proofs to the executing msg.sender to neutralize mempool front-running and proof-reuse attacks.
Practical Instantiation: The work presents ZK-Compliance, a browser-native Ethereum prototype that operationalizes the "Grant, Verify, Revoke" lifecycle without relying on persistent identity custodians.

Experimental Results
The authors evaluated ZK-Compliance on the Sepolia test network:

Client-Side Performance: Proof generation (witness generation + proof construction) executed in under 200 ms (specifically 184 ms) on a consumer-grade MacBook Air (M2, 16GB RAM) using WebAssembly.
On-Chain Cost: The verification transaction cost 240,512 gas, covering sender anchoring, BN128 pairing verification, and storage of the access record.
Security Validation: Simulations confirmed that when an adversarial wallet attempted to reuse a captured proof from a different address, the contract rejected the transaction due to the sender mismatch, successfully preventing unauthorized access transfer.

Significance and Claims
The paper claims that ZK-Compliance demonstrates the feasibility of sender-bound selective disclosure authorization on public ledgers. By treating authorization as a context-bound state transition rather than a stateless proof, the system reduces reliance on centralized identity repositories while preserving strict attribute privacy. The authors assert that this approach offers a practical path for regulatory compliance (e.g., age verification) that is auditable, time-bounded, and revocable, without exposing sensitive user data to the public ledger or vulnerable to mempool-based replay attacks.

Limitations
The authors note that the current prototype focuses primarily on sender binding; cross-chain and cross-contract binding (anchoring to block.chainid and address(this)) remain extensions for future work. Additionally, the current revocation mechanism deletes state but does not yet implement stateful nullifiers (e.g., using Poseidon hashes) to prevent the reactivation of revoked access via stale proofs, a necessary feature for production deployment.