Building the Future of Financial Privacy

We recently analyzed the comprehensive report "Zero-Knowledge Proofs in Blockchain Finance: Opportunity vs. Reality," published by Nethermind in partnership with Deutsche Bank. The report paints a vivid picture: while Zero-Knowledge Proofs (ZKPs) are the "endgame" for secure digital assets, the industry is struggling to bridge the gap between theoretical opportunity and market reality .

This is where our work begins. We are not just reading about the future; we are coding it. In this post, we’ll break down the core insights from the whitepaper and reveal how we are building a "First Person" solution using Rust, Plonky2, and Astra DB to finally enable users to verify bank and crypto wallets without ever exposing their data.

The "Why": The Opportunity vs. Reality Gap

According to the whitepaper, ZKPs are designed to ensure that data can be verified as true without revealing any additional information . This satisfies three core properties necessary for a modern financial system:

Completeness: If a statement is true, we can prove it .
Soundness: If a statement is false, you can't trick the system .
Zero-Knowledge: The verifier learns nothing except the fact that the statement is true .

However, the report highlights significant hurdles: high throughput costs, lack of standardization, and the heavy computational load of generating proofs . Current solutions often force a trade-off between privacy and performance. We are eliminating that trade-off.

"Financial institutions must transition toward scalable and secure system architectures that can support client needs and safely integrate blockchain-based technologies."

Our Solution: The "First Person" Prover

We are building a platform that allows users to act as their own "Prover." Instead of relying on a centralized authority to vouch for your funds (which creates a honey pot for hackers), our architecture empowers the user to generate a cryptographic proof of their assets locally. This proof is then shared with the bank or application (the "Verifier").

The Architecture: Plonky2 + Vercel + Astra DB

To make this scalable and "bank-ready," we are moving away from heavy on-chain computation. Instead, we use a recursive proof system.

1. The Prover Layer (Plonky2 + Vercel)

We use Plonky2, an incredibly fast ZK-proving system, hosted on serverless functions via Vercel. This setup uses Recursive Circuits, which are a game-changer for scalability:

The Inner Circuit: This verifies the raw data—for example, verifying a bank's digital signature or a scraped data "witness" that confirms you hold $10,000.
The Outer Circuit: This is where the magic happens. It verifies the previous proof plus the new transaction. This means we don't need to re-verify your entire history every time you buy a coffee; we just verify the "delta" (the change) .

2. The "Bank-Ready" API Handler with Astra DB

Banks require auditability and idempotency (ensuring the same operation doesn't happen twice erroneously). To handle this securely without storing PII (Personally Identifiable Information), we use Astra DB via its Data API. This allows us to manage cryptographic "nullifiers" and commitments with high performance and zero PII retention.

The Code: Implementing the Solution in Rust

Below is the actual Rust implementation blueprint we are using to bridge the gap between the whitepaper's theory and production reality.

A. Astra DB Integration (src/db.rs)

We use the Astra Data API to store hashes, not names. This ensures that even if our database is compromised, the attacker finds only cryptographic noise.

use serde_json::json;
use reqwest::Client;

pub struct AstraClient {
    token: String,
    endpoint: String,
    http: Client,
}

impl AstraClient {
    // Check if a proof's nullifier has already been used (prevent fraud)
    // This addresses the "double-spending" problem highlighted in the whitepaper
    pub async fn is_nullifier_spent(&self, nullifier: &str) -> Result<bool, Error> {
        let res = self.http.post(&format!("{}/find", self.endpoint))
            .header("Token", &self.token)
            .json(&json!({ "filter": { "nullifier": nullifier } }))
            .send().await?;
        
        // Logic to return true if document exists
        Ok(res.status().is_success()) 
    }

    // Update the commitment hash without storing the balance
    // This aligns with GDPR advice to store off-chain hashes
    pub async fn update_commitment(&self, user_id: &str, commitment: &str) -> Result<(), Error> {
        // Astra Data API 'findOneAndUpdate' call implementation
        Ok(())
    }
}

B. The Recursive Handler (api/update_balance.rs)

This is the core logic. It proves the transition from State A to State B recursively. This is essential for the "Blockchain Scaling Solutions" mentioned in the whitepaper, where single proofs validate batches of activity .

#[tokio::main]
async fn main() -> Result<(), Error> {
    run(service_fn(|req: Request| async move {
        // 1. Get raw bank witness (Ephemeral)
        // This is the "secret information" or witness mentioned in the ZKP protocols
        let witness = extract_bank_data(&req); 
        
        // 2. Build the Recursive Proof
        // Verify current state + new delta = new commitment
        let prev_proof = db.get_latest_proof(user_id).await?;
        
        // Using Plonky2's speed to generate proofs within Vercel execution limits
        let new_proof = recursive_prove(prev_proof, witness)?;

        // 3. Atomically update Astra DB
        // We store the nullifier to prevent replay attacks
        db.save_nullifier(new_proof.nullifier).await?;
        db.update_commitment(user_id, new_proof.new_commitment).await?;

        // 4. Return the proof to the bank/app
        // The Verifier (Bank) receives this proof, not the raw data
        Ok(Response::new(Body::from(json!(new_proof))))
    })).await
}

Why This Wins: The Pitch

The whitepaper asks for systems that provide "Proof of Assets" and "Proof of Liabilities" without exposing user data . Our solution delivers exactly that, superior to traditional aggregators like Plaid in three key ways:

Bank Trust: Banks can say, "We don't send you data; we send you a 'Commitment.' You can verify our math without us ever exposing a single account number." This solves the privacy leakage issues of current open banking models.
Regulatory Compliance: We maintain a 0-second data retention policy for PII. The only thing stored in Astra DB is cryptographic noise (hashes). This aligns perfectly with GDPR and eIDAS requirements mentioned in the report .
Massive Scale: Because Plonky2 is incredibly efficient (~300ms for recursion), our Vercel functions stay well within "Free/Pro" execution limits. We can scale to millions of users without the massive infrastructure costs typically associated with ZKPs .

The Next Steps: Completing the Mission

The Nethermind report concludes that "the financial sector stands at a crossroads" and that "ZKP standards will pave the way for a new era of trusted digital interaction" .

We are currently finalizing the Rust crates for the recursive circuits and optimizing the Astra DB schema for high-concurrency atomic updates. Our goal is to create this "First Person" verification layer, allowing any wallet or bank to plug into a privacy-preserving financial web.

Engineering the "First Person" Prover: Solving the ZKP Performance Gap with Rust, Plonky2, and Astra DB