How Veya works
A peer-to-peer market like Binance P2P, without the platform holding anyone's money or judging disputes. No oracle, no custodian, no screenshots: the evidence is the bank's own cryptographic signature on the transfer receipt e-mail, checked inside a zero-knowledge proof that Stellar verifies on-chain.
- 1
Makers post ads with liquidity
A seller deposits XLM or USDC into the Soroban escrow with a price in TRY, minimum and maximum trade sizes, and their bank details encrypted to the market's reveal key. Only a hash of the IBAN and name goes on-chain in the clear. A 5% bond is deposited alongside.
- 2
Takers reserve any amount
A buyer picks an ad, enters how much TRY to spend or how many tokens to receive, and reserves: that slice is held for 60 minutes at the quoted price. The maker's IBAN and name are revealed to the buyer after a wallet signature, and the app checks they match the on-chain hash before showing them.
- 3
The buyer pays by FAST and declares it
A normal instant transfer from a Ziraat or VakıfBank account, with a short payment reference in the description that ties the payment to the buyer's wallet. Declaring the payment on-chain freezes the reservation for 2 hours: nobody but the buyer can release it.
- 4
The bank e-mails a DKIM-signed receipt
Ziraat's e-dekont (HTML) and VakıfBank's Dekont.pdf e-mails are signed with the bank's RSA key (DKIM, the standard every mail provider checks). The receipt is inside the signed body, so it cannot be altered without breaking the signature. The buyer drops the downloaded .eml (Gmail: Show original → Download original) on the reservation page; the e-mail goes to the prover only.
- 5
A RISC Zero zkVM program verifies the e-mail
It checks the DKIM signature against the bank's public key, decodes the attachment, and reads the transfer: date, recipient, amount, and the payment reference. It outputs only hashes, the amount, the date and a nullifier. The dekont itself stays private.
- 6
Groth16 proof verified on Stellar, escrow pays out
The receipt is wrapped into a Groth16 proof over BN254, generated in about 15 seconds on a GPU prover. Soroban verifies it natively in the RISC Zero verifier router (Nethermind), then the escrow checks the payee hash, the reserved amount, the date window, the wallet reference and replay protection, and pays the buyer.
- 7
What protects each side
Buyer: the declared reservation cannot be released for 2 hours, and if it is released anyway a valid proof within 3 days takes the maker's bond slice. Maker: a reservation that is never paid simply expires and the liquidity returns; nobody can take tokens without a valid bank proof for exactly that reservation, and a stolen e-mail is useless to anyone but the wallet it was paid for.
Two rails to the same balance
| Peer market (Veya) | Licensed anchor (SEP-6) | |
|---|---|---|
| Who uses it | buyers | makers, to refill USDC inventory or cash out |
| Identity | a wallet; no KYC | KYC at the anchor (SEP-12) |
| Custody | none: escrow contract, released by a proof | the anchor holds the bank leg |
| Evidence | the bank's DKIM-signed receipt, verified in zero knowledge | the anchor's own bank sees the transfer |
| Price | set by makers, competing with the anchor's rate | USD/TRY oracle + spread (SEP-38) |
| Direction | TRY → XLM/USDC | both ways |
The anchor integration is the standard SEP client path (SEP-1 discovery, SEP-10 login, SEP-6, SEP-38), so a real Turkish anchor is a home-domain change.
Contracts on testnet
- Escrow: CAFU5GMKM3UNZ3VLOZ7HX5HDFB7L7U2HM3UZLYLTFHIQLILIEYN5SDLG
- RISC Zero verifier router: CBHIBH3T5ZZL6ZZZJFKS5QQKSB2VQ4D7GMBKQLNOQ7P2XBMPGVPG3FCG
What the operator can and cannot do today
Cannot: take anyone's funds without a valid bank proof, forge a bank receipt, or settle a reservation for a wallet other than the one the payment reference names. Can: read makers' bank details (the reveal key is held by the operator), see the e-mails buyers upload (they are kept in memory only), and change the accepted zkVM program, DKIM keys or the contract code with the admin key, immediately and without a delay. Every such change is a public on-chain transaction. The production plan puts those changes behind a timelock and the reveal key inside an attested enclave; until then, treat this as a testnet demo run by a single operator.
Known limits of this version: payers must bank with Ziraat or VakıfBank; both banks' DKIM keys are RSA-1024 (only the bank could forge); the full e-mail is shared with the prover you choose; the reveal service operator can read makers' bank details; a proof that arrives after the 3-day window is not compensated; a buyer can delay a maker by the 2-hour window without paying.