Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

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. Note that “public” alone does not put a deployment out of OSS scope — a non-custodial per-worker pool is fully covered (see Public 0% Solo Pool); what needs the commercial stack is holding funds, sharing rewards, and running a service with support obligations.

Tier Matrix

TierUse caseOSS sufficient?Profile
SoloOne operator, own miners on LANYesklein (0-5 miners)
Solo + Friends5-20 miners, trust-based, LAN or InternetYesmittel (6-20)
Community / public per-worker pool20-100 miners, vetted or openly non-custodialYesgross (21-100)
Custodial / reward-sharing servicePublicly advertised pool that holds funds or splits rewardsNo — requires commercial stackenterprise (101+)

The profile is a bundle of defaults, not a hard limit. A profile presets the connection cap, VarDiff bounds, memory budget and retention — nothing enforces the worker range in its name, and the software has been load-tested with 1,000 simulated miners against a single instance (see Benchmarks). Profiles hot-switch at runtime without a daemon restart (Admin → Profile, POST /api/admin/profile); the connection cap is resized live.

Do not jump to enterprise just because you crossed 100 miners. Its VarDiff defaults are calibrated for PH/s-class farms and start far too high for a pool full of Bitaxe/NerdMiner-class hardware. Compare the profiles side by side first (GET /api/admin/profiles/compare, rendered as a table in the admin UI). The optional [mining.auto_profile] switcher exists but is off by default for exactly this reason — see the Configuration Reference.

What the OSS stack ships

Applies to all tiers:

  • Stratum V1 plain (:3333) + TLS (:3334), Stratum V2 over NOISE NX (sv2_listen, :3336 in the reference deployment)
  • Bitcoin Core solo mining (full reward to the block finder), via getblocktemplate + ZMQ by default, or opt-in via Core’s IPC interface ([node] template_source = "ipc", Core ≥ 31 — Core’s IPC interface is itself experimental)
  • Multi-node failover: any number of [[node.backup]] nodes, with submitblock broadcast to all of them in parallel (Resilience)
  • Automated JSON ledger snapshots ([backup]) — no secrets, no raw shares
  • Per-worker payout mode — a public, non-custodial, 0%-fee solo pool where every miner mines to its own address (from the Stratum login), plus login-free wallet pages at /users/<address>. Because the pool never holds funds and shares no reward, this is a public deployment that stays inside the OSS scope — the commercial line below is about custodial / reward-sharing pools, not about being public. See Public 0% Solo Pool.
  • Class-aware VarDiff (Bitaxe / Antminer / Avalon Q / Avalon ASIC / NerdMiner / NerdNOS / Whatsminer)
  • Admin UI with Argon2 passwords, optional 2FA, signed auto-update channel, and API tokens with an admin or read-only read scope
  • 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 (ntfy, Telegram, Discord, Slack, email, Web Push) for block-found + health-alert events
  • Distribution: Linux .deb / .rpm / AppImage, multi-arch container images from the project’s own registry at git.warppool.org, Umbrel community store, plus a macOS .dmg (built manually per release — there is no macOS build runner). Windows .msi is paused (no Windows build runner)

For Solo and Solo + Friends that stack is ready for solo/friends use. The only external steps for the friends tier are:

  1. A DNS hostname (e.g. via DuckDNS) pointing at your public IP
  2. A Let’s Encrypt certificate (the Bitaxe “Bundled CA” mode requires a CA that’s in the Mozilla root bundle)
  3. 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 — what a community pool needs on top

The items below were originally listed here as gaps. Most have since shipped as opt-in core hardening; what remains is operator-supplied infrastructure rather than missing code.

ItemStatus
Per-IP connection capShipped (v1.13.0) — [stratum] max_connections_per_ip
Connect/auth rate-limit + escalating auto-banShipped — [ratelimit] with autoban_*
Reject-ratio ban (share-flood defence)Shipped (v1.13.0) — [ratelimit] reject_ban_*
Subnet access controlShipped — [ratelimit] ban_cidrs / allow_only / allow_cidrs
Stratum whitelist / registrationShipped as an address allowlist — [mining] address_allowlist (an invite-only per-worker pool); full member registration with accounts is still out of scope
Worker / address disclosure gatingShipped — [privacy] wallet_directory_public masks addresses in /api/workers and the wallet directory for anonymous visitors (v1.19.1), leaderboard_addresses_public masks the leaderboard. /api/workers carries no peer IPs at all. Daemon logs still contain peer IPs — treat them as personal data
Automated DB backupShipped (v1.13.0) — [backup] (enabled, interval_secs, dir, keep) writes JSON ledger snapshots. It contains no secrets and no raw shares
Reverse proxy with TLS, rate-limit + access-logOperator-supplied software, but fully documented: ready-to-paste nginx/Caddy configs in Reverse Proxy. Pair it with [server] trust_proxy_headers = true so per-IP limits see the real client IP

See Security and the Configuration Reference for every key, and Public 0% Solo Pool for a ready-made public hardening profile.

Tier 4 — custodial / service gaps (in addition to Tier 3)

GapWhy it matters at this scale
DDoS mitigationCloudflare TCP pass-through or dedicated providers; a connection cap alone is not protection
PPLNS / FPPS payout engineOSS is pure solo (100% of the reward to the finder). Reward sharing means custody, which is exactly the AGPL boundary: it lives in a separate commercial sidecar, not in this repo
Multi-admin + role-based accessA single admin user, plus read-only API tokens. Full per-user roles and per-user audit are not in OSS
T&C / Privacy templatesEU operators need a GDPR-compliant notice for worker-IP processing; liability if a found block is lost. The [legal] config block renders links to your own documents — it does not supply the texts
Monitoring stack/metrics is exposed (Prometheus format), but the scrape config, alerting beyond the built-in notifier, and Grafana dashboards are operator-supplied
Sentry / error trackingDaemon panics go to the tracing log only
SLA / maintenance contract24/7 on-call is a hard requirement for an advertised public pool

Not a gap any more: the public stats page. The dashboard is viewable anonymously (hashrate, active miners, block history), and a per-worker pool additionally serves login-free wallet pages at /users/<address> plus ckpool-compatible JSON at /api/users/<address>. How much of that anonymous visitors see is controlled by [privacy].

AreaSpecialist
Pool T&C templateLawyer
Privacy policy (GDPR)Lawyer
AML / KYC if pool fees applyTax advisor + possibly BaFin / FCA / equivalent
Income taxation of pool feesTax advisor

How to request Tier 3 or Tier 4 extensions

Open an issue in this repo at git.warppool.org/dvb-projekt/dvb-WarpPool/issues:

  • Tier 3 (Community Pool): label community-pool
  • Tier 4 (custodial / 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.