### 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)
@andreudumitro-eng
### Organization Name
Andrii Dumitro (Sole Developer)
### How did you learn about Zcash Community Grants
Through research on blockchain consensus innovation and Zcash's community grants program. I am familiar with Zcash's focus on ASIC resistance and decentralization.
### Requested Grant Amount (USD)
75000
### Category
Research & Development
### Project Lead
```project-lead.yaml
Name:Andrii Dumitro
Role:Founder, Lead Protocol Architect & Sole Developer
Background:Blockchain protocol designer and Rust systems developer with focus on consensus mechanisms and ASIC-resistant Proof-of-Work. Author of ACCUM v3.2+ full specification and reference implementation. Experience in:
- Cryptographic primitives: Argon2id, SHA256, secp256k1, Merkle trees
- Systems programming: Rust, memory safety, zero-copy deserialization
- Storage engines: RocksDB, column families, backup/recovery systems
- Networking: TCP/IP, async I/O (tokio), P2P protocol design
- Security: DDoS protection, rate limiting, attack detection systems
Responsibilities:- Core protocol architecture and consensus algorithm design
- Fair Proof-of-Contribution (F-PoC) implementation
- Full protocol specification maintenance
- Code review and quality assurance for all contributions
- Technical documentation
- Hiring and mentoring additional developers (Rust/P2P, cryptography)
- Coordination with security auditors
- Mainnet launch coordination
```
### Additional Team Members
```team-members.yaml
- Name:- Name: To be hired (Rust/P2P Developer)
Role: P2P Network Engineer
Background: Experience with Rust, tokio async runtime, P2P networking, and blockchain synchronization protocols. Familiar with DNS seed discovery, peer handshake protocols, and sync manager implementations.
Responsibilities:
- DNS seed discovery implementation
- Peer handshake and connection management
- Block and share propagation
- Sync manager with timeout handling and peer fallback
- Rate limiting and DDoS protection enhancements
- Name: To be hired (Cryptography/Security Developer)
Role: Wallet & Security Engineer
Background: Cryptography, secp256k1, ECDSA, transaction handling, security audit experience. Familiar with UTXO models, wallet implementations, and security hardening.
Responsibilities:
- CLI wallet implementation
- Transaction signing and verification
- Security review and hardening
- Audit preparation and coordination
- Name: To be hired (external)
Role: Security Auditor
Background: Blockchain security audit experience with focus on consensus correctness, memory safety, and cryptographic implementations.
Responsibilities:
- Third-party security audit of all core code
- Vulnerability assessment and reporting
- Verification of fixes for critical issues
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
ACCUM is an independent blockchain protocol exploring Fair Proof-of-Contribution (F-PoC) consensus β a new approach to Proof-of-Work that distributes rewards based on computational work (60%), long-term participation (20%), and economic commitment (20%).
β οΈ Project Status: ACCUM is in active development (70% complete). The core protocol is functional and tested, but P2P networking and wallet components are under construction. As with any experimental blockchain protocol, there may be bugs, edge cases, or unexpected issues during development and testing. All code will be thoroughly tested and audited before mainnet launch.
Core Formula:
PoCI_i = 0.6 Γ norm_shares_i + 0.2 Γ norm_loyalty_i + 0.2 Γ norm_bond_i
Where:
- norm_shares_i = βshares_i / maxβshares (square root prevents dominance)
- norm_loyalty_i = loyalty_i / max_loyalty (participation: +1 per epoch, decay Γ0.7 when absent)
- norm_bond_i = βbond_i / maxβbond (minimum 1 ACM locked for 14 days)
Reward Distribution per Epoch (1440 blocks, 24 hours):
reward_i = (PoCI_i / Ξ£ PoCI) Γ (72 ACM + tx_fees)
Current Status (4,300+ lines of Rust):
- β
Argon2id PoW with 256 MB memory, 2 iterations, 4 threads
- β
UTXO model with RocksDB storage (8 column families)
- β
RPC API (7 endpoints: /info, /block, /transaction, /peers, /miners, /mempool, /health)
- β
DDoS protection, attack detection, checkpoint system
- π‘ P2P network (40% complete)
- π‘ CLI wallet (planned)
- π‘ Testnet (planned)
Key Innovations:
- ASIC-resistant: Argon2id with 256 MB memory makes ASIC development economically unviable (>$50K per chip)
- Solo mining viable: epoch-based rewards (24 hours) eliminate lottery variance
- Stronger 51% protection: attack requires 51% shares + high loyalty + significant bond
While independent, ACCUM's innovations in ASIC-resistant mining and decentralized reward distribution are relevant to Zcash's ongoing research into mining decentralization and equitable participation.
### Project Description
ACCUM is a next-generation blockchain protocol built on an innovative consensus mechanism called Fair Proof-of-Contribution (F-PoC). The protocol addresses the structural weaknesses of classical Proof-of-Work while preserving its strengths: decentralization, openness, and objective security.
Unlike Bitcoin where ASIC miners dominate (top 3 pools control >50% hashrate), ACCUM uses Argon2id with 256 MB memory, making specialized hardware economically unviable. This ensures that mining remains accessible to anyone with a standard computer.
The protocol distributes rewards across three independent axes:
- **Shares (60%):** computational work measured by Argon2id hashing
- **Loyalty (20%):** long-term participation, decays when miners are absent
- **Bond (20%):** economic commitment, minimum 1 ACM locked for 14 days
Rewards are distributed per epoch (1440 blocks, 24 hours) based on the Proof-of-Contribution Index (PoCI), eliminating the lottery-like variance of traditional PoW and making solo mining viable.
The project is currently at 70% completion with a fully working node implementation in Rust (4,300+ lines), including:
- Argon2id PoW with cache system (60-second cache, 10,000 entries, 70-80% hit rate)
- UTXO model with TxIn/TxOut structures
- RocksDB storage with 8 column families: blocks, utxo, miners, bonds, state, mempool, slashes, checkpoints
- RPC API (7 endpoints: /info, /block, /transaction, /peers, /miners, /mempool, /health)
- DDoS protection with IP blacklisting, rate limiting (1000 msgs/hour), connection limits
- Attack detection system: 51% attack monitoring, hash rate anomaly detection
- Checkpoint system: automatic checkpoints every 1000 blocks with signature verification
- Backup & Restore: automatic RocksDB backups, restore from checkpoint
- Graceful shutdown with Ctrl+C handling
**Monetary Model:**
- Max supply: 150,000,000 ACM
- Block reward: 0.05 ACM (500,000 LYT)
- Epoch reward: 72 ACM (720,000,000 LYT)
- Block time: 60 seconds (target)
- Epoch length: 1,440 blocks (24 hours)
- Annual inflation (Year 1): 0.0175%
**ASIC Resistance:**
- Memory: 256 MiB per hash
- Iterations: 2
- Parallelism: 4
- ASIC development cost: >$50,000 per chip β economically unviable
- CPU mining viable: 9-10 H/s on modern CPU
**Goals:**
1. Complete P2P network implementation with DNS seed discovery and sync manager
2. Develop CLI wallet with transaction creation and signing
3. Launch public testnet with 50+ nodes
4. Complete third-party security audit
5. Launch mainnet with documentation and boot nodes
### Proposed Problem
Classic Proof-of-Work (PoW) suffers from fundamental flaws that undermine its promise of decentralization:
**1. ASIC Dominance**
Specialized hardware (ASICs) captures 99% of block rewards in networks like Bitcoin. Top 3 mining pools control >50% of total hashrate. Individual CPU miners are effectively excluded from participation.
**2. High Variance (Lottery Problem)**
Solo miners face extreme uncertainty:
- Expected time to find a block: months or years
- Rewards are "all or nothing" β no income between blocks
- This forces miners to join pools, further centralizing control
**3. High Entry Barrier**
ASIC equipment costs $10,000+ per unit:
- Excludes individuals from developing countries
- Requires specialized facilities (cooling, power)
- Creates economies of scale that favor industrial operations
**4. Pool Centralization**
Mining pools aggregate hashrate:
- Top 3 Bitcoin pools control >50% of network hashrate
- Pools can theoretically collude to censor transactions
- Individual miners have no voting power
**5. Vulnerability to 51% Attacks**
A single entity controlling >50% of network hashrate can:
- Double-spend transactions
- Censor specific addresses
- Reverse confirmed blocks
- Undermine network trust
**Relevance to Zcash:**
Zcash uses Equihash (memory-hard PoW) and faces similar challenges:
- ASICs exist for Equihash (Z15, Z16 miners)
- Mining pools dominate (Flypool, F2Pool, ViaBTC)
- Centralization pressure threatens Zcash's decentralization goals
These problems are not theoretical β they are actively undermining the security and fairness of major PoW networks today.
### Proposed Solution
ACCUM introduces Fair Proof-of-Contribution (F-PoC), a multi-dimensional consensus mechanism that fundamentally redesigns how mining rewards are distributed.
**Core Innovation: Three Dimensions of Contribution**
Instead of rewarding only the miner who finds a block, ACCUM distributes rewards across three independent axes:
| Component | Weight | Description |
|-----------|--------|-------------|
| Shares | 60% | Computational work (Argon2id hashing) |
| Loyalty | 20% | Long-term participation (decays when absent) |
| Bond | 20% | Economic commitment (1 ACM minimum, 14-day lock) |
**Formula:**
PoCI_i = 0.6 Γ norm_shares_i + 0.2 Γ norm_loyalty_i + 0.2 Γ norm_bond_i
reward_i = (PoCI_i / Ξ£ PoCI) Γ (72 ACM + tx_fees)
text
**How This Solves PoW Problems:**
**1. ASIC Resistance**
- Argon2id requires 256 MB memory per hash
- ASIC development: $50,000+ per chip
- ASIC advantage: only 5-8x (vs 1000x for SHA256)
- CPU mining remains competitive and economically viable
**2. Eliminates Lottery Variance**
- Rewards distributed every epoch (24 hours)
- Every participating miner receives reward proportional to contribution
- Solo mining becomes viable β no pools required
**3. Low Entry Barrier**
- Any standard computer with 256 MB+ RAM can mine
- CPU performance: 9-10 H/s on modern processor
- No specialized hardware required
**4. Decentralized Mining**
- Epoch-based rewards remove pool incentive
- Small miners earn consistently
- No advantage to pooling resources
**5. Stronger 51% Attack Protection**
- Attack requires:
- 51% of epoch shares (computational control)
- High loyalty (long-term participation)
- Significant bond (economic commitment)
- Slashing conditions (equivocation, invalid shares) burn bond
- Attack cost: $20B+ (economically infeasible)
**Additional Security Mechanisms:**
| Mechanism | Protection |
|-----------|------------|
| Bond Slashing | Equivocation or invalid shares β 100% bond burned |
| Loyalty Decay | Missed epochs reduce loyalty (Γ0.7 or Γ·2) |
| Sybil Resistance | Minimum 1 ACM bond for PoCI participation |
| Share Limits | 5,000 shares per miner per epoch max |
| DDoS Protection | Rate limiting, IP blacklisting, connection limits |
**Example:**
In an epoch with 72 ACM total reward:
- Miner A (10,000 shares, loyalty 100, bond 5 ACM) β 41.16 ACM
- Miner B (2,500 shares, loyalty 50, bond 1 ACM) β 20.14 ACM
- Miner C (1,600 shares, loyalty 10, bond 0 ACM) β 10.70 ACM
All miners receive reward every 24 hours β no waiting months for a block.
### Solution Format
The project delivers open-source software, technical documentation, and infrastructure ready for mainnet deployment.
**Already Completed (Funding Not Required):**
| Component | Status | Details |
|-----------|--------|---------|
| Core Protocol | β
Complete | 4,300+ lines of Rust, Argon2id PoW, UTXO model |
| Storage Layer | β
Complete | RocksDB with 8 column families, backup/restore |
| RPC API | β
Complete | 7 endpoints: /info, /block, /transaction, /peers, /miners, /mempool, /health |
| DDoS Protection | β
Complete | Rate limiting (1000 msgs/hour), IP blacklisting, connection limits |
| Attack Detection | β
Complete | 51% attack monitoring, hash rate anomaly detection |
| Checkpoint System | β
Complete | Automatic checkpoints every 1000 blocks, signature verification |
| Specification | β
Complete | SPEC.md with 20 sections, all formulas, parameters |
**To Be Completed with Grant Funding:**
**Milestone 1: P2P Network Foundation ($25,000)**
- DNS seed discovery
- Peer handshake protocol (version/verack)
- Sync manager with header-first synchronization
- Share propagation (inv/getdata/share)
- Rate limiting per peer
**Milestone 2: CLI Wallet & Transactions ($15,000)**
- Wallet CLI with key generation (secp256k1)
- Address creation (P2PKH format)
- UTXO selection and balance display
- Transaction creation and signing
- RPC integration for broadcasting
**Milestone 3: Testnet Launch ($15,000)**
- Public testnet with 50+ nodes
- Testnet faucet
- Monitoring dashboard (node count, block time, hashrate)
- Documentation for testnet participation
**Milestone 4: Security Audit & Mainnet Launch ($20,000)**
- Third-party security audit report
- Fixes for all critical and high-severity issues
- Mainnet genesis block
- Boot nodes deployment (minimum 3 seed nodes)
- Launch announcement
**Deliverables Summary:**
| Type | Deliverable |
|------|-------------|
| Software | Complete ACCUM node with P2P, wallet, testnet |
| Documentation | User guide, node operator guide, API reference |
| Infrastructure | Public testnet, monitoring, boot nodes |
| Audit | Third-party security audit report |
| Community | Forum post, launch announcement |
### Dependencies
**Technical Dependencies:**
| Dependency | Version | Purpose |
|------------|---------|---------|
| Rust | 1.70+ | Core programming language |
| RocksDB | 8.0+ | Embedded key-value storage |
| argon2id | 0.4+ | Proof-of-Work hashing function |
| secp256k1 | 0.24+ | ECDSA signatures for transactions |
| tokio | 1.0+ | Async runtime for P2P networking |
| warp | 0.3+ | HTTP server for RPC API |
| serde | 1.0+ | Serialization/deserialization |
| hex | 0.4+ | Hex encoding/decoding |
**Resource Dependencies:**
| Resource | Quantity | Purpose |
|----------|----------|---------|
| Rust/P2P Developer | 1 | DNS seed discovery, peer handshake, sync manager |
| Cryptography Developer | 1 | Wallet implementation, transaction signing, security hardening |
| Security Auditor | 1 | Third-party audit of all core code |
| Cloud Servers | 10+ | Testnet nodes across multiple regions |
| CI/CD Infrastructure | 1 | GitHub Actions runners, automated testing |
**External Coordination:**
- No external coordination with other teams or organizations is required
- The project is independent and self-contained
- All code is original and written from scratch in Rust
- No Zcash code is forked or modified
**Libraries Used:**
- All dependencies are open-source and well-maintained
- No proprietary or commercial libraries required
- All dependencies are compatible with Rust 1.70+ stable
### Technical Approach
ACCUM is implemented in Rust, chosen for memory safety, performance, and strong type system β critical requirements for blockchain protocols where bugs can lead to consensus failures or financial loss.
**Current Implementation (4,300+ lines, 70% complete):**
| Module | File | Status | Description |
|--------|------|--------|-------------|
| Constants | constants.rs | β
| Monetary units, PoW parameters, PoCI weights |
| Types | types.rs | β
| Shared type aliases, difficulty target wrapper |
| Error | error.rs | β
| Unified error handling |
| Blocks | blocks.rs | β
| Block header, block structure, Merkle tree |
| Transactions | transactions.rs | β
| TxIn, TxOut, txid, fee/dust validation |
| Consensus | consensus.rs | β
| PoCI computation, loyalty, bond, difficulty |
| P2P | p2p.rs | β
| Message types, share packet validation |
**Argon2id PoW Implementation:**
- Memory: 256 MB (configurable)
- Iterations: 2
- Parallelism: 4 threads
- SHA256 prefilter: cheap rejection of invalid shares before Argon2id computation
- 60-second cache: 10,000 entries, 70-80% hit rate
**Storage Layer (RocksDB):**
- 8 column families: blocks, utxo, miners, bonds, state, mempool, slashes, checkpoints
- Automatic backup/restore system
- Graceful shutdown with state persistence
**Security Features Already Implemented:**
- DDoS protection: IP blacklisting, rate limiting (1000 msgs/hour/peer), connection limits
- Attack detection: 51% attack monitoring, hash rate anomaly detection
- Checkpoint system: automatic every 1000 blocks, signature verification
**P2P Network (To Be Completed):**
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β P2P Network Stack β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ€
β Application Layer: block, tx, share, epoch_commit β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ€
β Sync Manager: header-first, timeout 60s, peer fallback β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ€
β Peer Management: discovery (DNS seeds), handshake β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ€
β Transport Layer: TCP, tokio async, non-blocking I/O β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
**Message Types:**
- version, verack β handshake
- ping, pong β keep-alive
- inv, getdata β inventory and requests
- block, tx, share β data transmission
- epoch_commit β Merkle root of completed epoch shares
- getshares, sharereply β resync mechanism
**Sync Manager:**
- Header-first synchronization
- Peer selection based on best height and score
- Sync session timeout: 60 seconds (if no progress, switch peer)
- Automatic fallback to next best peer on timeout
**CLI Wallet (To Be Completed):**
- Key generation: secp256k1, compressed public keys
- Address format: Bitcoin-compatible P2PKH (RIPEMD160(SHA256(pubkey)))
- UTXO selection algorithm
- Transaction creation and signing (ECDSA)
- RPC integration for broadcasting
**Testnet (To Be Completed):**
- Deploy 50+ nodes on cloud infrastructure across multiple regions
- Monitor block time, network latency, share propagation
- Stress tests: 10K TPS, 51% attack simulations
- Verify difficulty adjustment behaves correctly under varying hashrate
**Security Audit (To Be Completed):**
- Third-party audit of all 4,300+ lines of code
- Focus areas:
- Consensus correctness (PoCI, rewards, difficulty)
- Memory safety (Rust, no unsafe blocks)
- Arithmetic overflow (checked operations)
- P2P vulnerabilities (DoS, eclipse attacks)
- Cryptographic implementation (secp256k1, Argon2id)
### Upstream Merge Opportunities
**This project does not fork or modify existing Zcash software.** ACCUM is an independent protocol written entirely from scratch in Rust. There is no Zcash code to merge upstream.
**Why This Matters for Zcash:**
While ACCUM is independent, it shares Zcash's values and could benefit the broader ecosystem:
| Area | ACCUM Innovation | Potential Relevance to Zcash |
|------|------------------|------------------------------|
| ASIC Resistance | Argon2id with 256 MB memory | Zcash uses Equihash; both face ASIC pressure. Research from ACCUM could inform future Zcash PoW upgrades |
| Mining Decentralization | F-PoC with loyalty/bond mechanisms | Zcash mining is pool-dominated; alternative reward distribution models could be explored |
| Solo Mining Viability | Epoch-based rewards (24 hours) | Current Zcash solo mining has high variance; epoch-based models could be researched |
| Slashing Mechanisms | Bond slashing for equivocation | Zcash has no slashing; this could be relevant for future staking or consensus upgrades |
**Potential Collaboration Opportunities:**
1. **Research Exchange**
- ACCUM's F-PoC implementation is open-source
- Zcash researchers can study, adapt, or reference the code
- No formal coordination required β code is publicly available
2. **ASIC-Resistance Research**
- Both projects use memory-hard PoW functions
- Shared interest in maintaining CPU-mining accessibility
- Findings from ACCUM's Argon2id implementation could be valuable
3. **Educational Value**
- ACCUM demonstrates an alternative consensus model
- Can serve as reference for Zcash community discussions on mining decentralization
**No Upstream Coordination Required:**
- No Zcash repositories are forked or modified
- No timeline considerations for upstream merges
- The project is self-contained and independent
- All code is original and written from scratch
### Hardware/Software Costs (USD)
5000
### Hardware/Software Justification
| Item | Cost | Justification |
|------|------|---------------|
| CI/CD Infrastructure | $2,000 | GitHub Actions runners, automated testing across multiple Rust versions, cross-compilation builds |
| Development Tools | $1,500 | Profiling tools (perf, flamegraph), code coverage (tarpaulin), memory analysis (valgrind, heaptrack) |
| Backup Storage | $500 | Database snapshots, build artifacts, testnet backups |
| Monitoring Tools | $1,000 | Prometheus, Grafana for testnet monitoring, alerting systems |
These costs are distributed across Milestones:
- Milestone 1: CI/CD and development tools ($2,500)
- Milestone 3: Monitoring tools and backup storage ($2,500)
All tools are either cloud-based or open-source software with hosting costs. No proprietary hardware purchases are required β testnet nodes run on cloud infrastructure (covered in Service Costs).
### Service Costs (USD)
15000
### Service Costs Justification
| Service | Cost | Justification |
|---------|------|---------------|
| Security Audit | $15,000 | Third-party security audit of all 4,300+ lines of Rust code. Includes: consensus correctness review, memory safety analysis, cryptographic implementation verification, P2P vulnerability assessment, and final report with remediation guidance. |
**Audit Scope:**
- Core consensus (PoCI calculation, rewards, difficulty adjustment)
- Cryptographic primitives (Argon2id, secp256k1, ECDSA)
- UTXO and transaction validation
- Storage layer (RocksDB integrity)
- P2P message handling and sync manager
- DDoS protection and rate limiting
**Why $15,000:**
- Industry standard for blockchain audits: $5,000-$10,000 per auditor
- 2-week audit period with 1-2 auditors
- Covers full codebase (4,300+ lines) plus specification review
- Includes report and follow-up verification of fixes
This cost is allocated to Milestone 4 (Security Audit & Mainnet Launch).
### Compensation Costs (USD)
25000
### Compensation Costs Justification
| Role | Rate | Duration | Total | Responsibilities |
|------|------|----------|-------|------------------|
| Rust/P2P Developer | $6,250/month | 2 months | $12,500 | DNS seed discovery, peer handshake, sync manager, share propagation, rate limiting |
| Cryptography/Security Developer | $6,250/month | 2 months | $12,500 | Wallet implementation, transaction signing, security hardening, audit preparation |
| Project Lead | Volunteer | β | $0 | Core architecture, code review, specification, coordination |
**Total Compensation:** $25,000
**Compensation Breakdown by Milestone:**
| Milestone | Developer | Allocation |
|-----------|-----------|------------|
| Milestone 1 (P2P Network) | Rust/P2P Developer | $12,500 |
| Milestone 2 (CLI Wallet) | Cryptography Developer | $12,500 |
| Milestone 3 (Testnet) | Both (partial) | Included in infrastructure budget |
| Milestone 4 (Audit/Mainnet) | Both (fixes) | Included in audit budget |
**Rate Justification:**
- Market rate for Rust blockchain developers: $80,000-$120,000/year ($6,600-$10,000/month)
- Requested rate: $6,250/month (below market average)
- Duration: 2 months per developer (focused, milestone-based work)
- Project Lead works volunteer to maximize grant impact
**Hiring Plan:**
- Immediately upon grant approval, recruitment begins
- Pre-screened candidates from blockchain and Rust communities
- Milestone-based payments ensure accountability
### Total Budget (USD)
75000
### Previous Funding
No
### Previous Funding Details
No previous funding received from Zcash Community Grants or any other organization. The project has been developed independently by the project lead, with 4,300+ lines of Rust code completed without external financial support.
### Other Funding Sources
No
### Other Funding Sources Details
No other funding sources have been received or are planned. The project is solely seeking support through Zcash Community Grants.
### Implementation Risks
| Risk | Probability | Impact | Mitigation |
|------|-------------|--------|------------|
| Developer hiring delay | Medium | Medium | Pre-screened candidates identified; recruitment begins immediately upon grant approval; offer letters ready |
| P2P sync complexity | Medium | High | Modular architecture allows phased implementation; early prototyping completed; fallback to simple sync (header-first only) if needed; sync timeout 60s with automatic peer fallback |
| Security audit findings | Low | High | Code follows Rust best practices (no unsafe blocks); regular self-audits during development; allocate 2-week buffer for fixes; audit scheduled early to allow time for remediation |
| Testnet node adoption | Medium | Medium | Open source with clear documentation; incentivize early participants through community outreach; faucet for test coins; simple node setup (single binary) |
| Scope creep | Medium | Medium | Strict milestone tracking; scope frozen after grant start; additional features deferred to post-mainnet |
| Network stability | Low | High | Extensive testnet period (3+ months); monitoring dashboard; gradual mainnet rollout; emergency response plan |
| 51% attack simulation | Low | Medium | Testnet includes controlled 51% attack simulations to verify detection and response; bond slashing mechanisms tested |
**Contingency Plan:**
- 10% of total budget ($7,500) is distributed across milestones as buffer
- If developer hiring delayed: Project lead handles initial P2P implementation while recruitment continues
- If audit reveals critical issues: Additional time allocated before mainnet; fixes prioritized
- If testnet adoption low: Extended testnet period, additional documentation, community outreach
### Potential Side Effects
No major negative side effects are anticipated. As with any new blockchain protocol, there are normal risks that are actively managed:
| Potential Side Effect | Likelihood | Mitigation |
|----------------------|------------|------------|
| Protocol forks | Low | ACCUM is open source; forks are permitted and healthy for decentralization. The core protocol provides clear specification and reference implementation |
| Mainnet bugs | Low | Extensive testnet period (3+ months) before mainnet; third-party security audit; gradual node rollout; emergency response plan |
| Competition with existing networks | Low | ACCUM targets CPU miners underserved by ASIC-dominated networks. Healthy competition drives innovation |
| Bond slashing disputes | Medium | Slashing requires cryptographic proof (Merkle proofs of invalid shares, signed equivocation headers). All slashing events are recorded on-chain and verifiable by any node |
| Loyalty decay concerns | Low | Decay formula is transparent (Γ0.7 or Γ·2 after grace period). Miners can monitor their loyalty status via RPC |
| Mining centralization | Low | F-PoC specifically designed to prevent centralization: epoch-based rewards (24 hours) eliminate pool advantage; square root normalization prevents shares dominance; bond and loyalty add economic and time dimensions |
**Positive Side Effects:**
- CPU mining becomes viable again
- Solo miners receive consistent rewards
- ASIC manufacturers have reduced incentive to target ACCUM
- Open source code benefits broader blockchain research community
- Innovations in PoW reward distribution may inform future Zcash development
**No Unmanageable Risks:**
All identified risks have clear mitigation strategies. The protocol is designed with safety mechanisms (checkpoints, slashing, DDoS protection) to minimize attack surfaces.
### Success Metrics
**Technical Metrics:**
| Metric | Target | Measurement |
|--------|--------|-------------|
| P2P network connectivity | 10+ peers discovered via DNS seeds | Node connection count |
| Sync time | <5 minutes from genesis | Block height vs timestamp |
| Share propagation | Received by 3+ peers | Share broadcast tracking |
| Block time stability | 60 Β± 10 seconds | 1000 block average |
| Testnet nodes | 50+ active nodes | Monitoring dashboard |
| Testnet uptime | 99.9% over 27+ days | Node availability tracking |
**Implementation Metrics:**
| Metric | Target | Measurement |
|--------|--------|-------------|
| Milestone completion | 4/4 on schedule | Milestone delivery dates |
| Code quality | No critical audit findings | Security audit report |
| Documentation | User guide, API reference, node ops | Public documentation |
| Testnet stability | No critical failures | Incident tracking |
**Success Criteria by Milestone:**
**Milestone 1 (P2P Network Foundation)**
- Node discovers at least 10 peers via DNS seeds
- Full chain sync from genesis in <5 minutes
- Shares broadcast and received by 3+ peers
**Milestone 2 (CLI Wallet & Transactions)**
- Generate wallet and create address
- Display correct balance from UTXO set
- Create and broadcast valid transaction
- Transaction appears in mempool
**Milestone 3 (Testnet Launch)**
- 50+ nodes actively connected
- Block time within 60 Β± 10 seconds for 1000 blocks
- 10+ independent miners submitting shares
- No critical bugs discovered
**Milestone 4 (Security Audit & Mainnet Launch)**
- Audit report delivered with no critical vulnerabilities
- Mainnet live: nodes can connect and sync from genesis
- 20+ nodes running within first week
- Miners can connect and submit shares to the network
**Long-Term Success Indicators (Post-Grant):**
- 1000+ active nodes within 6 months of mainnet
- 10+ independent mining pools or solo miners with consistent rewards
- Gini coefficient of reward distribution <0.4 (fair distribution)
- No successful 51% attacks in first year
- Code forks or adaptations by other projects (sign of innovation adoption)
### Startup Funding (USD)
0
### Startup Funding Justification
Not applicable. All project expenses are distributed across the four milestones. No separate startup funding is requested.
- Milestone 1 ($25,000) covers P2P network development including developer compensation and infrastructure
- Milestone 2 ($15,000) covers wallet development
- Milestone 3 ($15,000) covers testnet launch including cloud infrastructure
- Milestone 4 ($20,000) covers security audit and mainnet launch
This structure ensures that funding is tied to measurable deliverables rather than upfront costs.
### Milestone Details
```milestones.yaml
- Milestone: 1
Amount (USD): 25000
Expected Completion Date: 2026-06-15
User Stories:
- "As a node operator, I want my node to discover other nodes automatically via DNS seeds so that I don't need to manually configure peers"
- "As a node operator, I want to synchronize with the network so that my node stays up to date"
- "As a miner, I want to broadcast shares to the network so that they are included in PoCI calculation"
Deliverables:
- DNS seed discovery implementation
- Peer handshake protocol (version/verack)
- Sync manager with header-first synchronization (60-second timeout, peer fallback)
- Share propagation (inv/getdata/share messages)
- Rate limiting (1000 messages/hour/peer)
- Comprehensive P2P module documentation
Acceptance Criteria:
- Node discovers at least 10 peers via DNS seeds within 2 minutes of startup
- Full chain sync from genesis completes in <5 minutes on test network
- Shares broadcast by one node are received and validated by at least 3 peers
- Peer exceeding rate limit is temporarily banned
- Milestone: 2
Amount (USD): 15000
Expected Completion Date: 2026-07-15
User Stories:
- "As a user, I want to generate a new wallet so that I can receive funds"
- "As a user, I want to check my balance so that I know my available funds"
- "As a user, I want to send transactions so that I can transfer funds"
Deliverables:
- Wallet CLI with key generation (secp256k1, compressed public keys)
- Address creation (P2PKH format: RIPEMD160(SHA256(pubkey)))
- UTXO selection algorithm (coin selection for optimal fee)
- Balance display (confirmed and unconfirmed)
- Transaction creation and signing (ECDSA with SIGHASH_ALL)
- RPC integration for broadcasting transactions
- Wallet documentation and usage examples
Acceptance Criteria:
- User can generate wallet and create receiving address in <30 seconds
- Balance displays correctly based on UTXO set from node
- User can create, sign, and broadcast valid transaction
- Transaction appears in node mempool and propagates to peers
- Milestone: 3
Amount (USD): 15000
Expected Completion Date: 2026-08-15
User Stories:
- "As a miner, I want to mine on testnet so that I can test the protocol"
- "As a developer, I want to run a testnet node so that I can integrate with the network"
- "As a community member, I want to verify network stability before mainnet"
Deliverables:
- Public testnet with 50+ nodes across multiple regions (cloud infrastructure)
- Testnet faucet for obtaining test coins
- Monitoring dashboard (node count, block time, hashrate, share propagation)
- Node operator documentation (installation, configuration, troubleshooting)
- Testnet participation guide
- Stress test report (10K TPS, 51% attack simulations)
Acceptance Criteria:
- 50+ nodes actively connected and synchronized
- Block time within 60 Β± 10 seconds for 1000 consecutive blocks
- 10+ independent miners submitting shares regularly
- No critical bugs or consensus failures discovered during testnet operation
- Monitoring dashboard publicly accessible
- Milestone: 4
Amount (USD): 20000
Expected Completion Date: 2026-09-15
User Stories:
- "As a user, I want the protocol to be audited so that I can trust the network"
- "As a miner, I want to mine on mainnet so that I can earn real rewards"
- "As a community member, I want to participate in mainnet launch"
Deliverables:
- Third-party security audit report (full codebase: 4,300+ lines)
- Fixes for all critical and high-severity audit findings
- Mainnet genesis block configuration
- Boot nodes deployment (minimum 3 seed nodes, geographically distributed)
- Mainnet launch announcement on Zcash forum and social media
- Post-launch monitoring report (first 30 days)
Acceptance Criteria:
- Audit report delivered with no critical or high-severity vulnerabilities remaining
- Mainnet live: nodes can connect and sync from genesis block
- 20+ nodes running within first week of mainnet
- Miners can connect and submit shares to mainnet network
- All fixes from audit verified and closed
```
### Supporting Documents
```files.yaml
- File Name 1: Brief description of the file contents
- File Name 2: Brief description of the file contents- GitHub Repository: https://github.com/andreudumitro-eng/accum-core
Contains main.rs (4,300+ lines of Rust code), SPEC.md (complete protocol specification with 20 sections), README.md (project overview and build instructions)
- Technical Specification: Full ACCUM v3.2+ specification document
Includes: monetary model, cryptographic parameters, block structure, PoCI formula with examples, bond and loyalty mechanisms, P2P protocol, difficulty adjustment, governance model, and security analysis
- RPC API Screenshots: Available in the GitHub repository under /docs/screenshots/
Shows /info, /block, /stats endpoints with live node data
- Code Quality: Rust code follows standard conventions, no unsafe blocks, comprehensive error handling
```
Executive Summary
Shares
Current Status: 70% Complete
Complete
40% complete
Key Technical Innovations
Monetary Model
Development Roadmap
Why ACCUM for Zcash?
Security Analysis
Governance (3-Phase Decentralization)
Links