Zcash Privacy Payment Rail & NFC Programmable Cards

1. Executive summary and decision snapshot

Blink requests $150,000 to build ZecPOS Core, an open-source, self-hostable shielded-ZEC payment rail with merchant checkout, optional fiat settlement and NFC payments. The application is under review. Delivery would be led by founder/CEO Ebube Ebuka Onuora and CTO/co-founder Jethro Adamu. [1][4]

The strongest capability evidence is the team’s self-reported banking, software and payment-infrastructure experience, including a prior Starknet Foundation grant and development of fiat on/off-ramp infrastructure. These are applicant claims, not independently demonstrated outcomes in the supplied evidence. [1]

Decision-focused inference: The central evaluation is whether reusable Zcash infrastructure justifies the breadth of the proposed settlement, custody and contactless-payment stack. Funding structure, security boundaries and differentiation from existing payment tools require particular scrutiny; the available milestone and budget evidence is detailed in section 3. [1][4]

2. Applicant and team track record

• Onuora: Reports nearly five years in Nigerian banking, software-development training, open-source contributions through OnlyDust and Drips, and a $25,000 Starknet Foundation grant to build Fortichain. His stated responsibilities include strategy, partnerships, fundraising and operations. [1]
• Adamu: Reports eight years of full-stack, mobile and blockchain development. Claimed work includes leading EcoHotels development, engineering AutoRamp’s fiat on/off-ramp infrastructure, and building mobile applications and microservices for Nextup. The application attributes €300,000 in revenue “last year” and 160,000 total bookings to EcoHotels. [1]

Inference: Adamu’s reported payment-infrastructure work is the closest capability match; Onuora’s banking background may support commercial execution. Neither establishes proficiency in Orchard integration or secure custody. [1]

For independently verified delivery outcomes, Fortichain grant completion, prior ZCG performance or demonstrated Zcash-specific implementation experience: No grounded evidence found. This does not establish that such experience or prior grants do not exist.

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

Proposed scope and architecture:

• Orchard shielded payments, merchant checkout, and fast payment detection and confirmation using diversified addresses. [4]
• Merchant-selected ZEC retention and local-fiat settlement through aggregated treasury batches, supported by a signing service, KMS-backed key management and destination policies. [4]
• Viewing-key selective disclosure; NFC using NTAG 424 DNA SUN verification and counter-based replay protection; Android POS with a self-custody upgrade path. [4]
• Open-source, self-hostable infrastructure, with Blink intended as the first production deployment and reuse by other wallets, merchants and payment providers. These are proposed deliverables, not demonstrated deployments. [4]

Funding and acceptance: The request is $150,000. The applicant accepts a requirement that intended users or their representatives validate milestone deliverables. For startup funding, milestone amounts, payment schedule, delivery dates, itemized costs and measurable acceptance tests: No grounded evidence found. Budget adequacy and delivery sequencing therefore cannot be assessed. [1]

Dependency inference: Execution requires compatible wallet/payment interfaces, secure signing and key management, NFC hardware integration and a workable local-fiat settlement arrangement. Named counterparties, binding integration commitments and settlement economics are not established in the supplied proposal discussion. [4]

4. Community discussion, arguments, responses, and resolution

Strongest argument for: Blink presents the project as reusable infrastructure for shielded commerce rather than a proprietary checkout. Its proposed combination of merchant settlement choice and in-person payment support is the substantive case for incremental ecosystem value; this case comes from the applicant, not a documented independent endorsement. [4]

Strongest challenge: Ready Mouse questions substantial overlap with CipherPay, asking whether Blink integration and NFC are the principal differences from an already-funded open-source POS system. That funding characterization is the commenter’s statement, not independently documented here. [4]

Applicant response: Onuora characterizes CipherPay as web checkout and positions ZecPOS Core beneath checkout, covering settlement, custody, NFC and Android POS. He specifies treasury batching, KMS-backed signing and NFC replay protection as distinguishing elements. [4]

Resolution assessment—inference: The response clarifies intended differentiation but does not resolve duplication or value-for-money concerns. No feature-by-feature comparison, reuse plan or subsequent substantive agreement is supplied. There is no grounded basis to conclude either that the projects are equivalent or that a new payment core is necessary. [4]

5. Relevant precedents and documented outcomes

• Nym mixnet integration — approved at $150,000 after reduction from $670,000. Relevant as similarly priced privacy infrastructure dependent on ecosystem integration. The committee supported its privacy contribution and team experience, while concerns included wallet usability, integration commitment, running costs and incomplete milestones. Approval was conditional on updated milestone details. Documented outcome: conditional funding approval; for deployed results or user impact, No grounded evidence found. Approval is not evidence of successful execution. [9]
• Zcash Light Client Privacy Transport Library — $18,500, declined. Relevant to reusable infrastructure with potential overlap and uncertain adoption. Committee reasons included inadequate alignment with existing tools and core-team roadmaps, lack of initial users, doubts about incremental privacy benefits and delivery concerns. Inference for Blink: a named first deployment is useful, but evidence of actual requirements and committed users would be more persuasive than a general reuse ambition. [10][4]

6. Material risks and execution considerations

The following are inferences, not documented failures:

• Privacy versus operational access: Signing services, custody, fiat settlement and selective disclosure introduce trust boundaries. The committee needs to distinguish on-chain shielding from what Blink, settlement providers or reporting recipients can observe or control. [4]
• Contactless authorization: Counter-based replay protection is one proposed control; it does not itself demonstrate safe payment authorization, lost-card handling or spending limits. [4]
• Delivery breadth: Combining shielded payments, treasury operations, key management, Android POS and NFC creates interacting workstreams. A staged demonstration would test whether the proposed components function together. [4]
• Public benefit versus Blink-specific benefit: Blink’s intended first deployment offers a concrete integration target, but reusable value depends on whether independent implementers can operate the resulting infrastructure without Blink-controlled services. [4]

7. Material gaps and questions for the applicant

• Funding: What startup payment and milestone amounts sum to $150,000, and what dates, staffing allocations, acceptance tests and independent validators attach to each?
• Incremental value: Which components can reuse CipherPay or other existing work, and what evidence shows a separate payment core is necessary?
• Custody and security: Who controls funds and signing keys at launch? What threat model, external security review and incident responsibilities cover both hosted and self-hosted deployments?
• NFC payment safety: What does tapping authorize, how are amount and merchant confirmed, and how are lost cards, replay attempts and spending limits handled?
• Settlement viability: Which jurisdictions and counterparties support fiat settlement, with what fees, liquidity requirements, reporting obligations and failure handling?
• Capability and adoption: Can the team provide verifiable prior payment-system deliverables, a working shielded-payment prototype and merchant or wallet commitments with measurable pilot targets?

8. Neutral decision considerations

Evaluation framework—inference: The proposal’s potential strength is infrastructure that makes shielded ZEC usable in physical commerce while remaining independently reusable. Its justification should be assessed against demonstrable incremental functionality, not the breadth of the feature list. [4]

Possible funding conditions for committee consideration—not an approval or rejection recommendation—include a bounded prototype stage, independently validated security and custody design, explicit settlement dependencies, and payments tied to accepted integration tests and pilot results.

The precedents support examining scope discipline, integration alignment and milestone specificity; they do not determine this application’s outcome. [9][10]

9. Numbered source list

• [1] Grant Application - Zcash Privacy Payment Rail & NFC Programmable Cards — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/456
• [4] Grant Application - Zcash Privacy Payment Rail & NFC Programmable Cards — posts 1–5 — https://forum.zcashcommunity.com/t/grant-application-zcash-privacy-payment-rail-nfc-programmable-cards/57930/1
• [9] The Nym mixnet for Network Privacy for Zcash — comparison summary — https://forum.zcashcommunity.com/t/zcash-community-grants-meeting-minutes-2-5-2024/46881
• [10] {Zcash Light Client Privacy Transport Library} — comparison summary — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/348