💻 computer science

Proof of Source of Funds: Efficient On-chain Provenance of Cryptoassets

This paper introduces Proof of Source of Funds (PoSoF), a cryptographic framework that enables users to generate zero-knowledge proofs verifying the compliant origin of their cryptoassets without revealing transaction history, thereby shifting the burden of regulatory compliance from centralized platforms to individual users while preserving financial privacy.

Original authors: Alireza Kavousi, István András Seres, Zhipeng Wang

Published 2026-06-10

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Alireza Kavousi, István András Seres, Zhipeng Wang

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 you are walking into a high-security bank. In the old days, the bank had a massive team of detectives who would spend hours, days, or even weeks digging through your entire financial history to make sure you weren't carrying dirty money. This was slow, expensive, and often made honest people feel like they were under constant surveillance.

Sometimes, these detectives would get it wrong. They might flag a perfectly clean person just because they once bought a coffee from a shop that later got caught selling something illegal. This is called a "false positive," and it freezes innocent people's assets.

The Problem with Current Crypto Rules
In the world of cryptocurrency (DeFi), there are no banks. Everyone is their own bank. Currently, to stop bad actors, platforms rely on those same "detectives" (third-party firms) to constantly scan the blockchain. If they find a link to a bad actor, they block the user. But this system has flaws:

It's reactive: It often catches the bad money after it has already entered the system.
It's fragile: Bad actors can easily trick the system by moving money through a few fresh, clean-looking addresses before depositing.
It hurts privacy: To prove you are clean, you often have to show your whole history, which destroys your financial privacy.

The New Idea: "Proof of Source of Funds" (PoSoF)
The authors of this paper propose a clever flip of the script. Instead of the bank (the platform) hiring detectives to hunt for your history, you (the user) become the detective.

Think of it like this:

Old Way: You walk up to the bank counter, and the teller starts asking, "Where did you get this money? Show me your receipts from 1995 to today."
New Way (PoSoF): You walk up with a sealed, magical envelope. Inside is a mathematical proof that says, "I guarantee that this money comes only from trusted, legal sources (like a regulated exchange where I passed ID checks)."

You don't open the envelope. You don't show the teller your receipts. You just hand them the envelope. The teller performs a super-fast, one-second check (like scanning a QR code) to verify the seal is unbroken and the math is correct. If it is, they let you in.

How Does the "Magical Envelope" Work?
The paper describes a system called Proof of Source of Funds (PoSoF). Here is the breakdown using simple metaphors:

The Map (The DAG): Imagine your money's journey as a map of paths. Some paths start at "Safe Zones" (like a KYC-compliant exchange). Some paths start at "Danger Zones" (unknown or blacklisted addresses).
The Filter: You take your map and cut out only the paths that start at Safe Zones. You ignore the paths that start at Danger Zones.
The Magic Proof: You use a special cryptographic tool (Zero-Knowledge Proof) to create a certificate. This certificate proves two things:
- "I have a valid path from a Safe Zone to my current money."
- "I am not lying about the path."
- Crucially: The certificate hides the rest of your map. The verifier (the platform) knows the money is clean, but they don't know which specific safe zone you used, nor do they see any of your other transactions.

Why is this better?

It's Proactive: You prove the money is clean before you try to deposit it. The bad money never gets a chance to enter the system.
It's Private: The platform doesn't need to see your whole life story. They only see the proof that the money is clean.
It's Fast for the Platform: The platform doesn't need a team of detectives. They just need a computer to check the "magical envelope" in a fraction of a second.
It's Hard to Cheat: The system uses a "flow" rule. Imagine water flowing through pipes. If you try to mix dirty water with clean water, the math proves you can't create more clean water than you started with. If you try to use the same clean transaction to pay for two different things, the system catches it.

Real-World Examples from the Paper
The authors tested this idea and showed it works:

Privacy Pools: Imagine a "Tornado Cash" style mixer where people hide their money. Usually, regulators hate these because criminals use them. With PoSoF, the mixer can say, "We only let money in if it has a valid 'Clean Source' proof." Now, the mixer stays private for everyone, but it's guaranteed to be free of dirty money.
Exchanges: When you deposit money into an exchange, instead of the exchange spending weeks checking your history, you just submit the proof. The exchange checks it in milliseconds.
Lending: If you want to borrow money without putting up a huge deposit (collateral), you can prove you have a long history of clean, steady income. The lender trusts you based on this proof without needing to know your name or see your bank statements.

The Bottom Line
This paper introduces a way for regular crypto users to prove their money is legal without giving up their privacy or making the platforms do all the heavy lifting. It moves the work from the "police" (the platform) to the "citizen" (the user), using advanced math to create a system that is faster, safer, and respects privacy.

The authors built a working prototype and found that generating this proof takes about 1.8 seconds on a normal laptop, and checking it on the blockchain costs very little (about 1.5 milliseconds). This suggests that a future where crypto is both private and compliant is actually possible.

Technical Summary: Proof of Source of Funds (PoSoF)

1. Problem Statement

The paper addresses the fundamental tension between financial privacy and regulatory compliance in Decentralized Finance (DeFi). Current compliance methodologies rely on two flawed approaches:

Fragile Binary Lists: Relying on inclusion/exclusion lists (allowlists/blocklists) which are easily evaded by transferring funds to fresh, unflagged addresses.
Retroactive Graph Analysis: Relying on centralized blockchain intelligence firms to continuously trace transaction histories. This approach is computationally expensive, suffers from high false-positive rates, and fails to prevent illicit funds from entering a protocol in the first place.

Furthermore, existing privacy-preserving solutions (e.g., Tornado Cash) have been sanctioned because they cannot distinguish between legitimate privacy and money laundering. Conversely, attempts to integrate compliance via retroactive "taint" tracking leave honest users vulnerable to "tainting attacks," where malicious actors intentionally mix illicit funds with legitimate ones to freeze honest users' assets. The paper argues that the current model of platform-side surveillance strips users of privacy and imposes heavy burdens on decentralized protocols.

2. Methodology

The authors propose Proof of Source of Funds (PoSoF), a paradigm shift from platform-side surveillance to user-side provenance. Instead of the platform tracing funds, the user locally generates a zero-knowledge proof (ZKP) demonstrating that their deposit originates exclusively from a set of compliant sources.

2.1 Unified Temporal DAG Abstraction

To handle heterogeneous blockchain structures (UTXO-based like Bitcoin and account-based like Ethereum), the authors formulate a unified temporal Directed Acyclic Graph (DAG) abstraction:

Nodes: Defined as temporal pairs $(a, h)$ , where $a$ is an address and $h$ is a deterministic sequence coordinate (block height, index). This creates unique snapshots of identity at specific times.
Edges: Represent value transfers between nodes, assigned a fractional capacity $v_e \le v(tx)$ .
Model: This abstraction unifies ledger histories into a generalized value-flow model, treating compliant capacity as a finite, non-inflationary resource.

2.2 Cryptographic Framework

The system utilizes Incrementally Verifiable Computation (IVC) via folding schemes (e.g., Nova) to achieve constant-time verification. The user extracts a compliant sub-DAG ( $G'$ ) from the global ledger ( $G$ ) and proves the satisfaction of rigorous state-transition predicates without revealing intermediate topology or specific origins.

The core predicates enforced by the zero-knowledge circuit include:

On-Chain Integrity & Distinctness: Every edge must have a valid inclusion proof (Merkle proof) mapping to a finalized on-chain transaction. Transactions must be distinct to prevent recycling a single compliant transaction across multiple branches.
Source Anchoring: Every source node in the sub-DAG must be a member of a pre-defined compliant set $C$ (e.g., KYC-compliant exchanges), verified via a positive inclusion proof (e.g., Merkle tree).
Edge Linkage: The receiver of an incoming edge must cryptographically match the sender of the outgoing edge, preventing topology forgery.
Temporal Ordering: Strict acyclicity is enforced ( $h_{in} < h_{out}$ ) to prevent time-travel exploits where future compliant inflows legitimize past non-compliant transfers.
Flow Solvency: For every intermediate node, the sum of outgoing fractional capacities must not exceed the sum of incoming capacities ( $\sum v_{out} \le \sum v_{in}$ ).
Terminal Execution Binding: The proof must bind to the specific target transaction payload ($txtarget$), ensuring the proof is non-malleable and valid only for the intended deposit.

2.3 Architecture

Prover: The user locally constructs the compliant sub-DAG and runs the IVC circuit. They extract a "clean" path, ignoring non-compliant edges (e.g., illicit dust received by the user).
Verifier: The smart contract performs a constant-time $O(1)$ verification of the succinct proof. It does not need to synchronize with dynamic blocklists or analyze the transaction graph.

3. Key Contributions

The paper makes three primary contributions:

Formalization of Prover-Side Provenance: The introduction of PoSoF, which shifts the compliance burden to the user. It establishes a unified temporal DAG abstraction that captures both account-based and UTXO ledgers under rigorous security definitions.
Efficient Protocol Instantiation: The construction of a PoSoF protocol using IVC to achieve constant-size, $O(1)$ on-chain verification. The system includes robust application-layer defenses (public nullifiers, private change commitments) to prevent double-spending of clean history.
Implementation and Empirical Evaluation: A working Ethereum-compatible prototype demonstrating that proactive compliance is practical on consumer hardware.

4. Results and Performance

The authors evaluated an Ethereum-compatible prototype using the Groth16 proof system (for a monolithic linear-path fragment) and Nova (for IVC).

Monolithic Prototype (Groth16):
- Proof Generation: On an Apple Silicon laptop, generating a proof for a path with 8 hops took approximately 37 seconds.
- Verification: On-chain verification cost was approximately 797,916 gas (approx. 1.5 ms), dominated by pairing checks.
- Constraints: The unified prover circuit required ~25.7 million R1CS constraints.
IVC Implementation (Nova):
- Incremental Updates: For an active wallet, updating the proof with a new transaction takes approximately 1.8 seconds.
- Verification: The final on-chain verification remains constant-time at ~1.5 ms (approx. 800k gas), regardless of the size or depth of the compliant sub-DAG.
- Scalability: While generating a chain from scratch under IVC has cumulative overhead, the marginal cost of adding a new transaction is constant and significantly lower than re-proving the entire history required by monolithic approaches.

5. Significance and Claims

The paper claims that PoSoF resolves the "fundamental tension between privacy and compliance" by enabling proactive, on-chain compliance layers.

Immunity to Tainting: By mathematically tracing funds back to a compliant origin and allowing users to exclude non-compliant edges from their witness, the system is indifferent to passive "tainting." An honest user who receives illicit funds can simply exclude that transaction from their provenance DAG.
Static vs. Dynamic Constraints: By anchoring eligibility to static, compliant origins (e.g., regulated entities) rather than dynamic blocklists, PoSoF removes the need for verifiers to synchronize with rapidly changing lists.
Privacy Preservation: The system guarantees the legitimacy of funds without leaking intermediate transaction topology, intermediary addresses, or specific origins.
Practicality: The benchmarks demonstrate that fully private, proactive compliance is highly practical, requiring only constant-time verification on-chain and manageable computation times off-chain for updates.

The authors position PoSoF not as a replacement for all compliance mechanisms, but as a foundational layer that can be combined with post-deposit auditing (like Derecho) to create a comprehensive, end-to-end compliance system for decentralized privacy pools and exchanges.