ZKP2P Grant Proposal

Project ZKP2P

Project Overview

Overview

ZKP2P is privacy-preserving trustless P2P fiat onramp interoperable with all popular web2 payment rails (e.g. Venmo). The network is powered by ZK proofs of DKIM signatures in payment confirmation emails, which allows for permissionless integration with any web2 payment network. We build upon the 0xParc / PSE ZK-Email libraries to prove the contents of the email without revealing sensitive information. Upon successful off-chain payment and corresponding proof generation, a user can trustlessly unlock escrowed assets on-chain.

Project Details

We envision the final state of ZKP2P to be a trustless protocol or primitive deployed on Ethereum / L2s where new payment use cases can be permissionlessly built on top and composable with DeFi, NFTs or other systems. We believe that ZK is the next 0-1 in crypto, and there are so many applications that can be built on this tech that we haven’t imagined yet. With this grant we hope to productionize ZKP2P by optimizing for the onramper UX (imagine the Uniswap UX), reach feature parity with centralized onramps and become the first application built on ZK-Email in prod. P2P on-ramps are a gray area depending on jurisdiction and traditionally a walled garden so it is important to be decentralized, permissionless and a public good.

Tech Stack

For our project, the tech stack consists of an end to end protocol including circuits, smart contracts and UI

Assumptions

  • Off-rampers are sophisticated actors, meaning they have more funds than onrampers, understand DeFi mechanisms and more closely monitor on-chain activity
  • On-rampers are less sophisticated and want minimal actions to onboard funds. This means hiding or moving complexities to the offramper (e.g. proof generation)
  • Off-rampers are incentivized to generate proof of payment received emails on behalf of on-rampers. This means on-rampers do not touch proof generation at all, and instantly unlocks mobile onboarding
  • On-rampers already have gas tokens in their EOA, or gasless onboarding done via a custom EIP4337 paymaster integration

High Level Flow - Happy Path

High Level Flow - Malicious or Lazy Offramper

High Level Flow - Account Registration (Malicious Onramper)

Smart Contract - Ramp.sol
Ramp is a singleton contract that provides endpoints for different actors in the system to trustlessly coordinate with each other. There will be a single contract for every new payment use case we build.

We draw inspiration from the Binance P2P flow. The key functionality includes:

  • Offrampers
    • Deposit Liquidity: Deposits crypto in the smart contract
    • Withdraw Liquidity: Returns crypto back to the user. Liquidity that is in progress (signaled intent) cannot be withdrawn.
    • Settle onramp (Offramper): Generates a proof of payment receipt which disburses funds to onrampers. They are incentivized by a fee % that onrampers agree to pay
  • Onrampers
    • Signal Intent: Onrampers submit an intent transaction to claim the order and send the Venmo transaction offchain. This prevents race conditions. Once the onramper signals intent, offramper cannot withdraw liquidity before the signal intent period has expired.
    • Settle onramp (Onramper): Enables onramper to also settle the order by generating a proof of payment email. This is an escape hatch for if the off-ramper is malicious or lazy. The fee % is sent to the onramper as a rebate instead
  • All users
    • Register by submitting a Venmo proof of payment email. This ties the public address with a unique identifier (hash of Venmo ID)
    • Allowlisting and blocking unique user IDs. This allows offrampers to specify if they only want to transact with certain Venmo IDs (e.g. I only want to transact with Vitalik)

Smart Contract - Verifier.sol
The verifier contract is for verifying zk-SNARK proofs using the Groth16 proving system. This will be upgraded to halo2 when we transition over to use the halo2-zk-email template. It is extended by the main Ramp contract.

Circuit - Offramper Receive Payment Circuit
Main circuit that offramper generates a proof of Venmo payment received email

  1. Verifies the DKIM signature (RSA, SHA256)
  2. Extracts Venmo payer ID, time of payment from email
  3. Houses nullifier to prevent replay attacks
  4. Contains other order information to tie a proof to an order ID to prevent frontrunning
Regex Config Description
Onramper Regex Extracts the Venmo payer ID from the payment received email body
Timestamp Regex Extracts timestamp from venmo payment received email header

Circuit - Onramper Send Payment Circuit
Main circuit that onramper generates a proof of payment if offramper fails to generate proof above

  1. Verifies the DKIM signature (RSA, SHA256)
  2. Extracts payee ID and amount for the Venmo transaction
  3. Houses nullifier to prevent replay attacks
  4. Contains other order information to tie a proof to an order ID to prevent frontrunning
Regex Config Description
Offramper ID Regex Extracts the Venmo payee ID from the payment sent email body
Amount Regex Extracts $ amount sent from from venmo payment sent email header

Circuit - Registration Circuit
Main circuit that both on and off rampers use to tie a specific Venmo ID hash to their public address

  1. Verifies the DKIM signature (RSA, SHA256)
  2. Extracts the Venmo ID of the user registering and hashes the packed ID to be used as identifier
Regex Config Description
ID Regex Extracts the Venmo payer/payee ID from the payment sent/received email body

Application - S3 Instance
Host proving keys in a server and accompanying script to download to local storage. Will use a modified zk-email script

Application - Onramper flow
UI flow for an onramper who wants to trade Venmo USD to crypto

  • Onramper automatically is shown the best rate given an input amount, and has secondary ability to browse orders
  • Onramper will have only 1 action to push a Venmo transaction to the offramper

Application - Offramper flow
UI flow for an offramper who wants to trade crypto for USD

  • Offramper can post orders
  • Offramper can cancel orders past the expiry

We have already built a working end to end Venmo flow as a PoC for ZKHack in April which ended up one of the winners in the hackathon. We’re currently making a few updates to the PoC that address some of the prior limitations and deploy an alpha version to an L2. This grant proposal will be for an updated version following the specification above where we plan to address most of the limitations and problems and deploy a secure protocol to production. For more details on prior research and work, check out the additional information section at the bottom.

Team

Team Members

Team Email Telegram
Richard richardliang2015@gmail.com @richard2015
Sachin 0xsachink@gmail.com @Sachin0x
Alex alexsoong91@gmail.com @asoong
Brian brian.weickmann@gmail.com @bmwball56

Team Website

http://zkp2p.xyz/

Team Experience

We’re all current or ex-colleagues of Set Labs, where we historically built on-chain DeFi asset management products. We’ve launched some popular on-chain indices such as DeFiPulse Index and ETH 2x Leverage Token which reached over $750M in assets. Most of our prior experience is in implementing production-grade smart contracts and applications, where we haven’t suffered a hack since we started building Set 4 years ago. Recently, we’re spending most of our time individually building in ZK.

Team Code Repos

Development Roadmap

Overview

Total Estimated Duration: 10 weeks (tentative)
Full-time equivalent (FTE): 2-3 FTE depending on milestone
Total Costs: $55,000

Milestone 1 - On-ramping Flow and Client Designs

Estimated Duration: 2 weeks
FTE: 2
Costs: $10,000
Estimated delivery date: 6/30/2023

No. Deliverable Specification
1 Documentation We will provide both inline documentation of the circuit and smart contract code. Include in write-up discussion about design decisions, detailed mechanism, and unmitigated potential attacks in the happy path. We’ll also include write ups with benchmarks and learnings from ramping up on halo2 and zk-email
2 Testing The code will have proper unit-test coverage (e.g. 90%) for both circuits and smart contracts to ensure functionality and robustness. In the guide we will describe how to run these tests
3 Functionality - Ramp.sol happy path functionality Smart contract implements on-ramping flow: Optimistic registration (no proofs involved) Deposit liquidity Withdraw liquidity Signal intent Settle order (offramper flow)
4 Functionality - Offramper Receive Payment Circuit Main circuit built in circom that enables the offramper to generate a proof of Venmo payment received email Verifies the DKIM signature (RSA, SHA256) Extracts Venmo onramper ID from email Houses nullifier to prevent replay attacks Contains other order information to tie a proof to an order ID to prevent frontrunning.
5 Functionality - Venmo Onramper ID Regex support Chips config generated using zk email that extracts the Venmo ID of the payer (onramper who paid) from a venmo payment email's subject body.
6 Functionality - Venmo Extract Email Timestamp Regex Support Chips config generated using zk email that extracts the timestamp from a venmo payment received email from the header.
7 UI Setup and designs Basic UI react app setup. Creating designs for various pages including non happy path flows.

Example Design:

Milestone 2 - Fallback flow for malicious offramper

Estimated Duration: 2 weeks
FTE: 3
Costs: $15,000
Estimated delivery date: 7/15/2023

No. Deliverable Specification
1 Documentation We will provide both inline documentation of the UI code and a basic tutorial that explains how a user can (for example) spin up the application. Application is up, it will be possible to send test transactions that will show how the new functionality works.
2 Testing The code will have proper unit-test coverage (e.g. 90%) for both circuits and smart contracts to ensure functionality and robustness. In the guide we will describe how to run these tests.
3 Functionality - Ramp.sol offramper isn’t honest Smart contract that accounts for dishonest offramper. Deposit liquidity includes a fee bounty where if offramper does not submit proof within x min, then onramper is given this rebate. Settle order (onramper fallback flow).
4 Functionality - Onramper Send Payment Circuit Main circuit that onramper uses to generate a proof of payment if offramper fails to generate proof above. Verifies the DKIM signature (RSA, SHA256). Extracts payee ID and amount for the Venmo transaction. Houses nullifier to prevent replay attacks. Contains other order information to tie a proof to an order ID to prevent frontrunning.
5 Functionality - Venmo Amount Regex support Regex config generated using zk email that extracts $ amount sent from the email's header in a payment sent email.
6 Venmo Extract Offramper ID Regex support Regex config generated using zk email that extracts the Venmo ID of the payee (user who was paid) from a venmo payment sent email's subject body.
7 Application - Onramper UI core path On ramping UI. Implement initial Uniswap trade UI component, best rate is automatically shown for an input amount. Implement component for an order intent transaction.

Milestone 3 - Registration flow

Estimated Duration: 2 weeks
FTE: 2
Costs: $10,000
Estimated delivery date: 7/31/2023

No. Deliverable Specification
1 Documentation We will provide both inline documentation of the circuit and smart contract code. Include in write-up discussion about the problems this fallback flow is meant to incentivize.
2 Testing The code will have proper unit-test coverage (e.g. 90%) for both circuits and smart contracts to ensure functionality and robustness. In the guide we will describe how to run these tests.
3 Functionality - Ramp.sol onramper isn’t honest Registration and allow / deny lists: smart contract adds functionality to offramper for when onramper doesn’t send payment despite signaling intent for the order. Registration: on and offramper both need to submit proof of payment email to tie a Venmo ID hash to public address. Allow / deny lists: offramper can choose which Venmo ID hash to block or which subset of addresses they are willing to allowlist.
4 Functionality - Registration circuit Circuit that both on and off rampers use to tie a specific Venmo ID hash to their public address. This mitigates griefing from the onramper signaling intent but never sends the Venmo payment. Therefore, the off-ramper’s order is canceled. Extracts the Venmo ID of the user registering and hashes the packed ID to be used as identifier. Packs ID and outputs into a signal for smart contract to verify.
5 Functionality - Extract Venmo ID of payee for registration Regex config so that both on and off rampers use to tie a specific Venmo ID hash to their public address. Extracts the Venmo ID of the user registering and hashes the packed ID to be used as identifier. Packs ID and outputs into a signal for smart contract to verify.
6 Application - Offramper UI core path Offramping UI. Implement component for offramper to post orders. Implement component for oframper to view open and previous orders. Implement component for offramper to add / remove entries to onchain allow / deny list Venmo ID hashes. Implement component for proof generation with email.

Milestone 4 - Client side proving and Upgradability

Estimated Duration: 2 weeks
FTE: 2
Costs: $10,000
Estimated delivery date: 8/15/2023

No. Deliverable Specification
1 Documentation We will provide a basic tutorial that explains how a user can (for example) spin up the application. Application is up, it will be possible to send test transactions that will show how the new functionality works.
2 Testing The code will have proper integration test coverage (e.g. 90%) for both circuits and smart contracts to ensure functionality and robustness. In the guide we will describe how to run these tests.
3 Functionality - Enable client side proof generation Host proving keys in a public S3 bucket and accompanying script to download to local storage to enable client side proof generation. Will use a modified zk-email script.
4 Functionality - Admin upgradeability to safeguard good onrampers Add admin controls for: Email templates or DKIM signatures change over time. This is needed in case orders are in progress when these changes happen, so funds do not get locked in the smart contract. Upgrades will initially be managed by a multisig to start. Onramp asset caps that is subject to multisig control.
5 Functionality - SC deployment scripts Write deployment scripts for deploying the smart contract protocol on any chain.
6 Application - Registration UI UI flow for both on-ramper and off-rampers to register themselves before using the protocol. On/off ramper generates a proof and submits to contract to register.
7 Application - Enable client side proving in UI Download hosted proving keys from S3 bucket and use wasm to generate proofs in the browser.

Milestone 5 - Proof aggregation service, QA & Deployment

Estimated Duration: 2 weeks
FTE: 2
Costs: $10,000
Estimated delivery date: 8/31/2023

No. Deliverable Specification
1 Blog post and documentation Blog post and documentations on contributing, current limitations, future improvements and use cases to build on top of this protocol.
2 Testing - QA Comprehensive end to end testing, including ancillary flows for cancelling and on-ramper proof generation. Coordination with PSE and zk-email teams regarding audits (see below).
3 Application - Server side proving Hosting proving service and using RapidSnark.
4 Application - Send proofs to aggregator server UI flow to forward the proof generated on client side to the hosted aggregation service.
5 Application - Ancillary UI actions for onramper and offramper End to end flow is working in the UI. Additional UI paths: Offramper can cancel orders past the expiry. Offramper can opt to generate proofs using proving service. Onramping fallback flow.
6 System Deployment Deployment of production environment including smart contracts and proving service. Client will be hosted on IPFS and configured to zkp2p dns.

External Audits

We will be collaborating with the PSE and zk-email teams on audits for the circuits, pending their availability. As of grant proposal submission, the external teams are focused on audits for the underlying zk-email circuits. Additional funding and coordination may be required to complete this step which will be required before releasing to production.

Additional Information

What work has been done so far?

V0 - Hackathon PoC (Completed)

Goals

  • Hacked on Venmo P2P onramp at ZKHack Lisbon
  • Showcase that an e2e PoC can be built over a weekend

Requirements / Features

  • Integrated Venmo as the first P2P payment service
  • Built on top of Circom ZK-Email circuits
  • Uses RapidSnark to generate proof in server
  • Deployed demo to Goerli

Limitations / Problems

  • Requires trusted server side proof generation. Unoptimized circuits: 8M+ constraints vs 3M in the Twitter verification circuit in ZK-Email
  • No privacy, all Venmo IDs are exposed and tied to a public ETH address
  • Doesn’t solve for the 0-1 onboarding; user must already have ETH gas on-chain in order to submit proofs to unlock escrowed USDC
  • Unaccounted for edge cases in mechanism (e.g. chargebacks, injection attacks, email template updates)

V1 - PoC alpha deployment that preserves privacy of Venmo user ID (In Progress)

Goals

  • Solve the privacy of Venmo user ID problem in V0, which is a must have for users to transact real value on the platform
  • Deployment to mainnet to showcase that real value can be transferred, albeit with heavy restrictions and admin controls

Requirements / Features

  • Re-architected payment flow to promote privacy of Venmo ID between an on and an offramper to a first class citizen. High level flow:
    1. On-ramper posts orders with the amount they wish to trade.
    2. Off-ramper bid for the order and post their rates and encrypted Venmo IDs on-chain.
    3. On-ramper chooses one of the Venmo IDs and pushes the Venmo payment off-chain.
    4. On-ramper submits proof, public inputs, and order to retrieve USDC
  • Client side proving
  • New flow reduces constraints from 8.8M to 6.6M
  • Wired up chunked zkey flow to the UI

Security

  • Add admin functionality to pause transactions / protocol to mitigate unexpected edge cases (e.g. DKIM / email template changes)
  • Add testing to cover happy paths and known edge cases

Limitations / Problems

  • Client side proving is still too slow
  • Doesn’t solve for the 0-1 onboarding; user must already have ETH gas on-chain in order to submit proofs to unlock escrowed USDC
  • Unaccounted for edge cases in mechanism (e.g. chargebacks, injection attacks, email template updates)
  • Our current choice of nullifier (SHA of email) allows the payment service to deanonymize the user

Future Research

  • Onramp AMM vs current orderbook design
  • Other mechanisms to detect and prevent fraud / edge cases
  • Preventing Venmo or other P2P payment services from shutting down accounts who use our service
  • Tradeoffs of upgradeability (e.g. DKIM signatures, email templates) vs decentralization
  • Secure nullifiers
    • X-Chain nullifier
    • Hiding email hash from Venmo
Select a repo