Journeys October 2026 Live Core Dev Bootcamp in New YorkBuild & run your own xrpld nodeLive now
intermediate 120 min

Build & run your own xrpld node

Turn the open-source rippled code into a running node: set up the C++ toolchain, compile the `xrpld` binary with Conan + CMake, then run it locally in standalone mode.

What you'll learn

  • Set up a C++ build environment (compiler, CMake, Conan, Python) on macOS or Ubuntu.
  • Fetch dependencies with Conan and configure the build with CMake.
  • Compile the `xrpld` binary from source and confirm it runs.
  • Run xrpld in standalone mode and drive it over the API.
Complete this module by mentor review and a quiz. Jump to assessment

Introduction

≈120 min (including compile time) · Intermediate · start here, no prerequisites

Welcome, this is where your journey under the hood of the XRP Ledger begins. Before you can read the code, trace a transaction, or change the protocol, you need your own node running. In this module you'll set up the C++ toolchain, compile the xrpld binary from the open-source rippled source with Conan and CMake, and launch it locally in standalone mode so you can drive it over the API. Take your time with the build, everything that follows in the bootcamp runs on the node you create here.


macOS

In brief: set up the build toolchain on macOS: Node, Clang/Xcode, Python, then Conan and CMake.

Install Node.js via nvm for easy version management:

# Install nvm (if not already installed)
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash

# Install and use the latest LTS version of Node.js
nvm install --lts
nvm use --lts

Prerequisites for Compiling Rippled

  • macOS with administrator rights
  • Apple account (to download certain versions of Xcode)
  • Stable internet connection for dependencies

Checking Clang Version

clang --version

Installing Xcode (if needed)

Version check. xrpld 3.2.0 builds with current Xcode: Xcode 26.6 is confirmed to work. The minimum compiler is Apple Clang 16. If your clang --version reports anything older, update Xcode before going further, the build will fail late and cryptically otherwise.

  1. Download Xcode from the Mac App Store or from Apple Developer. Current versions install directly as /Applications/Xcode.app, there is no .xip to extract anymore.
  2. Select it as the default toolchain:
sudo xcode-select -s /Applications/Xcode.app/Contents/Developer
export DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer
  1. Verify the installation:
clang --version
git --version

clang --version should report an Apple clang for your Xcode (16.0.0 or newer).

If you need a specific older version: Apple Developer Downloads still ships versioned .xip archives (e.g. Xcode_16.2.xip). Extract, rename (e.g. Xcode_16.2.app), move it to /Applications, and point xcode-select -s and DEVELOPER_DIR at that path instead.

Installing Build Tools

# Homebrew
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

# Essential dependencies
brew update
brew install xz pyenv

Python Configuration

# Install Python 3.11 (or higher) via pyenv
pyenv install 3.11.13
pyenv global 3.11.13
eval "$(pyenv init -)"

# Install Conan (2.17+) and CMake (3.22+)
pip install 'conan>=2.17'
pip install 'cmake>=3.22'

Ubuntu

In brief: the same toolchain on Ubuntu, installed through apt and pipx.

Prerequisites

  • Ubuntu with administrator rights
  • Stable internet connection

Installing Build Tools


Compilation Process & Generating Binary

In brief: clone rippled, configure Conan and CMake, then compile the xrpld binary.

Building Rippled from Source

Key idea. The binary you are building is called xrpld. "rippled" is the project and the repository; xrpld is the daemon it produces, so that is the name you will run.


Introduction

Once your development environment is properly configured, the next step is to obtain and build the Rippled source code.
Rippled uses a modern C++ toolchain and relies on Conan for dependency management and CMake for project configuration. These tools ensure consistent builds across different systems while maintaining compatibility with the C++20 standard.

This section will guide you through:

  • Cloning the official Rippled repository from the XRPL Foundation’s GitHub.
  • Setting up Conan profiles for macOS and Ubuntu.
  • Configuring the CMake build system.
  • Compiling the Rippled executable in Debug mode.

By following these steps, you’ll have a local, fully compiled version of Rippled, ready for testing, development, and contributing to the XRPL Core.


Cloning the Rippled Repository

Grab the source and switch to the development branch:

mkdir -p ~/projects
cd ~/projects
git clone https://github.com/XRPLF/rippled.git
cd rippled
git checkout 3.2.0

Conan Configuration

Importing default Conan profil.

conan config install conan/profiles/ -tf $(conan config home)/profiles/
  • You can check your Conan profile by running
conan profile show

If the default profile does not work for you and you do not yet have a Conan profile, you can create one by running:

conan profile detect

The recipes in Conan Center occasionally need to be patched for compatibility with the latest version of rippled.

To ensure our patched recipes are used, you must add our Conan remote at a higher index than the default Conan Center remote, so it is consulted first. You can do this by running:

conan remote add --index 0 xrplf https://conan.ripplex.io

Build Directory Structure

The rippled repository layout: bin/ (tooling), build/ (artifacts, the xrpld binary), cfg/ (example configs), src/ (source code), CMakeLists.txt and README.md

Compiling Rippled

The full build. Expect 30 to 60 minutes the first time:

# Create the build directory
mkdir -p build && cd build

# Install dependencies via Conan
conan install .. --output-folder . --build missing --settings build_type=Debug

# Pass the CMake variable CMAKE_BUILD_TYPE and make sure it matches the one of the build_type settings you chose in the previous step
cmake -DCMAKE_TOOLCHAIN_FILE:FILEPATH=build/generators/conan_toolchain.cmake -DCMAKE_BUILD_TYPE=Debug -Dxrpld=ON -Dtests=ON ..

# Build Rippled
cmake --build . --parallel 10

Compilation may take 30 to 60 minutes depending on your machine.

Verifying the Build

Once compilation completes successfully, confirm that the Rippled binary has been created:

# still inside the build/ directory from the previous step
ls ./xrpld

Depending on your CMake generator, the binary may instead be at ./Debug/xrpld (or ./Release/xrpld) for multi-config generators.

Then, check the version to ensure the binary runs correctly:

./xrpld --version

Local Development & Testing

In brief: run your fresh node in standalone mode and drive it with the explorer and playground.

Running Rippled in Standalone Mode


Introduction

Once built, Rippled can run in standalone mode, a fully local setup for testing transactions and ledger behavior without connecting to the XRPL network.
It offers full API access and manual ledger control, perfect for isolated development.

You’ll learn to launch Rippled locally and explore it with XRPL Explorer and Playground to simulate end-to-end XRPL workflows.


In stand-alone mode, the server operates without connecting to the network and participating in the consensus process. Without the consensus process, you have to manually advance the ledger and no distinction is made between "closed" and "validated" ledgers. However, the server still provides API access and processes transactions the same.

Learn more about stand-alone mode.

cd ~/projects/rippled/build
cp ../cfg/xrpld-example.cfg ./xrpld.cfg

Watch out. Launched as-is, the copied config aborts twice. First, it points at system paths (/var/lib/xrpld/db, /var/log/xrpld/debug.log) that only root can create: Can not create "/var/lib/xrpld/db". Second, its [validators_file] section requires a validators.txt next to the config: The file specified in [validators_file] does not exist. And since every xrpld invocation parses the config, even a client command like submit hits the same abort. Fix both before the first launch.

Create a local data directory, rewrite the three paths in xrpld.cfg, and provide the validators file:

mkdir -p db
sed -i.bak \
  -e 's|^path=/var/lib/xrpld/db/nudb|path=./db/nudb|' \
  -e 's|^/var/lib/xrpld/db|./db|' \
  -e 's|^/var/log/xrpld/debug.log|./debug.log|' \
  ./xrpld.cfg

# [validators_file] requires this file to exist, even in standalone.
# The example is entirely commented out = an empty trust list, which is
# exactly right here: standalone runs no consensus, so no validators needed.
cp ../cfg/validators-example.txt ./validators.txt

(Or edit them by hand; the result should read:)

[node_db]
type=NuDB
path=./db/nudb

[database_path]
./db

[debug_logfile]
./debug.log

Then launch:

./xrpld -a --conf ./xrpld.cfg
  • Optional variant: starting from a genesis ledger file

A --ledgerfile lets you start from a predefined first ledger instead of the default empty one. The one below contains three state entries: an account holding the full XRP supply, an Amendments entry with 78 amendments pre-enabled (so protocol features work from ledger 1 without any voting), and the fee settings.

Watch out. With --ledgerfile you are no longer in the default standalone starting state: your ledger 1 is whatever the file defines. The rest of this module, in particular the "Create and fund test accounts" loop below, assumes the default start without --ledgerfile. If you use a ledger file, skip that loop and define your starting accounts directly in the file instead (add their AccountRoot entries to accountState).

Save it as genesis.json in your build/ directory, then launch with it:

./xrpld -a --conf ./xrpld.cfg --ledgerfile ./genesis.json

The following options determine which ledger to load first when starting up.

  • Check the logs to confirm that the server is running correctly.

Create and fund test accounts (standalone)

Prerequisite: a running node, started the default way. Every command below talks to a live xrpld instance started without --ledgerfile: keep ./xrpld -a --conf ./xrpld.cfg running in its own terminal, open a second terminal in the same build/ directory, and run the commands there. If the node is not running they all fail with a connection error; if you started from a ledger file, this loop does not apply (your starting accounts come from the file itself).

Standalone mode has no faucet. You fund accounts yourself from the genesis account, which holds the entire XRP supply and whose credentials are public knowledge in standalone: address rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh, seed snoPBrXtMeMyMHUVTgbuqAfg1SUTb (derived from the passphrase masterpassphrase). Nearly every lab in this bootcamp assumes two funded test accounts, so learn this four-step loop now:

Repeat steps 1, 2 and 4 for a second account. Until ledger_accept runs, the payment sits in the open ledger; account_info on a validated ledger only sees it after the close.

Key idea. Standalone funding is always the same loop: wallet_propose, pay from genesis, ledger_accept, verify. Every "create two funded test accounts" instruction in later modules means exactly this.

Interacting with Rippled via the XRPL Technical Explorer

The XRPL Technical Explorer is XRPLF's technical (JSON-first) explorer for ledgers, transactions, and objects. Pointed at your standalone node, it gives you a click-through view of everything you submit.

  1. Clone and install it (once), in your home directory:
cd ~
git clone https://github.com/xrplf/xrpl-technical-explorer.git
cd xrpl-technical-explorer
npm install
  1. Launch it against your local node's WebSocket port (6006 with the example config, while xrpld runs):
NODE_OPTIONS=--openssl-legacy-provider VUE_APP_WSS_ENDPOINT=ws://localhost:6006 npm run serve

Watch out. Without NODE_OPTIONS=--openssl-legacy-provider, modern Node (17+) aborts the build with Error: error:0308010C:digital envelope routines::unsupported (ERR_OSSL_EVP_UNSUPPORTED): the explorer's older webpack uses a hash algorithm that OpenSSL 3 disabled by default, and this flag re-enables it for the dev server only. Alternative if you prefer: nvm install 16 && nvm use 16, then run without the flag.

  1. Navigate to http://localhost:8080/ and explore: submit a payment from your second terminal, close the ledger with ledger_accept, then click through the ledger, the transaction, and its metadata in the explorer.

Watch out. The explorer will sit on "Waiting for the next ledger to close..." forever until you close one. That is standalone working as designed: with no consensus, nothing closes ledgers for you. Use the Close ledger button at the top right of the explorer: connected to your node's admin WebSocket, it triggers a ledger_accept, which closes the current open ledger and makes your submitted transactions land. Click it after every transaction (or batch) you want to see; running ./xrpld --conf ./xrpld.cfg ledger_accept from the second terminal does exactly the same thing.

  1. Cross-check what the explorer shows with the same data over RPC: server_info, ledger_current, account_info.

Summary

This module got your development node running. You set up the C++ toolchain (compiler, CMake, Conan, Python) on macOS or Ubuntu, compiled the xrpld binary from the open-source rippled source, and launched it in standalone mode, a fully local setup where you control the ledger and drive the node over the API. That node is the foundation every later module builds on.

To remember:

  • Toolchain: Python 3.11+, Conan 2.17+, CMake 3.22+; rippled 3.2.0 is C++20 (GCC 12 / Clang 16 / Apple Clang 16 minimum; Xcode 26.6 confirmed on macOS)
  • The repository is rippled; the binary it builds is xrpld
  • Check out the stable tag: git checkout 3.2.0
  • Add the patched Conan remote first: conan remote add --index 0 xrplf https://conan.ripplex.io
  • Build: conan install .. --build missing, then cmake -Dxrpld=ON -Dtests=ON .., then cmake --build . --parallel
  • Standalone mode: ./xrpld -a --conf ./xrpld.cfg; you advance the ledger yourself with ledger_accept
  • Before the first launch: repoint [node_db] path, [database_path] and [debug_logfile] to local paths, and cp ../cfg/validators-example.txt ./validators.txt (required by [validators_file] even in standalone)
  • Standalone funding: wallet_propose, pay from genesis (rHb9...dtyTh, seed snoPBrXtMeMyMHUVTgbuqAfg1SUTb), ledger_accept, account_info
  • Config examples live in cfg/ (xrpld-example.cfg, validators-example.txt)
  • Watch out: the Conan build_type and CMake CMAKE_BUILD_TYPE must match, and the first build takes 30 to 60 minutes

Next up. Your node runs, but right now it is a black box that happens to answer RPC calls. Time to open it: who wires those seventy subsystems together when the process starts? Meet the Application layer.

Assignments

0 of 2 complete

XRPL Academy © 2026