Payment proof

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.

Sell USDC How ZKP2P works

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

All guides FAQ Payment methods Glossary

Common questions

What is USDCtoFiat?

USDCtoFiat coordinates non-custodial sales of native Base USDC for USD, EUR, or GBP through ZKP2P smart contracts. Payment-provider eligibility and account policies still apply; technical route support is not permission to use an external account, and Wise currently prohibits P2P crypto-sale receipts.

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 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.