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

**URL:** <https://forum.zcashcommunity.com/t/ile-labs-zcash-developer-testing-automation-toolkit-28k-request/54699>\
**Category:** Applications\
**Created:** [February 13, 2026, 9:24pm UTC](https://forum.zcashcommunity.com/t/ile-labs-zcash-developer-testing-automation-toolkit-28k-request/54699 "2026-02-13T21:24:27Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![ILE\_Labs](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/ile_labs/32/43117_2.png) [@ILE\_Labs](https://forum.zcashcommunity.com/u/ILE_Labs)\
**Post date:** [February 13, 2026, 9:24pm UTC](https://forum.zcashcommunity.com/t/ile-labs-zcash-developer-testing-automation-toolkit-28k-request/54699/1 "2026-02-13T21:24:27Z")

</div>

# 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](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**

- No GitHub Actions for Zcash
- No pre-commit hooks
- TxGuard approved Jan 2026 proves demand ([Zcash Community Grants Meeting Minutes 1/19/2026](https://forum.zcashcommunity.com/t/zcash-community-grants-meeting-minutes-1-19-2026/54383))

### 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](http://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

- 6+ years blockchain (Rust, TS, Solidity)
- Prior: Arbitrum CLI, VoxBridge, OX Rollup
- GitHub: [CodexEmmzy (Charles Emmanuel) · GitHub](https://github.com/CodexEmmzy)
- LinkedIn: [https://www.linkedin.com/in/emmanuel-charles-0b0023250/](https://www.linkedin.com/in/emmanuel-charles-0b0023250/)
- Email: [charles@ilelabs.org](mailto:charles@ilelabs.org)

### Team Members

**Stephen Ifeadi** - Blockchain Engineer

- 4+ years Rust systems
- Focus: Local testnet, CI/CD, performance
- X: [https://x.com/gospel70800](https://x.com/gospel70800)

**Rotsimi Olashindé** - DevRel Engineer

- 3+ years TS/Rust
- Focus: TypeScript SDK, docs, videos
- LinkedIn: [https://www.linkedin.com/in/rotimi-olasehinde-abimbola/](https://www.linkedin.com/in/rotimi-olasehinde-abimbola/)

**Contact:** [contact@ilelabs.org](mailto:contact@ilelabs.org) | [https://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](http://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](http://crates.io/npm), 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:**

- ECC quit: [https://www.coindesk.com/tech/2026/01/08/zcash-developer-team-behind-ecc-quits](https://www.coindesk.com/tech/2026/01/08/zcash-developer-team-behind-ecc-quits)
- ZF 2026 Strategy: [Zcash Foundation Details 2026 Strategy for Privacy and Network Strength](https://coinfomania.com/zcash-foundation-details-2026-strategy-for-privacy-and-network-strength/)
- ZCG TxGuard approval: [Zcash Community Grants Meeting Minutes 1/19/2026](https://forum.zcashcommunity.com/t/zcash-community-grants-meeting-minutes-1-19-2026/54383)
- ZCG RFP: [Zcash Community Grants RFP Program Updates | Zcash Community Grants](https://zcashcommunitygrants.org/news/rfp/2023/02/22/zcg-rfp-update/)

**Technical:**

- librustzcash: [GitHub - zcash/librustzcash: Rust-language assets for Zcash](https://github.com/zcash/librustzcash)
- orchard: [GitHub - zcash/orchard: Implementation of the Zcash Orchard Protocol](https://github.com/zcash/orchard)

**Contact:**

- Email: [contact@ilelabs.org](mailto:contact@ilelabs.org), [emmaxcharles123@gmail.com](mailto:emmaxcharles123@gmail.com)
- Telegram: @ilelabs, @charlesCode
- Forum: @ILE_Labs
- Discord: emmzycode01

---

<div class="post-metadata">

**Author:** ![pacu](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/pacu/32/15383_2.png) [@pacu](https://forum.zcashcommunity.com/u/pacu)\
**Post date:** [February 13, 2026, 10:28pm UTC](https://forum.zcashcommunity.com/t/ile-labs-zcash-developer-testing-automation-toolkit-28k-request/54699/2 "2026-02-13T22:28:00Z")

</div>

Hello!

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

```auto

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?

---

<div class="post-metadata">

**Author:** ![ILE\_Labs](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/ile_labs/32/43117_2.png) [@ILE\_Labs](https://forum.zcashcommunity.com/u/ILE_Labs)\
**Post date:** [February 13, 2026, 11:15pm UTC](https://forum.zcashcommunity.com/t/ile-labs-zcash-developer-testing-automation-toolkit-28k-request/54699/3 "2026-02-13T23:15:07Z")

</div>

> [@pacu](#):
>
> Are you no longer part of the @DappsoverApps team? If so, why haven’t you notified the comittee about it?

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.

---

<div class="post-metadata">

**Author:** ![pacu](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/pacu/32/15383_2.png) [@pacu](https://forum.zcashcommunity.com/u/pacu)\
**Post date:** [February 14, 2026, 12:08am UTC](https://forum.zcashcommunity.com/t/ile-labs-zcash-developer-testing-automation-toolkit-28k-request/54699/4 "2026-02-14T00:08:40Z")

</div>

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

> <https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/138>
>
> \### Terms and Conditions
> 
> \- \[x\] I agree to the \[Grant Agreement\](https://9ba4718…c-5c73-47c3-a024-4fc4e5278803.usrfiles.com/ugd/9ba471\_f81ef4e4b5f040038350270590eb2e42.pdf) terms if funded
> \- \[x\] I agree to \[Provide KYC information\](https://9ba4718c-5c73-47c3-a024-4fc4e5278803.usrfiles.com/ugd/9ba471\_7d9e73d16b584a61bae92282b208efc4.pdf) if funded above $50,000 USD
> \- \[x\] I agree to disclose conflicts of interest
> \- \[x\] I agree to adhere to the \[Code of Conduct\](https://forum.zcashcommunity.com/t/zcg-code-of-conduct/41787) and \[Communication Guidelines\](https://forum.zcashcommunity.com/t/zcg-communication-guidelines/44284)
> \- \[x\] I understand all milestone deliverables will be validated and accepted by their intended users or their representatives, who will confirm that the deliverables meet the required quality, functionality, and usability for each user story.
> \- \[x\] I agree that for any new open-source software, I will create a \`CONTRIBUTING.md\` file that reflects the high standards of Zcash development, using the \[\`librustzcash\` style guides\](https://github.com/zcash/librustzcash/blob/main/CONTRIBUTING.md#styleguides) as a primary reference.
> \- \[x\] I understand when contributing to existing Zcash code, I am required to adhere to the project specific contribution guidelines, paying close attention to any \[merge\](https://github.com/zcash/librustzcash/blob/main/CONTRIBUTING.md#merge-workflow), \[branch\](https://github.com/zcash/librustzcash/blob/main/CONTRIBUTING.md#branch-history), \[pull request\](https://github.com/zcash/librustzcash/blob/main/CONTRIBUTING.md#pull-request-review), and \[commit\](https://github.com/zcash/librustzcash/blob/main/CONTRIBUTING.md#commit-messages) guidelines as exemplified in the \`librustzcash\` repository.
> \- \[x\] I agree to post request details on the \[Community Forum\](https://forum.zcashcommunity.com/c/grants/33)
> \- \[x\] I understand it is my responsibility to post a link to this issue on the \[Zcash Community Forums\](https://forum.zcashcommunity.com/c/grants/33) after this application has been submitted so the community can give input. I understand this is required in order for ZCG to discuss and vote on this grant application.
> 
> \### Application Owners (@Octocat, @Octocat1)
> 
> CodexEmmzy
> 
> \### Organization Name
> 
> Charles Emmanuel (individual / solo proposer)
> 
> \### How did you learn about Zcash Community Grants
> 
> I learned about Zcash Community Grants via community channels and collaborator referrals (DappsoverApps announcement and Zcash community forum).
> 
> \### Requested Grant Amount (USD)
> 
> 13,500
> 
> \### Category
> 
> Infrastructure
> 
> \### Project Lead
> 
> \`\`\`project-lead.yaml
> Name: Charles Emmanuel
> Role: Project Lead / Lead Developer
> Background: Rust, TypeScript, Python blockchain tooling engineer. Lead developer on infrastructure and devtools projects (Ox-rollup, RetrievalTester, VoxBridge). Experienced in building CLIs, CI integrations, and developer DX.
> Responsibilities: Overall technical delivery, CLI & action implementation, acceptance testing, release and handover.
> \`\`\`
> 
> \### Additional Team Members
> 
> \`\`\`team-members.yaml
> Name: Gospel Ifeadi (contracted)
> Role: QA & E2E testing support
> Background: Backend / QA engineering for blockchain toolchains.
> Responsibilities: Assist with test harnesses, CI reliability work, sample repo integration and validation.
> \`\`\`
> 
> \### Project Summary
> 
> ZecDev Mini delivers a compact, Linux-first CLI and GitHub Action that brings up a Zebra regtest, a local faucet, and minimal Unified Address (ZIP-316) fixtures, then runs a lightweight golden shielded smoke test per PR. The tool dramatically reduces integration friction for maintainers migrating from zcashd to Zebra by providing a fast, reliable PR-level smoke check.
> 
> 
> \### Project Description
> 
> This project builds a small, maintainable devtool for the immediate Zebra migration needs. It is intentionally scoped for a single-developer delivery with a small set of contracted helpers for documentation, QA, and outreach. Deliverables:
> 
> \* zecmini CLI: commands zecmini up/test/down to spin a Zebra regtest, faucet, lightwalletd, load UA fixtures, run a smoke test, and collect artifacts.
> \* zecmini-smoke-action: a reusable GitHub Action that runs zecmini up/test/down per PR and publishes logs/artifacts.
> \* Minimal UA fixtures (ZIP-316 vectors) and a single deterministic golden flow: generate UA -\> fund -\> autoshield -\> shielded send -\> verify.
> \* Example sample repo with a passing PR run to demonstrate integration.
> \* Documentation: 2-minute local quickstart, 5-line CI snippet, troubleshooting and Linux-first guidance.
> \* Short demo GIF/video and a 30-day maintenance window for critical fixes post-release.
> Community outreach activities (included): forum announcement, 1 live demo session or workshop for maintainers, and outreach to key repos that will benefit from the action.
> 
> 
> \### Proposed Problem
> 
> Zebra is replacing zcashd and projects are expected to migrate. Many repositories lack a standardized way to run a reproducible local Zebra devnet and smoke tests in CI. This causes fragile repo-specific scripts, missed regressions, and slower migration. The full Launchpad project addresses this broadly but is larger in scope; many maintainers need a compact, immediately useful, low-friction smoke-test tool they can adopt now.
> 
> \### Proposed Solution
> 
> \* Boots a reliable Zebra regtest and lightwalletd locally (or in CI),
> \* Seeds deterministic UA fixtures and funds,
> \* Runs a minimal golden shielded smoke test,
> \* Provides a drop-in GitHub Action for PR-level checks,
> \* Documents known desktop caveats and enforces local-only defaults to maintain safety.
> 
> \### Solution Format
> 
> \* zecmini CLI repository (Rust with Docker-compose orchestration; prebuilt Linux binaries provided)
> \* zecmini-smoke-action GitHub Action repo + published tag
> \* Example PR sample repo wired to the action
> \* Docs, quickstart, and demo assets
> \* 30-day post-release maintenance
> 
> 
> \### Dependencies
> 
> \* zebra (zebrad) with pinned regtest-compatible versions
> \* lightwalletd (for the smoke flow)
> \* Docker Engine \>= 24.x and Docker Compose v2
> \* Linux runners (ubuntu-latest) for CI (GitHub Actions)
> \* GitHub Actions permissions to upload artifacts
> \* Minimal self-hosted Linux runner optionally used during development for reliable mult-container tests
> \* Coordination with upstream maintainers (Zebra, lightwalletd) if upstream doc merges are pursued
> 
> \### Technical Approach
> 
> \* Implement zecmini as a small Rust CLI that wraps pinned container orchestration (Docker Compose profiles) to ensure deterministic startup.
> \* zecmini up: compose profiles, health checks with retries, seed pre-mined funds, load UA fixtures.
> \* zecmini test: execute a single compact golden flow that exercises the end-to-end private send path using a deterministic set of keys/fixtures. Tests will be deterministic and produce artifact logs for debugging.
> \* zecmini down: teardown and collect logs/artifacts.
> \* Build a GitHub Action (action.yml) that runs the same commands on a Linux runner and exposes structured artifacts on failure (logs, traces, JSON summaries).
> \* Provide prebuilt Linux binaries and a sample workflow to ease adoption for maintainers.
> \* Safety: services bind to localhost by default; any “testing-only” flags are opt-in with explicit warnings.
> 
> 
> \### Upstream Merge Opportunities
> 
> 
> \* Targeted upstream touchpoints: zebra/zebra (docs/examples), zcash/lightwalletd (readiness guidance), and zingo-proxy / Zaino where lightweight examples are useful.
> \* Changes planned: add a devnet compose profile example, small docs improvements, and health-check recommendations. These changes are primarily documentation and example compose snippets that can be proposed as PRs to upstream projects.
> \* Coordination: will open PRs and request maintainers’ review for example compose profiles and small doc additions after M2 acceptance.
> \* Timeline for merges: docs and example PRs will be submitted during Milestone 3 and staged for upstream review; merges depend on upstream maintainers’ schedules.
> 
> 
> 
> 
> \### Hardware/Software Costs (USD)
> 
> 200
> 
> \### Hardware/Software Justification
> 
> Small Linux VM / self-hosted runner costs for development CI matrix and reliable multi-container testing; minimal packaging and binary build steps. Linux-first approach keeps local testing stable and reproducible.
> 
> \### Service Costs (USD)
> 
> 500
> 
> \### Service Costs Justification
> 
> Costs to publish action (marketplace/CI minutes where necessary during testing), small hosting for demo assets, and build artifacts. All tooling and most services are free; this covers unavoidable small service costs.
> 
> 
> \### Compensation Costs (USD)
> 
> 12,800
> 
> \### Compensation Costs Justification
> 
> Compensation covers the solo core development work (CLI, action, test harness, packaging) and contracted documentation / QA / outreach support (documentation authoring, workshop coordination, demo creation, acceptance testing). No hourly rates are provided in this submission; the total compensation pool is shown as a single amount to cover these activities and contractor engagements.
> 
> 
> \### Total Budget (USD)
> 
> 13,500
> 
> \### Previous Funding
> 
> No
> 
> \### Previous Funding Details
> 
> N/A
> 
> \### Other Funding Sources
> 
> No
> 
> \### Other Funding Sources Details
> 
> N/A
> 
> \### Implementation Risks
> 
> 
> \* Upstream zebra changes: Medium likelihood, high impact. Mitigation: pin versions, provide compatibility matrix, and accept maintenance window for rapid patching.
> \* lightwalletd integration quirks: Medium likelihood, medium impact. Mitigation: keep lwd as the default, document known issues, and provide clear error artifacts on failure.
> \* CI flakiness and startup races: Medium likelihood, medium impact. Mitigation: deterministic fixtures, health-checks with retries, artifact uploads to aid debugging.
> \* Desktop host-networking inconsistencies: Medium likelihood, medium impact. Mitigation: Linux-first policy and documented caveats for Docker Desktop users.
> \* Accidental exposure of test data: Low likelihood, high impact. Mitigation: bind to localhost by default and redact logs if necessary.
> 
> 
> 
> \### Potential Side Effects
> 
> \* Some maintainers may mistake passing smoke tests for full correctness; mitigation: clearly state limitations and encourage repo-specific tests.
> \* CI time can increase with attempts to run multiple backends; mitigation: single-backend default and optional matrix mode.
> 
> 
> 
> \### Success Metrics
> 
> 
> \* Repos adopting the Action: \>= 10 public repos using the action within 60 days.
> \* Local usage: \>= 100 zecmini up launches per month (tracked via opt-in telemetry link or GitHub repo activity).
> \* CI flakiness: rerun rate \< 10% for the smoke action on sample repos.
> \* Time-to-first-pass: following docs, a fresh Ubuntu VM runs a passing smoke test in \<= 10 minutes.
> \* Number of upstream doc PRs submitted: \>= 2 within first 60 days (compose examples / README improvements).
> 
> 
> 
> \### Startup Funding (USD)
> 
> 2000
> 
> \### Startup Funding Justification
> 
> Startup funds will seed initial repository bootstrap, create acceptance tests and CI scaffolding, and provision a small Linux runner for stable multi-container testing during M1. This enables an early working prototype and reliable acceptance tests for milestones.
> 
> 
> \### Milestone Details
> 
> \`\`\`milestones.yaml
> Milestone: 1
> Amount (USD): 3,000
> Expected Completion Date: YYYY-MM-DD (target: 2 weeks from award)
> User Stories:
> 
> \* "As a developer, I want a reproducible devnet scaffold so I can quickly spin up a test zebra regtest on Linux."
> Deliverables:
> \* Technical spec and acceptance tests documented in the repo; repository scaffolded (license, CONTRIBUTING.md, issue templates).
> \* Initial compose profile and health-check plan.
> Acceptance Criteria:
> \* On a fresh Ubuntu runner, zecmini up boots zebra and lwd containers and health checks pass; acceptance tests run and publish initial logs.
> 
> Milestone: 2
> Amount (USD): 4,500
> Expected Completion Date: YYYY-MM-DD (target: 3–4 weeks from award)
> User Stories:
> 
> \* "As a maintainer, I want zecmini up/test/down so I can validate golden shielded flows locally."
> Deliverables:
> \* zecmini CLI (Linux-first) with up/test/down, pre-mined funds, UA fixtures, and deterministic golden test.
> Acceptance Criteria:
> \* The golden smoke flow passes on a fresh Ubuntu VM; logs and artifacts are produced by the CLI.
> 
> Milestone: 3
> Amount (USD): 4,000
> Expected Completion Date: YYYY-MM-DD (target: 5 weeks from award)
> User Stories:
> 
> \* "As a CI maintainer, I want a reusable Action so PRs run the smoke test automatically."
> Deliverables:
> \* zecmini-smoke-action published/tagged; sample repo wired to the Action with a passing run and artifact capture on failure.
> Acceptance Criteria:
> \* Sample public PR shows passing Action run on lightwalletd and artifacts are visible for failures.
> 
> Milestone: 4
> Amount (USD): 2,000
> Expected Completion Date: YYYY-MM-DD (target: 6–7 weeks from award)
> User Stories:
> 
> \* "As a new contributor, I want a 2-minute local start and clear docs so I can get a passing test quickly."
> Deliverables:
> \* Docs (quickstart, 5-line CI snippet), demo GIF/video, forum post announcing the project, and 30-day maintenance window for critical fixes.
> Acceptance Criteria:
> \* Docs verified from a fresh VM produce a passing run in \<= 10 minutes; demo and forum announcement published; first maintenance commits (if needed) available within the 30-day window.
> \`\`\`
> 
> \### Supporting Documents
> 
> \`\`\`files.yaml
> I will coordinate community outreach to accelerate adoption: publish a forum post with usage guides, host a short live demo or walkthrough for maintainers, and proactively contact several repos that will benefit from the Action. Outreach and workshop coordination is included in the deliverables (no hourly breakdown will be provided in this application).
> \`\`\`

---

<div class="post-metadata">

**Author:** ![ILE\_Labs](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/ile_labs/32/43117_2.png) [@ILE\_Labs](https://forum.zcashcommunity.com/u/ILE_Labs)\
**Post date:** [February 14, 2026, 6:58am UTC](https://forum.zcashcommunity.com/t/ile-labs-zcash-developer-testing-automation-toolkit-28k-request/54699/5 "2026-02-14T06:58:39Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![ZCG](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/zcg/32/33712_2.png) [@ZCG](https://forum.zcashcommunity.com/u/ZCG)\
**Post date:** [February 16, 2026, 2:04pm UTC](https://forum.zcashcommunity.com/t/ile-labs-zcash-developer-testing-automation-toolkit-28k-request/54699/6 "2026-02-16T14:04:14Z")

</div>

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.