Scaling dvb-WarpPool
dvb-WarpPool is an open-source solo mining pool with operator UX. The codebase covers everything you need to mine to your own wallet with your own hardware, including for a small group of trusted friends. Beyond that, public pool operations introduce a different class of requirements (DDoS, reward sharing, multi-admin, compliance) that the OSS distribution does not address.
This document defines the four deployment tiers, what the OSS stack covers, and where commercial extensions begin.
Tier Matrix
| Tier | Use case | OSS sufficient? | Profile mapping |
|---|---|---|---|
| Solo | One operator, own miners on LAN | Yes | Klein |
| Solo + Friends | 5-10 miners, trust-based, LAN or Internet | Yes | Mittel |
| Community Pool | 50-100 miners, Discord-vetted | Partially — needs extensions | Gross |
| Public Service | Publicly advertised, 500+ miners | No — requires commercial stack | Enterprise |
What the OSS stack ships
Applies to all tiers:
- Stratum-V1 plain + TLS, Stratum-V2 NOISE
- Bitcoin Core solo mining (full reward to the block finder)
- Class-aware VarDiff (Bitaxe / Antminer / Avalon Q / Avalon ASIC / NerdMiner / NerdNOS / Whatsminer)
- Admin UI with Argon2 passwords, optional 2FA, signed auto-update channel
- Live miner telemetry probes (AxeOS, MM-Summary for Avalon, WantClue NerdNOS, NerdMiner V2)
- Energy tracking (live / 24h / 7d / lifetime with reset)
- Hashrate chart with best-share overlay + 24h aggregation + Week/Month/Year view from daily aggregates
- Notifier hooks (email, Web Push) for block-found events
- Distribution: macOS .dmg, Linux .deb / .rpm / AppImage, Windows .msi, Docker multi-arch, Umbrel community store
For Solo and Solo + Friends that stack is production-ready. The only external steps for the friends tier are:
- A DNS hostname (e.g. via DuckDNS) pointing at your public IP
- A Let's Encrypt certificate (the Bitaxe "Bundled CA" mode requires a CA that's in the Mozilla root bundle)
- Router port-forward for the TLS Stratum port (default
:3334)
What the OSS stack does NOT ship
These are deliberately scoped out — they're how a pool transitions from a personal tool into a service.
Tier 3 — Community Pool gaps
| Gap | Why it matters at this scale |
|---|---|
| Reverse proxy with rate-limit + access-log | OSS binds TLS directly in the daemon; Caddy/Nginx in front enables per-IP limits, easier cert rotation, and a single audit log |
| Per-IP connection limit | Global connection-cap=64 is trivially exhausted by one attacker holding 64 idle TCP connections |
| Worker IP / topology disclosure gating | /api/workers and daemon logs expose peer IPs unauthenticated — fine for a personal pool, a privacy issue if anyone untrusted can read the dashboard |
| Abuse-pattern detection | A worker that only submits invalid shares thrashes VarDiff and burns CPU on validation; needs auto-ban on > N% rejected |
| Automated DB backup | Admin restore card exists for config, but warppool.db snapshotting is manual |
| Stratum whitelist / registration | OSS accepts any bech32 address — operators of a real community pool usually want to register members |
Tier 4 — Public Service gaps (in addition to Tier 3)
| Gap | Why it matters at this scale |
|---|---|
| DDoS mitigation | Cloudflare TCP pass-through or dedicated providers; connection-cap alone is not protection |
| PPLNS / FPPS payout engine | OSS is pure solo (100% of the reward to the finder); a publicly advertised pool without reward sharing will not attract miners |
| Multi-admin + role-based access | Single admin user; production needs read-only roles and per-user audit |
| T&C / Privacy templates | EU operators need GDPR-compliant worker-IP processing notice; liability if a found block is lost |
| Public stats page | Anonymous view of hashrate / active miners / block history for prospective miners |
| Block-found webhooks | Discord / Telegram integrations are not in OSS |
| Block explorer linking | Every block in the UI should link to mempool.space |
| Monitoring stack | /metrics is exposed (Prometheus format), but a real scrape config + alerting beyond the local notifier + Grafana dashboards are operator-supplied |
| Sentry / error tracking | Daemon panics go to the tracing log only |
| SLA / maintenance contract | 24/7 on-call is a hard requirement for an advertised public pool |
Tier 4 — Compliance / Legal
| Area | Specialist |
|---|---|
| Pool T&C template | Lawyer |
| Privacy policy (GDPR) | Lawyer |
| AML / KYC if pool fees apply | Tax advisor + possibly BaFin / FCA / equivalent |
| Income taxation of pool fees | Tax advisor |
How to request Tier 3 or Tier 4 extensions
Open a GitHub issue in this repo:
- Tier 3 (Community Pool): label
community-pool - Tier 4 (Public Service): label
enterprise-inquiry
Please include in the issue body:
- Use case (private / community / commercial)
- Expected number of miners
- Hosting setup (own server / cloud / Umbrel / Mac / etc.)
- Timeline + budget range
- Specific items from the gap list above that you need addressed
Response time: typically 2-5 business days. You will receive a fixed-price proposal (Tier 4) or an hour estimate (Tier 3).
Why this split exists
The OSS distribution is what one person + a small trusted group can run safely themselves. Anything beyond that requires ongoing operations work — DDoS response, payout reconciliation, compliance updates, user support — that does not belong in a publicly forkable codebase. Splitting it this way keeps the core honest about its scope, and lets the project sustain itself if anyone wants to run it at scale.