ILE Labs: Zcash Developer Testing & Automation Toolkit - $28K Request

ZCASH COMMUNITY GRANTS APPLICATION - CONDENSED VERSION

PROJECT DETAILS

Project Summary

Testing framework and CI/CD automation for Zcash shielded transactions, providing local testnet simulation, automated consensus upgrade validation, and production-ready testing tools post-ECC departure.

Project Description

Overview: Complete testing infrastructure for Zcash’s privacy features (Sapling/Orchard). Enables developers to test shielded transactions, run local testnets without Kubernetes, automate consensus upgrades, and deploy privacy apps confidently.

Current Gaps:

  • No local framework for shielded tx testing (slow public testnet or complex K8s setup)
  • No CI/CD automation for consensus validation
  • No shielded pool mocking library
  • Scattered documentation

Proposed Problem

Problem 1: Protocol Upgrade Risk Post-ECC ECC team resigned Jan 7, 2026 (CoinDesk: https://www.coindesk.com/tech/2026/01/08/zcash-developer-team-behind-ecc-quits). Ecosystem lacks:

  • Automated consensus validation
  • Shielded tx regression tests
  • Fork detection/simulation
  • Documented testing procedures

Problem 2: Developer Onboarding Friction

  • Testnet-in-a-box requires Kubernetes (complex)
  • Public testnet: slow, unpredictable
  • No lightweight local option

Problem 3: Testing Complexity

  • No Sapling/Orchard mocking library
  • No assertion helpers
  • High barrier for ZK testing

Problem 4: CI/CD Gap

Proposed Solution

Layer 1: Testing Library

  • Sapling/Orchard pool mocks
  • Assertion helpers (assert_shielded_balance!())
  • Test fixtures
  • Rust crate + TypeScript package

Layer 2: Local Testnet Runner

  • CLI tool (zcash-devnet)
  • <2s startup vs. 5-10min for K8s
  • Mainnet forking
  • Deterministic blocks

Layer 3: CI/CD Suite

  • 5 GitHub Actions workflows (consensus validator, linter, fork detector, regression, release)
  • Pre-commit hooks
  • Slack/Discord notifications

Layer 4: Documentation

  • 50+ page testing guide
  • 5 video tutorials (30+ min)
  • 10+ example projects
  • Migration guides

Solution Format

Deliverables:

  • Software: Rust crate, npm package, CLI, GitHub Actions, hooks
  • Docs: Website (GitHub Pages), API ref, guides
  • Education: Videos (YouTube), examples, workshops
  • License: MIT/Apache 2.0

Distribution: crates.io, npm, GitHub Releases, Homebrew

Dependencies

Upstream (stable):

  • librustzcash, orchard, zcash_primitives, zcash_proofs

Tools: Rust 1.70+, Node.js, Git, GitHub Actions (free tier)

No Hard Blockers: Can start immediately, no waiting on others

Technical Approach

Development:

  • 2-week sprints, public GitHub from day 1
  • TDD, >80% coverage, CI on every push
  • Daily standups, weekly updates

Stack:

  • Rust core (team’s strength, Zcash momentum)
  • TypeScript bindings (napi-rs)
  • mdBook docs, OBS videos
  • hyper/tokio RPC

Performance: <2s startup, <100ms tx mocks

Upstream Merge Opportunities

Not forking - building ON TOP of librustzcash/orchard.

Will contribute back:

  • Bug reports/fixes if found
  • Doc improvements
  • Test utilities if useful

Coordination: Zcash Forum, Discord #development, Arborist Calls

TEAM INFORMATION

Project Lead

Charles Emmanuel - Founder, ILE Labs

Team Members

Stephen Ifeadi - Blockchain Engineer

Rotsimi Olashindé - DevRel Engineer

Contact: contact@ilelabs.org | https://ilelabs.org

BUDGET

Hardware/Software: $550

  • Domain: $15
  • Code signing: $200
  • Misc: $335 (Everything else free: GitHub Actions, YouTube, VS Code)

Service Costs: $0

All free services (GitHub, Pages, crates.io, npm)

Compensation: $27,450

Labor:

  • Charles (180h @ $65/hr): $11,700
  • Stephen (160h @ $60/hr): $9,600
  • Rotsimi (120h @ $60/hr): $7,200
  • QA/Video (60h @ $50/hr): $3,000
  • Subtotal: $31,500
  • Open-source discount (30%): -$9,450
  • Adjusted: $22,050
  • PM/contingency (25%): $5,400
  • Total: $27,450

Total Budget: $28,000

Previous Funding: No

Other Funding: No

RISK ASSESSMENT

Implementation Risks

Risk 1: ZK Mocking Complexity (40% prob, Med impact)

  • Mitigation: Use upstream crates, focus on high-level API, >80% tests

Risk 2: Performance <2s (30% prob, Low impact)

  • Mitigation: Minimal state, in-memory, adjust target to <5s if needed

Risk 3: CI/CD Complexity (25% prob, Med impact)

  • Mitigation: Start simple, leverage TxGuard, 80/20 rule

Risk 4: Low Adoption (35% prob, Med impact)

  • Mitigation: Direct outreach, Foundation partnership, conservative KPIs

Side Effects

Positive:

  • 10-20% dev community growth
  • 20-30% reduced consensus bugs
  • Institutional knowledge preserved
  • Becomes ecosystem standard

Negative (mitigated):

  • Dependency risk (docs emphasize test flow)
  • Maintenance burden (12mo commitment)

Success Metrics

Technical:

  • 4 milestones on time

  • 80% coverage

  • Zero critical bugs (1mo)

Adoption (3mo):

  • 50+ downloads
  • 20+ stars
  • 10+ quickstart completions
  • 5+ contributions
  • 1+ wallet adoption
  • Official docs integration

Impact (6-12mo):

  • 30% faster setup (survey)
  • 4.0+ satisfaction
  • Zero forks from gaps
  • 3+ new projects using toolkit

PROJECT SCHEDULE

Startup Funding: N/A

Milestones

M1: Testing Library (Weeks 1-3, $7,500)

  • Deliverables: Rust crate, npm package, 20+ examples, docs
  • Done when: Published to crates.io: Rust Package Registry, all tests pass, quickstart <10 steps, Sapling mock works

M2: Local Testnet (Weeks 4-6, $7,000)

  • Deliverables: zcash-devnet CLI, RPC server, mainnet forking, video
  • Done when: <5s startup, RPC works with zcash-cli, deterministic blocks, video live

M3: CI/CD Suite (Weeks 7-9, $6,500)

  • Deliverables: 5 workflows, pre-commit hooks, integration examples, notifications
  • Done when: All workflows run, catches bad forks, hooks block invalid tx

M4: Docs & Launch (Weeks 10-12, $7,000)

  • Deliverables: 50+ page site, 5 videos, 10+ examples, workshop materials, launch
  • Done when: Site live, 100+ views, 200+ reach, beta workshop done, >4/5 survey

Total: 12 weeks, $28,000

SUPPORTING DOCUMENTS

Evidence:

Technical:

Contact:

Hello!

is this the same people as in this grant https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/105?


Name: Emmanuel Charles
Role: Blockchain Developer & QA Engineer
Background: Rust/TypeScript/C++ with dual focus on smart contracts and QA for blockchain systems. LinkedIn: https://www.linkedin.com/in/emmanuel-charles-0b0023250

Responsibilities: E2E test suite design (UA vectors, autoshield, rescan/sync cases); health checks; failure artifacts/logging; compatibility matrix (Zebra/NU, lwd/Zaino); reproducible sample repo.


Name: Gospel Ifeadi
Role: Smart Contract & Backend Engineer
Background: Rust/C++/JavaScript/Python engineer with experience in dApps and developer tooling, automation, and R&D. X/Twitter: https://x.com/gospel70800

Responsibilities: Orchestrator core (CLI/compose), backend integration with Zebra regtest; lightwalletd/Zaino interface layer; CI Action internals; performance profiling and optimization.

It sounds a pretty similar grant to me.

Are you no longer part of the @DappsoverApps team? If so, why haven’t you notified the comittee about it?

1 Like

Yes, Emmanuel and Gospel are the same people mentioned in that earlier grant thread. In that case they were working as independent contractors on a specific project. They aren’t members of the DappsoverApps organization, and there wasn’t any long-term team affiliation involved.

For this proposal they’re again participating as independent contributors, but under a separate project and structure. There’s no funding overlap or shared obligations between the two efforts. Each proposal stands on its own in terms of scope, ownership, and accountability.

Can you explain why if you were working at DappsOverApps as independent contractor you opened this grant which was a subset of that work?

The project you are referring to was created by CodexEmmzy in error and was closed immediately after we noticed the mistake.
It is not tied to DappsOverApps or any other company. Our current work is being carried out independently, and there is no duplication or overlap with external teams.

Thank you for submitting your proposal. Following a thorough review by the ZCG the committee has decided not to move forward with this proposal. Further details will be available in the meeting minutes to be posted later this week.

1 Like