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

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

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?

2 Likes

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

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.

3 Likes

Thank you for the back-and-forth here.
These are super relevant questions, and I appreciate the chance to explain the product and the vision.

This is not a commercial take-rate layer.

There is no revenue model. Not yet, at least, and there will not be one for the duration of this grant if it is approved. We are not building a business here. That was never the intention, and right now there is no plan to turn 0xramp into one. We have already received a few proposals that would have changed that. We refused them (including a “business funding,” as you mentioned).

What we are building is an interface that connects two existing protocols: P2P.me (fiat merchants) and NEAR Intents (cross-chain execution), so the ZEC holder’s experience is improved:

  1. No need to manually swap ZEC → USDC@base and send it to a new wallet on app.p2p.me.
  2. Keep Zcash in the wallet you already use, then send to an address we give you (copy/paste or QR).
  3. A few product and architecture choices made for Zcash users in mind (like ourselves).

Anyone who holds Zcash and wants fiat through P2P.me today still has to do one to three extra steps: get USDC on Base, then use P2P.me. The buy path is the same problem in reverse: buy USDC on Base, then figure out how to get to ZEC (on P2P.me or somewhere else), often via a NEAR Intents-integrated interface/app.

NEAR Intents is a protocol, not an interface. You still need an app to do the swap. We are one of those interfaces, with the part that is still rare: it connects that swap to local fiat rails in emerging countries that need it the most (Brazil, India, Venezuela, Argentina, Indonesia, Nigeria, Colombia, Ecuador, etc). There aren’t many people doing that yet, which is why we started building 0xramp in the first place.

We are also facilitating Zcash onboarding from ZCG-funded communities and facilitating access (and liquidity) to other ZEC-pegged assets like wrapped version on Solana and Base. It’s a pretty unique solution overall.

The dependency risk is real in the current state. Right now, 0xramp is fully dependent on P2P.me and NEAR Intents. We are already studying alternatives for the Intents leg. We may look at alternatives for the fiat leg later if that is what the product and our users need.

Some dependency will always be there, though. Almost no fiat ramp is exempt from it. Local regulatory pressure has always been the largest risk for Zcash holders (and other crypto holders too) in these regions. Another reason why it’s still rare to find solutions like our own. If we can find ways around it so people can still move, we will. There is a limit, however, to what software can do when State aggression grows too large and decides to shut a rail down. That is not a 0xramp-only risk.

Working corridors stay up. We keep building where a path still exists. Not running this as a take-rate business is part of why we can do that. It’s a core decision to keep the interface useful, serving its users in the highest number of corridors as possible. Using protocols we do not own is the other part, as it is what lets us change a leg if one of them gets constrained.

No. We do not have one, and we would not ask for one.

  1. We understand corridor availability is not up to P2P.me alone. It depends on local rails and local rules. There is no point into demanding our integrator something that is not really up to them.

  2. We have implemented a battle-tested network/protocol that may stop serving some corridors, while also adding some others. We will keep using it while it is useful and serve enough corridors with active Zcash users. Also, there is no exclusivity agreement with P2P.

I strongly disagree that this is a take-rate layer. What we are building is a public-good interface. That is also why we need the grant: to keep building it, harden it, and have room to change a dependency when a commercial protocol cannot. There is no 0xramp fee on these flows.

Hope that clears the misunderstanding.

Please, tell me if you still disagree, or if you have any other questions/doubts on our vision and model.

— VB

2 Likes

Thanks Vini — appreciate the clear answers.

A few thoughts from my side (as ZCG DeFi strategist; personal view, not a committee decision):

On the take-rate / sustainability I actually think there should be a take-rate here. If this interface becomes useful, the value it offers users should cover its own costs. P2P.me and NEAR Intents should revenue-share with you for the flow you route through them. Happy to help: I’m connected with the NEAR team and can help you set up a revenue share with them if useful.

In the end, usage defines value. It would be nice if you could share how much volume can we expect over the next 12 month period?

On budget / scope Looking at the GitHub application (#408): the ask is $206k ($130k compensation, $65.5k services, $10.5k infra), for 12 months of hardening an interface that sits on top of two existing protocols — P2P.me (fiat) and NEAR Intents (swap) — with no custody and no custom contracts of your own.

I personally find that quite expensive for what is, at core, a frontend / UX glue layer over those two. For ~$200k+, I think a much larger corridor aggregator (multiple settlement legs, licensed rails where they exist, real alternatives) could be achieved.

On dependency / freeze risk I’m less worried about the “public good vs business” framing than about single-point corridor risk. I’ve been a founding member of Onramper.com (largest fiat↔crypto onramp aggregator). Over the last five years we’ve seen 10+ ramp providers get shut down or heavily constrained. From that seat, what P2P.me-style corridors do is quite risky for end users — Revolut / Wise freezes happen, and getting those unfrozen is tedious.

So I’d strongly recommend building alternatives for both legs (NEAR Intents and P2P.me). There are also more compliant corridors with licensed providers. DM me if you want intros — happy to help identify and connect.

All of the above is my opinion. Happy to keep helping as you build.

— rigZ

Thanks, rigZ. I appreciate the thoughtful feedback and your offers to help with NEAR revenue sharing and alternative providers. Your experience with Onramper is relevant to the risks we need to address.

One dimension I would give more weight to is individual empowerment and financial sovereignty. For someone earning and spending in local currency, Zcash becomes useful when they can acquire it, hold it in their own wallet, and convert it back when needed. Accessibility, privacy and user choice deserve consideration alongside volume and commercial sustainability.

That motivation comes from our own experience within the Zcash community. We built 0xramp to address a practical problem we encountered ourselves: connecting local payment methods with Zcash through a usable flow.

On the “frontend / UX glue” characterization, I think that understates the contribution of making separate financial systems work together. Existing protocols provide important components, but someone still has to connect them, handle incomplete transactions, reconcile amounts, manage recovery and give users accurate information about their money.

Our contribution has been to connect P2P.me’s fiat settlement with NEAR Intents’ conversion capabilities into a working local-currency ↔ ZEC experience. This specific connection was the gap we set out to solve. Building that experience creates additional utility from infrastructure that previously addressed separate parts of the problem. Our integration announcement.

There are useful examples of this approach within the Zcash ecosystem. ZODL raised more than $25 million in seed funding for its broader wallet and protocol work, while its wallet integrates NEAR Intents for both swaps and CrossPay. The execution infrastructure comes from NEAR, and ZODL contributes the wallet integration and user experience that make it useful. Both contributions have value. Funding announcement, Swaps documentation, CrossPay documentation.

Similarly, red·bridge has an approved $477,658 launch grant for connecting Zcash with Avalanche and the wider ecosystem, alongside operational and maintenance work. Its architecture also involves other networks and dependencies. These are different projects with different funding models and scopes, so their amounts are not direct budget benchmarks. They illustrate that interoperability can justify substantial engineering and operational investment. Approved application.

We also have an existing distribution opportunity. P2P.me whitelisted 0xramp, allowing approximately 30,000 existing protocol accounts to access the integration with their established reputation and limits. Those are eligible accounts, and converting that opportunity into active Zcash usage is work we need to measure. Whitelisting announcement.

The partner infrastructure has meaningful backing: P2P.me raised $2 million in seed funding, followed by the $6 million raise listed by MetaDAO. P2P.me and its leadership have also publicly expressed support for this direction, including the message, “Your private money deserves private ramps.” That alignment matters when building access to Zcash, while funding and endorsements leave the underlying risks to be assessed on their own merits. Coinbase Ventures, MetaDAO, P2P.me’s post, Sheldon’s post.

On volume, we have processed approximately $20,000 in a little over one month. That is our current observed baseline. We should distinguish overall platform volume from ZEC-specific activity, and the available history does not yet support a dependable twelve-month forecast. A credible projection needs explicit assumptions about account activation, repeat usage and transaction sizes, followed by regular comparison with actual results.

We agree that sustainability matters. We are open to a transparent take rate and revenue-sharing arrangements with the protocols receiving the flow. Your help with NEAR would be welcome. At this early volume, we still need to demonstrate that the economics can support reliable operations while keeping the service affordable.

On the $206k budget, the request covers twelve months. The $130k compensation supports two part-time founders and two part-time contractors. The $65.5k services category includes independent security review, legal work, community integrations and reserves; $10.5k covers infrastructure. The scope includes corridor hardening, privacy improvements, wallet integration and public reporting. We welcome scrutiny of individual costs against those deliverables. Application and budget.

On dependencies, we are already evaluating additional aggregators behind the interface. The cbZEC integration has also given us practical experience operating USDC/Base ↔ cbZEC/Base swaps, expanding our ability to assess liquidity and execution options beyond NEAR Intents. Those alternatives need validation of liquidity, costs, settlement and failure recovery before becoming dependable fallbacks.

That strengthens the swap side. Diversifying fiat settlement is a separate task, and your introductions could help us advance both.

Your concern about bank freezes is valid. Non-custody does not prevent a bank from freezing an account. Different providers and architectures expose users to different risks, which need to be evaluated by likelihood, impact and available protections. Licensed providers can expand users’ choices, and we would assess them alongside coverage, cost, privacy and user control.

We also need to remain precise about privacy: 0xramp currently delivers to transparent Zcash addresses; improving shielded delivery is part of the proposed work. Current capabilities and roadmap.

We welcome collaboration on stronger alternatives and sustainable economics. What we ask is that the evaluation also recognize the working connection we have built, the existing distribution opportunity, and the value of giving individuals practical access to Zcash. That contribution should be judged through reliable execution, measurable adoption and the financial choices it makes available to users.

3 Likes

*Felipe Montealegre on X: "P2P growth over the past few weeks is driven by emerging markets cohorts on-ramping to Zcash - interesting use case as P2P allows you to onramp anonymously" / X

*P2P.me on X: "Our weekly active users are growing vertically, alongside Zcash’s growth. “Private money deserves private ramps.” Our team is doubling down on this thesis, with two projects in our ecosystem building on P2P rails to make private money actually usable: 1. https://t.co/86iGYXk3gT (@0… / X

1 Like

Hello @ZCG and community,

I see our application was marked Rejected on the grants dashboard yesterday, but there is not yet a note here on the thread or on the GitHub issue. Could you confirm the decision here, and point to the meeting minutes or a short note on the main blockers, please?

We are ready to submit a revised application with a shorter timeline and a lower budget: two people, no community hiring, narrower deliverables, and limited scope (also following community feedback we got here and in other places as well). Before we file that, it would help to know whether the “no” was mainly about request size, scope, partner dependencies (P2P.me / NEAR Intents), or fit with ZCG priorities. We already have a reduced-scope draft and will wait for that feedback if it is coming in the next minutes post.

Thank you,
Vini B

We appreciate you taking the time to submit this proposal. Following the committee’s evaluation and an open window for forum feedback, ZCG has chosen not to proceed. Your work on this application is genuinely valued, and we’d love to see you stay engaged with the Zcash community going forward. Meeting minutes.

1 Like

Thank you for the note and for the meeting minutes.

The feedback is useful and super valuable. We are using it, together with what the community already raised on this thread and on 57215, to file a revised application: shorter timeline, smaller budget, and the blockers from the 14 Sep meeting answered.

We are adding an entire session in the new proposal quoting and answering each committee comment for clarity and transparency.

I love Zcash and this community. I am not going anywhere!
Michael and I will keep building 0xramp and keep contributing here (or anywhere else).
The ZEC mission is bigger than this one grant.

Will post a new GitHub issue soon. ZCG process asks for a new post in the Grants category for a new application, so I will do that and drop the link here so this thread stays the record of #408. Is that ok? Or do you prefer a different flow?

Thank you again,
Vini B

3 Likes