When I started the reference chain for the stack, the first real decision was which proof-of-work function it should use. That choice ripples through everything: what hardware can mine it, which miner software and pools already understand it, how the node checks work, and how much of the surrounding ecosystem I’d have to build versus inherit. I picked Scrypt — the Litecoin family — and the demo chain (GCC) is a fork of Litecoin Core v0.21.5.5 with its Scrypt PoW left exactly as it is.
This post is the reasoning. It’s also a correction: an early draft of our own materials described GCC as using “KawHash”. That was wrong, and I’d rather say so plainly than quietly edit it out. The algorithm is Scrypt. If you want the parameters, they’re in the Scrypt spec.
01 · The decision isn’t “best algorithm”, it’s “best substrate”
It’s tempting to treat PoW choice as a contest — which function is the most elegant, the most ASIC-resistant, the most novel. That’s the wrong frame for what this stack is. The stack is software a buyer re-brands and runs; the demo chain exists to prove the whole pipeline works end to end — node, pool, wallet, explorer, settlement — on testnet, where the coins have no monetary value. What I needed was a substrate that was boring in the good way: well understood, widely supported, and unlikely to surprise me at 2am.
A new PoW function would have meant writing or porting the hashing in the node, the pool’s share validation, the miner-facing stratum layer, and any verification tooling — and then debugging all of it with no community to compare notes with. Scrypt gave me the opposite: a mature, battle-tested implementation I could fork, and an ecosystem that already speaks it.
02 · What you inherit by forking Litecoin
Litecoin has run Scrypt in production since 2011. Forking v0.21.5.5 meant inheriting more than a hash function:
- A hardened node. Years of consensus, networking and wallet code, including the soft-fork machinery (P2SH, SegWit, CSV) that a modern chain needs.
- The Scrypt tooling ecosystem. cgminer, existing pool software, and Scrypt-aware miners all understand the work format already. To a Scrypt miner, GCC work looks like any other Scrypt-family chain’s work.
- Compatible RPC and address formats. Because it’s a Bitcoin/Litecoin-lineage node, the JSON-RPC is the one operators already know, and bech32 addresses (here,
gcc1…) work the way you’d expect.
That last point is what makes the white-label hand-off tractable. A re-brand is a change to the chain parameters — magic bytes, ports, address prefix, reward, halving schedule — and a rebuild, not a rewrite of the cryptography.
03 · The honest trade-off: Scrypt has ASICs
Here’s the part people expect me to dodge. Scrypt is not ASIC-resistant. Commercially available Scrypt ASICs exist and have for years. If your goal is a chain only ordinary CPUs or GPUs can mine, Scrypt is the wrong pick, and you’d reach for something like RandomX (CPU) or a memory-hard GPU algorithm instead.
I don’t treat that as a flaw to hide; I treat it as a property to design around. For a reference/testnet substrate it barely matters — the point is to demonstrate the pipeline, not to defend a token economy. And for a buyer planning a real launch, ASIC availability is sometimes exactly what you want: it means specialised, efficient hardware exists and a recognisable mining market already understands your algorithm. What matters is that you choose it deliberately, with the trade-off in front of you, rather than inheriting it by accident.
Scrypt’s memory-hardness (the N=1024, r=1, p=1 parameter set) was an early attempt to keep mining accessible. ASICs caught up, as they tend to. That history is useful context, not a reason to pretend the current reality is different.
04 · When Scrypt is the right call — and when it isn’t
If you take the stack and launch your own chain, the algorithm is one of the first things you’ll set. A rough guide:
| You want… | Reach for |
|---|---|
| A proven, batteries-included substrate with mature pools | Scrypt (this chain) |
| CPU-friendly, broad participation, ASIC resistance today | RandomX |
| GPU-friendly, consumer cards, ASIC resistance | KAWPOW, Autolykos2, kHeavyHash |
| Maximum security budget, specialised hardware market | SHA-256 (ASIC) |
The engine speaks several of these; the pool page lists what it supports and there’s a small recommender to match an algorithm to the hardware you have. GCC is Scrypt because it’s the reference build, and Scrypt is the substrate that let me get the whole stack working and demonstrable without reinventing the parts that already work well.