Payment proof is the bridge between a fiat app and a Base contract.
A buyer's fiat payment cannot be seen directly by a smart contract. ZKP2P solves that gap by verifying payment evidence offchain and giving the contract a signed attestation it can check.
What has to be proven
For a fill to release, the payment evidence has to match the order. The important fields are amount, currency, recipient, payment method, timing, and the intent being fulfilled.
The verifier does not need to publish the whole payment history. It needs enough authenticated evidence to say that this payment, for this amount, to this payee, belongs to this intent.
Current verification model
ZKP2P V3 uses a TEE-hosted attestation service for supported payment flows. The service runs verification logic inside an AWS Nitro Enclave, checks payment data against typed platform schemas, and signs an EIP-712 PaymentAttestation after the payment matches.
This replaced the older buyer-heavy zkTLS model for many flows because browser-side proof generation was slow, extension-dependent, and fragile when payment platforms changed their web interfaces. The tradeoff is explicit: hardware-attested execution and reproducible enclave builds instead of asking every buyer to generate a local proof.
TEE-TLS vs legacy zkTLS
| Question | Legacy zkTLS | TEE-TLS |
|---|---|---|
| Where verification runs | Buyer browser or extension | Nitro Enclave attestation service |
| Buyer UX | Extension/proof generation can be heavy | Payment evidence is checked server-side inside the enclave |
| Verification logic | Provider templates and proof matching | Typed schemas and platform-specific transformers |
| Trust root | Proof system plus notary/proxy assumptions | Hardware attestation plus audited enclave code |
| Onchain result | Signed or verified release data | EIP-712 PaymentAttestation checked by verifier |
Privacy boundaries
- Personal payment data is not posted onchain.
- The counterparty sees the payout identifier needed to complete the payment.
- The chain sees hashes, nullifiers, signatures, amounts, contract addresses, and release events.
- USDCtoFiat does not hold your fiat account, does not custody your private keys, and cannot reverse a payment-app transfer.
Keep exploring
Common questions
What is USDCtoFiat?
USDCtoFiat lets you sell USDC on Base for money in Venmo, Cash App, Chime, Revolut, Wise, Zelle, PayPal, Monzo, N26, and Luxon. You keep control of your wallet, and trades settle through non-custodial ZKP2P smart contracts on Base.
Does USDCtoFiat hold my funds?
No. You sign every transaction from your own wallet. Your USDC is locked in a public Base contract and releases to the buyer only after their payment is proven. You can withdraw any unfilled deposit at any time.
What does it cost to sell?
Creating and managing a seller deposit is free, though Base gas applies to onchain actions. The offramp SDK is free to integrate. On delegated fills, Delegate's 0.10% manager fee comes from the USDC released to the buyer, not from your fiat proceeds or your quoted rate. Peerlytics analytics, webhooks, and API credits are priced separately.
Do I need a centralized exchange account?
No exchange account is required to use USDCtoFiat. You need a wallet holding USDC on Base and an account on the payment app you want to be paid in. The payment app's own account rules and limits still apply.
Do I need to complete KYC?
USDCtoFiat does not collect identity documents, hold your fiat, or hold your keys. The payment app you use still controls its own verification, limits, and account rules. USDC settlement happens through Base smart contracts, and we cannot change what Venmo, PayPal, Wise, Zelle, or your bank requires.
Is payment proof the same as a screenshot?
No. A screenshot is easy to fake and requires human judgment. ZKP2P verifies authenticated payment data and signs a structured attestation that the onchain verifier can check.
Does USDCtoFiat publish my payment app history?
No. Personal payment data is not posted onchain. The release path uses hashes, nullifiers, and signed attestations rather than publishing full payment records.
Why mention TEE instead of pretending everything is zero knowledge?
Because accuracy matters. ZKP2P has used zkEmail and zkTLS historically, and V3 uses TEE-hosted payment attestation for supported flows. The security model is different, and users deserve a precise explanation.