# RandomX CPU PoW: Architecture, Build, and Adoption Limits

> RandomX is a CPU-oriented proof-of-work algorithm that combines random program execution with memory-hard techniques. It offers fast mining and light verification, but its 2 GiB fast-mode memory requirement and specialized execution model restrict where it fits.

**tevador/RandomX** — Proof of work algorithm based on random code execution

- Repository: https://github.com/tevador/RandomX
- Stars: 1,664 · Forks: 363
- Language: C++
- License: BSD-3-Clause
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/tevador-randomx

## RandomX targets CPU resistance through dynamic execution

RandomX solves a specific problem in proof-of-work design: reducing the efficiency advantage of specialized mining hardware. The README describes the algorithm as optimized for general-purpose CPUs and combines random code execution with memory-hard techniques. That goal differs from algorithms designed around a fixed, compact workload that ASICs can reproduce efficiently.

The project is primarily intended for cryptocurrency proof-of-work systems, especially designs where miners cannot simply select a favorable fixed key. The documentation identifies Monero as its original primary user and says RandomX was activated on the Monero network on 30 November 2019. It also links to configuration guidance for other cryptocurrency projects.

The project is written in C++11 and exposes a static library through the `randomx.h` C API. This makes it an implementation component rather than a complete mining application. The README names `randomx-benchmark` and `randomx-tests` as reference executables, while separate GPU miners are maintained outside this repository. A team considering adoption therefore needs a chain or wallet integration, not just the algorithm library.

## RandomX compiles generated programs into native code

RandomX uses a virtual machine whose instruction set covers integer mathematics, floating-point mathematics, and branches. The VM executes programs selected as part of the proof-of-work process. According to the README, these programs can be translated on the fly into the CPU's native machine code, with `doc/program.asm` presented as an example.

After program execution, the outputs are consolidated into a 256-bit result using Blake2b. The process therefore combines dynamic instruction generation with a conventional final hash operation. The detailed data flow, VM state, program construction rules, and dataset behavior are documented in `doc/specs.md`, while `doc/design.md` covers the design and analysis.

This architecture creates an important resource tradeoff. The generated program is intended to make fixed-function ASIC economics less attractive, but it also means that execution depends on CPU features and memory behavior. The README lists JIT compilers for x86-64, ARM64, and RISCV64. Other architectures use a portable interpreter, which the project describes as much slower.

## Fast mode and light mode share results but not memory cost

RandomX provides two interchangeable modes. Fast mode requires 2080 MiB of shared memory and is intended for mining. Light mode requires 256 MiB of shared memory but is significantly slower. The README states that both modes produce the same results, so a verifier can check work without allocating the mining dataset.

That distinction matters for deployment. A node that validates transactions or blocks may prefer light mode because its memory requirement is much lower than fast mode's. A mining service has a different profile because throughput and sustained execution matter more than minimizing verification memory. The project does not document a general-purpose API walkthrough in the README beyond pointing to `src/tests/api-example1.c` and `randomx.h`.

The memory figures also require care during capacity planning. The CPU FAQ recommends at least 2.5 GiB of free RAM per NUMA node and discusses memory-channel limits. Those figures appear in the context of efficient mining, not as a universal system-wide requirement for every possible light-mode use.

## Building RandomX with native or portable binaries

The Linux build requires `cmake` with minimum version 3.5 and `gcc` with minimum version 4.8. Version 7 or newer is recommended. The documented native build clones the repository, creates a build directory, configures CMake with `ARCH=native`, and compiles the project. The reader should end this procedure with the build products produced in the build directory, including the documented reference executables.

```bash
git clone https://github.com/tevador/RandomX.git
cd RandomX
mkdir build && cd build
cmake -DARCH=native ..
make
```

`ARCH=native` is intended to produce binaries optimized for the current machine. The README says to omit the `ARCH` option when portable binaries are needed. That choice trades machine-specific tuning for broader deployment compatibility.

Windows users can build with MinGW using the same general procedure as Linux, or use the supplied Visual Studio solution. Precompiled `randomx-benchmark` binaries are also linked from the Releases page. The README does not document a package-manager installation, so a new user should treat the source build or the release binary as the documented starting points rather than inventing an installation command.

## The first practical use is mining, not verification

The README's recommended proof-of-work use starts with a key `K` selected from blockchain data. The key block is the block whose hash supplies that key. For the stated Monero-like setup, the key should change every 2048 blocks, with a 64-block delay between the key block and the change of `K`. The document gives the condition `blockHeight % 2048 == 64` for the change and `keyBlockHeight % 2048 == 0` for selecting the key block.

The input `H` is described as the standard hashing blob with a selected nonce value. These two inputs drive the proof-of-work calculation. The project does not provide a standalone mining command in the README, and it does not claim that the repository contains a complete cryptocurrency miner. The supported first real use is therefore integration through the C API or use of the supplied benchmark executable.

For a new cryptocurrency, the README says to follow `doc/configuration.md`. Its ASIC-resistance requirement is explicit: `K` must change and must not be miner-selectable. If blockchain data cannot supply the key, it suggests a predefined sequence of keys.

## RandomX has hardware and memory boundaries

RandomX is not a portable equal-cost choice across all processors. The README identifies JIT support for x86-64, ARM64, and RISCV64, with a much slower portable interpreter for other architectures. Its CPU FAQ also lists a 64-bit architecture, IEEE 754 floating-point support, hardware AES support, specific cache sizes, large-page support, and sufficient free RAM as requirements for efficient mining.

GPUs are also at a disadvantage by design. The README points to external CUDA and OpenCL mining implementations and says the GPU code is included in XMRig, while explaining that GPUs are disadvantaged because RandomX was designed for CPUs. This does not mean GPUs cannot participate. It means their relative performance should not be compared using a generic assumption that every proof-of-work workload is equally suited to accelerator hardware.

A more basic limitation is the security and configuration burden of dynamic keys. The README's warning about miner-selectable keys shows that algorithm adoption is partly a consensus design decision. If the key changes incorrectly, is too predictable, or can be chosen by miners, the intended ASIC-resistance property is not established.

## Licensing and upgrades leave integration work to the adopter

RandomX is distributed under the BSD-3-Clause license. The repository also includes design documents, audits, a Visual Studio solution, source files, and reference tests. The license identifier is clear, but this review does not provide legal advice about how a particular cryptocurrency, mining service, or commercial product should comply with it.

The repository is not archived. Its last push was on 2026-10-16, and recent releases include v1.2.3 dated 2026-07-17, v2.0.1 dated 2026-05-10, and v1.2.2 dated 2026-05-10. The README does not provide a compatibility policy, migration guide, or release cadence, so upgrading the algorithm or library requires checking the relevant release contents and integration code directly.

The README reports four independent security audits conducted from May through August 2019. It says none found critical vulnerabilities, and that changes were made as a direct result of the audits. Those reports provide historical review evidence, but they do not replace checking the current implementation and configuration being selected.

## Conclusion

RandomX is appropriate for a cryptocurrency that deliberately targets general-purpose CPUs and can support dynamic keys tied to blockchain data. It is a poor fit for systems needing low-memory verification or users expecting equal efficiency across GPUs and specialized hardware. Before adoption, verify the key-change schedule, memory model, architecture support, and the operational cost of running the fast mode.

## FAQ

### What is RandomX used for?

RandomX is a proof-of-work algorithm intended primarily for cryptocurrency systems that favor general-purpose CPUs over specialized mining hardware. The README identifies Monero as its original primary user.

### How much memory does RandomX fast mode require?

Fast mode requires 2080 MiB of shared memory. The README presents it as the mode suitable for mining, while light mode requires 256 MiB for slower verification with the same results.

### Can RandomX be used on GPUs?

The README points to external CUDA and OpenCL mining implementations, with code included in XMRig. It also states that GPUs are at a disadvantage because RandomX was designed to be efficient on CPUs.

## Sources

- [Issues](https://github.com/tevador/RandomX/issues)
- [License: BSD-3-Clause](https://github.com/tevador/RandomX/blob/master/LICENSE)
- [README](https://github.com/tevador/RandomX/blob/master/README.md)
- [Releases](https://github.com/tevador/RandomX/releases)
- [tevador/RandomX on GitHub](https://github.com/tevador/RandomX)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tevador-randomx