# Table of Contents - [ZKP2P | ZKP2P](#zkp2p-zkp2p) - [IEscrow | ZKP2P](#iescrow-zkp2p) - [Escrow | ZKP2P](#escrow-zkp2p) - [Smart Contracts | ZKP2P](#smart-contracts-zkp2p) - [The ZKP2P V2 Protocol | ZKP2P](#the-zkp2p-v2-protocol-zkp2p) - [IPaymentVerifier | ZKP2P](#ipaymentverifier-zkp2p) - [FAQ | ZKP2P](#faq-zkp2p) - [Security | ZKP2P](#security-zkp2p) - [Privacy and Safety | ZKP2P](#privacy-and-safety-zkp2p) - [Risks | ZKP2P](#risks-zkp2p) - [Gating Service | ZKP2P](#gating-service-zkp2p) - [Integrate ZKP2P | ZKP2P](#integrate-zkp2p-zkp2p) - [PeerAuth Extension | ZKP2P](#peerauth-extension-zkp2p) - [Deployments | ZKP2P](#deployments-zkp2p) - [zkTLS | ZKP2P](#zktls-zkp2p) - [Team | ZKP2P](#team-zkp2p) --- # ZKP2P | ZKP2P [](#introducing-zkp2p) Introducing ZKP2P --------------------------------------------- Our mission is to bridge the gap between traditional Web2 platforms and decentralized Web3 platforms in a secure, private and user-friendly way. Our initial focus is to create the cheapest, fastest, lowest fraud and most composable fiat-to-crypto on/off ramp. ### [](#background) Background As crypto evolves (DeFi, NFTs, social, on-chain gaming), the necessity for seamless interoperability between fiat and cryptoassets becomes much more important. Existing solutions for onramping are not sufficient to address this need: ❌ Not globally inclusive (Coinbase is not available everywhere) ❌ High fees for direct onramps (direct onramps charge up to 5%) ❌ Complex KYC processes ❌ Slow (Coinbase ACH takes 5 days to clear) ❌ Not composable with rest of smart contract ecosystem (e.g. fiat to Aave, fiat to Uniswap LP) ### [](#zkp2p) ZKP2P ZKP2P is the first trust minimized onramp and offramp protocol powered by advanced cryptography such as zkTLS, MPC and ZK. These technologies enable permissionless integration with any web2 digital asset transfer platform. 1. **An intent-based onchain smart contract escrow** that unlocks tokens upon satisfying a predefined predicate (e.g. send $X to @my\_venmo\_account by X time). Users can post offramp liquidity in the smart contract which acts as a community bulletin board. Onrampers will then signal and fulfill intents to complete these orders 2. **Crypto primitives (e.g. zkTLS, zkEmail, TEEs)** that authenticate and generate verified proofs satisfying that predicate. Using advanced cryptographic primitives or TEEs, users cannot engage in fraud to generate a false proof for a predicate. ### [](#why-zkp2p) Why ZKP2P? * **Trustless:** By leveraging cryptographic proofs, ZKP2P eliminates trust required for intermediaries to settle transactions and disputes, thereby promoting direct transactions between users. * **Private:** The privacy of users is paramount. ZKP2P ensures that while the authenticity of transactions is verifiable, sensitive information remains concealed from the blockchain. * **Interoperable:** The protocol is designed to be interoperable with popular web2 payment rails, thus bridging the traditional and decentralized financial systems. * **Low Fees:** By eliminating intermediaries and leveraging ZK proofs of payment, ZKP2P aims to significantly reduce the fees associated with fiat-to-crypto conversions. * **Fast**: ZKP2P enables rapid transactions while maintaining on-chainuser anonymity. Binance P2P LocalBTC Coinbase Moonpay ZKP2P Accessible ✅ ❌ Must meet in person ❌ Limited countries ✅ ✅ Scalable to any platform Fees ✅ ✅ ✅ ❌ >3% ✅ 0% Fast ❌ Must coordinate with seller ❌ Must coordinate in person ❌ Multiple days for ACH ✅ ✅ Only prove a payment Complex KYC ❌ Must KYC to use escrow ❌ Must KYC to use escrow ❌ Must onboard ❌ Must onboard ✅ - Users prove ownership of KYC'd account No additional trust assumptions ❌ Trust Binance for disputs ❌ Trust LocalBTC for disputes ❌ Trust Coinbase custody ❌ Trust Moonpay custody ✅ - No intermediary Interoperable ❌ ❌ ❌ ❌ ✅ - Integrate in your smart contract Decentralized ❌ ❌ ❌ ❌ ✅ - Protocol is fully noncustodial and open source Looking ahead, we see the ZKP2P protocol evolving into a global, trustless payment network deployed on-chain. This network will enable permissionless innovation around new payment use cases, providing composability with DeFi, NFTs, games, and beyond. [NextThe ZKP2P V2 Protocol](/developer/the-zkp2p-v2-protocol) Last updated 2 days ago ![Page cover image](https://docs.zkp2p.xyz/~gitbook/image?url=https%3A%2F%2F3629680097-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F6e2L3XxfmJSq8oZRw1gA%252Fuploads%252FSqbsEGzbq6zDuS6Kx9zT%252FX-blob-background-1500x500px.png%3Falt%3Dmedia%26token%3Df5f2cea0-77dd-424a-a3d1-15d28e3349d7&width=1248&dpr=4&quality=100&sign=d1c3c8f0&sv=2) --- # IEscrow | ZKP2P The IEscrow interface defines the data structures and function signatures used by the Escrow contract. It helps external contracts and interfaces interact with the escrow in a standardized manner. Copy interface IEscrow { /* ============ Structs ============ */ struct Range { uint256 min; // Minimum value uint256 max; // Maximum value } struct Deposit { address depositor; IERC20 token; uint256 amount; Range intentAmountRange; bool acceptingIntents; uint256 remainingDeposits; uint256 outstandingIntentAmount; bytes32[] intentHashes; } struct Currency { bytes32 code; // keccak256 hash of the currency code uint256 conversionRate; // Conversion rate of deposit token to fiat currency } struct DepositVerifierData { address intentGatingService; // Optional gating service for verifying off-chain eligibility string payeeDetails; // Payee details (hash or raw) that the verifier can parse bytes data; // Additional data needed for payment verification } struct Intent { address owner; address to; uint256 depositId; uint256 amount; uint256 timestamp; address paymentVerifier; bytes32 fiatCurrency; uint256 conversionRate; } struct VerifierDataView { address verifier; DepositVerifierData verificationData; Currency[] currencies; } struct DepositView { uint256 depositId; Deposit deposit; uint256 availableLiquidity; VerifierDataView[] verifiers; } struct IntentView { bytes32 intentHash; Intent intent; DepositView deposit; } function getDepositFromIds(uint256[] memory _depositIds) external view returns (DepositView[] memory depositArray); } ### [](#structs) Structs * **Range** Defines a minimum and maximum value. Used for `intentAmountRange`. * **Deposit** Describes all state and configuration data for a given deposit: * `address depositor` – Who created the deposit. * `IERC20 token` – Which token (ERC-20) is deposited. * `uint256 amount` – How many tokens are locked in escrow. * `Range intentAmountRange` – The minimum and maximum each intent can claim. * `bool acceptingIntents` – Whether new intents can be created for this deposit. * `uint256 remainingDeposits` – The current unclaimed amount. * `uint256 outstandingIntentAmount` – Total amount locked by open/active intents. * `bytes32[] intentHashes` – An array of active intent identifiers. * **Currency** * `bytes32 code` – The currency code hashed via keccak256 (e.g. `"USD" -> keccak256("USD")`). * `uint256 conversionRate` – Conversion between deposit token and this currency. * **DepositVerifierData** * `address intentGatingService` – Optional gating service that signs off on user eligibility for an intent. * `string payeeDetails` – The string that identifies the payee or payee details. * `bytes data` – Additional proof or attestation data required for the payment verifier. * **Intent** * `address owner` – The address that initiated the intent (the potential off-chain payer). * `address to` – Address that will receive on-chain funds if the intent is fulfilled. * `uint256 depositId` – Reference to which deposit this intent targets. * `uint256 amount` – Amount of the deposit’s token to be claimed. * `uint256 timestamp` – Block timestamp when the intent was created. * `address paymentVerifier` – Which verifier is used to check off-chain payment. * `bytes32 fiatCurrency` – The keccak256 hash of the off-chain currency code (e.g., `USD`). * `uint256 conversionRate` – The rate used for off-chain-to-on-chain value conversion. * **VerifierDataView** * Binds a **verifier** address to its **DepositVerifierData** and an array of **Currency** structures. * **DepositView** * `uint256 depositId` * `Deposit deposit` – The core deposit data. * `uint256 availableLiquidity` – The effective unclaimed deposit (accounting for prunable/expired intents). * `VerifierDataView[] verifiers` – An array of verifiers and their supported currencies. * **IntentView** * `bytes32 intentHash` – Unique identifier for the intent. * `Intent intent` – The Intent struct. * `DepositView deposit` – Information about the deposit that the intent is targeting. [PreviousEscrow](/developer/smart-contracts/escrow) [NextIPaymentVerifier](/developer/smart-contracts/ipaymentverifier) Last updated 19 days ago --- # Escrow | ZKP2P ### [](#overview) Overview The **Escrow** contract allows users to lock ERC-20 tokens in order to receive off-chain payments. Users deposit tokens specifying: * Which off-chain payment verifiers they accept. * Conversion rates for various fiat currencies. * A gating service (optional) that can sign a user’s intent to claim funds. When a taker signals an intent to pay off-chain, they specify how many tokens they want to claim and through which payment verifier. Upon proving the off-chain payment has occurred (by calling `fulfillIntent`), the escrow releases the on-chain tokens to the taker (minus applicable fees). ### [](#constants) Constants * `uint256 internal constant PRECISE_UNIT = 1e18;` * `uint256 constant CIRCOM_PRIME_FIELD = ...;` * `uint256 constant MAX_SUSTAINABILITY_FEE = 5e16; // 5%` ### [](#state-variables) State Variables * `uint256 public immutable chainId;` The chain ID where this contract is deployed. * `mapping(address => uint256[]) public accountDeposits;` Which deposits belong to a given address. * `mapping(address => bytes32) public accountIntent;` Tracks a single active intent for each address. * `mapping(uint256 => mapping(address => DepositVerifierData)) public depositVerifierData;` Links a deposit ID + verifier to the relevant verification data (e.g., payee details). * `mapping(uint256 => address[]) public depositVerifiers;` Lists all verifiers associated with a deposit. * `mapping(uint256 => mapping(address => mapping(bytes32 => uint256))) public depositCurrencyConversionRate;` For a given deposit ID and verifier, maps fiat currency -> conversion rate. * `mapping(uint256 => mapping(address => bytes32[])) public depositCurrencies;` For a given deposit ID and verifier, stores an array of fiat currencies. * `mapping(uint256 => Deposit) public deposits;` The core deposit data. * `mapping(bytes32 => Intent) public intents;` All signaled intents (by their intent hash). * **Whitelist / Governance** * `bool public acceptAllPaymentVerifiers;` * `mapping(address => bool) public whitelistedPaymentVerifiers;` * `mapping(address => uint256) public paymentVerifierFeeShare;` * `uint256 public intentExpirationPeriod;` After which an intent is considered expired. * `uint256 public sustainabilityFee;` Fee (in `PRECISE_UNIT` terms) taken from each successful intent fulfillment. * `address public sustainabilityFeeRecipient;` Where the sustainability fee is sent. * `uint256 public depositCounter;` Incremented to create unique deposit IDs. ### [](#constructor) Constructor Copy constructor( address _owner, uint256 _chainId, uint256 _intentExpirationPeriod, uint256 _sustainabilityFee, address _sustainabilityFeeRecipient ) Ownable() { ... } **Parameters**: * `_owner`: The address to set as the contract owner (can pause, unpause, and manage verifiers). * `_chainId`: The chain ID for which this escrow is valid. * `_intentExpirationPeriod`: Time (in seconds) after which an open intent can be pruned. * `_sustainabilityFee`: Percentage (in 1e18 precision) charged upon successful intent fulfillment. * `_sustainabilityFeeRecipient`: Address to receive the sustainability fees. Transfers ownership to `_owner` and sets initial contract state. * * * ### [](#external-functions) External Functions #### [](#createdeposit) createDeposit Copy function createDeposit( IERC20 _token, uint256 _amount, Range calldata _intentAmountRange, address[] calldata _verifiers, DepositVerifierData[] calldata _verifierData, Currency[][] calldata _currencies ) external whenNotPaused **Description**: Deposits `_amount` of `_token` into escrow. You specify: * A range of intent sizes (`_intentAmountRange`). * Which verifiers (`_verifiers`) the deposit will accept. * Gating + payee details for each verifier (`_verifierData`). * Which currencies (and rates) each verifier can handle (`_currencies`). **Requirements**: * User must have approved this contract to transfer `_amount` of `_token`. * The deposit is unique (each call yields a new `depositId`). * `_amount` must be >= `min` of `_intentAmountRange`. * `_verifiers` length must match `_verifierData` and `_currencies` length. * Each verifier must be whitelisted or `acceptAllPaymentVerifiers` must be `true`. * Each currency’s `conversionRate` must be > 0. **Effects**: * Increments `depositCounter`. * Stores the deposit data. * Locks the tokens in this contract. * Emits `DepositReceived` and `DepositVerifierAdded` (and `DepositCurrencyAdded`) events. * * * #### [](#signalintent) signalIntent Copy function signalIntent( uint256 _depositId, uint256 _amount, address _to, address _verifier, bytes32 _fiatCurrency, bytes calldata _gatingServiceSignature ) external whenNotPaused **Description**: A taker declares an intent to pay the deposit’s off-chain counterpart. This: * Ensures the deposit is still `acceptingIntents`. * Validates `_amount` against deposit’s range. * Optionally checks a gating service signature. * Reserves `_amount` from the deposit’s `remainingDeposits`. * Records a new `Intent` in `intents`. **Requirements**: * Caller must not have another active `Intent` (`accountIntent[msg.sender] == 0`). * `_amount` is within the deposit’s `intentAmountRange`. * `_fiatCurrency` is recognized in `depositCurrencyConversionRate[_depositId][_verifier]`. **Effects**: * May prune expired intents if liquidity is insufficient. * Emits `IntentSignaled` upon success. * * * #### [](#cancelintent) cancelIntent Copy function cancelIntent(bytes32 _intentHash) external **Description**: Allows the **intent owner** to cancel an intent. This frees up the escrowed amount. Reverts if `msg.sender` is not the intent owner. * * * #### [](#fulfillintent) fulfillIntent Copy function fulfillIntent(bytes calldata _paymentProof, bytes32 _intentHash) external whenNotPaused **Description**: Attempts to prove that the off-chain payment has been made according to the associated payment verifier. On success: * The escrowed tokens are transferred to the specified `to` address. * Fees are taken out for sustainability and optionally the payment verifier. **Parameters**: * `_paymentProof` – The proof data for verifying off-chain payment (e.g., TLSNotary, ZK, etc.). * `_intentHash` – The ID of the signaled intent. **Reverts** if: * The verifier check fails. * The `_intentHash` does not match the proof’s extracted intent hash. **Emits**: * `IntentFulfilled` event. * * * #### [](#releasefundstopayer) releaseFundsToPayer Copy function releaseFundsToPayer(bytes32 _intentHash) external **Description**: Allows the **deposit owner** (not the intent owner) to push funds to the off-chain payer’s `to` address, effectively acknowledging the payment or an alternative arrangement. **Effects**: * Removes the intent from state. * Transfers tokens to the `intent.owner` or `intent.to`. * Emits `IntentFulfilled` event with zero verifier address. * * * #### [](#updatedepositconversionrate) updateDepositConversionRate Copy function updateDepositConversionRate( uint256 _depositId, address _verifier, bytes32 _fiatCurrency, uint256 _newConversionRate ) external whenNotPaused **Description**: The depositor can adjust the deposit’s conversion rate for a specific currency and verifier. Only future intents will be affected; existing ones store the old rate. * * * #### [](#withdrawdeposit) withdrawDeposit Copy function withdrawDeposit(uint256 _depositId) external **Description**: Withdraws any unencumbered tokens from the deposit. Prunes any expired intents (making more tokens claimable). If no tokens remain (and no open intents), the deposit is fully closed and removed. * * * ### [](#governance-functions) Governance Functions #### [](#addwhitelistedpaymentverifier) addWhitelistedPaymentVerifier Copy function addWhitelistedPaymentVerifier(address _verifier, uint256 _feeShare) external onlyOwner Adds a payment verifier to the whitelist, with a certain `_feeShare`. #### [](#removewhitelistedpaymentverifier) removeWhitelistedPaymentVerifier Copy function removeWhitelistedPaymentVerifier(address _verifier) external onlyOwner Removes a verifier from the whitelist. #### [](#updatepaymentverifierfeeshare) updatePaymentVerifierFeeShare Copy function updatePaymentVerifierFeeShare(address _verifier, uint256 _feeShare) external onlyOwner Updates the fee share for a given whitelisted verifier. #### [](#updateacceptallpaymentverifiers) updateAcceptAllPaymentVerifiers Copy function updateAcceptAllPaymentVerifiers(bool _acceptAllPaymentVerifiers) external onlyOwner Toggles whether **any** verifier address can be used (bypassing the whitelist). #### [](#setsustainabilityfee) setSustainabilityFee Copy function setSustainabilityFee(uint256 _fee) external onlyOwner Sets the global sustainability fee (max 5%). Fee is taken upon intent fulfillment. #### [](#setsustainabilityfeerecipient) setSustainabilityFeeRecipient Copy function setSustainabilityFeeRecipient(address _feeRecipient) external onlyOwner Sets the address receiving protocol fees. #### [](#setintentexpirationperiod) setIntentExpirationPeriod Copy function setIntentExpirationPeriod(uint256 _intentExpirationPeriod) external onlyOwner Updates how long an intent remains valid before it can be pruned. #### [](#pauseescrow-unpauseescrow) pauseEscrow / unpauseEscrow Copy function pauseEscrow() external onlyOwner function unpauseEscrow() external onlyOwner Pauses or unpauses the contract’s core functions: * **Paused**: Creates deposit, updates conversion rate, signals/fulfills intent are disabled. * **Unpaused**: Resumes all functionalities. * * * ### [](#external-view-functions) External View Functions #### [](#getprunableintents) getPrunableIntents Copy function getPrunableIntents(uint256 _depositId) external view returns (bytes32[] memory prunableIntents, uint256 reclaimedAmount); Returns a list of expired (prunable) intent hashes for a deposit and the total amount they occupy. #### [](#getdeposit) getDeposit Copy function getDeposit(uint256 _depositId) public view returns (DepositView memory depositView); Returns a **DepositView**, including: * The deposit details. * Available liquidity (accounting for expired intents). * Associated verifiers/currency data. #### [](#getaccountdeposits) getAccountDeposits Copy function getAccountDeposits(address _account) external view returns (DepositView[] memory depositArray); Returns the set of deposits belonging to `_account`. #### [](#getdepositfromids) getDepositFromIds Copy function getDepositFromIds(uint256[] memory _depositIds) external view returns (DepositView[] memory depositArray); Returns the `DepositView[]` for a given list of deposit IDs (part of **IEscrow** interface). #### [](#getintent) getIntent Copy function getIntent(bytes32 _intentHash) public view returns (IntentView memory intentView); Provides the **IntentView**, linking the intent to its deposit. #### [](#getintents) getIntents Copy function getIntents(bytes32[] calldata _intentHashes) external view returns (IntentView[] memory intentArray); Batch retrieval of multiple intents. #### [](#getaccountintent) getAccountIntent Copy function getAccountIntent(address _account) external view returns (IntentView memory intentView); Returns the active intent (if any) for a given account. [PreviousSmart Contracts](/developer/smart-contracts) [NextIEscrow](/developer/smart-contracts/escrow/iescrow) Last updated 19 days ago --- # Smart Contracts | ZKP2P [](#escrow) Escrow ----------------------- The `Escrow` contract is designed to orchestrate the interaction between different actors in the ecosystem. It manages user registrations, deposits, and transaction intents, and employs Zero-Knowledge Proofs for validation purposes. Additionally, it provides mechanisms for dispute resolution, instant verification, and governance controls to maintain system integrity and ensure a secure and trustless environment for P2P transactions. [](#verifiers) Verifiers ----------------------------- The Verifiers are contracts designed to verify and process on-chain proof of off-chain transactions, ensuring they conform to specified protocols. It validates various elements of the transactions including transaction amount, timestamp, recipient ID and intent hash. Through these validations, it facilitates secure transaction processing in the system. Verifiers conform to a `BasePaymentVerifier` [specification](https://github.com/zkp2p/zkp2p-v2-contracts/blob/main/contracts/verifiers/BasePaymentVerifier.sol) . For an example of an implemented payment verifier, please check [here](https://github.com/zkp2p/zkp2p-v2-contracts/blob/main/contracts/verifiers/VenmoReclaimVerifier.sol) . [](#nullifier-registry) Nullifier Registry ----------------------------------------------- The `NullifierRegistry` is a smart contract that records unique identifiers (nullifiers) to prevent duplication in actions like user registrations. It controls writer permissions for adding nullifiers and offers transparent logging of these actions through emitted events. [PreviousThe ZKP2P V2 Protocol](/developer/the-zkp2p-v2-protocol) [NextEscrow](/developer/smart-contracts/escrow) Last updated 19 days ago --- # The ZKP2P V2 Protocol | ZKP2P [](#introduction) Introduction ----------------------------------- The ZKP2P V2 Protocol enables trust minimized and fully noncustodial buying and selling of any offchain digital asset (e.g. fiat currencies) for any onchain asset (e.g. USDC, Ethereum, Solana). The protocol functions as a set of onchain smart contracts that escrows and unlocks tokens upon satisfaction of a predefined predicate (i.e. proof of web2 payment). These predicates can be defined in the form of any cryptographic primitive whether proxy-TLS (zkTLS), MPC-TLS (TLSNotary), zkEmail or TEEs. [](#why-zkp2p-v2) Why ZKP2P V2? ------------------------------------ With [ZKP2P V1](https://github.com/zkp2p/) , we launched the first ever trust minimized fiat to crypto on/offramp in production, enabling swaps between USD in Venmo, EUR in Revolut and INR in HDFC Bank for USDC. These swaps were powered by ZK proofs using the [zkEmail](https://prove.email/) library. V1 intended to be an alpha proof of concept which explored and pushed the edge of what could be done by bringing valuable web2 data for use onchain in a privacy preserving and verifiable way, while solving the biggest pain point that exists in crypto. ZKP2P V2 is a doubling down of this vision to create an exchange that enables fast, cheap, low fraud and DeFi composable swaps between offchain and onchain assets. V2 extends upon V1 and solves many of its limitations including: 1. Complex user flows 2. Fragmentation of liquidity 3. Difficulty for external integrations directly at the protocol layer 4. No optional identity verification layer to unlock higher limits 5. Proving speed [](#solution) Solution --------------------------- ZKP2P V2 is a set of generic escrow smart contracts, crypto primitives and supporting relayers and interfaces that enable seamless exchange between web2 and web3. The protocol now supports the following: 1. Generic to any payment platform and fiat currency as long as the platform uses a server 2. Optional identity verification service for sellers to enable higher limits. Some sellers may want to limit which buyers can transact with them, which is now handled by this service 3. Privacy of payment identifier. Previously, payments IDs were stored onchain, these have been moved to a offchain relayer role. Funds are always escrowed onchain and are not accessible to anyone else 4. Capital efficiency for sellers. Sellers can specify all fiat and platforms they are willing to receive payment in supported in the protocol for their deposited liquidity. This is in contrast to providing liquidity for each pool by itself 5. Supports any cryptographic primitives including TEEs. Cryptographic primitives have been evolving rapidly and will continue to do so, therefore, the protocol must adapt to be able to support any primitive in the future 6. OAuth using a headless extension. V2 introduces a new extension based flow that mirrors OAuth while preserving privacy and expanding access to what can be authenticated 7. Composable. All transactions can be aggregated with rest of ecosystem such as bridging, swapping or minting. 8. Wallet and gas abstraction. The protocol now supports any third party to sponsor gas or provision a wallet for the user. The user does not even need to own an account abstracted wallet to transact. 9. Non custodial. V2 moves all logic that is not associated with fund transfers or custody to supporting relayers which decreases latency and steps for parties transacting in the protocol. While leveraging the blockchain for decentralization, and the non custodial nature of smart contracts. No one has access to user funds except themselves. And that will always remain the case ### [](#user-flow) **User Flow** 1. **Signal Intent:** The buyer indicates an intention to on-ramp by creating an order and specifying the amount of the onchain asset they wish to receive. Once the order is created, the corresponding offramper's liquidity is locked in escrow the buyer a period of time to complete the offchain payment and generate a proof of transaction. 2. **Perform Off-chain Payment.** Execute an offchain payment in fiat currency through the payment service to the designated seller 3. **Proof of Payment:** After payment, the buyer generates a proof of payment data and it's authenticity along with also extracting the following from the payment data * Off-ramper’s Off-chain payment ID * Payment amount * Payment timestamp * Payment currency * Other optional state (e.g. transaction status) to be handled by the Verifier 4. **Unlocking Escrow.** The smart contract checks the proof of payment along with the following to unlock the escrowed funds: * Verification of the on-ramper’s intent * Correspondence of the deposit to the correct off-ramper * Adequacy of the payment amount * Timing of the payment post-intent Below is an illustrative example of a flow using MPC-TLS (TLSNotary) which can be extended to any crypto primitive. ### [](#the-tech-stack) The Tech Stack * **Escrow Protocol:** Smart contracts on the Ethereum blockchain enable trustless transactions and manage the logic of the protocol. * **Circuits / zkTLS protocol:** Cryptographic primitives that enable generation of private, secure and verifiable credentials to validate payments were made properly in a web2 context. Under the hood, these are proxy-TLS (Reclaim), MPC-TLS (TLSNotary), zkEmail and TEEs * **PeerAuth Extension / Appclip:** Browser extension and mobile appclip that enables users to generate privacy preserving web proofs using any cryptographic primitive (zkTLS, TLSNotary, zkEmail etc) similar to OAuth * **Gating Service:** Backend service that curates validates intents enabling sellers to only offer liquidity to users who pass any optional additional verification. Sellers trust the Gating Service to prevent buyers from submitting an intent to their liquidity if they haven't satisfied certain requirements (e.g. user identity). The gating service does not custody or touch funds ever. Conforms to a standard gating service specification as defined by the ZKP2P protocol. * **User Interface (UI):** The UI is the front-end through which users interact with the protocol. ### [](#supported-cryptographic-primitives) Supported Cryptographic Primitives **ZK-Email Libraries** ZKP2P builds upon the 0xParc/PSE [ZK-Email](https://prove.email/) libraries to enable proof generation related to the contents of payment confirmation emails. These libraries are essential for verifying transaction details without exposing private information. #### [](#tlsnotary-libraries) TLSNotary Libraries ZKP2P utilizes [TLSNotary](https://docs.tlsnotary.org/) for certain flows to enable TLS data to be used on-chain in a privacy preserving way. #### [](#tlsproxy-libraries) TLSProxy Libraries ZKP2P V2 utilizes [Reclaim protocol's](https://www.reclaimprotocol.org/) proxy-TLS flow to verify payments. [PreviousZKP2P](/) [NextSmart Contracts](/developer/smart-contracts) Last updated 2 days ago ![](https://docs.zkp2p.xyz/~gitbook/image?url=https%3A%2F%2F3629680097-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F6e2L3XxfmJSq8oZRw1gA%252Fuploads%252FkXuieA8le9pG2dOitFJY%252Fimage.png%3Falt%3Dmedia%26token%3D8ea4ac90-8d62-404c-8449-36cb744ab453&width=768&dpr=4&quality=100&sign=4979588f&sv=2) --- # IPaymentVerifier | ZKP2P ### [](#overview) Overview The **IPaymentVerifier** interface contract verifies off-chain payment proofs. This enables on-chain actions (such as releasing escrowed funds) once a valid proof that a payment occurred is provided. Verifiers can be added to the Escrow which unlock new payment platforms and currencies that users can transact with ### [](#structs) Structs Copy struct VerifyPaymentData { bytes paymentProof; // Payment proof address depositToken; // Address of deposit token uint256 amount; // Amount of deposit token uint256 timestamp; // Timestamp of payment string payeeDetails; // Payee details bytes32 fiatCurrency; // Fiat currency uint256 conversionRate; // Conversion rate of deposit token to fiat currency bytes data; // Additional data } Additional data may include mail server key hash if using zkEmail, notary public key for TLSNotary or witness proxy for TLSProxy (Reclaim) ### [](#external-functions) External Functions #### [](#verifypayment) verifyPayment Copy function verifyPayment( IPaymentVerifier.VerifyPaymentData calldata _verifyPaymentData ) external override returns (bool, bytes32) **Description**: Override function that must be implemented when adding a new Verifier. The `escrow` contract calls this method to confirm that a payment was indeed made according to the provided proof. If successful: * The payment is nullified (cannot be claimed again). * Returns a boolean indicating success and the `intentHash`. * * * [PreviousIEscrow](/developer/smart-contracts/escrow/iescrow) [NextDeployments](/developer/smart-contracts/deployments) Last updated 19 days ago --- # FAQ | ZKP2P [](#general) General ------------------------- #### [](#can-you-integrate-with-any-payment-service) Can you integrate with any payment service? > Yes, ZKP2P V2 is generic escrow protocol that can support any payment service or predicate as long as they have a website. If you are a developer and would like to build an integration, please contact us in our [Telegram](https://t.me/zk_p2p) > or check out the rest of the documentation. #### [](#is-it-possible-to-on-ramp-to-other-on-chain-assets) Is it possible to on-ramp to other on-chain assets? > Yes, the protocol is a set of smart contracts that can be composable with anything onchain including DeFi, bridges, NFTs and more. Its as simple as writing a periphery smart contract #### [](#what-are-the-risks-associated-with-using-zkp2p) What are the risks associated with using zkp2p? > Check out our risks page. [😬Risks](/developer/risks) #### [](#im-concerned-about-privacy-what-data-am-i-sharing) I'm concerned about privacy - what data am I sharing? > Check out our privacy and safety page. [🦺Privacy and Safety](/developer/privacy-and-safety) [PreviousRisks](/developer/risks) [NextPrivacy and Safety](/developer/privacy-and-safety) Last updated 19 days ago ![Page cover image](https://docs.zkp2p.xyz/~gitbook/image?url=https%3A%2F%2F3629680097-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F6e2L3XxfmJSq8oZRw1gA%252Fuploads%252F4uLfLN48CGEMVOLn2783%252Fworld_currency_7.png%3Falt%3Dmedia%26token%3D396801a1-0351-4aa8-8140-4ecae494c4bf&width=1248&dpr=4&quality=100&sign=11c44f8d&sv=2) --- # Security | ZKP2P ZKP2P is currently in its alpha stage and should be used at your own risk. Our circuits have been audited by PSE. We have outlined known potential risks associated with using the protocol, acknowledging that there may be additional risks not yet identified. ### [](#audits) Audits * ZKP2P alpha circuits have been audited by [PSE](https://pse.dev/) * Reclaim circuits that are used in our zkTLS flows are [audited by ZKSecurity](https://www.zksecurity.xyz/blog/posts/reclaim/) [PreviousIntegrate ZKP2P](/developer/integrate-zkp2p) [NextRisks](/developer/risks) Last updated 19 days ago --- # Privacy and Safety | ZKP2P ### [](#zktls-oauth) zkTLS OAuth **I'm concerned that I'm giving PeerAuth OAuth access to all of my data when I'm on a website.** When PeerAuth views data after an OAuth (e.g. Sign In With Venmo), only select data is revealed to the webpage by the extension. All data not required for a successful on-chain transaction is blinded. As part of the extension logic we redact all data except the required fields which prevents any additional account details being leaked other than data related to a transaction. All data remains local in your browser and nothing is stored across sessions. Our client is fully [open source](https://github.com/zkp2p/zkp2p-v2-client) . Additionally to verify client build is correct, you can inspect the Networks tab in your browser Developer Tools to ensure no data is leaked from your browser [PreviousFAQ](/developer/faq) [NextTeam](/resources/team) Last updated 19 days ago --- # Risks | ZKP2P [](#off-ramp-risks) Off-ramp Risks --------------------------------------- * **Governance-Controlled Public Key**: The protocol's governance can update the public key of the witness associated with payment verifiers. If the new key is under their control, they could potentially forge proofs, sign them, and access the USDC deposited in the protocol. Initially governance will consist of a multisig and will be decentralized in the future. * **Proxy or Notary colllusion:** If there is collusion between the buyer and the Notary or Proxy then there is possibility of forging proofs to access seller liquidity * **Proxy MITM attack:** It is theoretically possible for the buyer to man in the middle attack a proxy-TLS solution by injecting spoofed ciphertext packets in between the proxy and the server / datacenter when the data is going to be signed by the proxy. This is highly unlikely as attacker must be near a data center and incentivized to pull off the attack when single transaction amounts are not high. We will be monitoring this in the future, and as we scale up limits and MPC TLS becomes more production ready, we will switch to this which cannot be attacked by a MITM * **Reversible Transactions:** Web2 transactions are potentially reversible. An on-ramper after claiming your USDC may be able to reverse your transaction. We have restricted the on-ramp amount and frequency to disincentivize this behavior. Also, you can block a malicious on-ramper to prevent them from opening an order against your deposit [](#on-ramp-risks) On-ramp Risks ------------------------------------- * **Privacy Concerns**: All proving is conducted locally, sensitive data is redacted prior to posting onchain, but you are leaking your username to the seller when onramping * **API Change**: If the payment platform alters its API format, the existing integrations may no longer be valid for proof generation, even if the off-chain payment has already been made. This could prevent the completion of the on-ramping process. If this happens, governance will try to update the smart contract processors to allow the continued functioning of the protocol. [PreviousSecurity](/developer/security) [NextFAQ](/developer/faq) Last updated 19 days ago --- # Gating Service | ZKP2P [PreviousPeerAuth Extension](/developer/peerauth-extension) [NextzkTLS](/developer/zktls) Last updated 1 day ago The Gating Service is a periphery service that acts as a trusted relayer of identity verification and payment details offchain. The Gating Service does not have access to seller or buyer funds. All actions that the service conducts can be verifiably checked by either party to prevent undetected malicious behavior. The Gating Service has 2 roles 1. Gate [signalIntent](/developer/smart-contracts/escrow#signalintent) on behalf of the seller to only allow specified wallets from transacting with the seller liquidity. The Gating Service performs validations on the wallet address and other metadata and if buyer passes, then sign the intent with an ECDSA private key and return the seller payment data for buyer to send to. Anyone can create a gating service / relayer for different purposes if they do not want to use ZKP2P's default relayer. E.g. a relayer that requires KYC for large OTC trades, a relayer to gate for members of a specific community. Users can choose not to interact with a relayer and use the blockchain as a DB as well. 2. Store offchain payment identifiers (e.g. Venmo User ID) in the [deposit flow](/developer/smart-contracts/escrow) for sellers to introduce a layer of privacy to the blockchain ### [](#api-reference) API Reference Our current gating service API is hosted at api.zkp2p.xyz. Check out the docs: [![Logo](https://api.zkp2p.xyz/docs/favicon-32x32.png)Swagger UI](https://api.zkp2p.xyz/docs) ![](https://docs.zkp2p.xyz/~gitbook/image?url=https%3A%2F%2F3629680097-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F6e2L3XxfmJSq8oZRw1gA%252Fuploads%252FjcATRW7pdKrKl5V1fp1B%252Fv2_protocol_2.png%3Falt%3Dmedia%26token%3Dc37542bc-48f8-43f3-a166-0f4cd69e3dfe&width=768&dpr=4&quality=100&sign=8905f623&sv=2) --- # Integrate ZKP2P | ZKP2P [PreviouszkTLS](/developer/zktls) [NextSecurity](/developer/security) Last updated 2 days ago > ⚠️ Self service integration is currently not available. Please contact us if you're interested in integrating ZKP2P into your app [Team ZKP2P](mailto:team@zkp2p.xyz) --- # PeerAuth Extension | ZKP2P [PreviousDeployments](/developer/smart-contracts/deployments) [NextGating Service](/developer/gating-service) Last updated 1 day ago At the heart of ZKP2P, we use a cryptographic technology called zkTLS. zkTLS allows users to securely and **privately** export data similar to [OAuth](https://oauth.net/2/) but for **any website even if there are no public APIs**. This is powerful as users can now free their data from monopolies held by the the largest providers such as Google or Facebook. The entire flow is powered by advanced cryptographic techniques like **Zero Knowledge Proofs (ZKP)** and **Multi-Party Computation (MPC)**, to enable users to selectively share their data in a verifiable yet privacy-preserving manner. [](#peerauth-authenticate-and-use-credentials-across-websites) PeerAuth: Authenticate and use credentials across websites ------------------------------------------------------------------------------------------------------------------------------ The **PeerAuth** extension is a browser companion that provides a simple interface for users to generate zkTLS proofs for protocols that require verified credentials such as ZKP2P. The extension is **headless** meaning no popups or extra clicks from the user, and all data is stored locally thus preserving privacy for users. #### [](#functions) Functions PeerAuth plays a key role in helping buyers authenticate their payment transactions for the fastest and cheapest fiat to crypto onramp experience. Its primary functions include: * **Assisting with Data Flow:** The extension fetches and displays the required data from the web2 page you’re on, guiding you through the process. * **Returns metadata:** It returns metadata from the website that require your input, prompting you to generate a proof for the right payment transaction * **Fetching Necessary Cookies:** The extension retrieves the relevant cookies from sites you’re logged into. These cookies are used to generate proof of web2 data, such as previous 10 Venmo transactions. _**Note**__:_ All data collected strictly stays on the user's device and only zero-knowledge proofs of their data leave their devices. All private data that isn't relevant to proving the validity of a ticket or a ticket transfer, is redacted before sharing with our deployed verifier. Currently, PeerAuth only supports ZKP2P as its first integration, but the extension is generalized to support OAuth into any website. #### [](#install) Install You can install the [ZKP2P PeerAuth](https://chromewebstore.google.com/detail/zkp2p-extension/ijpgccednehjpeclfcllnjjcmiohdjih?hl=en&authuser=3&pli=1) from the Chrome web store. ![Page cover image](https://docs.zkp2p.xyz/~gitbook/image?url=https%3A%2F%2F3629680097-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F6e2L3XxfmJSq8oZRw1gA%252Fuploads%252F4uLfLN48CGEMVOLn2783%252Fworld_currency_7.png%3Falt%3Dmedia%26token%3D396801a1-0351-4aa8-8140-4ecae494c4bf&width=1248&dpr=4&quality=100&sign=11c44f8d&sv=2) ![](https://docs.zkp2p.xyz/~gitbook/image?url=https%3A%2F%2F3629680097-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F6e2L3XxfmJSq8oZRw1gA%252Fuploads%252Fjhh6aWqabuBuTgu7wpa0%252Fextension_diagram.png%3Falt%3Dmedia%26token%3Dcd72adcd-2427-4889-9c3f-4eae8d7fde3a&width=768&dpr=4&quality=100&sign=52091610&sv=2) --- # Deployments | ZKP2P ### [](#base) Base Contract Address Escrow [0xCA38607D85E8F6294Dc10728669605E6664C2D70](https://basescan.org/address/0xCA38607D85E8F6294Dc10728669605E6664C2D70) NullifierRegistry [0x27B4A4542af8EefB7eBf574a562C5D4DaA17137F](https://basescan.org/address/0x27B4A4542af8EefB7eBf574a562C5D4DaA17137F) VenmoReclaimVerifier [0x9a733B55a875D0DB4915c6B36350b24F8AB99dF5](https://basescan.org/address/0x9a733B55a875D0DB4915c6B36350b24F8AB99dF5) RevolutReclaimVerifier [0xAA5A1B62B01781E789C900d616300717CD9A41aB](https://basescan.org/address/0xAA5A1B62B01781E789C900d616300717CD9A41aB) CashappReclaimVerifier [0x76D33A33068D86016B806dF02376dDBb23Dd3703](https://basescan.org/address/0x76D33A33068D86016B806dF02376dDBb23Dd3703) WiseReclaimVerifier [0xFF0149799631D7A5bdE2e7eA9b306c42b3d9a9ca](https://basescan.org/address/0xFF0149799631D7A5bdE2e7eA9b306c42b3d9a9ca) ### [](#sepolia-testnet) Sepolia (Testnet) Contract Address Escrow [0xFF0149799631D7A5bdE2e7eA9b306c42b3d9a9ca](https://sepolia.etherscan.io/address/0xFF0149799631D7A5bdE2e7eA9b306c42b3d9a9ca) NullifierRegistry [0x9cF61278C2Cc9C41578fE3a0ED375E9870D514F1](https://sepolia.etherscan.io/address/0x9cF61278C2Cc9C41578fE3a0ED375E9870D514F1) VenmoReclaimVerifier [0x3Fa6C4135696fBD99F7D55B552B860f5df770710](https://sepolia.etherscan.io/address/0x3Fa6C4135696fBD99F7D55B552B860f5df770710) RevolutReclaimVerifier [0x79820f039942501F412910C083aDA6dCc419B67c](https://sepolia.etherscan.io/address/0x79820f039942501F412910C083aDA6dCc419B67c) CashappReclaimVerifier [0x3997dd7B691E11D45E8898601F5bc7B016b0d38B](https://sepolia.etherscan.io/address/0x3997dd7B691E11D45E8898601F5bc7B016b0d38B) ### [](#supported-currencies) Supported Currencies Currency Verifier Code AED 0x4dab77a640748de8588de6834d814a344372b205265984b969f3e97060955bfa AUD 0xcb83cbb58eaa5007af6cad99939e4581c1e1b50d65609c30f303983301524ef3 CAD 0x221012e06ebf59a20b82e3003cf5d6ee973d9008bdb6e2f604faa89a27235522 CHF 0xc9d84274fd58aa177cabff54611546051b74ad658b939babaad6282500300d36 CNY 0xfaaa9c7b2f09d6a1b0971574d43ca62c3e40723167c09830ec33f06cec921381 EUR 0xfff16d60be267153303bbfa66e593fb8d06e24ea5ef24b6acca5224c2ca6b907 GBP 0x90832e2dc3221e4d56977c1aa8f6a6706b9ad6542fbbdaac13097d0fa5e42e67 HKD 0xa156dad863111eeb529c4b3a2a30ad40e6dcff3b27d8f282f82996e58eee7e7d IDR 0xc681c4652bae8bd4b59bec1cdb90f868d93cc9896af9862b196843f54bf254b3 ILS 0x313eda7ae1b79890307d32a78ed869290aeb24cc0e8605157d7e7f5a69fea425 JPY 0xfe13aafd831cb225dfce3f6431b34b5b17426b6bff4fccabe4bbe0fe4adc0452 KES 0x589be49821419c9c2fbb26087748bf3420a5c13b45349828f5cac24c58bbaa7b MXN 0xa94b0702860cb929d0ee0c60504dd565775a058bf1d2a2df074c1db0a66ad582 MYR 0xf20379023279e1d79243d2c491be8632c07cfb116be9d8194013fb4739461b84 NZD 0xdbd9d34f382e9f6ae078447a655e0816927c7c3edec70bd107de1d34cb15172e PLN 0x9a788fb083188ba1dfb938605bc4ce3579d2e085989490aca8f73b23214b7c1d SAR 0xf998cbeba8b7a7e91d4c469e5fb370cdfa16bd50aea760435dc346008d78ed1f SGD 0xc241cc1f9752d2d53d1ab67189223a3f330e48b75f73ebf86f50b2c78fe8df88 THB 0x326a6608c2a353275bd8d64db53a9d772c1d9a5bc8bfd19dfc8242274d1e9dd4 TRY 0x128d6c262d1afe2351c6e93ceea68e00992708cfcbc0688408b9a23c0c543db2 USD 0xc4ae21aac0c6549d71dd96035b7e0bdb6c79ebdba8891b666115bc976d16a29e VND 0xe85548baf0a6732cfcc7fc016ce4fd35ce0a1877057cfec6e166af4f106a3728 ZAR 0x53611f0b3535a2cfc4b8deb57fa961ca36c7b2c272dfe4cb239a29c48e549361 [PreviousIPaymentVerifier](/developer/smart-contracts/ipaymentverifier) [NextPeerAuth Extension](/developer/peerauth-extension) Last updated 4 days ago ![Page cover image](https://docs.zkp2p.xyz/~gitbook/image?url=https%3A%2F%2F3629680097-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F6e2L3XxfmJSq8oZRw1gA%252Fuploads%252FV7cwSAg6YoR2PAjyKwz1%252Fcurrencies-world-5.png%3Falt%3Dmedia%26token%3D2c43c112-6521-44be-a424-d3ed7f9152e3&width=1248&dpr=4&quality=100&sign=3bbc75c4&sv=2) --- # zkTLS | ZKP2P [PreviousGating Service](/developer/gating-service) [NextIntegrate ZKP2P](/developer/integrate-zkp2p) Last updated 3 days ago [](#overview) Overview --------------------------- At ZKP2P, we make heavy use of zkTLS techniques to prove authenticity of data while preserving user privacy. zkTLS enables us to port any data from the web served through TLS1.2 and TLS1.3 to smart contracts. In particular, there are 2 techniques: TLSNotary (MPC-TLS) and TLSProxy (proxy based approach e.g [Reclaim Protocol](https://reclaimprotocol.org/) ) [](#tlsnotary) TLSNotary ----------------------------- ### [](#notary) Notary The Notary runs the 2PC-TLS protocol with the Buyer and attests the transcript to make the data portable. The buyer submits that attestation as the proof of payment to the verifier contract on-chain. Currently, ZKP2P provides a hosted Notary to its users via the ZKP2P extension. Generating proof of payment for ZKP2P using TLSN ### [](#websocket-proxy) WebSocket Proxy Since a web browser can't make TCP connection, we need to use a WebSocket proxy server. ZKP2P provides a hosted WebSocket proxy to all its users via the ZKP2P extension. The proxy only forwards encrypted data from the Prover to the server and returns the encrypted response returned from the server back to the Prover. If the proxy fails the user can always run their proxy to forward the request to the server. ### [](#decentralization-of-notaries) Decentralization of Notaries Note that, the seller is trusting the Notary to not collude with the Buyer and generate fake proof of payment. The buyer is also trusting the Notary to not censor it. Currently ZKP2P runs both the Notary and websocket proxy. But we are commited to the decentralization roadmap and are coming up with solutions to solve both the collusion and censorship problem in a decentralized way. One solution that we are working on currently is the Optimistic Notarization flow. #### [](#arbitration) Arbitration * Optimistic notarization works because seller is incentivized to initiate arbitration if they find a discrepancy * Arbitration involves getting majority stake to disagree with initial notarization * For on/off-ramping, proving that seller didn’t receive off-chain payment * If found guilty, the malicious notary is slashed * Slashed amount is used to compensate seller and the network * Arbitration is still inefficient * But slashing deters the notary from acting maliciously * Similar to optimistic rollups, don’t expect arbitration to happen in 99% of the cases * Privacy of data is maintained from notaries due to 2PC-TLS protocol ### [](#references) References To understand why we are building with TLSN and the Optimistic Notarization flow please watch our ZK11 talk To understand TLSNotary, please go through their docs [](#tlsproxy-reclaim) TLSProxy (Reclaim) --------------------------------------------- Unlike TLSNotary, the proxy approach relies on the Notary being in between the Prover (buyer) and the Server. Privacy is still preserved as only encrypted ciphertext is sent from the Prover to the Notary (Witness Proxy), and the prover is the only party that holds the symmetric TLS keys. This approach is significantly more efficient as it removes the need to generate the TLS session keys using 2PC Garbled Circuits. However, it is not as censorship resistant as the MPC-TLS approach due to the introduction of network topology assumptions. In particular, the server API call is from the Notary (Proxy), not from the prover's home computer, therefore, servers could censor the proxy if its hosted in a datacenter. Additionally, there is a possibility of a Prover MITM (man-in-the-middle) attack to change packets enroute if they are able to gain access to the port in the datacenter where the Notary (Proxy) is hosted. This is because the Prover holds the TLS keys. Despite this, we believe the proxy based approach is most production ready and can scale up to a certain dollar amount of value before we need to migrate to TLSNotary. Reclaim protocol has undergone multiple audits ([link](https://reclaimprotocol.org/blog/posts/chacha-circuit-audit) ). Additionally, ZKP2P is built to be generic so we can plug in any primitive as they become mature. For more details, please check out the Reclaim docs: Optimistic Notarization with a network of Notaries ![](https://docs.zkp2p.xyz/~gitbook/image?url=https%3A%2F%2Flh7-us.googleusercontent.com%2FVsvr4V0SKecmStzru9uuhag2bMlGuONqNA3zNj6NzVvYy--cc9jiEAUZCuIMR2q7tpQowRNMxl3S_rz2MzTKpdvdXg1y7GIcDv6RS2RPApIp_LkaYDozlPu1bCUh3Qt6sGO2Usfv7cdnqEiNEb2pzJzjGg%3Ds2048&width=768&dpr=4&quality=100&sign=351b1636&sv=2) ![](https://docs.zkp2p.xyz/~gitbook/image?url=https%3A%2F%2Flh7-us.googleusercontent.com%2FWN8pzQrQOghkgqRDt4L-P73KRhqelGebUWPq78Z1LvCA7JwWDxjrA2JEHZ19U-l24VkCAt5fOfPYuhdUGHbcgfWxS0q3leGX1pWJVPNYQdhfCXF_y4jXmB7_SU6VAPjUqQdf7CF4vQl5aKFNFMTcFrmfOQ%3Ds2048&width=768&dpr=4&quality=100&sign=197e2e64&sv=2) [![Logo](https://docs.tlsnotary.org/favicon.svg)Introduction - tlsn-docs](https://docs.tlsnotary.org) [Reclaim Protocol Docs](https://docs.reclaimprotocol.org/) Simplified 2PC-TLS protocol between the Prover and the Verifier (Notary) ![](https://docs.zkp2p.xyz/~gitbook/image?url=https%3A%2F%2F3629680097-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F6e2L3XxfmJSq8oZRw1gA%252Fuploads%252FtkeKhlroW2LPia2MDRWc%252Fgaranti%2520circuits%2520diagram%2520%281%29.png%3Falt%3Dmedia%26token%3D58bf305a-9288-4245-b7ed-6478e0bb4e6b&width=768&dpr=4&quality=100&sign=ac1dc5e5&sv=2) --- # Team | ZKP2P [PreviousPrivacy and Safety](/developer/privacy-and-safety) Last updated 20 days ago ### [](#talks) Talks ### [](#writing) Writing * [2PC is for P2P](https://github.com/zkp2p/zkp2p-tlsn-whitepaper/blob/main/zkp2p_tlsn_whitepaper.pdf) * [EIC02](https://issuu.com/ethinvestorsclub/docs/eic02_full_article_draft_3.0/72) It's supposed to be "Sachin" lmao ![Page cover image](https://docs.zkp2p.xyz/~gitbook/image?url=https%3A%2F%2F3629680097-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F6e2L3XxfmJSq8oZRw1gA%252Fuploads%252FV7cwSAg6YoR2PAjyKwz1%252Fcurrencies-world-5.png%3Falt%3Dmedia%26token%3D2c43c112-6521-44be-a424-d3ed7f9152e3&width=1248&dpr=4&quality=100&sign=3bbc75c4&sv=2) ---