[NCR#1 Proposal] TxnProof: A financial transaction verification platform

[ronykris]

Summary:

Studies show that around 61% of consumers are concerned about their financial data being shared without their consent​ (RestorePrivacy). Additionally, email-based transactions are particularly vulnerable, with 92% of malware delivered via email and phishing attacks accounting for more than 80% of reported security incidents​ (GitHub)​ (GitHub).

TxnProof is a platform designed to address critical privacy concerns in financial transactions. Using zkEmail and zero-knowledge proofs (ZKPs) built on Aztec's Noir, the platform will enable users to securely prove their financial activities without disclosing sensitive information. The platform ensures financial data remains private, secure, and verifiable on the blockchain, making it a powerful tool for modern financial systems.

Methodology

We aim to build a comprehensive MVP that demonstrates the end-to-end functionality of the ZK TxnProof platform. This platform leverages zkEmail and zero-knowledge proofs (ZKPs) built on Aztec's Noir to securely verify financial transactions and credit scores without revealing sensitive details. The project includes the development of various components that work together to create a secure, privacy-focused system that bridges traditional finance and the Web3 ecosystem.

Financial Use Cases:

1. Proof of Financial Transactions:

   • Users can securely prove that a financial transaction occurred without revealing the amount, parties involved, or other sensitive details.

2. Credit Score Verification:

   • The platform enables users to prove their creditworthiness based on credit score information without disclosing the actual score or underlying data.

3. Secure Reimbursement Claims:

   • Employees can submit proofs of transactions for reimbursement without revealing personal spending details.

4. Anonymous Donation Verification:

   • Donors can prove they made a contribution without revealing their identity or the amount donated.

5. Mortgage and Loan Payment Verification:

   • Homeowners or borrowers can prove they made mortgage or loan payments without revealing payment amounts or details.

User Flow:

1. User Registration: Users sign up and authenticate securely via zkEmail.

2. Transaction Notification: User receives an email notification regarding a transaction. In this grant we are looking at supporting off chain and on chain financial transactions and platforms Gmail and explore yahoo or hey. Notification could be either:

   • a. Transfer of funds (fiat) between parties
   • b. Notification of funds (fiat / crypto) sent or received.

3. Email Submission: User can either upload the email to the platform or forward it to the platform’s service ID.

4. Proof Generation: zkEmail generates a zero-knowledge proof of the email content.

5. Proof Submission: The proof is submitted to the smart contract, which verifies it, records the transaction on-chain, and mints an ERC-721 token.

System Components:

• Login and Signup: Implement a sign-up and login mechanism via zkEmail, where users provide only their email ID. Implementation details can be found here.

• Inbox Monitoring Service: A service that monitors the platform's inbox for received emails. Upon receiving an email, it triggers the Regex service.

• ZK Regex: This module parses the email content, extracts relevant details, and forwards them to the proof generation module. We will be implementing a regex module in Noir to perform the pattern matching. For now we plan to support the following characters (outlined in the pseudo function definition below).

fn is_valid_pattern_char(c: u8) -> bool {
    (c >= 'a' && c <= 'z') ||
    (c >= 'A' && c <= 'Z') ||
    (c >= '0' && c <= '9') ||
    c == '.' || c == '_' || c == '%' || c == '+' || c == '-'
}

Example expressions to match:

1. 'to:email@domain.com' : Regex pattern To:\s*([a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,})
2. 'from:sender@domain.com' : Regex pattern From:\s*([a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,})
3. 'successfully transferred' + amount + currency : Regex pattern (successfully transferred|sent|received)\s*([\d,.]+)\s*([A-Z]{3,4})

• The regular expressions will match the content supplied by the user but will not store or disclose it.

• Prover: Generates a proof of the email using zkEmail and submits it to the smart contract for processing. The following information will be hashed and used in generating the proof:

  1. DKIM from mail server
  2. Timestamp of the email
  3. Size of the email
  4. Raw email body

  Prover function inputs:

  Public Inputs:

  • Hash of the email body : poseidon_hash(email_body)
  • DKIM signature (public key hash) : poseidon_hash(dkim_public_key)
  • Hash of the extracted transaction details (amount + currency) : poseidon_hash(amount || currency)

  Private Inputs:

  • Raw email body
  • DKIM signature (full signature)
  • Extracted transaction amount
  • Extracted currency code
  • Extracted sender email address
  • Extracted recipient email address

• Smart Contract: Deployed on the Aztec chain, this contract will verify the proof and store the transaction details on-chain, triggering a mint function for a Soulbound like token (SBT) on the Aztec network.

• Mint: The smart contract will mint a SBT like token for every validated transaction record. This token serves as a representation of the financial transaction. The token metadata would contain reference to the txn record on chain and the proof. Going fwd, one doesn't have to explicity share records / emails as proof of txn. The presence of the token will be good enough. Ie: The contract will be able to verify the occurance of the txn using the metadata of the nft (txn record & proof) should a need arise.

• Indexing Service: We will integrate The Graph indexing service to enable fast querying of records and transactions on the platform.

Tech Stack:

• Frontend: Next.js / Vite
• Backend: Node.js, Express.js
• Blockchain: Aztec network
• ZK Proofs and Contract: Aztec.nr to create zk circuits and the smart contract
• Indexer: The Graph
• Containers: Docker
• Cloud Compute: GCP (Google Cloud Platform)

Timeline and Deliverables:

Month 1: Planning and Initial Development

• Week 1: Finalize Architecture and User Stories

  • Milestone: Complete the architecture design, finalize user stories, and break down tasks.
  • Deliverable: A detailed architecture plan and task breakdown.

• Week 2: User Registration and Authentication System

  • Milestone: Develop and integrate the user registration and authentication system, including the frontend and smart contract components.
  • Deliverable: A functioning user registration and login system with basic smart contract interactions.

• Week 3: Inbox Monitoring Service and Email Parser

  • Milestone: Develop the frontend email upload feature and build the inbox monitoring service. Implement zk-regex to write the email parser and extract relevant fields.
  • Deliverable: A fully functional email monitoring service and parser.

• Week 4: ZKP Generation

  • Milestone: Implement ZKP generation from the email content to create call data securely and privately.
  • Deliverable: A module that generates ZKPs for email content, ready for integration with the smart contract.

Month 2: Integration and Testing

• Week 5: Smart Contract and SBT like token Minting

  • Milestone: Write and deploy the smart contract that records proof and transaction details on-chain, triggering SBT token minting.
  • Deliverable: A deployed smart contract with working token minting functionality.

• Week 6: Frontend Integration and Indexing Service

  • Milestone: Integrate the frontend with the smart contract, enabling full interaction with the blockchain. Develop and deploy the indexing service using The Graph.
  • Deliverable: A user interface that allows interaction with the smart contract and a functioning indexing service.

• Week 7: User Profile and Token Listing

  • Milestone: Develop a user profile view that integrates with the indexing service to list tokens and transaction records.
  • Deliverable: A profile page where users can view their transaction history and associated tokens.

• Weeks 8-9: Testing, Bug Fixing, and Documentation

  • Milestone: Conduct extensive testing, fix identified bugs, and create detailed documentation.
  • Deliverable: A stable, bug-free platform with comprehensive documentation, ready for deployment.

This timeline ensures that each critical component of the platform is developed, tested, and integrated in a systematic manner, leading to a robust MVP by the end of the second month.

Team

Ayush:

• Full stack developer
• 2+ years in Web3
• O1js developer in Mina
• Core Member of the UniDAO 
• Github: https://github.com/ayush4345
• Tg: ayushk_211me112

Ritvik:

• Smart contract developer (Solidity, Cairo and Dojo framework)
• Developer of zkpoker
• Github: https://github.com/raghav-rama
• Tg: hackerrboy

Nikhil:

• Ace designer and frontend developer
• 4+ years in web3
• Ambassador at Arbitrum and several crypto exchanges.
• GitHub: https://github.com/nshri1609
• Tg: Nikhil0x

Saurabh:

• Web3 developer relations
• 5+ years of experience.
• Skilled in developer outreach, technical writing, and community management.
• GitHub: https://github.com/Saurus9290
• Tg: Saurus9290

Krish:

• Full stack, smart contract and zkp developer
• 6+ years in web3
• Solidity developer on EVM chains,
• ZK circuits developer in Mina, and Aztec
• Built zkpoker on EVM with solidity and zokrates
• zknonogram and zkuno using Noir on Aztec
• GitHub: https://github.com/ronykris
• Tg: lowcodekrish

Start Date:

The day after we get selected for the grant.

[Savio-Sou]

Hi @ronykris, thanks for submitting the proposal!

A few early questions and thoughts:

Methodology

User receives an email notification about a txn.

Would be great if you could elaborate on what transactions are intended to be proved with zkEmails.

For example: would that be on-chain / off-chain transactions, what platform(s) are you aiming to support, etc.

mints an erc721 token

Awesome if you could elaborate on what the ERC-721 token is for, or perhaps more widely how proofs of transaction are useful.

Aztec is our chosen chain and the contract will be deployed there. It will verify / validate the proof and store it on chain along with a record of the txn.

If the application is intended to work as a blockchain app (i.e. not off-chain), the program can be coded entirely in Aztec.nr as a mixture of private and public functions, not necessarily using Aztec just for proof verification.

You can read more about Aztec.nr here: https://docs.aztec.network/aztec/smart_contracts_overview

Team experience

Would be great if you could highlight the team's experience with Noir and/or Aztec.nr specifically.

[ronykris]

Hi @Savio-Sou !

Thank you for taking time to review and share some initial thoughts.

As for some answers;

Would be great if you could elaborate on what transactions are intended to be proved with zkEmails.

While writing the proposal I was primarily looking at proving off chain financial txns. Now that you said, I'm thinking it could be extended to on chain ones too. My intent is to solve this problem for all txn records / emails received / sent post a successful transfer.

Wrt platform; I'm guessing you meant email platform, I will supoort Gmail and explore one more, like a yahoo / hey.

Awesome if you could elaborate on what the ERC-721 token is for, or perhaps more widely how proofs of transaction are useful.

The mint of the txn and the proof creates a NFT which to a certain extent will be a proof in itself to the txn(s) that occurred. Going fwd, one doesn't have to explicity share records / emails as proof of txn. Only the token will be good enough. Ie: the nft, could reveal the txn and the proof if a need to verify a txn ever arises.

If the application is intended to work as a blockchain app (i.e. not off-chain), the program can be coded entirely in Aztec.nr as a mixture of private and public functions, not necessarily using Aztec just for proof verification.

Thank you for pointing it out. We choose to run the dapp on the Aztec network. Therefore, it could be used to write the entire contract, not just the proofs.

Thank you again for taking time out and sharing initial thoughts. I will update the proposal to add more clarity to it.

[Divide-By-0]

Do you have a sense of some specific institution's financial tx email receipts that you can use? Many of them are not 100% complete or don't have all the info, so finding those emails in the first place is often a big challenge.

[ronykris]

Hi @Divide-By-0 !

Thank you for the question. While writing the proposal I had few samples collected from different use cases. viz:

1. Emails communicating a successful wire transfer. (typically triggered by financial instruments like banks). These could differ across institutions, but by and large they follow a straight fwd template.
2. Emails communicating a successful payment for a service eg: subscription, insurance premiums, etc. (Institutions heavily invested in using email notification are Stripe, Paddle, Razor pay, etc)
3. In web3 there are plenty of on ramp solutions who'd benefit from this.. (Institutions like Simplex, Moonpay, etc are good first case examples).

I'd be happy to share screenshot of emails I mentioned above, if it helps. This is precisely the reason why a solution/product must exist to answer similar questions. Converting txn (receipt) into a Soul Bound Token with meta information to prove an authentic occurrence of it could be a brilliant use of zkemail.

I am looking forward to productising it for the benefit of the ecosystem. Therefore, happy to chat more.

Cheers,
krish

[Savio-Sou]

Selected proposals for NCR#1 are announced: https://github.com/orgs/noir-lang/discussions/5932

Thank you for your support on the initiative. NCR is just one of the many ways to start your explorations with Noir, check the announcement for more potential ways to collaborate.

Let's bring the world ZK!