Picking a coin for your build.
The fastest path from "I have a GPU or ASIC" to "shares are landing" on the testnet demo. Five steps.
01 What you are actually choosing
When you enable a coin for your build, you are really choosing a proof-of-work algorithm. The algorithm decides which hardware can mine it, how that hardware needs to be configured, and how much operational complexity you take on. Everything downstream — which miners your users will run, how the pool talks to them, how often blocks land — follows from that one decision.
For a first launch, the right instinct is to keep it boring. Pick one coin, on a well-understood algorithm, that matches hardware people actually own, and get the full flow working before you add a second. You can always enable more coins later; you cannot un-confuse a launch that tried to do five things at once.
Everything on the public stack runs on testnet, so the coins you mine while choosing have no monetary value — they are there to prove the pipeline, not to be worth anything.
02 Match the algorithm to hardware
Algorithms fall into three broad hardware classes. The class you pick decides who can mine and what they need to own.
ASIC — purpose-built mining machines. Fast and efficient, but single-purpose and a real purchase. Common algorithms:
- SHA-256 — the Bitcoin family. Antminer-class hardware.
- Scrypt — the Litecoin family. This is what GCC uses.
- X11 — multi-hash, Dash-style.
GPU — graphics cards. The most accessible serious tier, because a lot of people already own a capable card. Algorithms here are typically designed to resist ASICs and reward memory bandwidth:
- KAWPOW (Ravencoin-style), Etchash (Ethereum Classic), kHeavyHash (Kaspa-style), Autolykos2 (Ergo-style) and Equihash (Zcash-style) all run on GPUs, with VRAM and memory bandwidth deciding throughput.
CPU — ordinary processors. The lowest barrier to entry: anyone with a desktop can join, no special hardware at all.
- RandomX — the Monero algorithm, deliberately CPU-friendly and ASIC-hostile.
03 Block time and settlement cadence
Two more knobs shape the experience, and both are honest trade-offs rather than free wins.
Block time is how often the chain produces a block. A shorter block time means miners see contributions reflected and shares settle more frequently, which feels more responsive — at the cost of more orphan/stale blocks and more chatter. A longer block time is steadier but slower to give feedback. GCC targets a 60-second block, which is a comfortable middle ground for a demo: fast enough to watch things happen, slow enough to stay stable.
Complexity is the other axis, and it is easy to underestimate. Some coins are simple single-algorithm chains. Others layer on mechanisms like merge-mining (securing one chain with another’s work), multi-algorithm scheduling, or auxiliary proof-of-work. Each of those is a legitimate design, but each one is more moving parts to run, monitor and support. For a first launch, a plain single-algorithm chain is far less to go wrong.
04 GCC: the reference chain
GCC is the live demo chain and the one I would point you at first, because it is the configuration I run and prove the wallet and pool against every day. It is a Litecoin v0.21.5.5 Scrypt fork, which means:
Because it is Scrypt, it is a sensible default for both ASIC owners (Litecoin-class hardware) and people experimenting with CPU/GPU Scrypt miners on testnet. It is a single-algorithm chain — no merge-mining, no multi-algo scheduling — so there is the least to configure and the least to go wrong. If you are not sure where to start, start here, prove the full flow, then branch out.
05 Use the recommender
You do not have to memorise which algorithm suits which card. The “best coin for your card” recommender on the pool page takes your hardware and points you at the algorithm that fits it — handy when you are deciding what to enable, or telling your future users what to run. From there, each coin has its own page covering the miner software, configuration and characteristics in detail.