Hey everyone,
I submitted a retroactive grant application for ZAP1:
opened 09:25PM - 12 May 26 UTC
# Retroactive Grant Application - ZAP1 Attestation Protocol and Verification Too… ling
## Terms And Conditions
- [x] I agree to the Grant Agreement terms if funded.
- [x] I agree to provide KYC information if funded above `$50,000` USD.
- [x] I agree to disclose conflicts of interest.
- [x] I understand this program is only for fully completed work.
- [x] I understand applications for planned or partially finished work will not be considered.
- [x] I understand all completed work must be publicly verifiable and accepted by intended users or their representatives.
- [x] I agree that for new open-source software, I will maintain a `CONTRIBUTING.md` file that reflects high Zcash development standards.
- [x] I understand that when contributing to existing Zcash code, I am required to adhere to the project-specific contribution guidelines.
- [x] I understand I must copy this proposal into a separate Community Forum thread in the Retroactive Grants category.
- [x] I understand grants are valued in USD but disbursed in shielded ZEC, and disbursement amounts may fluctuate with the ZEC/USD exchange rate.
## Application Owners
`@Zk-nd3r`
## Organization Or Individual Name
Frontier Compute LLC
## Additional Team Members
```yaml
team_members: []
```
## How Did You Learn About This Program?
Zcash Community Forum / FPF Coinholder-Directed Retroactive Grants Q2 2026 announcement.
This application is retroactive and limited to completed public work. It does not request funding for future hardening, third-party integrations, adoption work, or new milestones.
## Requested Grant Amount
`$28,000`
This reflects completed open-source infrastructure, public Zcash mainnet anchoring, protocol documentation, verification tooling, and public package distribution.
## Category
Infrastructure
## Project Summary
ZAP1 is an open-source application-layer attestation protocol for Zcash that provides BLAKE2b Merkle commitments, Orchard shielded memo anchoring, standalone verification tooling, public API endpoints, and package distribution. It lets applications prove completed lifecycle events through public commitments without exposing customer rows, private payment data, custody, or a centralized attestation service.
## Project Description
The work completed from March 2026 through May 2026 delivered a public, MIT-licensed reference implementation and live Zcash mainnet deployment of the ZAP1 attestation protocol.
Completed deliverables include:
- ZAP1 reference implementation in Rust.
- BLAKE2b Merkle commitment scheme for lifecycle events.
- Orchard shielded memo anchoring on Zcash mainnet.
- Public API for stats, scanner health, anchor status, anchor history, protocol info, and verification surfaces.
- Standalone verification crate and memo decoder crate.
- JavaScript/NPM distribution for client-side verification tooling.
- Structured memo / ZIP draft work for broader ecosystem review.
- Public protocol documentation and contribution guidance.
- CI-backed repository with test coverage and automated checks.
- Live scanner state with current mainnet sync and anchor history.
The work is completed and public. Future work, integrations, or product-specific deployments are not part of this retroactive request.
## Technical Approach
ZAP1 uses application-level event commitments rather than exposing application records directly. Events are hashed into a Merkle tree. The Merkle root is anchored to Zcash using shielded Orchard memo data. Reviewers can verify public anchor history and proof material without requiring private user records, spending keys, viewing keys, customer rows, balances, addresses, or raw transaction data.
The technical stack includes:
- `zap1`: core Rust implementation, protocol documentation, tests, and conformance tooling.
- `zap1-verify`: standalone Rust verification crate.
- `zcash-memo-decode`: universal decoder for Zcash shielded memo formats, including ZAP1 attestation identification.
- `@frontiercompute/zap1`: JavaScript package for verification clients.
- Live API endpoints for public stats, health, anchor status, anchor history, and protocol info.
The protocol is designed to be independent of any one hosted service. Hosted APIs make verification easier, but the repository and package artifacts are open source and self-verifiable.
## Time Period Of Work Completion
March 2026 through May 2026.
## Total Budget
`$28,000`
## Budget Breakdown
```yaml
total_requested_usd: 28000
items:
- category: protocol_implementation_and_verification_tooling
amount_usd: 22000
description: Rust implementation, BLAKE2b Merkle commitments, Orchard memo anchoring, verification crate, memo decoder, API verification surfaces, tests, CI, and release work.
- category: infrastructure_and_operations
amount_usd: 4000
description: Mainnet scanner/API hosting, monitoring, domains, CI runs, and operational support during the completed work window.
- category: documentation_and_release
amount_usd: 2000
description: Public protocol docs, contribution guide, ZIP draft work, package release notes, and reviewer-verification materials.
```
## Previous Funding
No.
## Previous Funding Details
The earlier proactive ZCG application for ZAP1 was closed without funding:
- https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/258
No funds were received from that application.
## Other Funding Sources
No.
## Other Funding Sources Details
N/A.
## Success Metrics
Publicly verifiable metrics observed on 2026-05-12:
- ZAP1 repository is public and MIT licensed: https://github.com/Frontier-Compute/zap1
- Public reference commit: `59279222584e490f099a2f358c248cab5e800466`
- CI success for the public reference commit: https://github.com/Frontier-Compute/zap1/actions/runs/25327861079
- Live Zcash mainnet scanner health: `scanner_operational=true`, `rpc_reachable=true`, `sync_lag=0`, `network=MainNetwork`, `chain_tip=3339962`.
- Live ZAP1 stats: `29` anchors, `327` leaves, `9` event types.
- First observed anchor block: `3301151`.
- Last observed anchor block in stats: `3317133`.
- Anchor status: `needs_anchor=false`, `unanchored_leaves=0`, `recommendation="up to date"`.
- Current ZAP1 root: `3703f07ee72df334a447a1d7dc37bdefcfe5b2b469ec3d6f6868f7ca8c6e5485`.
- Last mainnet anchor txid: `77ba0fe519c24d8153df2d890e6186405678847c09ee34cfe3520f29afa8c463`.
- Protocol info reports `version=3.0.0`, `hash_function=BLAKE2b-256`, and `zip_status=draft`.
- Public README reports `118` tests and `60` automated checks.
- `zap1-verify` crate published on crates.io.
- `zcash-memo-decode` crate published on crates.io.
- `@frontiercompute/zap1` package published on npm.
- ZIP draft opened for ecosystem review: https://github.com/zcash/zips/pull/1243
These metrics are intended as verification anchors, not as a claim of final ZIP acceptance, third-party integration, broad ecosystem adoption, or formal protocol adoption.
## Proof Of Completion
Primary source links:
- ZAP1 repository: https://github.com/Frontier-Compute/zap1
- Public reference commit: https://github.com/Frontier-Compute/zap1/commit/59279222584e490f099a2f358c248cab5e800466
- Protocol documentation: https://github.com/Frontier-Compute/zap1/blob/main/ONCHAIN_PROTOCOL.md
- Contribution guide: https://github.com/Frontier-Compute/zap1/blob/main/CONTRIBUTING.md
- CI run: https://github.com/Frontier-Compute/zap1/actions/runs/25327861079
- Live stats endpoint: https://api.frontiercompute.cash/stats
- Live health endpoint: https://api.frontiercompute.cash/health
- Anchor status endpoint: https://api.frontiercompute.cash/anchor/status
- Anchor history endpoint: https://api.frontiercompute.cash/anchor/history
- Protocol info endpoint: https://api.frontiercompute.cash/protocol/info
- `zap1-verify` crate: https://crates.io/crates/zap1-verify
- `zcash-memo-decode` crate: https://crates.io/crates/zcash-memo-decode
- `@frontiercompute/zap1` package: https://www.npmjs.com/package/@frontiercompute/zap1
- ZAP1 ZIP draft: https://github.com/zcash/zips/pull/1243
## Conflict Of Interest Disclosure
The applicant is the operator of Frontier Compute and author/operator of the ZAP1 work described here.
Frontier Compute submitted a separate proactive Zush application, which was closed without funding. That application is separate from this retroactive request, and no funds were received from it.
No other conflict is being used as evidence for this request. The proposal should be evaluated on the completed ZAP1 public work and proof links above.
## Community Forum Posting
Pending. The forum thread will be posted in Community Grants | Retroactive Grants after the GitHub application issue is created.
The request is $28,000 for completed open-source Zcash attestation and verification tooling shipped between March and May 2026.
ZAP1 is an application-layer attestation protocol for Zcash. It lets an application commit structured lifecycle events into BLAKE2b Merkle roots, then anchor those roots through Orchard shielded memo data on Zcash mainnet.
The useful property is that the public side can verify roots, counts, anchors, health, and code without requiring customer rows, addresses, balances, viewing keys, or raw payment data.
MIT-licensed Rust reference implementation.
BLAKE2b Merkle commitment scheme for lifecycle events.
Orchard shielded memo anchoring on Zcash mainnet.
Public API for stats, scanner health, anchor status, anchor history, and protocol info.
Standalone verification crate: zap1-verify.
Universal memo decoder crate: zcash-memo-decode.
JavaScript verification package: @frontiercompute/zap1.
Protocol documentation and contribution guide.
CI-backed tests and conformance checks.
Open ZIP draft for structured attestation review.
Observed on May 12, 2026:
29 ZAP1 anchors.327 leaves.9 event types tracked.Mainnet scanner operational with sync_lag=0, rpc_reachable=true, and chain_tip=3339962.
Anchor status reports needs_anchor=false, unanchored_leaves=0, and recommendation="up to date".
Current ZAP1 root: 3703f07ee72df334a447a1d7dc37bdefcfe5b2b469ec3d6f6868f7ca8c6e5485.
Last mainnet anchor txid: 77ba0fe519c24d8153df2d890e6186405678847c09ee34cfe3520f29afa8c463.
Protocol info reports version=3.0.0, hash_function=BLAKE2b-256, and zip_status=draft.
README reports 118 tests and 60 automated checks.
These are public verification anchors. They are not claims of formal ZIP acceptance, third-party integration, broad ecosystem adoption, or protocol adoption.
A reviewer can inspect the repository and reference commit, check /stats, /health, /anchor/status, /anchor/history, and /protocol/info, then verify proof material with zap1-verify.
An earlier proactive ZCG application for ZAP1 was closed without funding:
opened 01:33AM - 31 Mar 26 UTC
closed 01:12PM - 13 Apr 26 UTC
📋 Grant Application
👀 Ready For ZCG Review
❌ Grant Declined
### 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
- [ ] 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.
- [ ] 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
@Zk-nd3r
### Organization Name
Frontier Compute / LiquidLV DAO LLC (Wyoming)
### How did you learn about Zcash Community Grants
Active in the Zcash community. Building attestation tooling on Zcash mainnet.
### Requested Grant Amount (USD)
18000
### Category
Infrastructure
### Project Lead
```project-lead.yaml
Name: zk_nd3r
Role: Design, implementation, deployment, protocol docs
Background: Built and deployed ZAP1 on Zcash mainnet. Published zap1-verify and zcash-memo-decode to crates.io. ZIP draft under review.
Responsibilities: All deliverables
```
### Additional Team Members
Solo developer. All work is public at https://github.com/Frontier-Compute
### The problem
Zcash has no standard for structured data in shielded memos. If you need private payments with public verifiability - mining operators, staking services, subscription platforms, DAO governance - you either invent a custom binary format or write plaintext. Neither lets wallets, explorers, or third-party verifiers parse and validate commitments without application-specific code.
ZIP 302 defines the memo container but says nothing about application-layer payload types. There is no convention for typed events, deterministic hash construction, Merkle commitment, or on-chain anchoring of application state.
### The solution
ZAP1 is a production-tested attestation protocol for Zcash. Open-source, MIT-licensed. It defines:
- a structured memo envelope: version, event type, cohort, payload hash, timestamp
- deterministic BLAKE2b-256 hash construction with operator-configurable domain separation
- an append-only Merkle tree commitment scheme
- an on-chain anchoring procedure via shielded memos
- a verification procedure that needs only the proof bundle and chain access
Application-agnostic. Operators register their own event types within the shared envelope. Independent deployments use separate personalization strings for domain separation. Targets ZIP 302 compatibility as a future part type.
### What already exists
This is a hardening grant for a system already running on mainnet. Everything below shipped before this application:
| Artifact | Link |
|----------|------|
| Reference implementation (Rust, MIT) | [zap1](https://github.com/Frontier-Compute/zap1) |
| Verification SDK (Rust + WASM, 22 tests, 1 dep) | [crates.io/crates/zap1-verify](https://crates.io/crates/zap1-verify) |
| JS/TS SDK (19 tests) | [zap1-js](https://github.com/Frontier-Compute/zap1-js) |
| Universal memo decoder (23 tests, zero deps) | [crates.io/crates/zcash-memo-decode](https://crates.io/crates/zcash-memo-decode) |
| 4 mainnet anchors, 15 event types ([live count](https://pay.frontiercompute.io/stats)) | [anchor/history](https://pay.frontiercompute.io/anchor/history) |
| ZIP draft (PR #1243) | [zcash/zips#1243](https://github.com/zcash/zips/pull/1243) |
| Protocol spec (v2.2.0) | [ONCHAIN_PROTOCOL.md](https://github.com/Frontier-Compute/zap1/blob/main/ONCHAIN_PROTOCOL.md) |
| Test vectors (all deployed event types) | [TEST_VECTORS.md](https://github.com/Frontier-Compute/zap1/blob/main/TEST_VECTORS.md) |
| Browser verifier (WASM, zero server trust) | [verify.html](https://frontiercompute.io/verify.html) |
| Attestation explorer | [explorer.frontiercompute.io](https://explorer.frontiercompute.io) |
| Interactive simulator | [simulator.frontiercompute.io](https://simulator.frontiercompute.io) |
| FROST 2-of-3 threat model | [FROST_THREAT_MODEL.md](https://github.com/Frontier-Compute/zap1/blob/main/FROST_THREAT_MODEL.md) |
| Zaino compact block adapter | [zaino_adapter.rs](https://github.com/Frontier-Compute/zap1/blob/main/src/bin/zaino_adapter.rs) |
| Zaino gRPC validation on mainnet | [ZAINO_VALIDATION.md](https://github.com/Frontier-Compute/zap1/blob/main/ZAINO_VALIDATION.md) |
| ZIP 302 TVLV reference encoder/decoder | [zip302_tvlv.rs](https://github.com/Frontier-Compute/zap1/blob/main/src/bin/zip302_tvlv.rs) |
| Operator runbook | [OPERATOR_RUNBOOK.md](https://github.com/Frontier-Compute/zap1/blob/main/docs/OPERATOR_RUNBOOK.md) |
| Conformance kit (14 protocol checks) | [conformance/](https://github.com/Frontier-Compute/zap1/tree/main/conformance) |
| API schema validation (21 checks) | [check_api.py](https://github.com/Frontier-Compute/zap1/blob/main/conformance/check_api.py) |
| OpenAPI 3.0 spec (read-only surfaces) | [openapi.yaml](https://github.com/Frontier-Compute/zap1/blob/main/conformance/openapi.yaml) |
| Reference clients (Python, TypeScript) | [clients/](https://github.com/Frontier-Compute/zap1/tree/main/conformance/clients) |
| Consumer contracts (wallet, explorer, indexer, operator) | [contracts/](https://github.com/Frontier-Compute/zap1/tree/main/conformance/contracts) |
| Versioning policy | [VERSIONING.md](https://github.com/Frontier-Compute/zap1/blob/main/conformance/VERSIONING.md) |
| Cross-implementation hash vectors | [hash_vectors.json](https://github.com/Frontier-Compute/zap1/blob/main/conformance/hash_vectors.json) |
| Interactive API docs | [frontiercompute.io/api.html](https://frontiercompute.io/api.html) |
| CI green on all 7 repos | 108 tests + 57 automated checks |
One production deployment is live on mainnet. The grant funds the protocol layer, not any specific deployment.
### Verify the claims
```bash
# One command - clone and run 14 end-to-end checks
git clone https://github.com/Frontier-Compute/zap1.git && cd zap1 && bash scripts/evaluate.sh
# Or check surfaces directly:
curl -s https://pay.frontiercompute.io/protocol/info | python3 -m json.tool
curl -s https://pay.frontiercompute.io/anchor/history | python3 -m json.tool
curl -s https://pay.frontiercompute.io/verify/075b00df286038a7b3f6bb70054df61343e3481fba579591354a00214e9e019b/check
# Conformance: 14 protocol checks + 21 API schema checks
python3 conformance/check.py
python3 conformance/check_api.py
```
Full evaluator walkthrough: [EVALUATOR_QUICKSTART.md](https://github.com/Frontier-Compute/zap1/blob/main/EVALUATOR_QUICKSTART.md)
### What the grant funds
Protocol hardening and ecosystem integration. Three milestones, tranche-based, each independently testable.
### Milestone 1: Protocol hardening + FROST design package
- Amount: **$6,000**
- Duration: 4 weeks
- Acceptance: test vectors pass in an independent implementation. FROST migration doc published. Spec finalized as v3.0.
- Outputs:
- Finalize ONCHAIN_PROTOCOL.md as stable v3.0 with generalized event type registry
- ZIP 302 compatibility: define ZAP1 attestation as a ZIP 302 part type
- Expanded test vectors with cross-implementation validation instructions
- FROST threshold-signing design: migration path from single-operator to 2-of-3 anchor signing
- Security model and assumptions documented
- CONTRIBUTING.md following librustzcash style guides
### Milestone 2: Anchor hardening + operator tooling
- Amount: **$5,000**
- Duration: 4 weeks
- Acceptance: anchor retry with backoff is working. Failure alerting is operational. Any operator can deploy from the runbook.
- Outputs:
- Exponential backoff on anchor broadcast failure
- Failure alerting (webhook-based, operator-configurable)
- Operator observability: anchor history, success rate, staleness monitoring
- Published operator runbook tested against a fresh deployment
- Manual fallback path preserved and documented
### Milestone 3: Zaino compact-block scanner integration
- Amount: **$7,000**
- Duration: 4 weeks
- Acceptance: a Zaino-backed scanner path is validated, or a working adapter plus integration guide is published and tested against recorded compact-block data.
- Outputs:
- Scanner integration or adapter using Zaino CompactTxStreamer gRPC interface
- Operational comparison: per-block RPC polling vs compact-block streaming
- Validation on testnet and mainnet-compatible staging
- Integration guide reusable by other Z3 stack applications (Zebra + Zaino + Zallet)
### Total
**$18,000 over 3 months.** Tranche-based. Each milestone evaluated before payment.
### Technical approach
- ZAP1 memo envelope: BLAKE2b-256 payload hashing with configurable domain separation
- Transitional `ZAP1:{type}:{payload}` encoding, targeting ZIP 302 part type when the container ships
- Append-only Merkle tree with separate leaf and node personalization
- Shielded memo anchoring with configurable threshold and interval
- `NodeBackend` trait abstracts Zebra RPC and Zaino gRPC for scanner portability
- `zap1-verify`: single dependency (`blake2b_simd`), compiles to native and WASM
- `zcash-memo-decode`: universal decoder, identifies ZAP1, ZIP 302 TVLV, plain text, binary, and empty memos with zero dependencies
### Who benefits
- **Wallet developers**: identify and display ZAP1 memos without per-application logic
- **Explorer operators**: structured memo parsing for attestation transactions
- **Mining operators**: lifecycle attestation for hardware programs
- **Staking services**: event commitment when Crosslink ships
- **Any builder** that needs "private payments + public verifiability" on Zcash
### Risks
1. **Zaino scanner API assumptions.** Mitigation: current scanner stays operational. Adapter path delivered if full integration hits blockers.
2. **FROST upstream APIs not production-ready for Orchard signing.** Mitigation: design package and migration doc delivered regardless. Live signing is upside, not a dependency.
### Post-grant
Maintenance continues under MIT license. The verification SDK has one dependency (`blake2b_simd`) and compiles to 83KB WASM. Maintenance cost is low by design.
If Phase 1 milestones clear, a follow-up application would cover cross-application structured memo tooling (ZIP 302 part types for operational attestation), credential derivation from attestation history, and DAO formation tooling for Zcash-native organizations.
### Community Forums Discussion
[Grant Application: ZAP1 Protocol Hardening and Zaino Integration](https://forum.zcashcommunity.com/t/grant-application-zap1-protocol-hardening-and-zaino-integration/55165)
This submission is narrower. It is routed through the Coinholder-Directed Retroactive Grants process because the work is now completed and publicly verifiable.
It does not ask for future hardening, third-party integrations, adoption work, or new milestones.
This application is for completed ZAP1 infrastructure and verification tooling only.
It is not a request for future Zush work or any future product-specific deployment.
No customer rows, viewing keys, custody claims, or private payment records are required to evaluate the work.
Kindest,