Xelishash V3 Memory Hardness
A few days ago, in my article on memory-hardness trade-offs, I mentioned Xelishash V3 as an example of a PoW algorithm that was raising its memory footprint as they have upcoming Hard Fork soon with new algorithm updates. After exchanging a few messages with Slixe (the developer of Xelis). Time for a correction and a deeper look, because what they actually did is subtler and, in my opinion, quite elegant for now.
What actually changed in V3?
- Scratchpad size increased from 440 KiB → 540 KiB per hash instance
- ChaCha rounds doubled from 10 → 20 (primarily to cut the GPU core advantage in half)
- Memory pattern access to the scratchpad are now using fully random indexes (vs deterministic before)
- Increased memory chain in computation to force the core to wait on the memory (which make it memory latency dependent)
- Removed the div/mod for scratchpad indexes computation, using murmurhash3 finalizer to distribute the indexes correctly using a high-mul
540 KiB doesn’t sound like much, but when you run thousands of parallel threads (which is exactly what GPUs love to do), it adds up fast.
Why this matters on GPUs
Let’s do the math for an Nvidia RTX 4090:
- 16,384 CUDA cores
- Each core running one hash instance needs its own 512 KiB scratchpad
- 16,384 × 540 KiB = 9.05 GB of VRAM just for the scratchpads
Upcoming hashrates
GPUs
- RTX 3070: 29.50 kh/s 130W to 5.9 KH/s 75w
- RTX 3080 Ti: 51.00 kh/s 250W to 8.3 KH/s 166w
- RTX 4090 39.00 kh/s to 11.6KH/s 156w
- RTX 5080 57.00 kh/s 160W to 11.3 KH/s 108w
- RTX 5070 50 KH/s 130W to 7.83 KH/s 106w
CPUs without XelishashV2 comparison.
- EPYC 7B12 25 KH/s
- 7950XD 19.6 KH/s
- 7950X 17.5 KH/s
- 9950X 16.5 KH/s
- 9950 16.3 KH/s
- 5950X ~10–11 KH/s
These are hashrates that Slixe sent me.
Not a fixed memory-hard requirement
Unlike classic memory-hard functions (Ethash, KawPoW, ProgPoW, etc.) that enforce a minimum N MB dataset no matter what, Xelishash ties the memory usage to the degree of parallelism the hardware tries to use.
- A CPU with 16–32 threads → only 8–16 MiB of RAM used → perfectly fine
- An older GPU with fewer cores → still comfortable
- A top-tier GPU trying to run 20k+ threads → almost hits the memory wall
In other words, Xelishash doesn’t punish low-parallelism devices with artificial memory bloat. It only punishes excessive parallelism. The more threads you try to run in parallel, the more memory you burn. It turns parallelism itself into the bottleneck.
Get Hoosat Network’s stories in your inbox
Join Medium for free to get updates from this writer.
The CPU’s also have benefit with extremely fast caches which can fit the 512kB scratchpad. Which gives them little bit of boost in the hashrate, even though they are not doing as much of parallel processing as the GPUs.
Comparison with my own Hoohash approach
I’ve been taking a slightly different route with Hoohash: instead of scaling memory with parallelism, I force every lane to perform heavy FP64 (double-precision) non-linear operations that are extremely costly on consumer GPUs (2–64 x slower than FP32). The effect is similar, the RTX 4090 still can’t use its full theoretical performance, but the mechanism is compute-bound rather than memory-bound.
Xelishash V3 went memory-bound in a dynamic way. Hoohash goes compute-bound with mandatory FP64 non-equation precision.
Same destination (FPGA/ASIC resistance without harming CPUs too much), different roads.
Here’s little difference between the hashrate and power usage between XelishashV3 and Hoohash.
- XelishashV3 RTX 3070: 5.9 KH/s 75w
- Hoohash RTX 3070 960 KH/s 55w
- XelishashV3 RTX 3080 Ti: 8.3 KH/s 166w
- Hoohash RTX 3080 Ti: 1900 Kh/s 93w
- XelishashV3 RTX 4090 11.6KH/s 156w
- Hoohash RTX 4090: 2400 Kh/s 109w
One notable thing I notice between the Memory Hardness and Core Hardness. Memory Hardness seems to have higher power consumption.
Conclusion
Xelishash V3 is not the “huge memory jump” I initially thought. It’s actually a very measured, almost minimalist change , just +100 KiB and double ChaCha rounds, yet it achieves a disproportionate leveling effect on high-end GPUs.
That’s good design: maximum impact with minimum collateral damage.
So yes, Xelishash V3 remains one of the most convincingly egalitarian algorithms out there right now with Hoohash. It just does it with surgical precision rather than a sledgehammer.
Respect to Slixe and the Xelis team, sometimes less really is more.
