Monero’s proof of work is called RandomX.
Monero does not ask miners to run the same tiny hash function over and over. It asks them to run a small random program on a virtual machine, hit memory hard while doing it, and then hash the result.
Bitcoin’s proof of work is great for specialized chips because the work never changes. RandomX was built to do the opposite. It tries to make efficient mining look as much like a normal CPU workload as possible.
Here is the shortest useful summary:
The interesting part is not the yes-or-no rule at the end. Every proof-of-work system has that. The interesting part is how Monero makes each hash attempt expensive in the exact ways normal CPUs are good at and custom chips hate.
If your proof of work is just “run this fixed function on new inputs until you get a lucky output,” hardware designers have a clear job: build silicon that runs that exact function as cheaply and as fast as possible.
That is what happened to Bitcoin with SHA-256 ASICs.
Monero did not want that path. Long before RandomX, the project was explicit that specialized mining hardware creates centralization pressure. Fewer manufacturers matter more. Large farms matter more. Ordinary users matter less.
Monero’s earlier answer was the CryptoNight family. Later, in late 2019, Monero switched to RandomX, which its own release notes described as a new proof of work “based on random instructions, adapted to CPUs.”
So the design target changed from make memory matter to make a whole CPU matter.
RandomX starts from one observation: CPUs are not just arithmetic boxes. They are flexible machines built to run changing code and juggle a lot of hardware features at once.
A modern CPU has:
Normal cryptographic hashes do not use much of that variety. They mostly push data through a fixed pipeline.
RandomX tries to bind proof of work to those broader CPU strengths. Its design document says the work must be dynamic. That means the miner is not just feeding in new data. The miner is also getting new code to run.
That is why RandomX is based on random code execution.
At the Monero level, RandomX takes two important inputs:
KHFor Monero, K comes from an older block hash, called the key block. The RandomX reference README recommends changing this key every 2048 blocks with a 64-block delay, and that is how Monero wires it in.
That detail matters because miners do not rebuild the heavy shared memory structures for every nonce. They rebuild them only when the key changes, roughly every 2.8 days.
H is the candidate block hashing blob with a chosen nonce. That is the part miners keep changing over and over.
So you can think of Monero mining like this:
KHThe environment changes slowly. The attempt changes constantly.
RandomX first takes the key K and runs Argon2d on it.
Argon2d is better known as a password-hashing and key-derivation function. It is useful here for the same reason it is useful there: it is memory-hard. It forces the machine to touch a lot of memory in a way that is annoying to cheat.
In the default RandomX parameters, this produces a 256 MiB cache.
That cache is the smaller of the two big memory structures in RandomX. It is not the structure miners want to use directly for maximum speed. It is the structure used to build the bigger one.
From that 256 MiB cache, RandomX builds the dataset.
The default dataset size is:
2,147,483,648 bytes base size33,554,368 bytes extra sizeTogether that is about 2080 MiB, a little over 2 GiB.
This odd-looking size is deliberate. It is big enough to spill out of on-chip memory and into DRAM, and the extra non-power-of-two tail makes life more annoying for hardware designers.
The dataset is read-only during hashing. RandomX uses it to force regular DRAM traffic. The design doc says each program iteration reads one 64-byte dataset item, and across a whole hash result that becomes 16,384 dataset reads.
That gives RandomX one of its main bottlenecks: memory access, not just arithmetic.
Now RandomX turns to the per-hash input H.
It computes Hash512(H) using Blake2b. That 64-byte result seeds an AES-based generator, which fills the scratchpad.
The scratchpad is the VM’s working memory. Unlike the large dataset, it is meant to live in CPU cache, not DRAM.
Its default size is 2 MiB, split to mimic CPU cache levels:
16 KiB L1256 KiB L22 MiB L3This is one of the smartest parts of RandomX. It uses two very different memory structures at once:
That lets it pressure both the memory subsystem and the CPU core.
After the scratchpad is ready, RandomX generates a program for its virtual machine.
This is not a C program or a JavaScript program. It is a compact VM program with its own instruction set.
Two details matter a lot:
That second choice is a big deal. It means RandomX can generate programs by just filling a buffer with random bytes. There is no slow parser and no complicated syntax checking.
Each program contains 256 instructions.
Those instructions are chosen to look like work real CPUs are built for:
The floating-point side is not cosmetic. RandomX uses IEEE 754 double precision operations, including division and square root, and it uses all four standard rounding modes. That makes the VM harder to collapse into a tiny “mostly integer” custom design.
The VM executes the 256-instruction program in a loop for 2048 iterations.
During each iteration it:
The design doc says an average iteration reads about 504 bytes from memory and writes about 256 bytes.
That number is a clue to what RandomX is really doing. It is not “a hash with extra steps.” It is trying to behave like messy, mixed, real software.
Branches are easy to overlook, but they matter.
If the code were fully straight-line, specialized hardware could optimize away more of it. Branches make static simplification harder.
RandomX uses branches sparingly. A branch is taken with probability about 1/256, and the design intentionally makes these branches usually predict as “not taken.” That means they are cheap on CPUs most of the time, while still getting in the way of over-optimized hardware shortcuts.
The important point is not that RandomX found some magic branch predictor trick. It did not. The point is that even a little real control flow makes the workload look more like actual code and less like a clean hardware pipeline.
One random program is not enough.
If miners only had to run a single random program, a dishonest miner could try to inspect the program first and skip “bad” ones. Or a custom chip designer could support only the subset of programs that are easy for their hardware.
RandomX blocks that by chaining 8 programs together.
The output state of one program becomes the seed for the next. So once you start, you cannot know the whole chain in advance. You either finish the chain or throw away work you already paid for.
This is one of the cleanest ideas in RandomX. It turns “maybe I will only do the easy jobs” into a bad strategy.
After the last of the 8 programs finishes, RandomX still has to turn all that machine state into one final digest.
It does two things:
That final 256-bit result is the RandomX output.
At the Monero level, the miner checks whether that result is below the current difficulty target. If yes, the block wins. If no, the miner changes the nonce and tries again.
RandomX has two modes:
2080 MiB dataset256 MiB cache and computes dataset items on the flyBoth modes give the same answer.
Verification has to agree with mining, but the two modes do not cost the same amount of work.
Fast mode is for mining. Light mode is for verification. The reference README says exactly that, and this split is one of RandomX’s best design choices.
If every verifier needed more than 2 GiB just to check one proof of work, that would be ugly. If light mode were cheap enough to mine competitively, that would also be ugly. RandomX tries to stay in the middle: verification should be practical, but not attractive as a mining shortcut.
The design document explicitly aims for light mode to lose on the memory-time tradeoff. In plain English, if you save memory, you should pay back that advantage in extra work.
“CPU-friendly” can sound like marketing, so it is worth being specific.
RandomX favors CPUs because it leans on the things good CPUs already have:
The reference implementation even includes JIT compilers for x86-64, ARM64, and RISCV64, so the VM programs can be translated into native machine code on the fly instead of being interpreted instruction by instruction.
That does not make ASICs impossible forever. Nothing honest should claim that. What it does is make the custom-chip job much uglier. A good RandomX ASIC starts looking less like a neat fixed-function hash engine and more like “build a weird expensive CPU with a lot of memory attached.” That shrinks the advantage.
RandomX is not mainly about raw speed. It is about hardware economics.
Monero wants proof of work that:
That is why RandomX looks so strange if you expect a normal mining hash.
It is not trying to be elegant in the Bitcoin sense. It is trying to be awkward for specialization.
If Bitcoin mining is “run this one small machine forever,” Monero mining is “keep generating little CPU-flavored workloads and survive the memory traffic.”
That is the shortest mental model I know that is still true.
Under the hood, RandomX is a stack of careful choices:
Put those together and you get Monero’s proof of work today.
It is not simple. But the point is simple: make mining look like general-purpose computing, so specialized hardware gets less room to run away with the network.