### 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)
Leon sage
### Organization Name
Leon sage
### How did you learn about Zcash Community Grants
Recommend by Jason mcgee
### Requested Grant Amount (USD)
175000
### Category
Zcash Protocol Extension
### Project Lead
```project-lead.yaml
Name:leon sage
Role:Development
Background:self taught
Responsibilities:Development and aquire team members
```
### Additional Team Members
```team-members.yaml
- Name:
Role:
Background:
Responsibilities:
- Name:
Role:
Background:
Responsibilities:
- Name:
Role:
Background:
Responsibilities:
- Name:
Role:
Background:
Responsibilities:
- Name:
Role:
Background:
Responsibilities:
- Name:
Role:
Background:
Responsibilities:
```
### Project Summary
# Zcash Confidential Bridge to Ethereum: ZK-Powered ERC-20 Grant Proposal
## Project Overview
This proposal seeks $175,000 USD (approximately 739 ZEC at $236.78/ZEC) from Zcash Community Grants to develop a confidential, non-custodial bridge enabling ZEC holders to access Ethereum DeFi while maintaining complete privacy. The core technology is a Confidential ERC-20 Token (wZEC) built using a custom Circom circuit leveraging Zero-Knowledge Proofs to enable shielded transfers and balances on Ethereum.
## Problem Statement
While Zcash offers unparalleled on-chain privacy, its utility in Ethereum's expansive DeFi ecosystem is limited by existing bridges that reveal transaction values and account balances, breaking Zcash's core value proposition when assets transfer off-chain.
## Technical Solution
We will develop a system where ZEC is locked in a vault on the Zcash chain with corresponding wZEC minted on Ethereum. This wZEC is governed by a Zero-Knowledge Proof system using a UTXO-style commitment model implemented via Merkle Tree. All wZEC transactions require valid ZK-SNARK proofs generated by our ConfidentialERC20Token circuit, ensuring shielded balances where user balances are hidden as cryptographic commitments, private transfers where transaction amounts and recipients remain secret, and non-custodial security through verifiable ZK proofs rather than trusted third parties.
## Core Technology: ConfidentialERC20Token Circuit
The cryptographic foundation is our production-ready Circom implementation supporting confidential transfer, transferFrom, approve, balanceOf, allowance, mint, and burn operations. The circuit uses a 20-level Merkle tree managing state commitments securely, supporting over one million accounts efficiently.
The circuit accepts public inputs including function selector, current Merkle root representing global state, total token supply, token metadata, transaction hash, and participant addresses. Private inputs include actual balances, secrets, nullifiers, and Merkle paths required to generate and validate shielded commitments. This separation keeps sensitive information hidden while enabling public verification.
For transfers, the circuit computes the sender's commitment by hashing their balance with secret and transaction hash, verifies this commitment exists in the Merkle root via cryptographic proof, checks sufficient balance, generates a unique nullifier preventing double-spending, creates the recipient's new commitment, and calculates the sender's updated balance. All validation checks combine into a single verification signal. Valid transactions output new commitments for Merkle tree insertion.
The transferFrom operation verifies both owner's balance and existing allowance commitments, checking sufficient balance and allowance before generating new commitments. The approve function validates owner's balance and generates allowance commitments binding spender addresses to approved amounts. View functions return encrypted commitments without revealing private information. Mint and burn operations create or destroy tokens while maintaining state consistency.
All cryptographic primitives use Poseidon hashing for commitments and nullifiers. Merkle proof verification ensures state transitions are valid without revealing actual balances or secrets. The circuit enforces arithmetic constraints ensuring balances remain non-negative and uses logical combinators guaranteeing every condition for valid transactions is satisfied before allowing state changes.
Circuit outputs include a verified flag indicating whether operations passed all checks, new commitment leaves representing updated balances or allowances ready for Merkle tree insertion, and result values for view functions.
## System Architecture
The complete system comprises a Zcash Vault/Multisig securely holding underlying ZEC in an unshielded pool, an Oracle/Relayer Network initially centralized but aiming for decentralized governance that observes ZEC deposits, triggers wZEC minting on Ethereum, and generates computationally intensive ZK-SNARK proofs for all shielded wZEC transactions, and EVM Smart Contracts including a Verifier Contract storing trusted setup keys and the wZEC Token Contract allowing state changes only with valid proofs.
## Milestones and Timeline (22 weeks)
**Milestone 1 (4 weeks, 20% payout):** Circuit Finalization and Powers of Tau Setup delivers finalized Circom circuit, completion of open Powers of Tau ceremony, and generation of Trusted Setup parameters. The immediate critical next step is initiating a transparent Powers of Tau multi-party computation ceremony essential for securely generating public parameters for ZK-SNARK trusted setup, ensuring the verification key used on Ethereum is secure and trustless with coordinated open participation and auditability.
**Milestone 2 (6 weeks, 30% payout):** EVM Bridge Contracts and Merkle Logic implements wZEC Token Contract, Merkle Tree State Manager, and Verifier contracts on Ethereum testnet.
**Milestone 3 (6 weeks, 30% payout):** Relayer and Proof Generation Engine develops off-chain relayer monitoring Zcash deposits and generating ZK-SNARK proofs for EVM transactions.
**Milestone 4 (4 weeks, 10% payout):** Security Audit and Testnet Deployment provides full security audit of Circom and Solidity code with successful deployment and stress-testing on Sepolia testnet.
**Milestone 5 (2 weeks, 10% payout):** Documentation and Open-Source Release delivers public open-source repository, comprehensive developer guides, final report, and community demo.
## Budget Breakdown ($175,000 USD / ~739 ZEC)
Development and Engineering for Milestones 1-3: $80,000 (~338 ZEC) compensating 4-5 months of ZK Cryptography and Solidity engineering. Relayer and Infrastructure for Milestone 3: $30,000 (~127 ZEC) building multi-chain relayer for Zcash monitoring and off-chain ZK proof generation. Security Audit for Milestone 4: $35,000 (~148 ZEC) for mandatory audit by reputable firm specializing in ZK circuits and bridge security. Gas and Deployment Fees: $15,000 (~63 ZEC) for deployment, proving, and transaction fees on Ethereum Mainnet and Testnets. Contingency and Documentation for Milestone 5: $15,000 (~63 ZEC) for risk mitigation, project management, and final documentation and outreach.
## Impact on Zcash Ecosystem
This project delivers expanded utility immediately enabling ZEC holders to engage in private DeFi activities on Ethereum and layer-2s such as shielded collateral or liquidity provision. It serves as compelling real-world demonstration of how ZK-SNARKs bolt privacy onto transparent blockchains, reinforcing Zcash's technological leadership. By adhering to ERC-20 standards while maintaining confidentiality, wZEC seamlessly interacts with thousands of existing protocols, significantly increasing visibility and demand for ZEC across the broader cryptocurrency ecosystem.
### Project Description
Confidential ERC20 Token: Zero-Knowledge Circuit Architecture
Executive Overview
The ConfidentialERC20Token circuit is a privacy-preserving implementation of an ERC-20 token using zero-knowledge proofs. It enables confidential transfers, approvals, minting, and burning while maintaining full compatibility with Ethereum's token standard. User balances and transaction amounts remain completely hidden, yet every operation is cryptographically verified as valid.
Architecture Foundation
The circuit manages encrypted state using a 20-level Merkle tree. Each user's balance is represented as a cryptographic commitment—a hash binding their balance to a secret only they know. The global state of all balances is compressed into a single Merkle root. Every transaction proves it correctly transforms one valid state into another without revealing underlying data.
Inputs are divided into public and private categories. Public inputs include the function selector, Merkle root, transaction hash, and participant addresses. Private inputs contain actual balances, secrets, nullifiers, and Merkle proofs. This separation keeps sensitive information hidden while enabling public verification.
Transfer Operation
finance.
### Proposed Problem
When executing a transfer, the circuit first computes the sender's commitment by hashing their balance, secret, and transaction hash. It verifies this commitment exists in the Merkle tree using the provided proof. The circuit then checks the sender has sufficient balance for the transfer.
Next, it generates a nullifier—a unique identifier for this specific spend that prevents the same funds from being transferred twice. The circuit verifies the provided nullifier matches the computed one. It then creates the recipient's new commitment incorporating the transferred amount and computes the sender's updated balance commitment.
Finally, the circuit performs comprehensive validation checks: Merkle proof validity, sufficient balance, correct nullifier, positive transfer amount, and distinct sender and recipient addresses. If all checks pass, it outputs two new commitments ready for insertion into the Merkle tree.
TransferFrom and Approve
The transferFrom operation extends the transfer logic by validating allowances. It verifies both the owner's balance commitment and the existing allowance commitment. The circuit checks that both the owner's balance and the approved allowance are sufficient for the transfer. It generates new commitments for the owner's updated balance and the reduced allowance.
The approve function creates an allowance by validating the owner's balance commitment and generating a new allowance commitment. This commitment binds the spender's address to the approved amount using the owner's secret, ensuring only authorized parties can utilize the approval.
Mint and Burn Operations
Minting creates new tokens by verifying the caller is authorized and computing a commitment for the newly created tokens. The circuit ensures the total supply increases correctly and generates a commitment representing the minted balance.
Burning removes tokens by verifying the owner's commitment, checking sufficient balance, and generating a nullifier to prevent double-burning. The circuit computes a new commitment reflecting the reduced balance and ensures the total supply decreases appropriately.
View Functions
The circuit supports read-only operations including balanceOf, allowance, totalSupply, and token metadata queries. These functions return encrypted commitments or public metadata without revealing private information. They provide necessary transparency while preserving confidentiality.
Cryptographic Primitives
All commitments and nullifiers use Poseidon hashing, a zero-knowledge-friendly hash function optimized for circuit efficiency. Commitment structure follows the pattern: hash of balance, secret, and transaction hash. Nullifier structure uses: hash of secret, amount, and transaction hash. This design prevents linkability between commitments while enabling double-spend prevention.
Merkle proof verification ensures state transitions are valid without exposing the tree's contents. The circuit verifies each level of the proof, confirming the leaf exists at the claimed position in the tree represented by the public Merkle root.
Verification Logic
The circuit employs logical combinators to enforce all constraints simultaneously. Each operation computes a verification signal indicating whether all conditions are satisfied. The final output includes a verified flag set to one if valid or zero if any check fails.
The circuit also outputs new commitment leaves representing updated balances or allowances ready for Merkle tree insertion. For view functions, it provides a result value containing the requested information. This structure enables the Ethereum smart contract to apply state changes only when verification succeeds.
Security Guarantees
The circuit prevents double-spending through nullifier tracking. Each spend generates a unique nullifier that must not exist in previous transactions. The circuit enforces balance non-negativity through range checks and arithmetic constraints. All operations require valid Merkle proofs, ensuring users can only spend funds they actually possess.
Privacy is absolute because actual balances and amounts never appear in public signals. Only commitments and nullifiers are visible on-chain, revealing no information about underlying values. The zero-knowledge proof confirms validity without exposing witness data.
Integration with Ethereum
The circuit generates proofs that Ethereum smart contracts verify on-chain. When a user submits a transaction, they generate a proof locally using their private inputs. The verifier contract checks the proof against public inputs and the current Merkle root. If verification succeeds, the contract updates the Merkle root by inserting the new commitments and records the nullifier to prevent reuse.
This architecture maintains ERC-20 compatibility while adding confidentiality. External contracts can interact with the token through standard interfaces, though they observe only encrypted state transitions. The verifier contract acts as the on-chain enforcement layer, ensuring all state changes are cryptographically valid.
Production Readiness
The circuit is fully optimized for production deployment. All constraints are properly bounded, preventing overflow and underflow vulnerabilities. The Merkle tree depth of twenty levels supports over one million accounts efficiently. Circuit size is optimized to generate proofs quickly while maintaining security.
The implementation supports gas-efficient verification on Ethereum through optimized verifier contracts. Proof generation occurs off-chain, minimizing on-chain costs. The circuit design allows batching multiple operations into single proofs for improved efficiency.
This zero-knowledge ERC-20 implementation delivers unprecedented privacy for token holders while preserving the composability and functionality that makes ERC-20 the foundation of decentralized finance.
### Proposed Solution
## Impact on Zcash Ecosystem
This project delivers expanded utility immediately enabling ZEC holders to engage in private DeFi activities on Ethereum and layer-2s such as shielded collateral or liquidity provision. It serves as compelling real-world demonstration of how ZK-SNARKs bolt privacy onto transparent blockchains, reinforcing Zcash's technological leadership. By adhering to ERC-20 standards while maintaining confidentiality, wZEC seamlessly interacts with thousands of existing protocols, significantly increasing visibility and demand for ZEC across the broader cryptocurrency ecosystem.
### Solution Format
# Zcash Confidential Bridge to Ethereum: ZK-Powered ERC-20 Grant Proposal
## Project Overview
This proposal seeks $175,000 USD (approximately 739 ZEC at $236.78/ZEC) from Zcash Community Grants to develop a confidential, non-custodial bridge enabling ZEC holders to access Ethereum DeFi while maintaining complete privacy. The core technology is a Confidential ERC-20 Token (wZEC) built using a custom Circom circuit leveraging Zero-Knowledge Proofs to enable shielded transfers and balances on Ethereum.
## Problem Statement
While Zcash offers unparalleled on-chain privacy, its utility in Ethereum's expansive DeFi ecosystem is limited by existing bridges that reveal transaction values and account balances, breaking Zcash's core value proposition when assets transfer off-chain.
## Technical Solution
We will develop a system where ZEC is locked in a vault on the Zcash chain with corresponding wZEC minted on Ethereum. This wZEC is governed by a Zero-Knowledge Proof system using a UTXO-style commitment model implemented via Merkle Tree. All wZEC transactions require valid ZK-SNARK proofs generated by our ConfidentialERC20Token circuit, ensuring shielded balances where user balances are hidden as cryptographic commitments, private transfers where transaction amounts and recipients remain secret, and non-custodial security through verifiable ZK proofs rather than trusted third parties.
## Core Technology: ConfidentialERC20Token Circuit
The cryptographic foundation is our production-ready Circom implementation supporting confidential transfer, transferFrom, approve, balanceOf, allowance, mint, and burn operations. The circuit uses a 20-level Merkle tree managing state commitments securely, supporting over one million accounts efficiently.
The circuit accepts public inputs including function selector, current Merkle root representing global state, total token supply, token metadata, transaction hash, and participant addresses. Private inputs include actual balances, secrets, nullifiers, and Merkle paths required to generate and validate shielded commitments. This separation keeps sensitive information hidden while enabling public verification.
For transfers, the circuit computes the sender's commitment by hashing their balance with secret and transaction hash, verifies this commitment exists in the Merkle root via cryptographic proof, checks sufficient balance, generates a unique nullifier preventing double-spending, creates the recipient's new commitment, and calculates the sender's updated balance. All validation checks combine into a single verification signal. Valid transactions output new commitments for Merkle tree insertion.
The transferFrom operation verifies both owner's balance and existing allowance commitments, checking sufficient balance and allowance before generating new commitments. The approve function validates owner's balance and generates allowance commitments binding spender addresses to approved amounts. View functions return encrypted commitments without revealing private information. Mint and burn operations create or destroy tokens while maintaining state consistency.
All cryptographic primitives use Poseidon hashing for commitments and nullifiers. Merkle proof verification ensures state transitions are valid without revealing actual balances or secrets. The circuit enforces arithmetic constraints ensuring balances remain non-negative and uses logical combinators guaranteeing every condition for valid transactions is satisfied before allowing state changes.
Circuit outputs include a verified flag indicating whether operations passed all checks, new commitment leaves representing updated balances or allowances ready for Merkle tree insertion, and result values for view functions.
## the broader cryptocurrency ecosystem.
### Dependencies
Zcash support and community
### Technical Approach
Confidential ERC20 Token: Zero-Knowledge Circuit Architecture
Executive Overview
The ConfidentialERC20Token circuit is a privacy-preserving implementation of an ERC-20 token using zero-knowledge proofs. It enables confidential transfers, approvals, minting, and burning while maintaining full compatibility with Ethereum's token standard. User balances and transaction amounts remain completely hidden, yet every operation is cryptographically verified as valid.
Architecture Foundation
The circuit manages encrypted state using a 20-level Merkle tree. Each user's balance is represented as a cryptographic commitment—a hash binding their balance to a secret only they know. The global state of all balances is compressed into a single Merkle root. Every transaction proves it correctly transforms one valid state into another without revealing underlying data.
Inputs are divided into public and private categories. Public inputs include the function selector, Merkle root, transaction hash, and participant addresses. Private inputs contain actual balances, secrets, nullifiers, and Merkle proofs. This separation keeps sensitive information hidden while enabling public verification.
Transfer Operation
### Upstream Merge Opportunities
I may be able to later create a zkfork with kaia
### Hardware/Software Costs (USD)
175000
### Hardware/Software Justification
The overall budget will include and compensate for everything necessary for development testing and deployment gas fees was my biggest hurdle because of my financial situation so I will allocate for everything with the amount given for the grant I may be under shooting or underscoring but if anything I will reach out but that's what my calculations detail
### Service Costs (USD)
175000
### Service Costs Justification
## Budget Breakdown ($175,000 USD / ~739 ZEC)
Development and Engineering for Milestones 1-3: $80,000 (~338 ZEC) compensating 4-5 months of ZK Cryptography and Solidity engineering. Relayer and Infrastructure for Milestone 3: $30,000 (~127 ZEC) building multi-chain relayer for Zcash monitoring and off-chain ZK proof generation. Security Audit for Milestone 4: $35,000 (~148 ZEC) for mandatory audit by reputable firm specializing in ZK circuits and bridge security. Gas and Deployment Fees: $15,000 (~63 ZEC) for deployment, proving, and transaction fees on Ethereum Mainnet and Testnets. Contingency and Documentation for Milestone 5: $15,000 (~63 ZEC) for risk mitigation, project management, and final documentation and outreach.
## Impact on Zcash Ecosystem
### Compensation Costs (USD)
175,000
### Compensation Costs Justification
# Zcash Confidential Bridge to Ethereum: ZK-Powered ERC-20 Grant Proposal
## Project Overview
This proposal seeks $175,000 USD (approximately 739 ZEC at $236.78/ZEC) from Zcash Community Grants to develop a confidential, non-custodial bridge enabling ZEC holders to access Ethereum DeFi while maintaining complete privacy. The core technology is a Confidential ERC-20 Token (wZEC) built using a custom Circom circuit leveraging Zero-Knowledge Proofs to enable shielded transfers and balances on Ethereum.
## Problem Statement
While Zcash offers unparalleled on-chain privacy, its utility in Ethereum's expansive DeFi ecosystem is limited by existing bridges that reveal transaction values and account balances, breaking Zcash's core value proposition when assets transfer off-chain.
## Technical Solution
We will develop a system where ZEC is locked in a vault on the Zcash chain with corresponding wZEC minted on Ethereum. This wZEC is governed by a Zero-Knowledge Proof system using a UTXO-style commitment model implemented via Merkle Tree. All wZEC transactions require valid ZK-SNARK proofs generated by our ConfidentialERC20Token circuit, ensuring shielded balances where user balances are hidden as cryptographic commitments, private transfers where transaction amounts and recipients remain secret, and non-custodial security through verifiable ZK proofs rather than trusted third parties.
## Core Technology: ConfidentialERC20Token Circuit
The cryptographic foundation is our production-ready Circom implementation supporting confidential transfer, transferFrom, approve, balanceOf, allowance, mint, and burn operations. The circuit uses a 20-level Merkle tree managing state commitments securely, supporting over one million accounts efficiently.
The circuit accepts public inputs including function selector, current Merkle root representing global state, total token supply, token metadata, transaction hash, and participant addresses. Private inputs include actual balances, secrets, nullifiers, and Merkle paths required to generate and validate shielded commitments. This separation keeps sensitive information hidden while enabling public verification.
For transfers, the circuit computes the sender's commitment by hashing their balance with secret and transaction hash, verifies this commitment exists in the Merkle root via cryptographic proof, checks sufficient balance, generates a unique nullifier preventing double-spending, creates the recipient's new commitment, and calculates the sender's updated balance. All validation checks combine into a single verification signal. Valid transactions output new commitments for Merkle tree insertion.
The transferFrom operation verifies both owner's balance and existing allowance commitments, checking sufficient balance and allowance before generating new commitments. The approve function validates owner's balance and generates allowance commitments binding spender addresses to approved amounts. View functions return encrypted commitments without revealing private information. Mint and burn operations create or destroy tokens while maintaining state consistency.
All cryptographic primitives use Poseidon hashing for commitments and nullifiers. Merkle proof verification ensures state transitions are valid without revealing actual balances or secrets. The circuit enforces arithmetic constraints ensuring balances remain non-negative and uses logical combinators guaranteeing every condition for valid transactions is satisfied before allowing state changes.
Circuit outputs include a verified flag indicating whether operations passed all checks, new commitment leaves representing updated balances or allowances ready for Merkle tree insertion, and result values for view functions.
## System Architecture
The complete system comprises a Zcash Vault/Multisig securely holding underlying ZEC in an unshielded pool, an Oracle/Relayer Network initially centralized but aiming for decentralized governance that observes ZEC deposits, triggers wZEC minting on Ethereum, and generates computationally intensive ZK-SNARK proofs for all shielded wZEC transactions, and EVM Smart Contracts including a Verifier Contract storing trusted setup keys and the wZEC Token Contract allowing state changes only with valid proofs.
## Milestones and Timeline (22 weeks)
**Milestone 1 (4 weeks, 20% payout):** Circuit Finalization and Powers of Tau Setup delivers finalized Circom circuit, completion of open Powers of Tau ceremony, and generation of Trusted Setup parameters. The immediate critical next step is initiating a transparent Powers of Tau multi-party computation ceremony essential for securely generating public parameters for ZK-SNARK trusted setup, ensuring the verification key used on Ethereum is secure and trustless with coordinated open participation and auditability.
**Milestone 2 (6 weeks, 30% payout):** EVM Bridge Contracts and Merkle Logic implements wZEC Token Contract, Merkle Tree State Manager, and Verifier contracts on Ethereum testnet.
**Milestone 3 (6 weeks, 30% payout):** Relayer and Proof Generation Engine develops off-chain relayer monitoring Zcash deposits and generating ZK-SNARK proofs for EVM transactions.
**Milestone 4 (4 weeks, 10% payout):** Security Audit and Testnet Deployment provides full security audit of Circom and Solidity code with successful deployment and stress-testing on Sepolia testnet.
**Milestone 5 (2 weeks, 10% payout):** Documentation and Open-Source Release delivers public open-source repository, comprehensive developer guides, final report, and community demo.
## Budget Breakdown ($175,000 USD / ~739 ZEC)
Development and Engineering for Milestones 1-3: $80,000 (~338 ZEC) compensating 4-5 months of ZK Cryptography and Solidity engineering. Relayer and Infrastructure for Milestone 3: $30,000 (~127 ZEC) building multi-chain relayer for Zcash monitoring and off-chain ZK proof generation. Security Audit for Milestone 4: $35,000 (~148 ZEC) for mandatory audit by reputable firm specializing in ZK circuits and bridge security. Gas and Deployment Fees: $15,000 (~63 ZEC) for deployment, proving, and transaction fees on Ethereum Mainnet and Testnets. Contingency and Documentation for Milestone 5: $15,000 (~63 ZEC) for risk mitigation, project management, and final documentation and outreach.
## Impact on Zcash Ecosystem
This project delivers expanded utility immediately enabling ZEC holders to engage in private DeFi activities on Ethereum and layer-2s such as shielded collateral or liquidity provision. It serves as compelling real-world demonstration of how ZK-SNARKs bolt privacy onto transparent blockchains, reinforcing Zcash's technological leadership. By adhering to ERC-20 standards while maintaining confidentiality, wZEC seamlessly interacts with thousands of existing protocols, significantly increasing visibility and demand for ZEC across the broader cryptocurrency ecosystem.
### Total Budget (USD)
175000
### Previous Funding
No
### Previous Funding Details
_No response_
### Other Funding Sources
No
### Other Funding Sources Details
No other plans for funding from other sources truth be told I was planning this project on my own but did not realize the lack of funding prevented the like a funds basically played ties and limiting the testing building deployment phase so might as well work with the best in the game so I reached out
### Implementation Risks
Circuit capillin verifying nullifier transactions and security of the most complete and complicated aspects of this whole journey so that's why rigorous testing and fuzzing before deployment is needed no room for error when dealing with monetary values tokens and people's money so all points of access and entry and ownership and transactions and validation and everything will be regularly tested
### Potential Side Effects
Complicated testing
### Success Metrics
At the rigorous testing on local testing and chestnuts after hardcore fuzzing for safety to make sure all things are covered no vulnerability aspects are exposed deployment of such completed contract will signify completion but it will all be on a page with the team truly can actually hopefully utilize insight and expertise from the community when necessary for user inputs on what would they like to see while in the creation aspect or development aspect but as I stated clearly it would be the what would they like to see while in the creation aspect or development aspect but as I stated clearly it would be the deployment incompletion of the project fully functioning on the on the blockchain
### Startup Funding (USD)
175,000
### Startup Funding Justification
# Zcash Confidential Bridge to Ethereum: ZK-Powered ERC-20 Grant Proposal
## Project Overview
This proposal seeks $175,000 USD (approximately 739 ZEC at $236.78/ZEC) from Zcash Community Grants to develop a confidential, non-custodial bridge enabling ZEC holders to access Ethereum DeFi while maintaining complete privacy. The core technology is a Confidential ERC-20 Token (wZEC) built using a custom Circom circuit leveraging Zero-Knowledge Proofs to enable shielded transfers and balances on Ethereum.
## demand for ZEC across the broader cryptocurrency ecosystem.
### Milestone Details
```milestones.yaml
- Milestone: 1
Amount (USD): 0
Expected Completion Date: 2026-11-13
User Stories:
- "As a [type of user], I want [some goal], so that [some reason]"
- "As a [different type of user], I want [some goal], so that [some reason]" (optional - add more as needed)
Deliverables:
- [List specific deliverables that fulfill the user stories]
- [Each deliverable should clearly address one or more user stories]
Acceptance Criteria: [How will the target users validate this milestone is complete?]
- Milestone: 2
Amount (USD): 0
Expected Completion Date: YYYY-MM-DD
User Stories:
- "As a [type of user], I want [some goal], so that [some reason]"
- "As a [different type of user], I want [some goal], so that [some reason]" (optional - add more as needed)
Deliverables:
- [List specific deliverables that fulfill the user stories]
- [Each deliverable should clearly address one or more user stories]
Acceptance Criteria: [How will the target users validate this milestone is complete?]
- Milestone: 3
Amount (USD): 0
Expected Completion Date: YYYY-MM-DD
User Stories:
- "As a [type of user], I want [some goal], so that [some reason]"
- "As a [different type of user], I want [some goal], so that [some reason]" (optional - add more as needed)
Deliverables:
- [List specific deliverables that fulfill the user stories]
- [Each deliverable should clearly address one or more user stories]
Acceptance Criteria: [How will the target users validate this milestone is complete?]
- Milestone: 4
Amount (USD): 0
Expected Completion Date: YYYY-MM-DD
User Stories:
- "As a [type of user], I want [some goal], so that [some reason]"
- "As a [different type of user], I want [some goal], so that [some reason]" (optional - add more as needed)
Deliverables:
- [List specific deliverables that fulfill the user stories]
- [Each deliverable should clearly address one or more user stories]
Acceptance Criteria: [How will the target users validate this milestone is complete?]
- Milestone: 5
Amount (USD): 0
Expected Completion Date: YYYY-MM-DD
User Stories:
- "As a [type of user], I want [some goal], so that [some reason]"
- "As a [different type of user], I want [some goal], so that [some reason]" (optional - add more as needed)
Deliverables:
- [List specific deliverables that fulfill the user stories]
- [Each deliverable should clearly address one or more user stories]
Acceptance Criteria: [How will the target users validate this milestone is complete?]
- Milestone: 6
Amount (USD): 0
Expected Completion Date: YYYY-MM-DD
User Stories:
- "As a [type of user], I want [some goal], so that [some reason]"
- "As a [different type of user], I want [some goal], so that [some reason]" (optional - add more as needed)
Deliverables:
- [List specific deliverables that fulfill the user stories]
- [Each deliverable should clearly address one or more user stories]
Acceptance Criteria: [How will the target users validate this milestone is complete?]
- Milestone: 7
Amount (USD): 0
Expected Completion Date: YYYY-MM-DD
User Stories:
- "As a [type of user], I want [some goal], so that [some reason]"
- "As a [different type of user], I want [some goal], so that [some reason]" (optional - add more as needed)
Deliverables:
- [List specific deliverables that fulfill the user stories]
- [Each deliverable should clearly address one or more user stories]
Acceptance Criteria: [How will the target users validate this milestone is complete?]
- Milestone: 8
Amount (USD): 0
Expected Completion Date: YYYY-MM-DD
User Stories:
- "As a [type of user], I want [some goal], so that [some reason]"
- "As a [different type of user], I want [some goal], so that [some reason]" (optional - add more as needed)
Deliverables:
- [List specific deliverables that fulfill the user stories]
- [Each deliverable should clearly address one or more user stories]
Acceptance Criteria: [How will the target users validate this milestone is complete?]
- Milestone: 9
Amount (USD): 0
Expected Completion Date: YYYY-MM-DD
User Stories:
- "As a [type of user], I want [some goal], so that [some reason]"
- "As a [different type of user], I want [some goal], so that [some reason]" (optional - add more as needed)
Deliverables:
- [List specific deliverables that fulfill the user stories]
- [Each deliverable should clearly address one or more user stories]
Acceptance Criteria: [How will the target users validate this milestone is complete?]
- Milestone: 10
Amount (USD): 0
Expected Completion Date: YYYY-MM-DD
User Stories:
- "As a [type of user], I want [some goal], so that [some reason]"
- "As a [different type of user], I want [some goal], so that [some reason]" (optional - add more as needed)
Deliverables:
- [List specific deliverables that fulfill the user stories]
- [Each deliverable should clearly address one or more user stories]
Acceptance Criteria: [How will the target users validate this milestone is complete?]
- Milestone: 11
Amount (USD): 0
Expected Completion Date: YYYY-MM-DD
User Stories:
- "As a [type of user], I want [some goal], so that [some reason]"
- "As a [different type of user], I want [some goal], so that [some reason]" (optional - add more as needed)
Deliverables:
- [List specific deliverables that fulfill the user stories]
- [Each deliverable should clearly address one or more user stories]
Acceptance Criteria: [How will the target users validate this milestone is complete?]
- Milestone: 12
Amount (USD): 0
Expected Completion Date: YYYY-MM-DD
User Stories:
- "As a [type of user], I want [some goal], so that [some reason]"
- "As a [different type of user], I want [some goal], so that [some reason]" (optional - add more as needed)
Deliverables:
- [List specific deliverables that fulfill the user stories]
- [Each deliverable should clearly address one or more user stories]
Acceptance Criteria: [How will the target users validate this milestone is complete?]
```
### Supporting Documents
```files.yaml
- File Name 1: Brief description of the file contents
- File Name 2: Brief description of the file contents
I keep all files private so no one beat me to the punch i can share anything with jason for necessary transparency it is a brutal market and this opportunity is one to only be shown to team
```