Grant Application - 0xramp: Non-custodial ZEC ⇿ local-fiat ramp for emerging markets

Community Grants Applications
1

Hello, Zcash community!

We have just submitted a ZCG application for 0xramp ($206,000; startup + six milestones): 12 months of corridor hardening, NGN/COP/Ecuador-USD to production, shielded-first delivery, network-privacy work, and a public on-chain metrics dashboard.

GitHub application: Grant Application - 0xramp: Non-custodial ZEC ⇿ local-fiat ramp for emerging markets #408
Product introduction: Introducing 0xramp: non-custodial ZEC ↔ local fiat (Pix and more) for emerging markets
Live product: https://0xramp.app

Feedback and questions welcome here.
We will keep this thread updated through review and, if funded, monthly reports.

— Vini B
building 0xramp.app with @Michae2xl

6 Likes
2

Great to see the non-custodial architecture laid out so clearly.

Since every corridor settles through P2P.me and local rails like Pix, UPI, and GoPay.

Could you clarify whether 0xramp/p2p.me has a documented permission or partnership agreement with these rail providers for this kind of automated flow — generally their terms and conditions do not allow this, so doesn’t that risk users’ bank accounts getting frozen?

1 Like
3

UPDATE: 0xramp v1.0.0 is live!

Open beta is closed. 0xramp v1.0.0 is what is now running at 0xramp.app.

Same architecture as the original post: 0xramp is the interface + session layer. Your wallet places the order. P2P.me owns identity, limits, merchant matching, and USDC escrow on Base. NEAR Intents owns USDC ↔ ZEC (and other cryptocurrencies). We do not custody keys or the fiat payment.

What shipped in v1: revamped UI (user interface), the production shell (buy/sell, swap, activity, account/limits, invites, help), fiat-first quotes, in-app receipts, and the corridor table:

  • Stable: BRL (Pix), INR (UPI), IDR (GoPay / QRIS), ARS (Alias), VEN (Pago Móvil)
  • Alpha (mainnet, start small): COP, NGN, ECU, BOB, CUP, PEN, PHP

ZEC is still the pinned default. Delivery is still transparent t-addr only.

Announcement: 0xramp labs on X: "🛡️♾ 0xramp v1.0.0 is live! 0xramp[.]app is out of open beta. We have shipped many notable improvements and bug fixes, thanks to the incredible community that starts to build around the app and actively provided feedback to our team. The first thing you will notice: it's a di… / X

Answering @rigs

Thank you very much for this very important question.

0xramp does not have, and does not need, a Pix / UPI / GoPay participant contract.

We are not a bank, not a Pix participant, not an NPCI TPAP, not a GoPay acquirer, and not a payment institution sitting on those rails. The grant application says the same thing in different words: this is integration software.

Fiat never hits an 0xramp account. We do not pool BRL/INR/IDR, we do not initiate a transfer from the user’s bank, and we do not operate a Pix key.

What the user does in a buy is the ordinary rail action they already know: open the bank / wallet app and pay a destination that belongs to a P2P.me merchant (QR or copy-paste). That is a person-to-person (or person-to-merchant) credit on the rail, signed off in their bank app. 0xramp showing the amount and the QR is not the same thing as 0xramp being plugged into SPI, NPCI, or GoPay as an automated participant.

P2P.me is the marketplace those merchants sit on.
Merchants receive on keys they already hold at a bank or e-wallet, and they escrow USDC on Base. Local-rail terms and tax rules for that activity are on the merchant and on P2P.me, not on 0xramp. We are not going to speak for P2P.me’s filings or contracts with any central bank. Probably better to ask them directly.

Freeze risk exists. We will not pretend it does not.
Any flow where fiat moves between personal or small-merchant accounts can be flagged by a bank. P2P.me’s own merchant docs say the same in their words: freeze risk is non-zero, they try to keep merchant balances low, merchants own local compliance. That risk sits mainly on merchants who receive many payments. It can also touch a user who sends unusual amounts to keys they have never paid before. 0xramp cannot override a bank. That is why we keep telling people to start small, use limits that match their history, and treat alpha corridors as alpha.

So the short version:

  • No, 0xramp does not have a documented partnership with Banco Central / NPCI / GoPay to run those rails. We are not on those rails.
  • The “automated” part of v1 is the on-chain hop (Diamond escrow + NEAR Intents), not a background login into anyone’s internet banking.
  • Yes, bank-side freezes are a real residual risk of P2P merchant rails. We mitigate by not touching the fiat, by fail-closed limits we do not invent, and by telling users the risk instead of selling a regulatory shield we do not have.

Questions like yours are super important and a great opportunity to double down on these things, which is why we highly appreciate you making it.

Best,

Vini B

2 Likes
4

Thanks Vini — I like the reuse approach (P2P.me + NEAR Intents). Cleaner than rebuilding the stack.

A few more questions from my side:

If 0xramp is the interface layer on top of those two, what’s the revenue model on each flow — and why is this a ZCG grant rather than a business funding its own product? Related: what does 0xramp uniquely add for ZEC users that P2P.me and Intents don’t already provide?

On dependency risk: India’s ED has recently shut down or heavily restricted a number of on/off-ramp firms (example). If P2P.me hit the same kind of pressure and corridors closed, what happens to 0xramp — and is it worth ZCG underwriting a grant that bottlenecks on them? Do you have any SLA / commitment with P2P.me that those corridors stay available?

I think this can be a strong product as a business. I’m less sure it fits ZCG funding, which I’d rather see go toward public-good infrastructure than a commercial take-rate layer.

Curious how you see that.