Californium (CF) SHA256/SHA256d Mining Pool Setup — Operator Runbook
Because Californium is mined with SHA256/SHA256d, it fits naturally into ASIC‑based pool operations. This guide walks through the practical pieces we deploy for a reliable CF mining pool: node/RPC, Stratum behavior, payouts, and public documentation.
How a CF pool actually runs in production
A Californium pool is more than a Stratum port. You’re running a small payments system: miners submit shares, your backend scores them, and your wallet signs payouts on a schedule you control. The goal is predictable behavior under load, not “it works on my LAN.”
- Operating mode: decide whether CF will be solo, invite‑only, or open registration (controls, abuse surface, and support load change).
- Payout policy: choose a scheme and document it clearly; variance, fees, and thresholds should be understandable to miners.
- Node discipline: keep the CF daemon healthy (sync, peers, disk, backups) and isolate RPC so only pool services can reach it.
- Stratum behavior: set VarDiff (variable difficulty) bounds, connection limits, and ban rules so bad clients don’t dominate resources.
Picking the engine for CF: Yiimp, Miningcore, or custom
Most CF launches succeed or fail on repeatability. We pick an engine that fits how you want to operate: UI-first and familiar, API-driven and lean, or tailored around your own accounting and reporting.
- Yiimp-based: Great when you want the classic pool website quickly; Yiimp setup guide is the fastest path to a full public UI.
- Miningcore: Best when you prefer clean service boundaries and an API-centric layout; start from the Miningcore setup guide baseline and customize from there.
- Custom stack: Choose this when you have special requirements (regional gateways, custom share accounting, or unusual payout logic).
If you plan to accept rented hashpower, test with strict limits first. Marketplace miners often reconnect aggressively and can amplify small configuration mistakes.
Build scope for CF: what we wire up end‑to‑end
- CF node layer: install/build, safe services, and RPC limited to allowlisted pool hosts.
- Pool core + database: schema, share persistence, block tracking, and retention sized for CF share volume.
- Stratum endpoints: ports, TLS where needed, VarDiff (variable difficulty) bounds, bans, and miner-facing worker rules.
- Payout pipeline: wallet signing flow, batching strategy, and a documented scheme decision (see payout schemes plus how to choose SOLO vs PPLNS vs PROP).
- Website UI: a clean CF landing page, miner dashboard, worker stats, and a status page tied to real health checks.
- Security hardening: secrets handling, firewalling, backups with restore drills, and monitoring guidance (see security hardening).
We keep CF isolated from other SHA256 coins in the same environment: separate wallets, separate payout accounting, and a rollback plan if a node falls out of consensus.
CF miner endpoints and worker naming examples
Publish only the endpoints you’ll actually support, and keep examples short. Miners should not have to guess which URL or port to use.
stratum+tcp://POOL-DOMAIN:3333
stratum+ssl://POOL-DOMAIN:3443In your help text, define the worker format you accept (for example, ADDRESS.WORKER) and show one tested configuration for each common ASIC firmware you expect.
CF operational checks you should do before opening the pool
- Address validation: confirm what the CF wallet accepts and enforce it at signup to prevent misdirected payouts.
- Confirmation strategy: pick a consistent rule for when blocks are credited, and monitor for reorganizations that can invalidate earlier credit.
- Wallet recovery: document backup, rescan, and key separation so a corrupted wallet database is a recoverable event.
CF go‑live checklist (pre‑launch to first payout)
- CF daemon fully synced and monitored (alerts for stalled tip, disk pressure, and peer collapse).
- RPC locked down: strong auth, firewall rules, and only pool daemons allowed to connect.
- Database backed up with a restore test; share retention and pruning verified.
- Stratum ports live with sane limits (connections, bans, VarDiff range) and logs reviewed under load.
- Payout wallet prepared: small-value end‑to‑end test from share credit → payment broadcast → confirmation.
- Public docs published: endpoints, worker format, and troubleshooting for common miner errors.
- Operational handoff: dashboards, on-call notes, and a rollback plan for the first 24 hours.
CF setup questions (what operators ask us)
Should the CF node run on the same server as Stratum?
It can, but we usually separate roles once the pool is public. Keeping the CF daemon and wallet on a controlled node reduces blast radius if the Stratum layer is abused.
How do you prove CF payouts are correct before launch?
We run a closed test: submit shares, force a payout cycle, and reconcile wallet transactions against the pool’s accounting tables. Only after that do we open registrations.
What VarDiff behavior is most important for CF ASIC miners?
Stability. We tune the target share rate and clamp extremes so small miners aren’t starved and large miners don’t flood the database with tiny shares.
Can a CF pool be invite‑only with manual accounts?
Yes. We can lock registrations, pre-create accounts, and restrict withdrawals until you’re comfortable with the payout flow and monitoring.
What details speed up a CF build quote?
Tell us your expected hashrate range, preferred engine (Yiimp or Miningcore), hosting plan, and whether you need a full public UI plus managed operations.
Ready to ship CF with production controls? Contact us and include your hashrate target plus whether the pool is private or public.