Hello Zcash community,
I’m Arun Pratap Singh Chandel, co-founder of The Origin Guild. I’m sharing Zcash BuildPath India for community feedback: a $24,400 combined request comprising the original $17,600, 14-week pilot in Bhopal, Indore, Delhi and Noida, plus a separately costed $6,800 Mumbai “Zcash First Build” day during the wider Devcon 8 period.
Scope amendment for review - 7 October 2026: the base pilot is unchanged. The Mumbai module adds distinct deliverables and its own follow-up; ZCG may assess the two modules separately. Neither module has been approved for funding.
Full application, itemized budget, team profiles and acceptance criteria: ZCG GitHub application #465.
The problem we want to test
Understanding why privacy matters is not the same as completing a useful Zcash integration. A first-time builder still needs to choose supported tooling, distinguish address formats and networks, handle requests correctly, and test failures without exposing secrets or risking funds.
Our premise comes from community delivery experience: keeping the same participants through setup, practice, building and revision may produce more useful results than disconnected introductory events. We have not measured this across the Zcash ecosystem. This pilot would document the baseline, the failures and the results rather than assume the approach works.
Base pilot: what participants would actually do
The programme combines one shared online warm-up, one four-hour workshop and one ten-hour build day in each city, and six shared online mentor clinics, with a 30-day project check.
- Warm-up: fundamentals of transparent and shielded activity, network separation, Unified Addresses, safe key handling and a setup exercise. Participants do not need to buy ZEC or disclose balances.
- Workshop - “A request is not a payment”: inspect revision-0 Unified Addresses, compose a bounded ZIP-321 ZEC request, generate a QR locally, and test wrong-network inputs, checksum failures and malformed amounts. A separate, rehearsed wallet/SDK testnet exercise would distinguish request creation, wallet approval, broadcast and confirmation.
- Build day: teams develop one narrow, testable solution. Candidate briefs are Request Desk (a request/invoice-reference interface with honest payment status), Wallet Compatibility Notebook (versioned acceptance/rejection tests), and Onboarding Repair Kit (a debugger or setup improvement addressing an observed failure).
- Revision: mentors help teams fix issues, repeat intended-user tests and document changes. Arun owns follow-up and Siddharth owns technical review.
These briefs are not an upstream-endorsed backlog. Each team must name an intended user and test with someone outside the team. Before transaction workshops launch, our technical lead must rehearse a maintained testnet path, pin versions and document the results. We will not teach an unverified transaction flow.
Why four cities, and who this serves
We propose 70 builders per city: developers who can run a small app locally, technical students, early-stage founders and designers paired with developers. English and Hindi facilitation would help make the sessions accessible.
- Bhopal: our local student and early-career network, focusing on setup and privacy-safe request interfaces.
- Indore: application builders and startup teams, focusing on useful payment-request integrations.
- Delhi: developer and founder networks, focusing on tooling and reproducible diagnostics.
- Noida: a distinct cohort focused on application QA, interoperability and error recovery.
Delhi and Noida are neighbouring parts of India’s National Capital Region, so participants will be deduplicated across locations. We will coordinate with existing India organisers to avoid overlapping calendars and content; their participation is not assumed. Institutional relationships are a route to hosting, not a claim that dates, venues or sponsorships are already confirmed.
Base pilot: what Zcash would receive
The following are proposed targets, not existing results or guaranteed adoption:
| Measure | Target and evidence |
|---|---|
| Unique builders | 160, with deduplicated check-ins |
| Returning build-day participants | At least 100, linked to their workshop cohort |
| Qualifying team prototypes | 12, with public repositories, run instructions, tests, limitations and intended-user review notes |
| Supported end-to-end testnet flows | 6 within those 12 prototypes, with reproducible evidence |
| Projects continuing at 30 days | 8 with a substantive revision and repeat intended-user review |
A public curriculum/setup kit, consolidated onboarding-friction report, four regional recaps, at least four technical demo clips and a final outcomes-and-expenditure report would remain available. Marketing would point to the work; impressions would not count as developer adoption.
Delivery team
I would lead the programme and remain accountable for delivery, budget and reporting through The Origin Guild, with Builder Base supporting Delhi and Noida.
- Siddharth Rajput: accountable technical lead; lab rehearsal, tooling selection and technical review.
- Alok and Laksh Sadhwani: technical mentoring, troubleshooting and revisions.
- Aniket Sahu: Bhopal and Indore coordination.
- Punit Pal: Delhi and Noida coordination through Builder Base.
- Vishal Kumar: operations, check-ins and follow-up tracking.
Participation in the four-city pilot has been confirmed to me; precise assignments and hours will be scheduled before delivery.Their professional profiles are in the application. My background is organising 54+ meetups, workshops and hackathons through a community of 5,800+ people.
Existing proof of work: Veil
Before applying, I built Veil, local-first Zcash request-diagnostics prototype.
Live demo · Source, tests and limitations
Its 116 core checks include 60 official Unified Address fixtures, 12 F4Jumble checks and 44 behaviour/negative/boundary checks, verified on 3 October. Veil inspects address encodings and a bounded ZIP-321 ZEC request subset. It does not hold keys, sign or broadcast transactions, prove settlement, constitute a security audit or demonstrate real-wallet interoperability. It is pre-application work, excluded from grant-funded outputs and not charged retrospectively.
Additional module: Mumbai “Zcash First Build” - Creator & Community Tools
Additional request: $6,800. Capacity: up to 70 selected participants plus 10 mentors/crew; target 70 actual check-ins. Tentative date: 2 November 2026, 09:00–19:00 IST. There are confirmed venue options.
The idea: build one useful thing without learning a whole protocol first
A creator wants a clear way for someone to support their work. A small open-source project wants to explain what a contribution would help it do. A freelancer wants to prepare a clear payment request. These are understandable product tasks that web developers, designers and founders can work on together.
Each team starts from one tested, browser-first starter and builds a small Zcash payment-request demo around one of these tasks. A visitor chooses a purpose or item, reviews the recipient and ZEC amount, and copies a matching request link or QR code. The team designs the journey, adds one useful function beyond the starter, and improves it after watching another person try it.
No previous Zcash experience is required. Recruit web/app developers new to Zcash alongside designers, creators and founders, with at least one person comfortable editing a basic web app per team. This is not a promise to teach programming from zero in a day. A short online setup check and a working example remove most installation work before the event; participants do not have to run a node, install an SDK or write cryptography.
A deliberately small, honest technical scope
The starter prepares a bounded ZEC payment request using tested request-generation components, including appropriately attributed reuse from Veil where suitable. Participants use fixed, clearly labelled testnet demo recipients and fictional data. Creating a request is not sending, receiving or confirming a payment. The app must never mark a request “paid” without real settlement evidence; settlement integration is outside this day’s required scope.
No real funds, wallet keys, custom signing, bridges or mainnet transactions are required. An optional facilitator-led testnet payment demonstration can show the next step only if successfully rehearsed; it is not a required participant output or a claimed adoption result. A public page, its labels and analytics are not automatically private because Zcash is used. No sensitive memo content or personal transaction history is collected.
Examples of achievable adaptations are a creator’s project-support selector, an open-source project’s needs-and-contribution page, or an itemised freelancer request preview. A qualifying output needs a meaningful team-built flow/function and one documented improvement, not a logo change or another copy of the starter. Existing Veil code and shared starter features are disclosed and excluded from new-work claims.
One-day flow (IST)
| Time | Activity and outcome |
|---|---|
| 09:00–09:30 | Welcome, team formation and setup check |
| 09:30–10:15 | Live showcase: a visitor’s task from page to request; explain networks, privacy limits and why a request is not payment |
| 10:15–11:15 | Guided first build: everyone runs and changes the same working starter |
| 11:15–11:30 | Short concept quiz and break |
| 11:30–12:00 | Concept review: teams choose one user, one task and one achievable addition |
| 12:00–13:00 | Build sprint 1 with mentor support |
| 13:00–13:45 | Lunch |
| 13:45–15:45 | Build sprint 2: finish the user journey and its checks |
| 15:45–16:00 | Break |
| 16:00–17:00 | Swap teams, watch an unfamiliar person try the task, then fix the confusing step |
| 17:00–18:15 | Short live showcases: the task, working demo, feedback and remaining limitations |
| 18:15–19:00 | Review outputs, agree next improvements and book the shared follow-up clinic |
Admission is free. Participants bring laptops; selection is based on motivation, a basic web-building mix and setup readiness, not ZEC holdings or prior Zcash credentials. No cash prizes or token purchases are budgeted.
What Zcash receives and how conversion is measured
The intended progression is new-to-Zcash participant → first reproducible demo → continued building, not attendance presented as adoption.
- Around 10 small teams, with a target of 6 distinct starter-derived prototypes by E+7. Each includes public MIT-licensed original code with third-party notices retained, run instructions, a demo or reproducible local walkthrough, clear limitations and a peer task-test note.
- Each qualifying demo must show: a correct recipient/amount in the request; rejection or clear handling of invalid amounts and wrong-network recipients; a QR/copy link matching the displayed request; and no false “paid” status. Starter checks and newly added checks are reported separately.
- One shared online clinic after the event, plus asynchronous team review within the budgeted follow-up hours. By E+30, target 4 teams making a substantive revision and repeating their user test. Public deployment is optional and requires consent; a reproducible local demo is acceptable.
- An E+7 project register and consented demo recap, followed by an E+30 onboarding-friction report and actual-vs-budget account. Report registrations, check-ins, completed demos, repeat clinic attendance and revised projects separately. Nonresponses are not retention; mainnet adoption and revenue are not promised.
These are proposed targets, not existing results. Mumbai is a separate cohort. Reused assets, hours, people and outputs cannot be charged or counted twice across the base pilot and this module. Six starter-based demos are not six production applications or six fully original codebases.
Readiness and non-duplication
Arun is proposed as event owner and Siddharth as technical lead; Mumbai availability and the incremental rota must be reconfirmed. Two technical facilitators must first complete the exercise, and two web developers unfamiliar with Zcash must reproduce the starter without live rescue. The kit needs a resettable working example, setup instructions, small example briefs and the acceptance checklist. Facilitators still need product competence; simplifying participant prerequisites does not remove that requirement.
Devcon 8 is 3–6 November; Zcash World is proposed for 1 November and Hack-to-Dark is also planned during that week. Before committing, compare audiences and curricula with the existing organisers. If this guided first-build format does not fill a genuine gap, propose a coordinated/smaller format or withdraw the separate module with ZCG’s agreement. Their participation is not assumed.
For the tentative 2 November date, request execution-plan approval and receipt of the $6,040 advance by 19 October (E−14), subject to ZCG agreement. This advance is needed before paid technical preparation and venue/supplier commitments. Complete the funded starter preparation and technical checks after release; by E−7, require successful rehearsal/reproduction, at least 70 setup-ready participants and confirmed staffing. Setup-ready means able to open/run the starter, not experienced in Zcash. Funding approval does not waive the technical launch gate. No non-refundable commitments before funds and supplier terms are in place. If funding or readiness is late, agree a date/scope change with ZCG; do not borrow from the base budget or assume personal bridge financing. There is no assumption of expedited review.
This module runs independently of the 14-week base pilot, with its own E+30 closeout. ZCG may assess the $17,600 base and $6,800 Mumbai module separately.
Planning references
Devcon dates · Zcash World proposal · Hack-to-Dark discussion · Zcash payment-request specification
Base pilot budget: $17,600 (unchanged)
All rates are planning estimates; supplier terms and cost ceilings would be checked during readiness.
| Cost category | USD |
|---|---|
| Hardware/software: hosting and test-device/connectivity allowance | 600 |
| Venue rental: 8 delivery days × $350 | 2,800 |
| Refreshments/meals: 8 days × up to 50 people × $9 | 3,600 |
| AV/equipment: 8 days × $100 | 800 |
| Regional travel: 2 allocations × $700 | 1,400 |
| Documentation/media: 4 city allocations × $300 | 1,200 |
| Recruitment: 8 delivery days × $75 | 600 |
| Printing/materials: 8 delivery days × $50 | 400 |
| Programme leadership: 100 hours × $20 | 2,000 |
| Technical lead: 100 hours × $25 | 2,500 |
| Technical mentoring: 45 combined hours × $20 | 900 |
| Regional operations: 80 combined hours × $10 | 800 |
| Total | 17,600 |
Room and catering allowances include mentors and crew as well as the planned 40 builders per city. The categories reconcile to $600 hardware/software + $10,800 services + $6,200 compensation. There is no cash-prize, token-airdrop or mainnet ZEC-purchase budget. We have no previous ZCG funding and no other funding confirmed or sought for this programme.
Mumbai-only incremental budget: $6,800
These are proposed all-in USD ceilings, not supplier quotations or a personal organising fee. Local quotations, applicable charges and cancellation terms must be confirmed before commitment. No event tickets, cash prizes, airdrops, mainnet token purchases or retrospective work are included.
| Item | Basis | USD |
|---|---|---|
| Venue rental | One 10-hour Mumbai session | 1,600 |
| Food and refreshments | Up to 70 builders/mentors/crew × $22 | 1,540 |
| AV, power and dedicated/backup connectivity | One event package | 650 |
| Trainer travel/accommodation | Capped crew allowance; no general attendee travel subsidy | 500 |
| Demo recording, documentation and editing | One technical documentation package | 350 |
| Printed lab guides, signage and consumables | One event allocation | 200 |
| Technical preparation, delivery and follow-up | 48 incremental hours × $25 | 1,200 |
| Event coordination, delivery and reporting | 38 incremental hours × $20 | 760 |
| Additional request | $4,840 services + $1,960 compensation | 6,800 |
Technical hours are planned as 20 starter preparation/rehearsal, 20 combined live-delivery hours for two technical facilitators, and 8 review/follow-up hours including one shared online clinic. Coordination hours are 20 preparation, 10 live delivery and 8 reporting hours. These are additional, recorded hours, not a second charge for the same work in the base pilot. Shared assets, travel or donated services will be allocated once; savings will be reported. The $760 coordination fee is proposed to be deferred until Mumbai closeout, subject to written agreement; no unapproved vendor costs should rely on personal financing.
Combined request: $17,600 base pilot + $6,800 Mumbai module = $24,400. Consolidated categories are $600 hardware/software + $15,640 services + $8,160 compensation. Mumbai’s planning cost is $136 per target checked-in builder (50) and approximately $1,133 per qualifying starter-derived prototype at the target of six; these are budget ratios, not proven acquisition costs.
Combined milestones and payment reconciliation
Requested funding release before execution
The Mumbai module requires a $6,040 advance to execute; it is not proposed as a reimbursement-only event. Subject to ZCG’s written approval and the grant agreement, this payment would be released after acceptance of the execution plan and before paid technical preparation, venue bookings and supplier commitments. It covers $4,840 in event services and $1,200 in technical preparation, delivery and follow-up. The organiser is not committing to personally bridge delayed event funding.
Technical readiness is a separate launch gate: after the advance, the team completes the starter and rehearsals, then demonstrates readiness before the event. The remaining $760 coordination/reporting fee is requested only after accepted delivery evidence and the 30-day report. This changes payment timing clarity, not the $6,800 Mumbai budget or $24,400 combined ceiling. If ZCG cannot approve this arrangement, agree a revised schedule or scope before committing costs; do not assume funding or spend first.
T0 is the base-pilot kickoff after the agreement, startup funding and technical-lead confirmation. E is the separately agreed Mumbai event date, tentatively 2 November. Mumbai milestones run independently and do not wait for M4. Startup funding is included in, not additional to, the $24,400 combined request.
| Payment | Timing | Evidence for review | USD |
|---|---|---|---|
| Startup | Before kickoff | Agreed funding and delivery arrangements | 3,520 |
| M1: Ready to teach and test | T0 + 2 weeks | Tested curriculum, testnet rehearsal, setup reproduced by at least 3 prospective participants, briefs tested with at least 4 intended-user representatives, delivery rota and supplier terms | 7,040 |
| M2: Madhya Pradesh delivery | T0 + 6 weeks | Bhopal/Indore workshops and build days, attendance, first 6-prototype target, reviewer notes and expenditure report | 5,280 |
| M3: National Capital Region delivery | T0 + 10 weeks | Delhi/Noida workshops and build days, base-pilot 12-prototype/6-testnet-flow targets, reproducible evidence and spend ledger | 880 |
| M4: Follow-up and reusable kit | T0 + 14 weeks | Six clinics completed, 30-day follow-up targeting 8 revised projects, final kit reviewed by at least 2 external educators/builders, friction report and budget reconciliation | 880 |
| Base pilot subtotal | Startup $3,520 + M1–M4 $14,080 | 17,600 | |
| M5: Mumbai execution-plan approval and advance | Requested by E−14, before paid preparation/bookings; provisionally 19 October | Plan, quotations/terms, confirmed rota, non-duplication check and written advance agreement. Funded starter preparation follows release; rehearsal/reproduction checks and 40 setup-ready participants are required by E−7 before launch | 6,040 |
| M6: Mumbai first-build delivery and follow-up | E+30; provisionally 2 December | E+7 register targeting six distinct starter-derived demos with meaningful additions and peer tests; one shared clinic; E+30 targeting four substantive revisions with repeat user tests, friction report and expense reconciliation | 760 |
| Combined total | Startup $3,520 + all milestones $20,880 | 24,400 |
The base pilot’s last $1,760 is proposed deferred programme-lead compensation. Mumbai M5 is requested in advance to cover $4,840 services and $1,200 technical work. Paid preparation and supplier commitments depend on receipt of approved funds, and technical readiness is checked separately before launch. Its $760 coordination/reporting fee remains proposed deferred to M6. All deferrals and advance-payment arrangements require written agreement. No non-refundable commitments precede approved funds. Full grant closeout follows acceptance of both modules, including Mumbai’s E+30 report. Intended-user representatives validate relevant outputs, with full acceptance criteria in the GitHub application. Unmet targets will be reported with remediation or scope discussion, not labelled successful automatically.
Feedback we would particularly value
- Which proposed integration exercises would be most useful to current Zcash builders?
- Which maintained wallet/SDK testnet route should we evaluate during readiness?
- Are there existing India activities or reusable materials we should coordinate with rather than duplicate?
- Are the technical acceptance checks and follow-up evidence sufficient for judging the pilot?
- Does the Mumbai guided first-build day fill a real beginner-onboarding gap alongside existing Devcon-week activities, or should it be coordinated or reduced?
Thank you for reviewing the proposal. I will respond here and keep any revisions consistent with the GitHub application.
Arun Pratap Singh Chandel
The Origin Guild