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

1. Executive summary and decision snapshot

0xramp Labs requests $206,000 for a 12-month Integration-category project: a non-custodial interface intended to let users buy and sell ZEC using local-fiat payment rails in emerging markets. The product uses P2P.me for merchant matching and fiat settlement and NEAR Intents for the crypto conversion leg, while positioning ZEC as the default asset. [1][11]

Delivery is proposed by co-founders Michael, responsible for architecture, security, integrations and partnerships, and Vini, responsible for product, operations, growth, documentation and NEAR integrations. Two further roles—an integrations engineer and community manager—are proposed hires after startup funding. [1]

Funding is structured as $34,000 startup funding plus six milestones totaling $172,000: $34,000, $32,000, $29,000, $29,000, $28,000, and $20,000. The applicants state that each milestone has deliverables and acceptance criteria, but the supplied evidence does not include the substantive milestone definitions or criteria. [10]

Strongest capability evidence: the applicants report a live v1.0 product, active and alpha corridors, and approximately $20,000 processed over a little more than one month. This is applicant-reported early traction, not independently verified ZEC-specific volume or a demonstrated annual demand forecast. [4][8]

The central decision issue is whether early product evidence and potential access value justify a large grant despite reliance on P2P.me and NEAR Intents, no service-level commitment for corridor availability, current transparent-address delivery, and an unvalidated case that $206,000 is proportionate to the integration scope. [4][6][7][8]

2. Applicant and team track record

Michael is described as 0xramp’s co-founder, software engineer and product owner; the application states that he has led Zcash Brazil for more than 4.5 years, participated in Zcash-related community governance, and has experience with P2P.me, NEAR Intents and emerging-market fiat rails. [1]

Vini is described as co-founder and product/operations lead, with claimed Brazilian Pix UX experience and more than six years’ technical-writing and documentation work across Zcash, NEAR and open-source ecosystems. [1]

The founders have directly brought a stated version 1.0 product out of beta, with buy/sell, swap, activity, account/limits, invite and help functionality. [4]

Evidence limitation: No grounded evidence found of independently documented delivery outcomes from prior ZCG grants by 0xramp itself. The application says Michael participated in multiple Zcash Brazil funding cycles, but the supplied evidence does not establish his role, deliverables, or results in those grants. [1]

Inference: The founders’ stated domain familiarity and existence of a live product support some execution credibility. However, the planned dependence on two not-yet-hired roles means sustained delivery capacity remains partly contingent on recruitment or additional founder workload. [1]

3. Proposal scope, milestones, budget, technical approach, and dependencies

The proposed 12-month scope includes corridor hardening, production work for NGN, COP and Ecuador-USD corridors, shielded-first delivery, network-privacy work, wallet integration, public metrics reporting, security review and community support. [4][8]

The reported budget allocation is:

• $130,000 for two part-time founders and two part-time contractors.
• $65,500 for services, including independent security review, legal work, community integrations and reserves.
• $10,500 for infrastructure. [7][8]

The product is described as non-custodial: users retain keys; P2P.me handles identity, limits, merchant matching and USDC escrow on Base; NEAR Intents handles conversion between USDC and ZEC; and 0xramp provides the interface and session layer. [4][11]

The applicants state that the product currently sends ZEC to transparent addresses only, with shielded delivery a proposed improvement rather than current capability. [4][8]

Critical external dependencies are P2P.me for fiat-side merchant access and NEAR Intents for the conversion path. The applicant explicitly states that 0xramp is currently fully dependent on both and has no SLA or commitment from P2P.me that corridors will remain available. [5][6]

4. Community discussion, arguments, responses, and resolution

Arguments supporting the request

• The project addresses a concrete user-access problem: moving between local currency and self-custodied ZEC without users manually completing intermediate USDC/Base and swap steps. [5][11]
• A working interface, current corridors, and reported early processing volume indicate more than a conceptual proposal. [4][8]
• The applicants argue that integration work—handling user flow, incomplete transactions, recovery and accurate financial information—creates value beyond the underlying protocols. [7]

Arguments against the request

• A community participant questioned whether $206,000 is excessive for an interface built atop existing fiat and swap protocols, suggesting that a broader multi-provider aggregator might be expected at this funding level. [7]
• The same participant questioned the public-good rationale and long-term sustainability of a product with no current revenue model. [5][7]
• The most consequential concern is user and corridor risk: P2P merchant flows can lead to bank freezes, and regulatory pressure or provider shutdowns could interrupt service. [4][7]

Applicant responses and clarification

• The applicants state there is currently no 0xramp fee and no planned revenue model during the grant period, while later indicating openness to a transparent take rate or revenue sharing. [5][8]
• They acknowledge bank-freeze risk, advise small transactions and limits matching user history, and state that local-rail compliance obligations sit with merchants and P2P.me rather than 0xramp. [4]
• They acknowledge full current dependence on P2P.me and NEAR Intents and say they are assessing alternatives, particularly on the swap side. [5][6][8]

Resolution: The discussion resolved that 0xramp does not claim direct rail-provider contracts and does not deny freeze or dependency risk. It did not resolve whether the grant size matches the scope, whether sustainable funding is desirable or feasible, or whether credible fallback providers and user protections can be established. [4][6][7][8]

5. Relevant precedents and documented outcomes

• ZEX for Zcash — $75,000, declined. This is relevant because it was also an access/liquidity proposal framed around self-custodial ZEC trading and cross-chain integration. The documented committee rationale cited lack of demonstrated demand or a functioning market, concern that the technology was not operating, and the view that stronger solutions already existed. 0xramp differs materially by claiming a live product and initial volume, but it should still substantiate demand, differentiation and value relative to existing access paths. [15]
• weave-zec: Non-Custodial Shielded Merchant Payments — $48,000, declined. This is relevant as another non-custodial Zcash payments/access concept. The supplied evidence documents rejection but provides no committee rationale or outcome explanation; therefore, it cannot support a substantive comparison beyond showing that non-custodial payment framing alone has not assured approval. [14]

No grounded evidence found of an approved, completed comparable ZCG grant with documented outcomes sufficiently close to fiat-ramp integration, dependence on external settlement providers, and a request of comparable scale.

6. Material risks and execution considerations

• Single-provider exposure: Loss or restriction of P2P.me or NEAR Intents could substantially impair the service. Alternatives are only under evaluation, not documented as operational fallbacks. [5][6][8]
• Fiat-side user harm: The applicants acknowledge that banks may freeze merchant or user accounts in unusual payment patterns. Non-custody does not remove this risk. [4][8]
• Privacy delivery gap: The proposed privacy rationale exceeds current product capability because ZEC delivery is presently transparent-address only. [4][8]
• Budget-to-scope uncertainty: The request is large relative to a product described as an integration layer, while substantive milestone acceptance criteria and detailed cost-to-output mapping are absent from supplied evidence. [7][10]
• Sustainability uncertainty: The applicant first states no intended revenue model during the grant, then expresses openness to take-rate or revenue sharing. This is not necessarily contradictory—one describes current plans and the other future openness—but it leaves post-grant operating funding unclear. [5][8]

7. Material gaps and questions for the applicant

1. Provide the six milestones’ exact deliverables, acceptance tests, dates, and payment gates, especially measurable definitions of corridor readiness, shielded delivery, security work and fallback integrations.
2. Break down the $130,000 compensation and $65,500 services budgets by role, deliverable and timing; identify which outputs would not occur without grant funding.
3. Report ZEC-specific rather than aggregate platform metrics: completed buy/sell count, completed volume, active users, repeat users, failure/refund rates, corridor-level availability and average transaction size.
4. Define minimum user-protection standards for freezes, failed settlements, pricing discrepancies and recovery; clarify what support 0xramp can provide when P2P.me merchants or local banks are involved.
5. Identify at least one validated alternative for each critical leg—fiat settlement and crypto conversion—and specify the conditions that trigger migration or disablement of a corridor.
6. Clarify whether shielded-address receipt is technically feasible across every proposed corridor and what security review must confirm before it becomes a milestone acceptance condition.
7. State the intended post-grant operating model, including whether fees or partner revenue sharing will be pursued and how that choice affects user affordability and public-good claims.

8. Neutral decision considerations

Factors supporting funding consideration

• The proposal targets practical ZEC accessibility in markets where local payment methods may be central to user adoption. [11]
• The applicants present a live product rather than an unbuilt concept and report early transaction activity. [4][8]
• The non-custodial design, if accurately implemented, aims to avoid 0xramp holding user keys or fiat funds. [4][11]

Factors supporting stronger conditions or staged funding consideration

• Milestone funding should be tied to independently reviewable functional outputs and corridor-level reliability, rather than status claims alone. The evidence supplied does not expose the detailed tests needed to judge that. [10]
• Conditions could prioritize validated fallback paths, transparent disclosure of freeze and corridor risks, and a verified security review before expanded deployment.
• Adoption-based later milestones may be more decision-relevant than broad corridor announcements, given that the only reported usage baseline is early, aggregate and not ZEC-specific. [8]

Inference: The committee’s core trade-off is between funding a potentially useful early access interface and avoiding a 12-month commitment before it has demonstrated resilient dependencies, shielded delivery, measurable ZEC adoption, and a proportionate use of funds.

9. Numbered source list

• [1] Grant Application - 0xramp: Non-custodial ZEC ⇿ local-fiat ramp for emerging markets — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/408
• [11] Introducing 0xramp: non-custodial ZEC ↔ local fiat (Pix and more) for emerging markets — posts 1–5, part 1 — https://forum.zcashcommunity.com/t/introducing-0xramp-non-custodial-zec-local-fiat-pix-and-more-for-emerging-markets/57215/1
• [10] Comment on #408: Grant Application - 0xramp: Non-custodial ZEC ⇿ local-fiat ramp for emerging markets — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/408#issuecomment-5480738561
• [4] Grant Application - 0xramp: Non-custodial ZEC ⇿ local-fiat ramp for emerging markets — posts 1–5, part 1 — https://forum.zcashcommunity.com/t/grant-application-0xramp-non-custodial-zec-local-fiat-ramp-for-emerging-markets/57271/1
• [8] Grant Application - 0xramp: Non-custodial ZEC ⇿ local-fiat ramp for emerging markets — posts 6–10, part 2 — https://forum.zcashcommunity.com/t/grant-application-0xramp-non-custodial-zec-local-fiat-ramp-for-emerging-markets/57271/7
• [6] Grant Application - 0xramp: Non-custodial ZEC ⇿ local-fiat ramp for emerging markets — posts 1–5, part 3 — https://forum.zcashcommunity.com/t/grant-application-0xramp-non-custodial-zec-local-fiat-ramp-for-emerging-markets/57271/5
• [7] Grant Application - 0xramp: Non-custodial ZEC ⇿ local-fiat ramp for emerging markets — posts 6–10, part 1 — https://forum.zcashcommunity.com/t/grant-application-0xramp-non-custodial-zec-local-fiat-ramp-for-emerging-markets/57271/6
• [5] Grant Application - 0xramp: Non-custodial ZEC ⇿ local-fiat ramp for emerging markets — posts 1–5, part 2 — https://forum.zcashcommunity.com/t/grant-application-0xramp-non-custodial-zec-local-fiat-ramp-for-emerging-markets/57271/4
• [15] {ZEX for Zcash: CEX Speed, DEX Security, Simple and Global Access to ZEC.} — comparison summary — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/208
• [14] weave-zec: Non-Custodial Shielded Merchant Payments for Zcash — comparison summary — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/233