docs: Document the JSON-RPC 2.0 changes in API version 3

`API-VERSION-3.md` describes two handler changes and nothing else, so
everything the JSON-RPC 2.0 work does is readable only from the code.
Describe the reply envelope, the two request spellings, the batch form, the
notification shape, and the `error_code` change on the `ledger_entry`
tokens, with the wire shape a client must handle for each. The version's own
document carries the detail and the changelog a summary plus the entries that
reach every version.

Every departure from the specification is stated in one place: a request
naming no `id` still receives a reply; `error.code` is `-32000` for every
failure a command reports, `unknownCmd` excepted; a rejection the server
cannot attribute to an API version is a plain text body, so a client must
tolerate a non-JSON reply for that class; a batch stops once the connection
is over the drop threshold, so a reply array can be shorter than the request
array; a subscriber named by a `url` keeps the legacy `event` call at every
version; `ripplerpc` is ignored; and a `subscribe` naming a second version is
refused.

`cfg/xrpld-example.cfg` never said which version `[beta_rpc_api]` unlocks,
and neither document said the section needs a value line, a bare header
leaving the flag off. All three say so now.

.clang-tidy

@@ -5,7 +5,10 @@ Checks: "-*,
   -bugprone-exception-escape,
   -bugprone-implicit-widening-of-multiplication-result,
   -bugprone-narrowing-conversions,
+  -bugprone-signed-bitwise,
+  -bugprone-std-exception-baseclass,
   -bugprone-throwing-static-initialization,
+  -bugprone-unhandled-code-paths,
 
   cppcoreguidelines-*,
   -cppcoreguidelines-avoid-c-arrays,
@@ -14,6 +17,7 @@ Checks: "-*,
   -cppcoreguidelines-avoid-magic-numbers,
   -cppcoreguidelines-avoid-non-const-global-variables,
   -cppcoreguidelines-c-copy-assignment-signature,
+  -cppcoreguidelines-explicit-constructor,
   -cppcoreguidelines-interfaces-global-init,
   -cppcoreguidelines-macro-usage,
   -cppcoreguidelines-missing-std-forward,
@@ -32,6 +36,7 @@ Checks: "-*,
   llvm-namespace-comment,
 
   misc-*,
+  -misc-explicit-constructor,
   -misc-multiple-inheritance,
   -misc-no-recursion,
   -misc-non-private-member-variables-in-classes,
@@ -45,6 +50,8 @@ Checks: "-*,
   -modernize-avoid-c-style-cast,
   -modernize-return-braced-init-list,
   -modernize-use-integer-sign-comparison,
+  -modernize-use-string-view,
+  -modernize-use-structured-binding,
   -modernize-use-trailing-return-type,
 
   performance-*,
@@ -53,6 +60,7 @@ Checks: "-*,
   -performance-noexcept-move-constructor,
   -performance-unnecessary-copy-initialization,
   -performance-unnecessary-value-param,
+  -performance-use-std-move,
 
   readability-*,
   -readability-avoid-const-params-in-decls,
@@ -65,7 +73,11 @@ Checks: "-*,
   -readability-named-parameter,
   -readability-qualified-auto,
   -readability-redundant-access-specifiers,
+  -readability-redundant-nested-if,
+  -readability-redundant-qualified-alias,
   -readability-static-accessed-through-instance,
+  -readability-trailing-comma,
+  -readability-trivial-switch,
   -readability-uppercase-literal-suffix
   "
 # ---
@@ -81,6 +93,10 @@ CheckOptions:
   bugprone-unsafe-functions.ReportMoreUnsafeFunctions: true
   bugprone-unused-return-value.CheckedReturnTypes: ::std::error_code;::std::error_condition;::std::errc
 
+  # New in clang-tidy 23; disabled until the code is updated
+  misc-const-correctness.AnalyzeAutoVariables: false
+  misc-const-correctness.AnalyzeLambdas: false
+  misc-const-correctness.AnalyzeParameters: false
   misc-include-cleaner.IgnoreHeaders: ".*/(detail|impl)/.*;.*fwd\\.h(pp)?;time.h;stdlib.h;sqlite3.h;netinet/in\\.h;sys/resource\\.h;sys/sysinfo\\.h;linux/sysinfo\\.h;__chrono/.*;bits/.*;_abort\\.h;boost/.*;openssl/obj_mac\\.h"
 
   readability-braces-around-statements.ShortStatementLines: 2

.cspell.config.yaml

@@ -255,6 +255,7 @@ words:
   - queuable
   - Raphson
   - rcflags
+  - reencrypted
   - replayer
   - repodata
   - repomd

.envrc

@@ -8,3 +8,7 @@ watch_file rust-toolchain.toml
 watch_dir conan
 
 use flake
+
+# Optional, untracked local overrides. To use a different shell, put e.g.
+# `use flake .#formal-verification` in .envrc.local.
+source_env_if_exists .envrc.local

.gersemi/definitions.cmake

@@ -108,3 +108,75 @@ endfunction()
 
 function(patch_nix_binary target)
 endfunction()
+
+function(rpcspec_generate_instantiations)
+    set(options)
+    set(oneValueArgs OUT_VAR VALUE_TYPE VIEW_HEADER INCLUDE_DIR)
+    set(multiValueArgs HANDLERS)
+    cmake_parse_arguments(
+        THIS_FUNCTION_PREFIX
+        "${options}"
+        "${oneValueArgs}"
+        "${multiValueArgs}"
+        ${ARGN}
+    )
+endfunction()
+
+function(corrosion_import_crate)
+    set(options
+        ALL_FEATURES
+        NO_DEFAULT_FEATURES
+        NO_STD
+        NO_LINKER_OVERRIDE
+        NO_USES_TERMINAL
+        LOCKED
+        FROZEN
+    )
+    set(oneValueArgs MANIFEST_PATH PROFILE IMPORTED_CRATES)
+    set(multiValueArgs
+        CRATE_TYPES
+        CRATES
+        FEATURES
+        FLAGS
+        OVERRIDE_CRATE_TYPE
+    )
+    cmake_parse_arguments(
+        THIS_FUNCTION_PREFIX
+        "${options}"
+        "${oneValueArgs}"
+        "${multiValueArgs}"
+        ${ARGN}
+    )
+endfunction()
+
+function(corrosion_set_env_vars target_name env_var)
+endfunction()
+
+function(corrosion_add_cxxbridge cxx_target)
+    set(options)
+    set(oneValueArgs CRATE)
+    set(multiValueArgs FILES)
+    cmake_parse_arguments(
+        THIS_FUNCTION_PREFIX
+        "${options}"
+        "${oneValueArgs}"
+        "${multiValueArgs}"
+        ${ARGN}
+    )
+endfunction()
+
+function(_unlink_libgcc_s crate)
+endfunction()
+
+function(add_xrpl_crate name)
+    set(options)
+    set(oneValueArgs CRATE)
+    set(multiValueArgs FILES)
+    cmake_parse_arguments(
+        THIS_FUNCTION_PREFIX
+        "${options}"
+        "${oneValueArgs}"
+        "${multiValueArgs}"
+        ${ARGN}
+    )
+endfunction()

.git-blame-ignore-revs

@@ -5,6 +5,18 @@
 # This file is sorted in reverse chronological order, with the most recent commits at the top.
 # The commits listed here are ignored by git blame, which is useful for formatting-only commits that would otherwise obscure the history of changes to a file.
 
+# chore: CamelCase for typedef/using in `clang-tidy` (#8177)
+97a1824537d20d82d25bf151a37a7a4532ebf085
+# chore: Rename CamelCase namespaces to snake_case (#7933)
+06488c1318d96f56d0536251bee08ac85fa7fdd3
+# style: Unify style for all Doxygen comments (#7776)
+73b6852a122854140336e6e6bc30a3a4b41aa5fd
+# style: More clang-tidy identifier renaming (#7290)
+a830ab10efed8d3e59ef2fc15d66efdf9c6bb0d8
+# refactor: Rename static constants (#7120)
+5b6e8b6f93b19c1e3f6a3467a25639031d9d9a53
+# chore: More fixes for bad renames (#7092)
+7afdd71a54d562b32a50b29a5aa00bb997dc9053
 # refactor: Enable clang-tidy `readability-identifier-naming` check (#6571)
 8995564ed6b9e453e144bb663303072a3c1ba305
 # refactor: Enable remaining clang-tidy `cppcoreguidelines` checks (#6538)

.github/actions/build-deps/action.yml

@@ -15,9 +15,9 @@ inputs:
     required: false
     default: "false"
   log_verbosity:
-    description: "The logging verbosity."
+    description: 'The logging verbosity ("quiet", "verbose"), or empty to use the Conan defaults.'
     required: false
-    default: "verbose"
+    default: ""
   sanitizers:
     description: "The sanitizers to enable."
     required: false
@@ -35,6 +35,16 @@ runs:
         LOG_VERBOSITY: ${{ inputs.log_verbosity }}
         SANITIZERS: ${{ inputs.sanitizers }}
       run: |
+        # By default, leave the verbosity unset, so CMake configure output is
+        # shown, but compile commands and Boost's b2 debug output (~85k lines
+        # when "verbose") are not.
+        VERBOSITY_ARGS=()
+        if [[ -n "${LOG_VERBOSITY}" ]]; then
+            VERBOSITY_ARGS=(
+                --conf:all tools.build:verbosity="${LOG_VERBOSITY}"
+                --conf:all tools.compilation:verbosity="${LOG_VERBOSITY}"
+            )
+        fi
         conan install \
             --profile:all ci \
             --build="${BUILD_OPTION}" \
@@ -42,6 +52,13 @@ runs:
             --options:host='&:xrpld=True' \
             --settings:all build_type="${BUILD_TYPE}" \
             --conf:all tools.build:jobs=${BUILD_NPROC} \
-            --conf:all tools.build:verbosity="${LOG_VERBOSITY}" \
-            --conf:all tools.compilation:verbosity="${LOG_VERBOSITY}" \
-            .
+            "${VERBOSITY_ARGS[@]}" \
+            --format=json \
+            . >"${RUNNER_TEMP}/conan-graph.json"
+
+    # Tools that run during the build may only load glibc from the Nix store,
+    # as their package ID survives a GCC runtime update.
+    - name: Check build-context packages for Nix store dependencies (Linux)
+      if: ${{ runner.os == 'Linux' }}
+      shell: bash
+      run: ./bin/nix/check-build-context-runtime.sh "${RUNNER_TEMP}/conan-graph.json"

.github/actions/release-info/action.yml

@@ -15,30 +15,25 @@ outputs:
 runs:
   using: composite
   steps:
-    # A tag names its own version. Anything else takes it from BuildInfo.cpp and
-    # appends the commit hash as build metadata, joined with a plus sign because a
-    # Conan version cannot contain two hyphens.
+    # A tag names its own version. Anything else is a development build named by
+    # its commit hash, matching what cmake/XrplVersion.cmake derives: the head of
+    # a pull request rather than the merge commit GitHub creates for it.
     - name: Determine version
       id: version
       shell: bash
       env:
         IS_TAG: ${{ startsWith(github.ref, 'refs/tags/') }}
         REF_NAME: ${{ github.ref_name }}
-        SHA: ${{ github.sha }}
+        SHA: ${{ github.event.pull_request.head.sha || github.sha }}
       run: |
         if [[ "${IS_TAG}" == "true" ]]; then
             version="${REF_NAME}"
         else
-            version="$(awk -F'"' '/versionString =/ { print $2 }' src/libxrpl/protocol/BuildInfo.cpp)"
-            if [[ -z "${version}" ]]; then
-                echo "Unable to read versionString from BuildInfo.cpp." >&2
-                exit 1
-            fi
-            version="${version}+${SHA:0:7}"
+            version="0.0.0-dev+${SHA:0:7}"
         fi
 
         echo "version=${version}" | tee -a "${GITHUB_OUTPUT}"
 
     - name: Determine release channel and package release
       id: release_info
-      uses: XRPLF/actions/release-info@ebcf6cea14eee258697308a51fea55cad777581b
+      uses: XRPLF/actions/release-info@a9f2eeca6fb3980ba3a84cf68566f1c69ad30674

.github/scripts/levelization/results/ordering.txt

@@ -174,8 +174,10 @@ test.server > xrpl.basics
 test.server > xrpl.config
 test.server > xrpld.app
 test.server > xrpld.core
+test.server > xrpld.rpc
 test.server > xrpl.json
 test.server > xrpl.protocol
+test.server > xrpl.resource
 test.server > xrpl.server
 test.unit_test > xrpl.basics
 test.unit_test > xrpl.protocol

.github/scripts/releasing/check-merge-back-commits.sh

@@ -0,0 +1,40 @@
+#!/usr/bin/env bash
+
+# Exit the script as soon as an error occurs.
+set -euo pipefail
+
+# This script fails if <head> merges a release back into <base>,
+# but also adds commits that aren't on a release or staging branch, see RELEASING.md.
+# Merge commits are allowed.
+# Usage: .github/scripts/releasing/check-merge-back-commits.sh <base> <head>
+
+if [ "$#" -ne 2 ]; then
+    echo "Usage: $0 <base> <head>"
+    exit 1
+fi
+
+BASE=$1
+HEAD=$2
+
+SCRIPT_DIR=$(dirname "${BASH_SOURCE[0]}")
+# shellcheck source=.github/scripts/releasing/common.sh
+source "${SCRIPT_DIR}/common.sh"
+load_release_branches
+
+# A PR is a merge-back if some of its commits are on a release or staging branch.
+PR_COUNT=$(git rev-list --no-merges --count "${BASE}..${HEAD}")
+NEW_COUNT=$(git rev-list --no-merges --count "${BASE}..${HEAD}" --not "${BRANCHES[@]}")
+if ((NEW_COUNT == PR_COUNT)); then
+    echo "This PR doesn't merge a release back."
+    exit 0
+fi
+if ((NEW_COUNT == 0)); then
+    echo "This merge-back adds no commits of its own."
+    exit 0
+fi
+
+echo "This PR merges a release back, but also adds commits that aren't on a release or staging branch:"
+git log --no-merges --format='  %h %s' "${BASE}..${HEAD}" --not "${BRANCHES[@]}"
+echo
+echo "Make these changes in a separate PR, see RELEASING.md."
+exit 1

.github/scripts/releasing/check-no-copied-release-commits.sh

@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/usr/bin/env bash
 
 # Exit the script as soon as an error occurs.
 set -euo pipefail
@@ -21,11 +21,10 @@ patch_ids() {
     git log --no-merges --patch --no-color --no-ext-diff "$@" | git patch-id --stable | sort
 }
 
-mapfile -t BRANCHES < <(git for-each-ref --format='%(refname)' 'refs/remotes/*/release/*' 'refs/remotes/*/staging/*')
-if [ "${#BRANCHES[@]}" -eq 0 ]; then
-    echo "Error: No release or staging branches found."
-    exit 1
-fi
+SCRIPT_DIR=$(dirname "${BASH_SOURCE[0]}")
+# shellcheck source=.github/scripts/releasing/common.sh
+source "${SCRIPT_DIR}/common.sh"
+load_release_branches
 
 # Each line is "<patch-id> <commit>".
 RELEASE_PATCHES=$(patch_ids "${BRANCHES[@]}" --not "${HEAD}")

.github/scripts/releasing/check-no-merge-back.sh

@@ -0,0 +1,38 @@
+#!/usr/bin/env bash
+
+# Exit the script as soon as an error occurs.
+set -euo pipefail
+
+# This script fails if <head> contains release or staging commits that <base> does not,
+# i.e. if <head> merges a release back into <base>.
+# Used in the merge queue, which squashes PRs and would drop the merge commit, see RELEASING.md.
+# Usage: .github/scripts/releasing/check-no-merge-back.sh <base> <head>
+
+if [ "$#" -ne 2 ]; then
+    echo "Usage: $0 <base> <head>"
+    exit 1
+fi
+
+BASE=$1
+HEAD=$2
+
+SCRIPT_DIR=$(dirname "${BASH_SOURCE[0]}")
+# shellcheck source=.github/scripts/releasing/common.sh
+source "${SCRIPT_DIR}/common.sh"
+load_release_branches
+
+RELEASE_COMMITS=$(git rev-list "${BRANCHES[@]}" --not "${BASE}")
+HEAD_COMMITS=$(git rev-list "${BASE}..${HEAD}")
+# The release commits in <head>, newest first.
+MERGED=$(grep -xF -f <(echo "${RELEASE_COMMITS}") <<<"${HEAD_COMMITS}" || true)
+if [ -z "${MERGED}" ]; then
+    echo "No release commits are merged back."
+    exit 0
+fi
+
+echo "This PR merges $(wc -l <<<"${MERGED}" | tr -d ' ') release commits back, e.g.:"
+head -5 <<<"${MERGED}" | xargs git log --no-walk --format='  %h %s'
+echo
+echo "Merge-backs must not go through the merge queue, which squashes them."
+echo "Fast-forward develop to the PR branch instead, see RELEASING.md."
+exit 1

.github/scripts/releasing/check-releases-merged.sh

@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/usr/bin/env bash
 
 # Exit the script as soon as an error occurs.
 set -euo pipefail

.github/scripts/releasing/common.sh

@@ -0,0 +1,12 @@
+# shellcheck shell=bash
+
+# Helpers shared by the release checks in this directory, see RELEASING.md.
+
+# Sets BRANCHES to all release and staging branches, and fails if there are none.
+load_release_branches() {
+    mapfile -t BRANCHES < <(git for-each-ref --format='%(refname)' 'refs/remotes/*/release/*' 'refs/remotes/*/staging/*')
+    if [ "${#BRANCHES[@]}" -eq 0 ]; then
+        echo "Error: No release or staging branches found."
+        exit 1
+    fi
+}

.github/scripts/strategy-matrix/linux.json

@@ -1,5 +1,5 @@
 {
-  "image_tag": "sha-060957e",
+  "image_tag": "sha-3d526d4",
   "configs": {
     "ubuntu": [
       {
@@ -74,7 +74,7 @@
         "extra_cmake_args": "-Dvalidator_keys=ON",
         "package": {
           "type": "deb",
-          "image": "ghcr.io/xrplf/xrpld/packaging-debian:sha-49cdc10"
+          "image": "ghcr.io/xrplf/xrpld/packaging-debian:sha-e6055dd"
         }
       },
       {
@@ -86,7 +86,7 @@
         "extra_cmake_args": "-Dvalidator_keys=ON -Dassert=ON",
         "package": {
           "type": "deb",
-          "image": "ghcr.io/xrplf/xrpld/packaging-debian:sha-49cdc10",
+          "image": "ghcr.io/xrplf/xrpld/packaging-debian:sha-e6055dd",
           "variant": "assert"
         }
       }
@@ -101,7 +101,7 @@
         "extra_cmake_args": "-Dvalidator_keys=ON",
         "package": {
           "type": "rpm",
-          "image": "ghcr.io/xrplf/xrpld/packaging-rhel:sha-49cdc10"
+          "image": "ghcr.io/xrplf/xrpld/packaging-rhel:sha-e6055dd"
         }
       }
     ]

.github/workflows/build-nix-images.yml

@@ -12,8 +12,7 @@ on:
       - "!nix/docker/README.md"
       - "!nix/devshell.nix"
       - "!nix/check-tools/**"
-      - "bin/default-loader-path.sh"
-      - "bin/install-sanitizer-libs.sh"
+      - "bin/nix/default-loader-path.sh"
   pull_request:
     paths:
       - ".github/workflows/build-nix-images.yml"
@@ -25,8 +24,8 @@ on:
       - "!nix/devshell.nix"
       - "!nix/check-tools/**"
       - "bin/check-tools.sh"
-      - "bin/default-loader-path.sh"
-      - "bin/install-sanitizer-libs.sh"
+      - "bin/nix/default-loader-path.sh"
+      - "bin/install/sanitizer-libs.sh"
   workflow_dispatch:
 
 concurrency:

.github/workflows/build-packaging-images.yml

@@ -5,14 +5,13 @@ on:
     branches:
       - develop
     paths:
-      - ".github/workflows/build-packaging-images.yml"
-      - "bin/install-packaging-tools.sh"
-      - "package/docker/**"
+      - "bin/install/packaging-tools.sh"
+      - "package/images/packaging/**"
   pull_request:
     paths:
       - ".github/workflows/build-packaging-images.yml"
-      - "bin/install-packaging-tools.sh"
-      - "package/docker/**"
+      - "bin/install/packaging-tools.sh"
+      - "package/images/packaging/**"
   workflow_dispatch:
 
 concurrency:
@@ -44,6 +43,6 @@ jobs:
     uses: XRPLF/actions/.github/workflows/build-multiarch-image.yml@696384b292577293292daed06af0306d1b83bd7d
     with:
       image_name: xrpld/packaging-${{ matrix.distro.name }}
-      dockerfile: package/docker/Dockerfile
+      dockerfile: package/images/packaging/Dockerfile
       base_image: ${{ matrix.distro.base_image }}
       push: ${{ github.event_name == 'push' }}

.github/workflows/build-pre-commit-image.yml

@@ -5,7 +5,6 @@ on:
     branches:
       - develop
     paths:
-      - ".github/workflows/build-pre-commit-image.yml"
       - "bin/pre-commit/Dockerfile"
       - "rust-toolchain.toml"
   pull_request:

.github/workflows/cargo-audit.yml

@@ -34,7 +34,7 @@ permissions:
 jobs:
   audit:
     runs-on: ubuntu-latest
-    container: ghcr.io/xrplf/xrpld/nix-ubuntu:sha-060957e
+    container: ghcr.io/xrplf/xrpld/nix-ubuntu:sha-3d526d4
     permissions:
       contents: read
       # Needed to open an issue on scheduled failures.

.github/workflows/on-pr.yml

@@ -93,9 +93,8 @@ jobs:
             .github/workflows/reusable-upload-recipe.yml
             .clang-tidy
             .codecov.yml
-            bin/check-nix-store-refs.sh
             bin/check-tools.sh
-            bin/default-loader-path.sh
+            bin/nix/**
             cfg/**
             cmake/**
             conan/**
@@ -166,10 +165,31 @@ jobs:
           fetch-depth: 0
           persist-credentials: false
       - name: Check for copied release commits
+        if: ${{ github.event_name == 'pull_request' }}
         env:
-          BASE: ${{ github.event.pull_request.base.sha || github.event.merge_group.base_sha }}
-          HEAD: ${{ github.event.pull_request.head.sha || github.event.merge_group.head_sha }}
+          BASE: ${{ github.event.pull_request.base.sha }}
+          HEAD: ${{ github.event.pull_request.head.sha }}
         run: .github/scripts/releasing/check-no-copied-release-commits.sh "${BASE}" "${HEAD}"
+      # Runs even if the previous check fails, so that both problems are reported at once.
+      - name: Check merge-back has no new commits
+        if: ${{ !cancelled() && github.event_name == 'pull_request' }}
+        env:
+          BASE: ${{ github.event.pull_request.base.sha }}
+          HEAD: ${{ github.event.pull_request.head.sha }}
+        run: .github/scripts/releasing/check-merge-back-commits.sh "${BASE}" "${HEAD}"
+      # The queue squashes PRs, so check the PR's own branch, named in the queue branch.
+      - name: Check the merge queue doesn't merge a release back
+        if: ${{ github.event_name == 'merge_group' }}
+        env:
+          BASE: ${{ github.event.merge_group.base_sha }}
+          HEAD_REF: ${{ github.event.merge_group.head_ref }}
+        run: |
+          if ! [[ "${HEAD_REF}" =~ /pr-([0-9]+)-[0-9a-f]+$ ]]; then
+              echo "Error: Can't find the PR number in '${HEAD_REF}'."
+              exit 1
+          fi
+          git fetch --no-tags origin "refs/pull/${BASH_REMATCH[1]}/head"
+          .github/scripts/releasing/check-no-merge-back.sh "${BASE}" FETCH_HEAD
 
   clang-tidy:
     needs: should-run

.github/workflows/on-tag.yml

@@ -1,9 +1,12 @@
 # When a versioned tag is pushed, this workflow:
 #
-#   - uploads the libxrpl recipe to the Conan remote
 #   - builds and tests the release binaries
+#   - uploads the libxrpl recipe to the Conan remote
 #   - builds the DEB and RPM packages
 #   - publishes those packages to the XRPLF package repositories
+#
+# Nothing is published unless the build passes, which is also where CMake
+# rejects a tag that is not a valid version, e.g. 3.2.01.
 name: Tag
 
 on:
@@ -22,6 +25,7 @@ defaults:
 jobs:
   upload-recipe:
     if: ${{ github.repository == 'XRPLF/rippled' }}
+    needs: build-test
     uses: ./.github/workflows/reusable-upload-recipe.yml
     secrets:
       remote_username: ${{ secrets.NEXUS_REMOTE_USERNAME }}
@@ -51,3 +55,6 @@ jobs:
       remote_password: ${{ secrets.NEXUS_REMOTE_PASSWORD }}
       signing_key: ${{ secrets.NEXUS_PACKAGES_PRIVATE_KEY }}
       dockerhub_token: ${{ secrets.DOCKERHUB_TOKEN }}
+      antithesis_docker_host: ${{ secrets.ANTITHESIS_DOCKER_HOST }}
+      antithesis_docker_path: ${{ secrets.ANTITHESIS_DOCKER_PATH }}
+      antithesis_docker_credentials: ${{ secrets.ANTITHESIS_DOCKER_CREDENTIALS }}

.github/workflows/on-trigger.yml

@@ -31,9 +31,8 @@ on:
       - ".github/workflows/reusable-upload-recipe.yml"
       - ".clang-tidy"
       - ".codecov.yml"
-      - "bin/check-nix-store-refs.sh"
       - "bin/check-tools.sh"
-      - "bin/default-loader-path.sh"
+      - "bin/nix/**"
       - "cfg/**"
       - "cmake/**"
       - "conan/**"
@@ -130,3 +129,6 @@ jobs:
       remote_password: ${{ secrets.NEXUS_REMOTE_PASSWORD }}
       signing_key: ${{ secrets.NEXUS_PACKAGES_PRIVATE_KEY }}
       dockerhub_token: ${{ secrets.DOCKERHUB_TOKEN }}
+      antithesis_docker_host: ${{ secrets.ANTITHESIS_DOCKER_HOST }}
+      antithesis_docker_path: ${{ secrets.ANTITHESIS_DOCKER_PATH }}
+      antithesis_docker_credentials: ${{ secrets.ANTITHESIS_DOCKER_CREDENTIALS }}

.github/workflows/pre-commit.yml

@@ -17,4 +17,4 @@ jobs:
     uses: XRPLF/actions/.github/workflows/pre-commit.yml@279ec358f4a1be4088be3e024b07916fa97c75b6
     with:
       runs_on: ubuntu-latest
-      container: '{ "image": "ghcr.io/xrplf/xrpld/pre-commit:sha-473fe44" }'
+      container: '{ "image": "ghcr.io/xrplf/xrpld/pre-commit:sha-70b8fd3" }'

.github/workflows/publish-docs.yml

@@ -41,7 +41,7 @@ env:
 jobs:
   build:
     runs-on: ubuntu-latest
-    container: ghcr.io/xrplf/xrpld/nix-ubuntu:sha-060957e
+    container: ghcr.io/xrplf/xrpld/nix-ubuntu:sha-3d526d4
     steps:
       - name: Checkout repository
         uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1

.github/workflows/reusable-build-test-config.yml

@@ -186,9 +186,6 @@ jobs:
         with:
           build_nproc: ${{ steps.nproc.outputs.nproc }}
           build_type: ${{ inputs.build_type }}
-          # Set the verbosity to "quiet" for Windows to avoid an excessive
-          # amount of logs. For other OSes, the "verbose" logs are more useful.
-          log_verbosity: ${{ runner.os == 'Windows' && 'quiet' || 'verbose' }}
           sanitizers: ${{ inputs.sanitizers }}
 
       - name: Configure CMake
@@ -196,6 +193,19 @@ jobs:
         env:
           BUILD_TYPE: ${{ inputs.build_type }}
           CMAKE_ARGS: ${{ inputs.cmake_args }}
+          # GitHub creates a merge commit for a PR
+          # https://www.kenmuse.com/blog/the-many-shas-of-a-github-pull-request/
+          #
+          # We:
+          # - explicitly provide branch name
+          # - use `github.event.pull_request.head.sha` to get the SHA of last commit in the PR branch
+          #
+          # This way it works both for PRs and pushes to branches.
+          GITHUB_BRANCH_NAME: "${{ github.head_ref || github.ref_name }}"
+          GITHUB_HEAD_SHA: "${{ github.event.pull_request.head.sha || github.sha }}"
+          #
+          # If tag is being pushed, we use that version.
+          FORCE_XRPLD_VERSION: ${{ startsWith(github.ref, 'refs/tags/') && github.ref_name || '' }}
         run: |
           cmake \
               -G '${{ runner.os == 'Windows' && 'Visual Studio 18 2026' || 'Ninja' }}' \
@@ -244,20 +254,20 @@ jobs:
       # cache included, since what it holds is what gets uploaded and reused.
       - name: Check the build output for Nix store references (Nix toolchain)
         if: ${{ inputs.toolchain == 'nix' }}
-        run: ./bin/check-nix-store-refs.sh "${BUILD_DIR}"
+        run: ./bin/nix/check-nix-store-refs.sh "${BUILD_DIR}"
 
       - name: Check the Conan cache for Nix store references (Nix toolchain)
         if: ${{ inputs.toolchain == 'nix' }}
-        run: ./bin/check-nix-store-refs.sh "${CONAN_HOME}"
+        run: ./bin/nix/check-nix-store-refs.sh "${CONAN_HOME}"
 
       # Only what PatchNixBinary.cmake retargets: the toolchain in the Linux
       # images always references the store. Same condition it uses.
       - name: Check for Nix store references (Linux)
         if: ${{ runner.os == 'Linux' && env.SANITIZERS_ENABLED == 'false' }}
         run: |
-          ./bin/check-nix-store-refs.sh "${BUILD_DIR}/xrpld"
-          ./bin/check-nix-store-refs.sh "${BUILD_DIR}/xrpl_tests"
-          ./bin/check-nix-store-refs.sh "${BUILD_DIR}/xrpld_tests"
+          ./bin/nix/check-nix-store-refs.sh "${BUILD_DIR}/xrpld"
+          ./bin/nix/check-nix-store-refs.sh "${BUILD_DIR}/xrpl_tests"
+          ./bin/nix/check-nix-store-refs.sh "${BUILD_DIR}/xrpld_tests"
 
       - name: Show ccache statistics
         if: ${{ inputs.ccache_enabled }}

.github/workflows/reusable-clang-tidy.yml

@@ -34,7 +34,7 @@ jobs:
     needs: [determine-files]
     if: ${{ needs.determine-files.outputs.cpp_changed_files != '' || needs.determine-files.outputs.need_full_run == 'true' }}
     runs-on: ["self-hosted", "Linux", "X64", "heavy"]
-    container: "ghcr.io/xrplf/xrpld/nix-debian:sha-060957e"
+    container: "ghcr.io/xrplf/xrpld/nix-debian:sha-3d526d4"
     permissions:
       contents: read
       issues: write
@@ -73,7 +73,6 @@ jobs:
         with:
           build_nproc: ${{ steps.nproc.outputs.nproc }}
           build_type: ${{ env.BUILD_TYPE }}
-          log_verbosity: verbose
 
       - name: Configure CMake
         working-directory: ${{ env.BUILD_DIR }}

.github/workflows/reusable-package.yml

@@ -9,8 +9,9 @@
 #     never reaches Nexus
 #   - 'publish' uploads with the image's publish_pkg.py, doing a --dry-run
 #     unless 'publish: true'
-#   - 'docker' builds an Ubuntu image from the tested DEB, pushing it to Docker
-#     Hub only with 'publish: true'
+#   - 'docker' builds an Ubuntu image from the tested DEB, and one with the
+#     voidstar binary for Antithesis, pushing them to Docker Hub and to the
+#     Antithesis registry only with 'publish: true'
 #
 # Only linux/amd64 is supported; the runner is hardcoded in the jobs below.
 name: Package
@@ -37,10 +38,19 @@ on:
         description: "The password or token for that Nexus account."
         required: false
       signing_key:
-        description: "Armoured PGP private key used to sign the RPMs. Required when publishing."
+        description: "Armoured PGP private key used to sign the RPMs."
         required: false
       dockerhub_token:
-        description: "A Docker Hub organization access token for xrplf, with push access to xrplf/xrpld. Required when publishing."
+        description: "A Docker Hub organization access token for xrplf, with push access to xrplf/xrpld."
+        required: false
+      antithesis_docker_host:
+        description: "The host of the Antithesis container registry, e.g. us-central1-docker.pkg.dev."
+        required: false
+      antithesis_docker_path:
+        description: "The repository path in that registry, the image name excluded."
+        required: false
+      antithesis_docker_credentials:
+        description: "The JSON key of a service account with push access to that repository."
         required: false
 
 defaults:
@@ -247,18 +257,35 @@ jobs:
 
   docker:
     needs: [test-install-deb, test-install-rpm]
-    name: "docker${{ !inputs.publish && ' (dry run)' || '' }}"
+    strategy:
+      fail-fast: false
+      matrix:
+        target: [xrpld, voidstar]
+    name: "docker ${{ matrix.target }}${{ !inputs.publish && ' (dry run)' || '' }}"
     permissions:
       contents: read
     runs-on: ubuntu-latest
-    timeout-minutes: 5
+    timeout-minutes: 15
     env:
-      IMAGE: xrplf/xrpld:${{ github.ref_type == 'tag' && github.ref_name || 'develop' }}
+      CONTEXT: image-context
+      IMAGE: ${{ matrix.target == 'voidstar' && 'xrpld-voidstar' || 'xrplf/xrpld' }}:${{ github.ref_type == 'tag' && github.ref_name || 'develop' }}
 
     steps:
       - name: Checkout repository
         uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
 
+      - name: Determine release info
+        id: release_info
+        uses: ./.github/actions/release-info
+
+      # Docker Hub is public, so it only gets builds whose packages are public:
+      # those of a public codebase, and stable releases.
+      # The Antithesis registry is private, so it gets every build.
+      - name: Decide whether to push
+        env:
+          PUSH: ${{ inputs.publish && (matrix.target == 'voidstar' || github.event.repository.visibility == 'public' || steps.release_info.outputs.channel == 'stable') }}
+        run: echo "PUSH=${PUSH}" | tee -a "${GITHUB_ENV}"
+
       - name: Download package artifacts
         uses: actions/download-artifact@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c # v8.0.1
         with:
@@ -266,13 +293,20 @@ jobs:
           merge-multiple: true
           path: ${{ env.PACKAGE_DIR }}
 
+      - name: Download voidstar binary
+        if: ${{ matrix.target == 'voidstar' }}
+        uses: actions/download-artifact@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c # v8.0.1
+        with:
+          name: xrpld-ubuntu-clang-debug-amd64-voidstar
+          path: ${{ env.CONTEXT }}
+
       - name: Build image
         env:
-          CONTEXT: image-context
+          TARGET: ${{ matrix.target }}
         run: |
           mkdir -p "${CONTEXT}"
           find "${PACKAGE_DIR}" -type f -name 'xrpld_[0-9]*.deb' -exec cp {} "${CONTEXT}/" \;
-          docker build --pull --file package/image/Dockerfile --tag "${IMAGE}" "${CONTEXT}"
+          docker build --pull --file package/images/xrpld/Dockerfile --target "${TARGET}" --tag "${IMAGE}" "${CONTEXT}"
 
       - name: Start the server
         run: |
@@ -290,14 +324,25 @@ jobs:
           docker logs "${container}"
           exit 1
 
-      # Docker Hub is public, so a private build never reaches it.
       - name: Log in to Docker Hub
-        if: ${{ inputs.publish && github.event.repository.visibility == 'public' }}
+        if: ${{ env.PUSH == 'true' && matrix.target == 'xrpld' }}
         uses: docker/login-action@dbcb813823bdd20940b903addbd779551569679f # v4.6.0
         with:
           username: xrplf
           password: ${{ secrets.dockerhub_token }}
 
+      - name: Log in to the Antithesis registry
+        if: ${{ env.PUSH == 'true' && matrix.target == 'voidstar' }}
+        uses: docker/login-action@dbcb813823bdd20940b903addbd779551569679f # v4.6.0
+        with:
+          registry: ${{ secrets.antithesis_docker_host }}
+          username: _json_key
+          password: ${{ secrets.antithesis_docker_credentials }}
+
       - name: Push image
-        if: ${{ inputs.publish && github.event.repository.visibility == 'public' }}
-        run: docker push "${IMAGE}"
+        if: ${{ env.PUSH == 'true' }}
+        env:
+          REGISTRY: ${{ matrix.target == 'voidstar' && format('{0}/{1}/', secrets.antithesis_docker_host, secrets.antithesis_docker_path) || '' }}
+        run: |
+          docker tag "${IMAGE}" "${REGISTRY}${IMAGE}"
+          docker push "${REGISTRY}${IMAGE}"

.github/workflows/reusable-rust.yml

@@ -28,7 +28,7 @@ permissions:
 jobs:
   clippy:
     runs-on: ubuntu-latest
-    container: ghcr.io/xrplf/xrpld/nix-ubuntu:sha-060957e
+    container: ghcr.io/xrplf/xrpld/nix-ubuntu:sha-3d526d4
     steps:
       - name: Checkout repository
         uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
@@ -41,7 +41,7 @@ jobs:
 
   coverage:
     runs-on: ubuntu-latest
-    container: ghcr.io/xrplf/xrpld/nix-ubuntu:sha-060957e
+    container: ghcr.io/xrplf/xrpld/nix-ubuntu:sha-3d526d4
     steps:
       - name: Checkout repository
         uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
@@ -70,7 +70,7 @@ jobs:
 
   doc:
     runs-on: ubuntu-latest
-    container: ghcr.io/xrplf/xrpld/nix-ubuntu:sha-060957e
+    container: ghcr.io/xrplf/xrpld/nix-ubuntu:sha-3d526d4
     steps:
       - name: Checkout repository
         uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1

.github/workflows/reusable-upload-recipe.yml

@@ -40,7 +40,7 @@ defaults:
 jobs:
   upload:
     runs-on: ubuntu-latest
-    container: ghcr.io/xrplf/xrpld/nix-ubuntu:sha-060957e
+    container: ghcr.io/xrplf/xrpld/nix-ubuntu:sha-3d526d4
     env:
       REMOTE_NAME: ${{ inputs.remote_name }}
       CONAN_LOGIN_USERNAME_XRPLF: ${{ secrets.remote_username }}

.github/workflows/upload-conan-deps.yml

@@ -108,14 +108,11 @@ jobs:
           build_nproc: ${{ steps.nproc.outputs.nproc }}
           build_type: ${{ matrix.build_type }}
           force_build: ${{ github.event_name == 'schedule' || github.event.inputs.force_source_build == 'true' }}
-          # Set the verbosity to "quiet" for Windows to avoid an excessive
-          # amount of logs. For other OSes, the "verbose" logs are more useful.
-          log_verbosity: ${{ runner.os == 'Windows' && 'quiet' || 'verbose' }}
           sanitizers: ${{ matrix.sanitizers }}
 
       - name: Check the Conan cache for Nix store references (Nix toolchain)
         if: ${{ matrix.toolchain == 'nix' }}
-        run: ./bin/check-nix-store-refs.sh "${CONAN_HOME}"
+        run: ./bin/nix/check-nix-store-refs.sh "${CONAN_HOME}"
 
       - name: Log into Conan remote
         if: ${{ github.repository == 'XRPLF/rippled' && (github.event_name == 'push' || github.event_name == 'workflow_dispatch') }}

.gitignore

@@ -92,6 +92,9 @@ target/
 # Direnv's directory
 /.direnv
 
+# Direnv's local, per-developer overrides
+/.envrc.local
+
 # clangd cache
 /.cache
 

.pre-commit-config.yaml

@@ -60,7 +60,7 @@ repos:
         types_or: [c++, c]
 
   - repo: https://github.com/pre-commit/mirrors-clang-format
-    rev: e2b496dc2bd8340c2524cb9a2d2a943cde1bb6df # frozen: v23.1.1
+    rev: a9a8a861f30ed207ead7d5a3b7e8032283ba5da7 # frozen: v23.1.2
     hooks:
       - id: clang-format
         args: [--style=file]
@@ -82,9 +82,10 @@ repos:
         files: ^crates/.*\.rs$
 
   - repo: https://github.com/BlankSpruce/gersemi-pre-commit
-    rev: f1c4833f8cf23c6d952673abc73525411a5719e8 # frozen: 0.29.1
+    rev: 28010ddd6016e1a0f7bd232acb6536ef996ae897 # frozen: 0.29.2
     hooks:
       - id: gersemi
+        args: [-i, --warnings-as-errors]
 
   - repo: https://github.com/rbubley/mirrors-prettier
     rev: ef4a397f916211b4a39ccf9d3d9cbb6562157251 # frozen: v3.9.9
@@ -95,19 +96,19 @@ repos:
   # Scoped to package/: the rest of the repo's Python has pre-existing findings,
   # so widening these is its own change.
   - repo: https://github.com/astral-sh/ruff-pre-commit
-    rev: a56c0b927e6465d37cae3e97d35d4d18ab2b96cd # frozen: v0.16.9
+    rev: f12be1ebaa5351c1fc76472de98db2c3446c8253 # frozen: v0.16.10
     hooks:
       - id: ruff-check
         args: [--fix]
         files: ^package/.*\.py$
 
   - repo: https://github.com/psf/black-pre-commit-mirror
-    rev: 4160603246a6b365d4a2af661c6d71b0a0f50478 # frozen: 26.5.1
+    rev: 96ae3e5802f3fe2d551e703e18f0a367d1a81ac2 # frozen: 26.10.0
     hooks:
       - id: black
 
   - repo: https://github.com/pre-commit/mirrors-mypy
-    rev: 7ff8d35ae36a7d2b968f2f90b4c723e292e594ee # frozen: v2.3.1
+    rev: 2834ec6639549dd6796205c8f011dedcd587288b # frozen: v2.4.0
     hooks:
       - id: mypy
         args: [--strict]

API-CHANGELOG.md

@@ -6,13 +6,19 @@ For info about how [API versioning](https://xrpl.org/request-formatting.html#api
 
 The API version controls the API behavior you see. This includes what properties you see in responses, what parameters you're permitted to send in requests, and so on. You specify the API version in each of your requests. When a breaking change is introduced to the `xrpld` API, a new version is released. To avoid breaking your code, you should set (or increase) your version when you're ready to upgrade.
 
-The [commandline](https://xrpl.org/docs/references/http-websocket-apis/api-conventions/request-formatting/#commandline-format) always uses the latest API version. The command line is intended for ad-hoc usage by humans, not programs or automated scripts. The command line is not meant for use in production code.
+The [commandline](https://xrpl.org/docs/references/http-websocket-apis/api-conventions/request-formatting/#commandline-format) sends `api_version` 1 unless the request names one. `kApiCommandLineVersion` is stamped on a request naming none, and a static assert holds it at or below the highest non-beta version, so the default cannot reach 3; the `json` and `json2` commands pass a caller-supplied `api_version` through as given. The command line is intended for ad-hoc usage by humans, not programs or automated scripts. The command line is not meant for use in production code.
 
 For a log of breaking changes, see the **API Version [number]** headings. In general, breaking changes are associated with a particular API Version number. For non-breaking changes, scroll to the **XRP Ledger version [x.y.z]** headings. Non-breaking changes are associated with a particular XRP Ledger (`xrpld`) release.
 
 ## API Version 3 (Beta)
 
-API version 3 is currently a beta API. It requires enabling `[beta_rpc_api]` in the xrpld configuration to use. See [API-VERSION-3.md](API-VERSION-3.md) for the full list of changes in API version 3.
+API version 3 is currently a beta API. It requires `[beta_rpc_api]` set to `1` in the xrpld configuration to use; the section takes one value line, and a bare header leaves the flag off. See [API-VERSION-3.md](API-VERSION-3.md) for the full list of changes in API version 3.
+
+From this version, replies take the JSON-RPC 2.0 envelope on both transports, with the deviations [API-VERSION-3.md](API-VERSION-3.md) lists, a top-level array is accepted as a batch, and subscription messages are sent as notifications. The `ripplerpc` field no longer selects the reply envelope and is ignored.
+
+A request that is rejected before it reaches a method is answered with a JSON-RPC error object carrying `jsonrpc`, `id` and `error`, whether it was sent alone or as an entry in a batch; the `id` is the request's own, or `null` where the `id` itself was the unusable member. The HTTP status is the one the matching rejection reports at earlier versions; the two rejections version 3 adds, an unusable `id` and a `method` disagreeing with the one inside `params`, answer 400. On the JSON-RPC transport three classes of rejection stay a plain text body, because the server cannot tell which envelope the client speaks: a body it could not parse or that exceeds the size limit, a body that parses to `{}` or `null` and so carries no request, and a request whose `api_version`, where the server reads it, names a version it does not serve, unless it is an entry of a batch. That place is inside `params` for a lone JSON-RPC request, a top-level value naming such a version being ignored there and the request served as version 1. The WebSocket transport never answers plain text: a message naming such a version at its top level, where that transport reads it, is answered in the legacy frame those versions have always used, and a frame the server cannot read is answered with the `jsonInvalid` frame, at every version. An empty array `[]` is not in the second class: only a version 3 client sends an array, so it is answered with a `-32600` error object and `Request is empty`. A batch entry is not in the third: an entry of a top-level array naming such a version is answered in place with a `-32606` error object in the array's envelope, and an entry of a `"method": "batch"` request is answered with an error object in the body's envelope, so neither takes the body down with it. A version 3 client must therefore tolerate a non-JSON body for the three classes.
+
+A JSON-RPC (HTTP) request may also name `api_version` at its top level, beside `method` and `id`, and may send `params` as the object itself rather than an array holding it. Neither reaches the WebSocket transport, whose message is one flat object that has always carried `api_version` at its top level and whose members are the parameters themselves, so a `params` member there is not unpacked. The `params` object is the specification's own spelling; `api_version` is an XRPL extension, which the specification does not define, placed beside the members it does. Both are additive: for a lone request a top-level `api_version` is honored only when it names version 3 or above, since a lower one has been answered as version 1 for years. An entry of either batch form honors any version it names at its top level: a `"method": "batch"` entry carries its parameters at its own top level, so that is where its version sits, and one that carries a by-name `params` object is read for `api_version` and credentials from that object instead; an array entry is read the same way so that the two forms agree, and an entry naming a served version other than the body's refuses the body, while one naming a version the server does not serve is answered on its own.
 
 ## API Version 2
 
@@ -22,13 +28,61 @@ API version 2 is available in `xrpld` version 2.0.0 and later. See [API-VERSION-
 
 This version is supported by all `xrpld` versions. For WebSocket and HTTP JSON-RPC requests, it is currently the default API version used when no `api_version` is specified.
 
+## Unreleased
+
+### Breaking changes
+
+- The `ripplerpc` request field, which selects the shape of the JSON-RPC reply envelope, is now validated, and a value that is not exactly `"1.0"`, `"2.0"` or `"3.0"` is rejected. Two things it does not reach: a WebSocket session, which reads the field only to echo it back, and API version 3, where the field selects nothing and so is neither read nor checked, `ripplerpc: "banana"` and no `ripplerpc` at all being served alike. A request sending `"2"`, `" 2.0"`, `"2.00"`, `"02.0"`, `"2.0.0"`, `"10.0"` or any other text, such as `"abc"` or `"x2"`, gets a working reply today. After this ships, such a request sent alone gets HTTP 400 with `ripplerpc is not a supported version`, charged as a malformed request, and such an entry of a `"method": "batch"` body gets that error in its own reply while the batch answers 200. A client that spells the version loosely must therefore be corrected to one of the three exact values, or omit the field. Previously the value was compared as a string, which both accepted values that name no version and ordered multi-digit versions incorrectly: `"abc"` and `"x2"` sorted above `"3.0"` and so selected version 3, and `"10.0"` sorted below `"2.0"` and so selected version 1. Requests that send one of the three supported values, or omit the field, are unaffected.
+- `subscribe`: every subscription a connection holds must name the same `api_version`. The first `subscribe` establishes it, and a later one naming a different version is refused with `apiVersionConflict`, registering nothing; the message names the version the connection's subscriptions are served at. The HTTP status is 400 where the envelope derives it from the error, with `ripplerpc: "3.0"` or at API version 3, and 200 with `ripplerpc` `"1.0"` or `"2.0"`, as for every error; a WebSocket frame carries no status. A `subscribe` refused for another reason, a stream name the server does not have for one, still fixes that version, since the registrations it makes are spread through the handler. A connection that subscribed one stream at `api_version` 2 and another at 1, in two calls, was previously served both at version 1, the later call's, so the first stream's shape changed under it. The version is fixed for the connection's life: a client that wants another version opens another connection. On the webhook path the subscriber is keyed on its `url` alone, so the refusal reaches a second admin because of a first admin's version, and the message names the version the url's subscriptions are served at, and no remedy: releasing a url means unsubscribing its streams, which would remove that first admin's subscription, and the server cannot tell the two callers apart. `API-VERSION-3.md` describes the procedure and that risk. Naming the url alone does not release it, a subscriber a stream map still holds not being evicted. This reaches every API version, since version 1 and version 2 content is not interchangeable either: version 2 renames `transaction` to `tx_json` and hoists `hash`, so a version 1 client handed version 2 content finds no `transaction` member.
+- `batch`: An entry of a `"method": "batch"` request that names `api_version` both inside `params` and at its own top level is now served at the version inside `params`. It was previously served at the top-level version whenever the one inside `params` resolved to version 1, so an entry asking for version 1 explicitly and something else at the top level changes which version answers it. A lone request can name both values too, and for it the version inside `params` has always won; reversing that precedence was confined to a batch entry.
+- `batch`: every entry of one batch request is now served at the same API version. An entry may name the version the body names, or name none and inherit it, and a body whose entries name two different versions is refused whole with `Batch entries name different versions` at HTTP 400, charged as a malformed request. **This is visible to a version 1 or 2 client:** a `"method": "batch"` body could mix versions across its entries, each entry being dispatched at its own, and the difference is observable because the reply shape changes with the version. Two bodies change. One that mixes versions is now refused instead of answered. One where some entries name a version and others name none now serves all of them at the named version, where an entry naming none was served at version 1; the same applies to a version named on the request's own top level, which the entries now inherit. A body whose entries all name the same version, or name none at all, is unaffected. A `"method": "batch"` body naming at its own top level a version the server does not serve is refused with `invalid_API_version` at HTTP 400, where it was previously served at version 1 as if it had named none. No test pinned the mixing behavior and the line that produced it was a fallback about where the field sits rather than a decision that entries may differ, so this is a correction rather than a removal of a feature: a per-entry version made the entry cap above unanswerable, since a cap can only ask about a body that has one version.
+
+### Additions
+
+- A JSON-RPC (HTTP) request may send its parameters as an object, `"params": {"account": "r..."}`, as well as the array of one object that was already accepted. This reaches every API version: such a request was previously rejected with HTTP 400 and `params unparsable`, and is now served. A request that already sends the array form is unaffected. An entry of a `"method": "batch"` request that carries a by-name `params` object is read for `api_version` and credentials from that object. Previously such an entry had its `api_version` read from its top level and its credentials ignored, since credentials were read only from an array-form `params`.
+- A lone JSON-RPC (HTTP) request naming `api_version` 3 or above at its own top level, beside `method` and `id`, is now answered at that version. The member is an XRPL extension, which the JSON-RPC 2.0 specification does not define, placed beside the members it does. It was previously answered at version 1, the version being read from inside `params` alone; a WebSocket request, which is one flat object, has always been read there. This is deliberate: reading the version beside the specification's own members is what lets a version 3 client send a specification-shaped request. A top-level value below version 3, or one the server does not serve, is still ignored for a lone request, since `"api_version": 2` there has been answered as version 1 for years and honoring it now would change a shipped reply shape. Only API version 3 is reachable this way, and it is gated behind `[beta_rpc_api]`.
+
+### Bugfixes
+
+- A request echoed back in an error reply now has every credential-bearing field masked: `admin_password`, `admin_user`, `passphrase`, `password`, `secret`, `seed`, `seed_hex`, `url_password`, `url_username` and `username`. Nesting no longer matters, so a credential inside `params` is masked too. The same masking is applied to every request and reply written to the log, and it covers six further names that only a reply carries: `master_key`, `master_seed`, `master_seed_hex`, `validation_key`, `validation_private_key` and `validation_seed`, which is how `wallet_propose` and `validation_create` used to write a live private key to the log. A request or reply written to the log is truncated at 10,000 characters.
+- The command line client no longer prints a credential the operator did not type. A failing command echoes the request it built under `request_sent`, which carries the `admin_password` the client copies out of `[port_rpc]` in the config, so `./xrpld account_info rBogus` printed that password to stdout and into any captured output. `request_sent` is now masked. The `rpc` member beside it, which echoes the arguments as they were typed, is unchanged. The command line client also no longer writes an unparsed `json` or `ripple_path_find` argument to its trace log before parsing it, where a `secret` inside that argument could not be masked; it logs the parsed request instead, masked. The reply it receives is logged the same way, parsed and masked, where the raw body was written before, a `validation_create` answer included.
+- A WebSocket frame that does not parse, or exceeds the request size limit, is answered `{"type": "error", "error": "jsonInvalid", "size": <bytes>}`. The frame's body is reported by size rather than echoed back in a `value` member, since a body that does not parse has no fields to mask. A client that read `value` gets `size` instead.
+- Four error codes that named no HTTP status of their own, and so answered 200 on a reply reporting an error, now name one: `actMalformed`, `alreadyMultisig` and `alreadySingleSig` answer 400, and `actNotFound` answers 404. **Only API version 3 reports these four.** A request sending `ripplerpc: "3.0"` at API version 1 or 2 still receives 200 for all four, as it always has, so `account_info` on a malformed account or one the ledger does not hold answers 200 for those clients exactly as before.
+- `submit`, `simulate`, `transaction_entry`, `ledger_entry` and `ledger_accept`: Errors from these methods now include `error_code` and `error_message` alongside the `error` token, as every other method already did. Each error now answers the status its code names: 400 for a malformed request, 404 for `transactionNotFound`, 500 for an internal failure, and 501 for `notYetImplemented` and `notStandAlone`. That status change reaches only a request sending `ripplerpc: "3.0"`, or API version 3, which are the envelopes that derive the status from the error. With `ripplerpc` `"1.0"` the status stays 200 and the two new members appear beside `error`; with `"2.0"` the status stays 200, `error_code` appears, and the `code` and `message` members carry the code and the message rather than null, since that envelope copies them from `error_code` and `error_message` and drops `error_message`. From API version 3 the twenty-one `malformed*` tokens `ledger_entry` names each report the code they own instead of 31. See [API-VERSION-3.md](API-VERSION-3.md).
+- A reply reporting HTTP 402 or 502 now carries a status line. Those two statuses named no case in the switch that writes one, so such a reply began with a header instead and did not parse as an HTTP response at all. Both are reachable at any API version with `ripplerpc: "3.0"`, which derives the status from the error code: 402 through `highFee` from `sign`, `sign_for` or `submit` with a low `fee_mult_max`, and 502 through `dbDeserialization` from `tx`. The eleven statuses that already named a case report the same phrase they always have.
+- An error reply to a request sending `ripplerpc: "2.0"` or `"3.0"` no longer carries a stray `"error_message": null` beside the error it reports. The member appeared only when the `Server` log partition was set to debug or lower, because the log statement read `error_message` after the reply had renamed it to `message`, and reading it put it back as null. So the reply a client received depended on the server's log level, and the log line itself printed an empty message. Both are fixed.
+- A body the server rejects before it reads a request out of it now says what was wrong. A body over the size limit answers `Request is too large`, and a body that parses to `{}` or `null` answers `Request is empty`; both previously answered `Unable to parse request: ` with nothing after the colon, the parser having recorded no error for them. Any other body that is not an array does not parse, which includes one that is only whitespace and one whose top-level value is a string, number or boolean; it answers `Unable to parse request: ` followed by the parser's own reason, as it did before. The status is 400 for all three, as before, and this reaches every API version. A top-level array, the one other body nothing can read a request from, is answered with a JSON error object instead, which the entry on top-level arrays below describes.
+- `batch`: An entry that is not identified through a secure gateway no longer clears the connection's `X-User` and forwarded-for values for the entries after it, so every entry of one body reports the role and username it would have reported on its own.
+- `batch`: Every entry of a `"method": "batch"` request is now charged against the sender's resource allowance, including one rejected before it reaches a handler, and the request stops at the first entry the connection is too loaded to serve. A reply array can therefore be shorter than the request array, and its last element depends on where the batch stopped. An entry that is not a JSON object, or names an API version the server does not serve, is charged before its role is known and answered with its own rejection; if that charge took the connection over the drop threshold, the batch stops there and that rejection is the last answer. Every other entry met over the threshold is answered `Server is overloaded` and nothing follows. A client should read any reply array shorter than its request as a connection over the drop threshold, whatever the last element says. A well-behaved client is unaffected; one that sends thousands of entries in a single body no longer gets every one of them answered.
+- A body the server rejects before it reads a request out of it is now charged against the sender's resource allowance, as a malformed request already was. Ten conditions were free: a body over the size limit, one that does not parse, one carrying no document, one that is neither a JSON object nor an array, a `"method": "batch"` naming no entry array, and six ways a top-level array is not a batch this server can serve. The answer to the first five is unchanged; an array's answer changes as the entry on top-level arrays below describes, the one generic rejection it received having become six. A well-behaved client is unaffected; one that repeats such a body exhausts its allowance and is refused the next request a handler would have served. A WebSocket frame that does not parse, or exceeds the request size limit, is charged the same way, and a connection that sends only such frames is closed once it crosses the drop threshold.
+- `subscribe`, `path_find`: A subscription is now served at the API version its own `subscribe` call named, rather than at the version of the most recent `subscribe` or `path_find` on the same connection. A `path_find` no longer changes the version anything that connection has subscribed is served at. An ordinary request is unaffected: it names its own version and is answered at it, so a connection subscribed at `api_version` 3 still calls `account_info` at version 1 and reads the version 1 shape.
+- `batch`: A batch request served at API version 3 or above is now refused when it holds more than 100 entries, before any entry is dispatched. The cap reads the one version the body is served at, so no ordering of the entries evades it. A body served below version 3 is unaffected and stays bounded only by the request size limit.
+- A top-level JSON array, which is the JSON-RPC 2.0 batch form accepted from API version 3, is now rejected with a JSON-RPC error object rather than a plain text body when it cannot be served: when it is empty, holds more than 100 entries, holds nothing that could be a request, names no API version of 3 or above that the server serves, or names two different versions the server serves. An array naming no served version of 3 or above is refused for requiring version 3, or, where every version it names is one the server does not serve, with `invalid_API_version`. One entry naming a version the server does not serve does not reject an array in which another entry names a served version: it is answered on its own, inside the reply array, with the same `-32606` code. This reaches every API version, since no earlier version accepts an array at all: a client that sent one received HTTP 400 with `Unable to parse request: ` and now receives the same status with a JSON body. The message also names the version rather than the shape where the version is what is wrong, which is what a client with `[beta_rpc_api]` disabled receives.
+
+## XRP Ledger server version 3.5.0
+
+Version 3.5.0 is not yet released.
+
+### Additions in 3.5.0
+
+- `subscribe`, `unsubscribe`: Added an optional `mpt_issuances` request field, an array of MPT issuance IDs (hex strings). Subscribers receive the same `transaction` message as the `transactions` stream for each validated transaction whose metadata affects a subscribed issuance. MPT issuance subscriptions count toward the per-connection subscription limit. An empty array, a non-array value, or an invalid ID returns `invalidParams`. ([#5671](https://github.com/XRPLF/rippled/pull/5671))
+- `ledger_entry`: Add full support for checks, NFT offers, payment channels, and signer lists. ([#6319](https://github.com/XRPLF/rippled/pull/6319))
+
+### Bugfixes in 3.5.0
+
+- `channel_authorize`: The `channel_id` field now returns an `invalidParams` error if the value is not a string. [#7582](https://github.com/XRPLF/rippled/pull/7582)
+- `channel_verify`: The `channel_id` and `signature` fields now return an `invalidParams` error if the value is not a string. [#7582](https://github.com/XRPLF/rippled/pull/7582)
+
+### Bugfixes in 3.5.0
+
+- `feature`: The admin-only `vetoed` field now returns `invalidParams` unless its value is a boolean. [#7583](https://github.com/XRPLF/rippled/pull/7583)
+
 ## XRP Ledger server version 3.4.0
 
 Version 3.4.0 is not yet released. These changes are available in the 3.4.0 beta releases.
 
 ### Additions in 3.4.0
 
-- `server_info` (admin): The `node_size` field has been removed; it reported the deprecated `[node_size]` config setting, which is still accepted as an alias for `[memory_limit]` and still emits a startup warning. Admin responses now include `memory_limit`, the cache memory budget in gigabytes rounded up (0 when enforcement is disabled).
 - `ledger`: `nftoken_id`, `nftoken_ids`, and `offer_id` are now included in transaction metadata when transactions are expanded (`expand`, or admin-only `full`), matching the `tx`, `account_tx`, and `subscribe` (`transactions` stream) responses. ([#5706](https://github.com/XRPLF/rippled/pull/5706))
 
 ### Bugfixes in 3.4.0
@@ -43,6 +97,7 @@ Version 3.4.0 is not yet released. These changes are available in the 3.4.0 beta
 - `account_lines`: The `peer` field now returns an error if the value is not a string. [#7728](https://github.com/XRPLF/rippled/pull/7728)
 - `ledger`: `delivered_amount` is now included in the metadata of successful `AccountDelete` transactions when transactions are expanded (`expand`, or admin-only `full`). Previously it was only added for `Payment` and `CheckCash`, which made `ledger` inconsistent with `tx` and `account_tx`. [#5706](https://github.com/XRPLF/rippled/pull/5706)
 - `noripple_check`: The `transactions` field is no longer included in error responses; it is still returned (possibly as an empty array) whenever `transactions` is `true` and the request succeeds. A malformed `account` is now rejected before the ledger is looked up, so that error response no longer carries the `ledger_hash`, `ledger_index`, and `validated` fields ([#6303](https://github.com/XRPLF/rippled/pull/6303)).
+- `transaction_entry`: An object or an array in `tx_hash` now returns `malformedRequest`, like any other value that is not a hex hash, instead of an `internal` error.
 
 ## XRP Ledger server version 3.3.0
 

API-VERSION-3.md

@@ -1,11 +1,220 @@
 # API Version 3
 
-API version 3 is currently a **beta API**. It requires enabling `[beta_rpc_api]` in the xrpld configuration to use. To use this API, clients specify `"api_version" : 3` in each request.
+API version 3 is currently a **beta API**. It requires `[beta_rpc_api]` set to `1` in the xrpld configuration to use; the section takes one value line, and a bare header leaves the flag off. To use this API, clients specify `"api_version" : 3` in each request.
 
 For info about how [API versioning](https://xrpl.org/request-formatting.html#api-versioning) works, including examples, please view the [XLS-22d spec](https://github.com/XRPLF/XRPL-Standards/discussions/54). For details about the implementation of API versioning, view the [implementation PR](https://github.com/XRPLF/rippled/pull/3155). API versioning ensures existing integrations and users continue to receive existing behavior, while those that request a higher API version will experience new behavior.
 
 ## Breaking Changes
 
+### Replies take the JSON-RPC 2.0 envelope
+
+Every reply the server can attribute to API version 3 takes the envelope the [JSON-RPC 2.0 specification](https://www.jsonrpc.org/specification) defines, on both the JSON-RPC and WebSocket transports. The Deviations section below lists where the content departs from the specification, and the rejections that stay a plain text body. This replaces the three envelope shapes selected by the `ripplerpc` request field, none of which conformed to the specification that the field is named after.
+
+A successful reply carries the payload under `result`:
+
+```json
+{
+  "jsonrpc": "2.0",
+  "id": 7,
+  "result": { "ledger_hash": "F742...", "ledger_index": 2 }
+}
+```
+
+A failure carries it under `error` instead:
+
+```json
+{
+  "jsonrpc": "2.0",
+  "id": 7,
+  "error": {
+    "code": -32000,
+    "message": "Account malformed.",
+    "data": { "error": "actMalformed", "error_code": 35 }
+  }
+}
+```
+
+Compared with earlier versions:
+
+- **`jsonrpc` is always present** and names the protocol version.
+- **`id` is echoed from the top level of the request**, where the specification puts it. This changes the JSON-RPC transport only. Earlier versions of that transport echoed `id` only when it was nested inside `params`, so a client that placed it correctly received no `id` and could not correlate the reply with its request. A WebSocket session has always echoed a top-level `id`, and is unaffected. A request that names no `id` receives `"id": null`, so that a reply is always distinguishable from a notification; the specification would send nothing, which the Deviations section below records. The specification allows a string, a number or null there, so a request naming anything else there, an object, an array or a boolean, is rejected as an invalid request, on both transports; that reply names `"id": null` too, the id being the thing that was wrong. A number is read as this server reads every JSON number: an integer from -2147483648 to 4294967295, or a fraction. An integer outside that range fails to parse, and the body is refused as unreadable before any envelope is chosen, so a client using a millisecond timestamp as an `id` should send it as a string; the Deviations section below records the bound. Earlier versions echo whatever they are given, whatever its shape, and continue to.
+- **`status` is gone from the reply envelope**, at both levels. Whether the call succeeded is already carried by which of `result` or `error` is present. Earlier versions also let `path_find`'s `status` subcommand report one inside `result`; that one is dropped too. A subscription notification is not a reply and keeps whatever the event carries: the `transactions` stream reports `"closed"` or `"proposed"` in a `status` member of the event itself, so a version 3 subscriber still receives it under `params`.
+- **`error.code` is `-32000`** for any request that reaches a command, the specification's reserved code for an implementation-defined server error. The XRPL error token and numeric code move into `error.data`, so the two code spaces stay separate and renumbering an XRPL error can never change a JSON-RPC code. Everything else the handler reported about the failure also travels in `data`. A request naming a method this server does not have reaches no command, and the specification gives that one condition a code of its own, so it reports `-32601` instead, with `unknownCmd` and its code still under `data`.
+- **A notice stays at the top level.** Three member names are notices: `warning`, `warnings` and `deprecated`. The rule is positional, not a judgment about what each one says: any of the three that a handler puts at the **top level of its result** is moved beside the specification's members, and one nested deeper is left where the handler put it. So `ledger`'s `warnings` is moved, while `server_info`'s, nested under `info`, and `server_state`'s, nested under `state`, are not. Two of the three moved members do describe one outcome rather than the server: `wallet_propose`'s `warning` describes the wallet the call just produced, and `subscribe`'s describes an experimental feature. Both are moved, because they sit at that top level.
+- **`error_exception` is gone; its text is `error.message`.** `submit` and `simulate` reported the specific detail of a failure in an `error_exception` member of their own, leaving a generic `error_message` beside it: a `tx_blob` that fails to parse reported both `"Transaction is invalid."` and `"Transaction length invalid"`. The specific text is now the `message`, which is where every other handler puts it, and the token and code in `data` still say what kind of failure it was. A client that read `error_exception` must read `error.message`.
+- **The request is not echoed back.** Earlier versions echoed it on version 1 errors. A request rejected before it reaches a command is not echoed either, and the shape its reply takes is described below.
+- **`ripplerpc` is ignored.** It no longer selects the envelope. The field is ignored rather than rejected, as any other field the server does not honor is.
+
+The envelope above describes a request that reaches a command. A request the server rejects before then (one naming no method, or a method that is not a string, or one refused for permissions or load) is answered differently, since there is no handler result to shape. One case has no reply at all: a WebSocket sender over the resource drop threshold is disconnected, whatever its message carried, as it has been at every version, while the JSON-RPC transport answers that sender with 503 and `Server is overloaded`. A request whose `api_version`, where the server reads it, names a version it does not serve is rejected before then too, but is answered outside the envelope, as plain text on the JSON-RPC transport and in the legacy frame on WebSocket, unless it is an entry of a batch, as described below: the server cannot tell which envelope that client speaks. That place is inside `params` for a lone JSON-RPC request, a top-level value naming such a version being ignored there and the request served as version 1, as the request section below describes, and the top level of a WebSocket message.
+
+Such a rejection is a specification error object, whether the request was sent alone or as an entry in a batch, correlated by the request's own `id`, or naming `"id": null` where the `id` itself was the unusable member:
+
+```json
+{
+  "jsonrpc": "2.0",
+  "id": 2,
+  "error": { "code": -32602, "message": "params unparsable" }
+}
+```
+
+The HTTP status is the one the rejection has always reported: 400 for a malformed request, 403 for a forbidden one and 503 for an overloaded server. Earlier versions receive that status with the message as a bare text body (`Null method`, `params unparsable`), and continue to. A request sent as an entry of a batch reports no status of its own, the body carrying several outcomes; the batch section below says where its outcome is stated instead.
+
+The rejected request is **not** echoed back. Earlier versions echo a rejected batch entry with its credentials masked and continue to do so; the specification makes `error.data` optional, a client already knows what it sent, and copying a whole entry per rejection is what an overloaded server must not do.
+
+The codes reported here are the specification's own: `-32600` for a request that names no usable `method`, or is not a JSON object at all, and `-32602` for invalid parameters. Earlier versions report `-32601`, method not found, for such an entry of a `"method": "batch"` request, where version 3 reports `-32600`; a lone request there is answered as plain text, with no code at all. `-32601` is what they have always sent for the entry and moving it would change `error.code` for their clients. Version 3 keeps `-32601` for the one condition the specification defines it for, a request naming a method this server does not have, which is answered from the reply path above rather than as a rejection: a request naming no usable method names nothing that could be found or not found. A request naming one method at its top level and another inside `params` names two, which is not that condition either, so it reports `-32600` from version 3 up on the JSON-RPC transport, the WebSocket transport having no `params` to disagree with, its `command` and `method` disagreement being described below; earlier versions of the JSON-RPC transport answer it as `unknownCmd` with `error_code` 32 at HTTP 200 in the `ripplerpc` `"1.0"` and `"2.0"` envelopes, and at 405 in the `"3.0"` envelope, and continue to. They also report `-32604` for an overloaded server, `-32605` for a forbidden request and `-32606` for an unsupported API version, which lie in the range the specification reserves for the protocol rather than the `-32000..-32099` range it leaves to implementations. Those are unchanged at every version, for the same reason.
+
+Those three codes belong to a rejection the server makes before it dispatches a request. Load and permission can also be reported once a request has been read, and then they carry an XRPL token and so report `-32000` like any other: a request refused because the job queue is full reports `-32000` with `tooBusy` under `data` and HTTP 503, and an admin-only command called without the role reports `-32000` with `noPermission` and HTTP 401. The rule is not which subject the failure is about: **every error carrying an XRPL token reports `-32000`, with the one exception of `unknownCmd`, which reports `-32601`.**
+
+On the JSON-RPC transport three classes of rejection are answered as plain text at every version, including this one, because the server cannot tell which envelope the client speaks:
+
+- a body it could not parse, and one larger than the request size limit;
+- a body that parses but carries no request: `{}` or `null`;
+- a request whose `api_version`, read from inside `params` for a lone request, names a version the server does not serve, unless it is an entry of a batch.
+
+The first two name no version anywhere. The third names one, but not one this server has, so it cannot know what that client expects. A lone request naming such a version at its top level only is not in the third: that value is ignored, as the request section below describes, and the request is served as version 1. A version 3 client must therefore tolerate a non-JSON body for these. A top-level value that is neither an object nor an array, such as `42` or `"text"`, does not parse at all and falls in the first class.
+
+The WebSocket transport never answers plain text. A frame the server cannot read is answered with the `jsonInvalid` frame described below, and a frame naming an `api_version` the server does not serve is answered in the legacy envelope those versions have always used: `{"type": "response", "status": "error", "error": "invalid_API_version", "request": { ... }}`, with the request echoed and its credentials masked. That is the reply a version 3 WebSocket client receives from a server where `[beta_rpc_api]` is not enabled.
+
+An entry of a top-level array is the exception to the third, because the array's own version is known: only a version 3 client sends an array at all. Such an entry is answered with a `-32606` error object in the array's envelope, described in the batch section below. An entry of a `"method": "batch"` request is answered the same way when the body is served at version 3, which it is when the body or any of its entries names it; a body served below version 3 keeps the shape earlier versions send.
+
+One rejection is worth naming separately. On the WebSocket transport there are four ways for a request to name no one command to dispatch on: it names neither `command` nor `method`, one of those two is not a string, or the two disagree. From version 3 each is answered in the specification envelope, reporting `-32600` and a message naming which of the four it was. No such reply carries `data`: a rejection is not a failure a command reported, so it has no XRPL token to put there. Earlier versions answer all four with the single `missingCommand` token, and continue to.
+
+The HTTP status still derives from the XRPL error code, now read from `error.data.error_code`. Four codes named no status in the error table and fell back to 200, which said the call succeeded on a reply that carries an error: `account_info` answered both a malformed account and a missing one with 200. They now name the status the table gives every comparable code: `actMalformed`, `alreadyMultisig` and `alreadySingleSig` report 400, and `actNotFound` reports 404.
+
+Only version 3 reports those four. The legacy `ripplerpc: "3.0"` envelope derives the status from the same code and still answers 200 for them, since that is the status it has answered since it shipped and `account_info` on an account the ledger does not hold is a routine call rather than a failure. Every other code reports the status it always has, in both envelopes.
+
+On the WebSocket transport the reply carries one extra member, `"type": "response"`. The specification has no place for it, but a WebSocket session also receives server-initiated messages on the same connection, and `type` is how a client tells the two apart. It is retained for that reason.
+
+A WebSocket frame that does not parse as a JSON object, or exceeds the request size limit, is answered `{"type": "error", "error": "jsonInvalid", "size": <bytes>}` at every API version, including this one, unless the sender is already over the resource drop threshold, in which case the frame is charged and the connection is closed without a reply, as it is for a readable message from such a sender. There are no fields yet to shape into an envelope, and none to mask either, so the body is reported by its size rather than echoed: a frame with a stray comma would otherwise return whatever it carried, credentials included.
+
+### Requests may take the specification's shape
+
+Two request spellings are now accepted on the JSON-RPC transport, in addition to the ones XRPL clients already send: one the specification defines, `params` as an object, and one XRPL extension placed beside the members the specification defines, `api_version` at the top level. Both are additive, so every request that worked before still works; one shape is read differently, and it is named below. A WebSocket message is one flat object whose members are the parameters themselves: it has always carried `api_version` at its top level, and a `params` member there is not unpacked, so neither spelling applies to it.
+
+- **`api_version` at the top level**, beside `method` and `id`, and not only inside `params`. For a lone JSON-RPC request a top-level value is honored only when it names version 3 or above: `"api_version": 2` there has been answered as version 1 for years, as has a version the server does not serve, and both continue to be. An entry of either batch form honors any version it names at its top level, including one the server does not serve, which is answered as an unsupported version: a `"method": "batch"` entry carries its parameters at its own top level, so that is where its version sits, and one that carries a by-name `params` object is read for `api_version` and credentials from that object instead; an array entry is read the same way so that the two forms agree, and an entry naming a served version other than the body's refuses the body.
+
+  A value inside `params` decides where a request carries both, which **reverses the earlier precedence**: a request that named a version inside `params` and a different one at its top level was previously answered at the top-level one whenever the value inside `params` resolved to version 1. Only a `"method": "batch"` entry could carry both, so that is the only shape the reversal reaches, and it reaches it at every API version. `API-CHANGELOG.md` records it.
+
+- **`params` as the object itself**, the specification's by-name form, rather than an array holding that object. The array form is unchanged: it holds exactly one element, which is the object or `null`, as the Deviations section below records.
+
+#### One API version per connection is the shape to write a client to
+
+The server reads `api_version` from each request and answers that request at that version, so a connection may carry requests at several versions and each reply is shaped for the request that asked for it. Nothing refuses that. But there is no reason for a client to rely on it: a client that names one version for the life of a connection reads one reply shape throughout, and has one thing to change when it migrates. Write a client that way.
+
+One case is not advice but a rule the server enforces: **every subscription a connection holds must name the same `api_version`**. A `subscribe` naming a version different from the one the connection's subscriptions are served at is refused with `apiVersionConflict` and registers nothing, because one event can match several of a connection's subscriptions and only one message goes out, so a second version would leave no shape that message could take. The version is fixed by the first `subscribe` for the connection's life, whether or not that call went on to register anything: a `subscribe` refused for a stream name the server does not have has still fixed it. A client that wants another version opens another connection.
+
+A webhook subscriber is keyed on its `url` alone, so the same rule reaches every caller that names that url. To subscribe a url at a different version, send `unsubscribe` naming that `url` **and its streams**: naming the url alone does not release it, since the subscriber is not evicted while any stream map still holds it. Be aware that doing so removes the subscription of whoever subscribed that url first, whether or not that was you - the server keeps no record of which caller named it. Where the url may be shared, naming a different url is the safer answer. The refusal message names the version the url's subscriptions are served at and no remedy, for that reason. Ordinary requests are untouched by this: a connection subscribed at version 3 still calls `account_info` at version 1 and reads the version 1 shape.
+
+```json
+{
+  "jsonrpc": "2.0",
+  "id": 7,
+  "method": "ledger_closed",
+  "api_version": 3,
+  "params": { "ledger_index": "validated" }
+}
+```
+
+### Batch requests
+
+A top-level JSON array is accepted as a [batch](https://www.jsonrpc.org/specification#batch), and is answered with an array of replies, one per entry, each correlated by its own `id`:
+
+```json
+[
+  {
+    "jsonrpc": "2.0",
+    "id": 1,
+    "method": "ledger_closed",
+    "params": [{ "api_version": 3 }]
+  },
+  {
+    "jsonrpc": "2.0",
+    "id": 2,
+    "method": "account_info",
+    "params": [{ "api_version": 3 }]
+  }
+]
+```
+
+In earlier versions a top-level array is rejected with HTTP 400, and that is unchanged; an array is treated as a batch only when an entry names an `api_version` of 3 or above that the server serves, inside its own `params` or at its top level, wherever that entry sits; an array holding at least one object in which no entry does is refused whole: as below version 3 where an entry names a served version below 3 or no entry names any, and for the version named where every version named is one the server does not serve. An array holding no object at all is answered per entry instead, as below. That entry also sets the version for the array: an entry naming none of its own inherits it, whether it comes before or after, so one batch is answered in one envelope even where an entry is rejected before its parameters can be read. An entry that names a served version of its own must name that one; a body whose entries name two different served versions is refused whole, as the table below shows. An entry naming a version the server does not serve is answered on its own, as below.
+
+An entry's parameters are nested exactly as a lone request's are, so an entry reports the same error it would have reported on its own.
+
+An entry that is not a JSON object is not a request. It is answered in place, among the replies, with `-32600` and `Request is not a JSON object`, and the entries that are requests are still dispatched. Earlier versions answer such an entry with `-32601` and `Method not found`, and echo it back under `request`; both are unchanged for them.
+
+An entry naming an `api_version` the server does not serve is answered the same way: in place, with `-32606` and `invalid_API_version`, correlated by the entry's own `id`, or naming `"id": null` where the `id` itself was unusable, and echoing nothing. It takes the array's envelope rather than the one it asked for, since the version it asked for does not exist, and unlike a lone request in that position it is not answered as plain text: the array told the server which envelope this client reads. An entry naming a version the server does have must name the array's, or the whole array is refused.
+
+A rejection of the whole array is answered with one error object, since only version 3 sends an array at all. The array names no `id`, its entries do, so `id` is null. The version is set by the first entry naming a served version of 3 or above. The version rows below are read in order: the first applies where every version named is one the server does not serve, the second where no entry names a served version of 3 or above, and the third where an entry names a served version other than the one set. An entry naming a version the server does not serve beside one naming a served version is answered on its own, wherever it sits, as above:
+
+| Body                                                                                    | HTTP | `error.code` | `error.message`                         |
+| --------------------------------------------------------------------------------------- | ---- | ------------ | --------------------------------------- |
+| `[]`                                                                                    | 400  | `-32600`     | `Request is empty`                      |
+| More than 100 entries                                                                   | 400  | `-32600`     | `Batch has too many entries`            |
+| Every version named is one the server does not serve                                    | 400  | `-32606`     | `invalid_API_version`                   |
+| Otherwise, no entry names a served version of 3 or above                                | 400  | `-32600`     | `Batch requires API version 3 or above` |
+| An entry names a served version of 3 or above, and another names a different served one | 400  | `-32600`     | `Batch entries name different versions` |
+
+A non-empty array of 100 entries or fewer holding nothing that could be a request, such as `[1,2,3]` from the specification's own example, is answered with one `-32600` object per entry, since no entry can name a version or an `id`. The table's first two rows are checked before any entry is read, so an empty or oversized array is answered once, whatever it holds.
+
+A batch is limited to 100 entries, and the limit is applied before the entries are read, so an oversized array is answered once rather than once per entry. The body size limit alone is not a bound on the work a batch buys, since it dispatches one command per entry.
+
+The `"method": "batch"` form, which nests its entries under `params`, is unrelated to the specification and continues to work on every API version. From version 3 up it takes the same 100-entry limit, read from the one version the body is served at, so no ordering of the entries evades it. Below version 3 it stays uncapped, which is what keeps every body clients send today acceptable.
+
+Every entry is charged against the sender's resource allowance, whether it reaches a handler or is rejected first, except the one shed as overloaded, whose load the drop check has already accounted for. Once a connection is over the drop threshold the remaining entries are not answered, so a reply array can be shorter than the request array. The last element depends on where the batch stopped: an entry that is not a JSON object, or names an API version the server does not serve, is charged before its role is known and answered with its own error object, and the batch stops after it when that charge crossed the threshold; every other entry met over the threshold reports `-32604` and `Server is overloaded` in its own error object. Nothing follows in either case, so a client that correlates by `id` sees answers missing for the entries at the end, and should read any short reply array as an overloaded connection whatever its last element says. This applies to both batch forms.
+
+A batch whose entries are answered reports HTTP 200, whatever those entries report, including the overloaded one above. An array holding nothing that could be a request is the exception: its entries are answered one by one, but the body is a rejection rather than a batch the server served, and it reports 400. One status cannot describe several outcomes, so an entry's own reply is where its outcome is stated: whether it carries `result` or `error`, and, for an error, the specification code in `error.code` for a rejection and the XRPL token and code under `error.data` for a handler failure, every one of which reports `-32000` in `error.code`. No entry has an HTTP status of its own. A rejection of the whole array is one answer rather than many and reports its own status, as the table above shows, and so does a request sent alone.
+
+### Subscription messages are notifications
+
+A message the server sends without being asked, such as a `subscribe` stream event, is shaped as a specification [notification](https://www.jsonrpc.org/specification#notification): a request-shaped object naming the protocol and the method, with the event's content under `params` and no `id`.
+
+```json
+{
+  "jsonrpc": "2.0",
+  "method": "ledgerClosed",
+  "params": { "ledger_index": 3, "...": "..." }
+}
+```
+
+The `type` member that named the event in earlier versions becomes `method`.
+
+A `path_find` update is a notification too, though the server directs it at the one client that asked rather than publishing it to a stream. The specification allows one response per request, and `path_find create` already consumed it, so no later update can be one. The `id` that correlates the update with the request travels inside `params`, which is where the update has always carried it:
+
+```json
+{
+  "jsonrpc": "2.0",
+  "method": "path_find",
+  "params": { "id": 7, "alternatives": ["..."], "full_reply": true }
+}
+```
+
+An `account_history` subscription that fails reports the failure the same way, naming `account_history_tx_stream` as the method with the error under `params`. Earlier versions receive a bare error object with no `type`, which is what they have always received.
+
+A subscriber named by a `url` is the exception, and receives the legacy `event` call at every version, including version 3. Such a subscriber is not sent the message directly: the server posts each message to the URL as the `params` of an `event` call, with a `seq` member counting the messages beside it. A notification sent that way would arrive nested inside a request and next to a member the specification does not define, so it would not be a notification. Which shape a subscriber receives therefore depends on how the message reaches it, not only on the version it asked for.
+
+### Deviations from the specification
+
+The reply follows the specification as closely as the XRPL API allows. These are the places it does not, all of them deliberate:
+
+- **A request that names no `id` still receives a reply.** The specification calls such a request a notification and gives it no reply at all. XRPL clients routinely omit `id`, so a reply is always sent, with `"id": null`.
+- **A batch of such requests is answered with an array**, for the same reason, where the specification would send no body.
+- **An integer `id` must fit this server's JSON integer range**, -2147483648 to 4294967295. The specification allows any Number. One outside that range fails to parse, and the body is refused as unreadable before any envelope is chosen, so a client using a larger value, such as a millisecond timestamp, should send it as a string.
+- **By-position `params` is an array of exactly one element, an object or `null`.** The specification allows an array of any length. This server's methods take one object, so an array of any other length, or one whose element is neither an object nor `null`, is refused with `-32602` and `params unparsable`. A `null` element is served as an empty parameter object, as it has been at every version.
+- **`error.code` is `-32000`** for every failure a command reports, rather than a code per failure. The XRPL token and code carry that detail in `error.data`. A method the server does not have is the one exception, reporting `-32601`, because no command runs for it.
+- **`-32700` (parse error) and `-32603` (internal error) are never reported.** A body that does not parse is answered as plain text on the JSON-RPC transport and as a `jsonInvalid` frame on WebSocket, and neither is an envelope, so there is no `error.code` to put a parse code in. An internal failure of a command is reported the way every other failure a command reports is, with `-32000` and the `internal` token under `error.data`, so that a client reads one code space for all of them.
+- **`-32604`, `-32605` and `-32606`** lie in the band the specification reserves for the protocol. They are the codes earlier versions report for an overloaded server, a forbidden request and an unsupported API version, and moving one would change `error.code` for their clients.
+- **A rejection the server cannot attribute to a version is plain text**, not an error object. The three classes are listed above.
+- **The batch is accepted on the JSON-RPC transport only.** A WebSocket frame must be a single object, as it always has been.
+- **`ripplerpc` is ignored** rather than rejected, as any other field the server does not honor is. When support for versions 1 and 2 ends, an ignored field stays ignored, where a rejection would silently turn into acceptance.
+- **A WebSocket reply carries `"type": "response"`**, which the specification has no place for. A WebSocket session receives server-initiated messages on the same connection, and `type` is how a client tells the two apart.
+- **A batch is served at one API version.** The specification says nothing about versions. An entry may name the version the body names, or name none and inherit it, and a body whose entries name two different versions the server serves is refused whole with `-32600` and `Batch entries name different versions`; one naming a version the server does not serve is answered on its own, as below. For a top-level array it is the one the first entry naming a served version of 3 or above does, wherever that entry sits. For a `"method": "batch"` body it is the one the first entry naming a served version does; such a body may also name it at its own top level, which then decides, and one naming a version the server does not serve there is refused. An entry names a version wherever dispatch would read one from it, inside its own `params` or at its top level. An entry naming a version the server does not serve is answered on its own, as it always has been, rather than taking the body down with it, except that a top-level array holding at least one object in which no entry names a served version of 3 or above is refused whole, with `-32606` where every version named is one the server does not serve and with `-32600` otherwise, as the table above shows, while one holding no object at all is answered per entry once it has passed the empty and size checks of the table's first two rows.
+- **A reply array can be shorter than the request array.** The specification asks for one response per non-notification request; a batch stops at the entry the connection is too loaded to serve. `API-CHANGELOG.md` records this for the `"method": "batch"` form, which earlier versions serve; the array form is version 3 only, and this document is its record.
+- **`warning`, `warnings` and `deprecated` sit beside `jsonrpc`, `result` and `id`** at the top level of the reply, where the specification defines no member of its own. The rule is positional: any of the three that a handler puts at the top level of its result is moved there, whatever it describes, and one nested deeper stays where the handler put it. A client therefore reads a top-level notice from one place whether the call succeeded or failed.
+- **A subscriber named by a `url` receives the legacy `event` call**, not a notification, at every version. The transport that carries the message to the URL wraps it in a request of its own, so a notification could not survive the trip. See above.
+- **A batch is limited to 100 entries.** The specification places no bound on an array's length. One command is dispatched per entry, so the request size limit bounds the bytes rather than the work, and an array of small entries buys far more of it than its size suggests. The same limit applies to the `"method": "batch"` form from version 3 up, for the reason given above.
+- **A `subscribe` naming an `api_version` different from the one this connection's subscriptions are served at is refused.** The specification describes no such condition. Every subscription a connection holds is served at one version, for the reason given above, which is also why the remedy is a second connection rather than a second version. The refusal reports `apiVersionConflict`, registers nothing, and names the version already established. On the JSON-RPC transport it answers HTTP 400, as every version 3 error reporting a malformed request does. A WebSocket frame carries no status. `API-CHANGELOG.md` records it as breaking. This constrains `subscribe` alone: an ordinary request names its own `api_version` and is answered at it, whatever the connection has subscribed.
+- **The request's own `jsonrpc` member is neither required nor read.** The specification asks a client to send `"jsonrpc": "2.0"`. A request is served whether it names that member, names some other value, or names none at all: `api_version` is what selects the shape of the reply, and refusing an otherwise well formed call for a missing member would reject requests every XRPL client sends today. The reply always names the member.
+
 ### Modifications to `amm_info`
 
 The order of error checks has been changed to provide more specific error messages. ([#4924](https://github.com/XRPLF/rippled/pull/4924))
@@ -25,3 +234,37 @@ In API version 3, the following string values can be used with the `"index"` par
 - `"index": "hashes"` - Returns the "short" `LedgerHashes` ledger entry (recent ledger hashes)
 
 These shortcuts are only available in API version 3 and later. In API versions 1 and 2, these string values would result in an error.
+
+#### `error_code` is the code that belongs to the reported token
+
+`ledger_entry` validates its request fields through helpers that name the malformed field in the `error` token, such as `malformedOwner` or `malformedDirRoot`. Below API version 3 all of them report `error_code` 31 (`invalidParams`) regardless of the token, because changing the number would have broken clients matching on it. From version 3 each token reports the code it owns.
+
+A client that matches on `error_code` 31 for these methods must match on the token instead, or on the code listed below. The `error` token itself is unchanged at every version, so a client that already matches on the token needs no change.
+
+| Token                                      | `error_code` below v3 | `error_code` from v3 |
+| ------------------------------------------ | --------------------- | -------------------- |
+| `malformedRequest`                         | 31                    | 107                  |
+| `malformedAccount`                         | 31                    | 110                  |
+| `malformedAddress`                         | 31                    | 111                  |
+| `malformedAuthorized`                      | 31                    | 112                  |
+| `malformedAuthorizedCredentials`           | 31                    | 113                  |
+| `malformedBridgeAccount`                   | 31                    | 114                  |
+| `malformedBroker`                          | 31                    | 115                  |
+| `malformedCurrency`                        | 31                    | 116                  |
+| `malformedDirRoot`                         | 31                    | 117                  |
+| `malformedDocumentID`                      | 31                    | 118                  |
+| `malformedIssue`                           | 31                    | 119                  |
+| `malformedIssuingChainDoor`                | 31                    | 120                  |
+| `malformedLockingChainDoor`                | 31                    | 121                  |
+| `malformedMPTIssuanceID`                   | 31                    | 122                  |
+| `malformedMPTokenIssuance`                 | 31                    | 123                  |
+| `malformedOwner`                           | 31                    | 124                  |
+| `malformedSeq`                             | 31                    | 125                  |
+| `malformedSponsee`                         | 31                    | 126                  |
+| `malformedSponsor`                         | 31                    | 127                  |
+| `malformedXChainOwnedClaimID`              | 31                    | 128                  |
+| `malformedXChainOwnedCreateAccountClaimID` | 31                    | 129                  |
+
+`transaction_entry` reports `malformedRequest` too, and the two handlers agree on it from version 3 on. It set that token with no `error_code` at all before this release, and now reports 107 at every API version, where `ledger_entry` reports 31 below version 3 as the table above shows.
+
+The HTTP status is unchanged: every code in the table above carries 400, as `invalidParams` does. `entryNotFound`, `lgrNotFound` and `unexpectedLedgerType` are unaffected by all of this, having always carried their own code. `unknownOption` is a separate change and is not a version 3 one: `ledger_entry` reports that token at API version 1 only, it carried no `error_code` at all there, and it now carries code 109.

BUILD.md

@@ -41,15 +41,19 @@ branch.
 git checkout develop
 ```
 
-For a release candidate, choose the relevant release branch, e.g.
-`release/3.2.x`.
+For a release or release candidate, check out its [tag](https://github.com/XRPLF/rippled/releases), e.g.:
 
 ```bash
-git checkout release/3.2.x
+git checkout 3.4.0
 ```
 
-For a stable release, choose one of the [tagged
-releases](https://github.com/XRPLF/rippled/releases).
+See [RELEASING.md](./RELEASING.md) for how branches and releases are organized.
+
+A build reports `0.0.0-dev` with its short commit hash as build metadata, e.g.
+`0.0.0-dev+0123abc`. Only builds of a release, from a tag in CI or a versioned
+Conan reference, report a release version. To use another version, set the
+`FORCE_XRPLD_VERSION` environment variable when running CMake, e.g.
+`FORCE_XRPLD_VERSION=3.4.0`.
 
 ### Set Up Conan
 

CMakeLists.txt

@@ -77,7 +77,6 @@ endif()
 include(PatchNixBinary)
 
 include(XrplSanity)
-include(XrplVersion)
 include(XrplSettings)
 # this check has to remain in the top-level cmake because of the early return statement
 if(packages_only)

CONTRIBUTING.md

@@ -14,9 +14,13 @@ The following branches exist in the main project repository:
 
 - `develop`: The latest set of unreleased features, and the most common
   starting point for contributions.
-- `release/*` (e.g. `release/3.2.x`): Release branches, one per release line,
-  holding the latest release candidate, or stable release for that line.
-  Stable releases are published as [tagged releases](https://github.com/XRPLF/rippled/releases).
+- `staging/*` (e.g. `staging/3.4.x`): Staging branches, one per release line,
+  where fixes for that line are developed.
+- `release/*` (e.g. `release/3.4.x`): Release branches, one per release line,
+  holding the latest public release candidate or release for that line.
+  Releases are published as [tagged releases](https://github.com/XRPLF/rippled/releases).
+
+See [RELEASING.md](./RELEASING.md) for how these branches are used.
 
 The tip of each branch must be signed. In order for GitHub to sign a
 squashed commit that it builds from your pull request, GitHub must know
@@ -145,8 +149,8 @@ tl;dr
 
 In general, pull requests use `develop` as the base branch.
 
-The exceptions are fixes, improvements, and hotfixes for an existing release,
-which use that release's branch (e.g. `release/3.2.x`) as the base.
+The exceptions are fixes for an existing release line,
+which use that line's staging branch (e.g. `staging/3.4.x`) as the base.
 
 If your changes are not quite ready, but you want to make it easily available
 for preliminary examination or review, you can create a "Draft" pull request.
@@ -591,15 +595,16 @@ the suggested commit message, or modify it as needed.
 
 #### Slightly more complicated pull requests
 
-Some pull requests need to be pushed to `develop` as more than one
-commit. A PR author may _request_ to merge as separate commits. They
+Some pull requests need to be pushed to their base branch (usually `develop`)
+as more than one commit.
+A PR author may _request_ to merge as separate commits. They
 must _justify_ why separate commits are needed, and _specify_ how they
 would like the commits to be merged. If you disagree with the author,
 discuss it with them directly.
 
 If the process is reasonable, follow it. The simplest option is to do a
-fast forward only merge (`--ff-only`) on the command line and push to
-`develop`.
+fast forward only merge (`--ff-only`) on the command line
+and push to the base branch.
 
 Some examples of when separate commits are worthwhile are:
 
@@ -612,9 +617,10 @@ Some examples of when separate commits are worthwhile are:
 
 Either way, check that:
 
-- The commits are based on the current tip of `develop`.
-- The commits are clean: No merge commits (except when reverse
-  merging), no "[FOLD]" or "fixup!" messages.
+- The commits are based on the current tip of the base branch.
+- The commits are clean:
+  No merge commits (except when merging a release, see [RELEASING.md](./RELEASING.md)),
+  no "[FOLD]" or "fixup!" messages.
 - All commits are signed. If the commits are not signed by the author, use
   `git commit --amend -S` to sign them yourself.
 - At least one (but preferably all) of the commits has the PR number
@@ -626,578 +632,8 @@ use them!**
 
 ### Releases
 
-All releases, including release candidates and betas, are handled
-differently from typical PRs. Most importantly, never use
-the Github UI to merge a release.
-
-Xrpld uses a linear workflow model that can be summarized as:
-
-1. In between releases, developers work against the `develop` branch.
-2. Periodically, a maintainer will build and tag a beta version from
-   `develop`, which is pushed to `release`.
-   - Betas are usually released every two to three weeks, though that
-     schedule can vary depending on progress, availability, and other
-     factors.
-3. When the changes in `develop` are considered stable and mature enough
-   to be ready to release, a release candidate (RC) is built and tagged
-   from `develop`, and merged to `release`.
-   - Further development for that release (primarily fixes) then
-     continues against `release`, while other development continues on
-     `develop`. Effectively, `release` is forked from `develop`. Changes
-     to `release` must be reverse merged to `develop`.
-4. When the candidate has passed testing and is ready for release, the
-   final release is merged to `master`.
-5. If any issues are found post-release, a hotfix / point release may be
-   created, which is merged to `master`, and then reverse merged to
-   `develop`.
-
-#### Betas, and the first release candidate
-
-##### Preparing the `develop` branch
-
-1. Optimally, the `develop` branch will be ready to go, with all
-   relevant PRs already merged.
-2. If there are any PRs pending, merge them **BEFORE** preparing the beta.
-   1. If only one or two PRs need to be merged, merge those PRs [as
-      normal](#when-and-how-to-merge-pull-requests), updating the second
-      one, and waiting for CI to finish in between.
-   2. If there are several pending PRs, do not use the Github UI,
-      because the delays waiting for CI in between each merge will be
-      unnecessarily onerous. (Incidentally, this process can also be
-      used to merge if the Github UI has issues.) Merge each PR branch
-      directly to a `release-next` on your local machine and create a single
-      PR, then push your branch to `develop`.
-      1. Squash the changes from each PR, one commit each (unless more
-         are needed), being sure to sign each commit and update the
-         commit message to include the PR number. You may be able to use
-         a fast-forward merge for the first PR.
-      2. Push your branch.
-      3. Continue to [Making the release](#making-the-release) to update
-         the version number, etc.
-
-      The workflow may look something like:
-
-```
-git fetch --multiple upstreams user1 user2 user3 [...]
-git checkout -B release-next --no-track upstream/develop
-
-# Only do an ff-only merge if pr-branch1 is either already
-# squashed, or needs to be merged with separate commits,
-# and has no merge commits.
-# Use -S on the ff-only merge if pr-branch1 isn't signed.
-git merge [-S] --ff-only user1/pr-branch1
-
-git merge --squash user2/pr-branch2
-git commit -S # Use the commit message provided on the PR
-
-git merge --squash user3/pr-branch3
-git commit -S # Use the commit message provided on the PR
-
-[...]
-
-# Make sure the commits look right
-git log --show-signature "upstream/develop..HEAD"
-
-git push --set-upstream origin
-
-# Continue to "Making the release" to update the version number, so
-# everything can be done in one PR.
-```
-
-You can also use the [squash-branches] script.
-
-You may also need to manually close the open PRs after the changes are
-merged to `develop`. Be sure to include the commit ID.
-
-##### Making the release
-
-This includes, betas, and the first release candidate (RC).
-
-1. If you didn't create one [preparing the `develop`
-   branch](#preparing-the-develop-branch), Ensure there is no old
-   `release-next` branch hanging around. Then make a `release-next`
-   branch that only changes the version number. e.g.
-
-```
-git fetch upstreams
-
-git checkout --no-track -B release-next upstream/develop
-
-v="A.B.C-bD"
-build=$( find -name BuildInfo.cpp )
-sed 's/\(^.*versionString =\).*$/\1 "'${v}'"/' ${build} > version.cpp && mv -vi version.cpp ${build}
-
-git diff
-
-git add ${build}
-
-git commit -S -m "Set version to ${v}"
-
-# You could use your "origin" repo, but some CI tests work better on upstream.
-git push upstream-push
-git fetch upstreams
-git branch --set-upstream-to=upstream/release-next
-```
-
-You can also use the [update-version] script. 2. Create a Pull Request for `release-next` with **`develop`** as
-the base branch.
-
-1.  Use the title "[TRIVIAL] Set version to X.X.X-bX".
-2.  Instead of the default description template, use the following:
-
-```
-## High Level Overview of Change
-
-This PR only changes the version number. It will be merged as
-soon as Github CI actions successfully complete.
-```
-
-3. Wait for CI to successfully complete, and get someone to approve
-   the PR. (It is safe to ignore known CI issues.)
-4. Push the updated `develop` branch using your `release-next`
-   branch. **Do not use the Github UI. It's important to preserve
-   commit IDs.**
-
-```
-git push upstream-push release-next:develop
-```
-
-5. In the unlikely event that the push fails because someone has merged
-   something else in the meantime, rebase your branch onto the updated
-   `develop` branch, push again, and go back to step 3.
-6. Ensure that your PR against `develop` is closed. Github should do it
-   automatically.
-7. Once this is done, forward progress on `develop` can continue
-   (other PRs may be merged).
-8. Now create a Pull Request for `release-next` with **`release`** as
-   the base branch. Instead of the default template, reuse and update
-   the message from the previous release. Include the following verbiage
-   somewhere in the description:
-
-```
-The base branch is `release`. [All releases (including
-betas)](https://github.com/XRPLF/rippled/blob/develop/CONTRIBUTING.md#before-you-start)
-go in `release`. This PR branch will be pushed directly to `release` (not
-squashed or rebased, and not using the GitHub UI).
-```
-
-7. Sign-offs for the three platforms (Linux, Mac, Windows) usually occur
-   offline, but at least one approval will be needed on the PR.
-   - If issues are discovered during testing, simply abandon the
-     release. It's easy to start a new release, it should be easy to
-     abandon one. **DO NOT REUSE THE VERSION NUMBER.** e.g. If you
-     abandon 2.4.0-b1, the next attempt will be 2.4.0-b2.
-8. Once everything is ready to go, push to `release`.
-
-```
-git fetch upstreams
-
-# Just to be safe, do a dry run first:
-git push --dry-run upstream-push release-next:release
-
-# If everything looks right, push the branch
-git push upstream-push release-next:release
-
-# Check that all of the branches are updated
-git fetch upstreams
-git log -1 --oneline
-# The output should look like:
-# 0123456789 (HEAD -> upstream/release-next, upstream/release,
-#            upstream/develop) Set version to 2.4.0-b1
-# Note that upstream/develop may not be on this commit, but
-# upstream/release must be.
-# Other branches, including some from upstream-push, may also be
-# present.
-```
-
-9. Tag the release, too.
-
-```
-git tag <version number>
-git push upstream-push <version number>
-```
-
-10. Delete the `release-next` branch on the repo. Use the Github UI or:
-
-```
-git push --delete upstream-push release-next
-```
-
-11. Finally [create a new release on
-    Github](https://github.com/XRPLF/rippled/releases).
-
-#### Release candidates after the first
-
-Once the first release candidate is [merged into
-release](#making-the-release), then `release` and `develop` _are allowed
-to diverge_.
-
-If a bug or issue is discovered in a version that has a release
-candidate being tested, any fix and new version will need to be applied
-against `release`, then reverse-merged to `develop`. This helps keep git
-history as linear as possible.
-
-A `release-next` branch will be created from `release`, and any further
-work for that release must be based on `release-next`. Specifically,
-PRs must use `release-next` as the base, and those PRs will be merged
-directly to `release-next` when approved. Changes should be restricted
-to bug fixes, but other changes may be necessary from time to time.
-
-1. Open any PRs for the pending release using `release-next` as the base,
-   so they can be merged directly in to it. Unlike `develop`, though,
-   `release-next` can be thrown away and recreated if necessary.
-2. Once a new release candidate is ready, create a version commit as in
-   step 1 [above](#making-the-release) on `release-next`. You can use
-   the [update-version] script for this, too.
-3. Jump to step 8 ("Now create a Pull Request for `release-next` with
-   **`release`** as the base") from the process
-   [above](#making-the-release) to merge `release-next` into `release`.
-
-##### Follow up: reverse merge
-
-Once the RC is merged and tagged, it needs to be reverse merged into
-`develop` as soon as possible.
-
-1. Create a branch, based on `upstream/develop`.
-   The branch name is not important, but could include "mergeNNNrcN".
-   E.g. For release A.B.C-rcD, use `mergeABCrcD`.
-
-```
-git fetch upstreams
-
-git checkout --no-track -b mergeABCrcD upstream/develop
-```
-
-2. Merge `release` into your branch.
-
-```
-# I like the "--edit --log --verbose" parameters, but they are
-# not required.
-git merge upstream/release
-```
-
-3. `BuildInfo.cpp` will have a conflict with the version number.
-   Resolve it with the version from `develop` - the higher version.
-4. Push your branch to your repo (or `upstream` if you have permission),
-   and open a normal PR against `develop`. The "High level overview" can
-   simply indicate that this is a merge of the RC. The "Context" should
-   summarize the changes from the RC. Include the following text
-   prominently:
-
-```
-This PR must be merged manually using a push. Do not use the Github UI.
-```
-
-5. Depending on the complexity of the changes, and/or merge conflicts,
-   the PR may need a thorough review, or just a sign-off that the
-   merge was done correctly.
-6. If `develop` is updated before this PR is merged, do not merge
-   `develop` back into your branch. Instead rebase preserving merges,
-   or do the merge again. (See also the `rerere` git config setting.)
-
-```
-git rebase --rebase-merges upstream/develop
-# OR
-git reset --hard upstream/develop
-git merge upstream/release
-```
-
-7. When the PR is ready, push it to `develop`.
-
-```
-git fetch upstreams
-
-# Make sure the commits look right
-git log --show-signature "upstream/develop^..HEAD"
-
-git push upstream-push mergeABCrcD:develop
-
-git fetch upstreams
-```
-
-Development on `develop` can proceed as normal.
-
-#### Final releases
-
-A final release is any release that is not a beta or RC, such as 2.2.0.
-
-Only code that has already been tested and vetted across all three
-platforms should be included in a final release. Most of the time, that
-means that the commit immediately preceding the commit setting the
-version number will be an RC. Occasionally, there may be last-minute bug
-fixes included as well. If so, those bug fixes must have been tested
-internally as if they were RCs (at minimum, ensuring unit tests pass,
-and the app starts, syncs, and stops cleanly across all three
-platforms.)
-
-_If in doubt, make an RC first._
-
-The process for building a final release is very similar to [the process
-for building a beta](#making-the-release), except the code will be
-moving from `release` to `master` instead of from `develop` to
-`release`, and both branches will be pushed at the same time.
-
-1. Ensure there is no old `master-next` branch hanging around.
-   Then make a `master-next` branch that only changes the version
-   number. As above, or using the
-   [update-version] script.
-2. Create a Pull Request for `master-next` with **`master`** as
-   the base branch. Instead of the default template, reuse and update
-   the message from the previous final release. Include the following verbiage
-   somewhere in the description:
-
-```
-The base branch is `master`. This PR branch will be pushed directly to
-`release` and `master` (not squashed or rebased, and not using the
-GitHub UI).
-```
-
-7. Sign-offs for the three platforms (Linux, Mac, Windows) usually occur
-   offline, but at least one approval will be needed on the PR.
-   - If issues are discovered during testing, close the PR, delete
-     `master-next`, and move development back to `release`, [issuing
-     more RCs as necessary](#release-candidates-after-the-first)
-8. Once everything is ready to go, push to `release` and `master`.
-
-```
-git fetch upstreams
-
-# Just to be safe, do dry runs first:
-git push --dry-run upstream-push master-next:release
-git push --dry-run upstream-push master-next:master
-
-# If everything looks right, push the branch
-git push upstream-push master-next:release
-git push upstream-push master-next:master
-
-# Check that all of the branches are updated
-git fetch upstreams
-git log -1 --oneline
-# The output should look like:
-# 0123456789 (HEAD -> upstream/master-next, upstream/master,
-#            upstream/release) Set version to A.B.0
-# Note that both upstream/release and upstream/master must be on this
-# commit.
-# Other branches, including some from upstream-push, may also be
-# present.
-```
-
-9. Tag the release, too.
-
-```
-git tag <version number>
-git push upstream-push <version number>
-```
-
-10. Delete the `master-next` branch on the repo. Use the Github UI or:
-
-```
-git push --delete upstream-push master-next
-```
-
-11. [Create a new release on
-    Github](https://github.com/XRPLF/rippled/releases). Be sure that
-    "Set as the latest release" is checked.
-12. Open a PR to update the [API-CHANGELOG](API-CHANGELOG.md) and `API-VERSION-[n].md` with the changes for this release (if any are missing).
-13. Finally, [reverse merge the release into `develop`](#follow-up-reverse-merge).
-
-#### Special cases: point releases, hotfixes, etc.
-
-On occasion, a bug or issue is discovered in a version that already
-had a final release. Most of the time, development will have started
-on the next version, and will usually have changes in `develop`
-and often in `release`.
-
-Because git history is kept as linear as possible, any fix and new
-version will need to be applied against `master`.
-
-The process for building a hotfix release is very similar to [the
-process for building release candidates after the
-first](#release-candidates-after-the-first) and [for building a final
-release](#final-releases), except the changes will be done against
-`master` instead of `release`.
-
-If there is only a single issue for the hotfix, the work can be done in
-any branch. When it's ready to merge, jump to step 3 using your branch
-instead of `master-next`.
-
-1. Create a `master-next` branch from `master`.
-
-```
-git checkout --no-track -b master-next upstream/master
-git push upstream-push
-git fetch upstreams
-```
-
-2. Open any PRs for the pending hotfix using `master-next` as the base,
-   so they can be merged directly in to it. Unlike `develop`, though,
-   `master-next` can be thrown away and recreated if necessary.
-3. Once the hotfix is ready, create a version commit using the same
-   steps as above, or use the
-   [update-version] script.
-4. Create a Pull Request for `master-next` with **`master`** as
-   the base branch. Instead of the default template, reuse and update
-   the message from the previous final release. Include the following verbiage
-   somewhere in the description:
-
-```
-The base branch is `master`. This PR branch will be pushed directly to
-`master` (not squashed or rebased, and not using the GitHub UI).
-```
-
-7. Sign-offs for the three platforms (Linux, Mac, Windows) usually occur
-   offline, but at least one approval will be needed on the PR.
-   - If issues are discovered during testing, update `master-next` as
-     needed, but ensure that the changes are properly squashed, and the
-     version setting commit remains last
-8. Once everything is ready to go, push to `master` **only**.
-
-```
-git fetch upstreams
-
-# Just to be safe, do a dry run first:
-git push --dry-run upstream-push master-next:master
-
-# If everything looks right, push the branch
-git push upstream-push master-next:master
-
-# Check that all of the branches are updated
-git fetch upstreams
-git log -1 --oneline
-# The output should look like:
-# 0123456789 (HEAD -> upstream/master-next, upstream/master) Set version
-#            to 2.4.1
-# Note that upstream/master must be on this commit. upstream/release and
-# upstream/develop should not.
-# Other branches, including some from upstream-push, may also be
-# present.
-```
-
-9. Tag the release, too.
-
-```
-git tag <version number>
-git push upstream-push <version number>
-```
-
-9. Delete the `master-next` branch on the repo.
-
-```
-git push --delete upstream-push master-next
-```
-
-10. [Create a new release on
-    Github](https://github.com/XRPLF/rippled/releases). Be sure that
-    "Set as the latest release" is checked.
-
-Once the hotfix is released, it needs to be reverse merged into
-`develop` as soon as possible. It may also need to be merged into
-`release` if a release candidate is under development.
-
-1. Create a branch in your own repo, based on `upstream/develop`.
-   The branch name is not important, but could include "mergeNNN".
-   E.g. For release 2.2.3, use `merge223`.
-
-```
-git fetch upstreams
-
-git checkout --no-track -b merge223 upstream/develop
-```
-
-2. Merge master into your branch.
-
-```
-# I like the "--edit --log --verbose" parameters, but they are
-# not required.
-git merge upstream/master
-```
-
-3. `BuildInfo.cpp` will have a conflict with the version number.
-   Resolve it with the version from `develop` - the higher version.
-4. Push your branch to your repo, and open a normal PR against
-   `develop`. The "High level overview" can simply indicate that this
-   is a merge of the hotfix version. The "Context" should summarize
-   the changes from the hotfix. Include the following text
-   prominently:
-
-```
-This PR must be merged manually using a --ff-only merge. Do not use the Github UI.
-```
-
-5. Depending on the complexity of the hotfix, and/or merge conflicts,
-   the PR may need a thorough review, or just a sign-off that the
-   merge was done correctly.
-6. If `develop` is updated before this PR is merged, do not merge
-   `develop` back into your branch. Instead rebase preserving merges,
-   or do the merge again. (See also the `rerere` git config setting.)
-
-```
-git rebase --rebase-merges upstream/develop
-# OR
-git reset --hard upstream/develop
-git merge upstream/master
-```
-
-7. When the PR is ready, push it to `develop`.
-
-```
-git fetch upstreams
-
-# Make sure the commits look right
-git log --show-signature "upstream/develop..HEAD"
-
-git push upstream-push HEAD:develop
-```
-
-Development on `develop` can proceed as normal. It is recommended to
-create a beta (or RC) immediately to ensure that everything worked as
-expected.
-
-##### An even rarer scenario: A hotfix on an old release
-
-Historically, once a final release is tagged and packages are released,
-versions older than the latest final release are no longer supported.
-However, there is a possibility that a very high severity bug may occur
-in a non-amendment blocked version that is still being run by
-a significant fraction of users, which would necessitate a hotfix / point
-release to that version as well as any later versions.
-
-This scenario would follow the same basic procedure as above,
-except that _none_ of `develop`, `release`, or `master`
-would be touched during the release process.
-
-In this example, consider if version 2.1.1 needed to be patched.
-
-1. Create two branches in the main (`upstream`) repo.
-
-```
-git fetch upstreams
-
-# Create a base branch off the tag
-git checkout --no-track -b master-2.1.2 2.1.1
-git push upstream-push
-
-# Create a working branch
-git checkout --no-track -b master212-next master-2.1.2
-git push upstream-push
-
-git fetch upstreams
-```
-
-2. Work continues as above, except using `master-2.1.2`as
-   the base branch for any merging, packaging, etc.
-3. After the release is tagged and packages are built, you could
-   potentially delete both branches, e.g. `master-2.1.2` and
-   `master212-next`. However, it may be useful to keep `master-2.1.2`
-   around indefinitely for reference.
-4. Assuming that a hotfix is also released for the latest
-   version in parallel with this one, or if the issue is
-   already fixed in the latest version, do no do any
-   reverse merges. However, if it is not, it probably makes
-   sense to reverse merge `master-2.1.2` into `master`,
-   release a hotfix for _that_ version, then reverse merge
-   from `master` to `develop`. (Please don't do this unless absolutely
-   necessary.)
+Releases, release branches, and merging releases back into `develop`
+are described in [RELEASING.md](./RELEASING.md).
 
 [contrib]: https://docs.github.com/en/get-started/quickstart/contributing-to-projects
 [squash]: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/about-pull-request-merges#squash-and-merge-your-commits
@@ -1205,5 +641,3 @@ git fetch upstreams
 [xrpld]: https://github.com/XRPLF/rippled
 [signing]: https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification
 [setup-upstreams]: ./bin/git/setup-upstreams.sh
-[squash-branches]: ./bin/git/squash-branches.sh
-[update-version]: ./bin/git/update-version.sh

RELEASING.md

@@ -0,0 +1,152 @@
+# Branching and Release Management
+
+This document describes how we branch, release, and merge releases back into `develop`.
+It does not define version naming
+(e.g., what constitutes a major-minor, patch, or beta release).
+
+Examples use `X.Y` for a release line:
+`X` and `Y` are placeholders, while the trailing `x` is literal,
+e.g., `release/X.Y.x` is `release/3.4.x` for the `3.4` line.
+
+## Branches
+
+| Branch          | Purpose                                                                                   |
+| :-------------- | :---------------------------------------------------------------------------------------- |
+| `develop`       | Main development branch. Betas and the first RC of a major-minor release are tagged here. |
+| `staging/X.Y.x` | Where fixes for the `X.Y` line are developed and RCs are prepared.                        |
+| `release/X.Y.x` | The last public RC or release of the `X.Y` line.                                          |
+
+A release line is named `X.Y.x`
+because one branch serves every patch release of that line (`X.Y.0`, `X.Y.1`, `X.Y.2`, ...).
+The `/` groups branches hierarchically,
+so tools can filter them and protection rules can target `release/*` and `staging/*`.
+
+## Principles
+
+- **Releases are merged back into `develop`, never cherry-picked or rebased onto it.**
+  Cherry-picked and rebased commits get new hashes,
+  so Git can't tell that `develop` already has them.
+  Future merges then replay them and produce artificial conflicts,
+  and it's hard to verify that every fix actually reached `develop`.
+  Merging keeps a single history:
+  Git knows exactly which release commits `develop` contains,
+  and no fix is left behind.
+- **Branches only move forward.**
+  `develop`, `staging/X.Y.x`, and `release/X.Y.x` are never rewritten.
+- **Cherry-picking only goes from `develop` to a staging branch**,
+  for fixes that must get into a release after the code freeze
+  (see [Emergency Fixes From `develop`](#emergency-fixes-from-develop)).
+- **Security fixes are prepared privately and published with the release that contains them**,
+  so vulnerabilities are not disclosed prematurely.
+
+## Release Lifecycle
+
+This diagram shows a major-minor release and its first patch release.
+The staging and release branches are drawn as one line.
+
+```text
+develop                            staging/X.Y.x & release/X.Y.x
+   │
+   ├── Tag: X.Y.0-b1
+   ├── Tag: X.Y.0-bN
+   ├── Tag: X.Y.0-rc1 ───────────────┐ (branches created)
+   │                                 │
+   │  (development continues)        ├── Fixes
+   │                                 ├── Tag: X.Y.0-rcN
+   │                                 ├── Tag: X.Y.0 (final)
+   ◀──── (merge) ────────────────────┤
+   │                                 ├── Fixes
+   │                                 ├── Tag: X.Y.1-rcN
+   │                                 ├── Tag: X.Y.1 (final)
+   ◀──── (merge) ────────────────────┤
+   │
+   ▼
+```
+
+### Betas, First RC & Branching
+
+> [!NOTE]
+> This phase applies only to a new major-minor release (e.g., `X.Y.0`).
+> Patch releases work on the existing branches of the line.
+
+1. **Betas:** All beta versions (e.g., `X.Y.0-b1`) are built and tagged directly on `develop`.
+2. **First RC:** We release the first RC (`X.Y.0-rc1`)
+   once everything that should be included in the release has been merged.
+3. **Branches:** `staging/X.Y.x` and `release/X.Y.x` are created from `develop`
+   at the commit tagged `X.Y.0-rc1`.
+   The first RC also kicks off the QE process.
+4. **Code freeze:** No new features or unrelated changes are pulled from `develop`
+   into `staging/X.Y.x` or `release/X.Y.x`.
+   Only critical stabilization fixes go into the line.
+5. **No large changes on `develop`:** Until `X.Y.0` is [merged back](#merging-back-into-develop),
+   large changes (e.g., big refactors, moving or renaming many files, mass reformatting)
+   are not merged into `develop`,
+   so that fixes on the line and the merge back don't run into conflicts.
+
+### Release Candidates
+
+1. Fixes are developed against `staging/X.Y.x`.
+2. When ready, a new RC is created on `staging/X.Y.x`,
+   and `release/X.Y.x` is fast-forwarded to it.
+
+RCs that contain unpublished security fixes are not published,
+and don't touch the public branches.
+
+RCs are not merged back into `develop`:
+`X.Y.0-rc1` is tagged on `develop` itself,
+and all later changes reach `develop` with the [final release](#final-release).
+
+### Final Release
+
+Security fixes become public as soon as they reach the public repo,
+so these steps happen only once the release is ready to be published,
+one right after the other.
+
+1. Unpublished security fixes, if any, are merged into `staging/X.Y.x`.
+2. `release/X.Y.x` is fast-forwarded to `staging/X.Y.x`,
+   and the release is tagged on it.
+3. The release is immediately [merged back into `develop`](#merging-back-into-develop).
+   For a major-minor release, this lifts the freeze on large changes in `develop`.
+
+### Merging Back Into `develop`
+
+The merge back is a regular PR into `develop`
+whose branch contains a real merge commit of the release tag:
+
+1. Create a branch from `develop`, run `git merge --no-ff <tag>`, and resolve any conflicts.
+2. Once the PR is approved, `develop` is fast-forwarded to the PR branch,
+   so the merge commit lands as it is.
+   Never squash or rebase it.
+   Never add it to the merge queue either: the queue squashes PRs, which would drop the merge commit.
+3. If `develop` moves while the PR is open, redo the merge on top of the new `develop`.
+
+After the merge, `git log develop..<tag>` must be empty.
+
+## Special Cases
+
+### Emergency Fixes From `develop`
+
+If a commit was merged to `develop`
+and needs to be included in a release after the code freeze:
+
+1. Create a PR that cherry-picks the commit onto `staging/X.Y.x`.
+2. Leave `develop` as it is, with no reverts.
+3. Follow the [release candidates](#release-candidates) process as usual.
+
+When the release is later merged back into `develop`,
+both sides already contain the same change,
+so the merge usually resolves it cleanly or with a trivial conflict.
+From Git's perspective, the cherry-picked commit then becomes part of `develop` too.
+
+### Several Supported Lines
+
+When a fix must ship in more than one supported line (e.g., `X.Y` and `X.(Y+1)`),
+the lines are merged upwards rather than cherry-picked between:
+
+1. The fix goes into the oldest line first.
+2. After that line's release,
+   its `release/X.Y.x` is merged into the staging branch of the next newer line,
+   and so on up to the newest line.
+3. The newest line is merged back into `develop` as usual.
+
+This way every newer line, and eventually `develop`, contains the history of the older lines.

bin/check-tools.sh

@@ -20,19 +20,32 @@
 # development setups, but not in the macOS CI environment. They are checked
 # everywhere except when running in CI on macOS.
 #
-# Tools that Nix also exposes under a version-suffixed name (`clang-tidy-22`,
-# `g++-15`, ...) are probed under both names: a suffixed name can break while
-# the plain one still works (see mkVersionedToolLinks in nix/packages.nix).
+# Tools that Nix also exposes under a version-suffixed name
+# (`clang-tidy-<v>`, `g++-<v>`, ...) are probed under both names:
+# a suffixed name can break while the plain one still works
+# (see mkVersionedToolLinks in nix/packages.nix).
+# The suffix is the major version of the plain `clang` / `gcc` on PATH.
+#
+# Tools scoped to a single dev shell rather than to commonPackages are checked
+# only in that shell, keyed off XRPL_DEVSHELL.
 #
 # Environment variables:
 #   CI                      if set, skip the tools above when on macOS.
 #   CHECK_TOOLS_SKIP_CLONE  if set, skip the git-over-HTTPS connectivity check.
+#   XRPL_DEVSHELL           active dev shell; selects shell-specific tools.
 
 set -uo pipefail
 
-# Version suffixes of the Nix tool links, tracking nix/packages.nix.
-gcc_version=15
-llvm_version=22
+# major_version <compiler>
+# Major version of a compiler on PATH, or "unknown" when it isn't there.
+major_version() {
+    local version
+    version="$("$1" -dumpversion 2>/dev/null)" || version=""
+    version="${version%%.*}"
+    printf '%s' "${version:-unknown}"
+}
+
+llvm_version="$(major_version clang)"
 
 missing=()
 checked=0
@@ -108,6 +121,7 @@ if [ "${os}" = "linux" ] || [ "${os}" = "macos" ]; then
     check ClangBuildAnalyzer
     check curl
     check file
+    check jq
     check less
     check make
     # net-tools netstat reports "net-tools X.Y"; macOS ships BSD netstat with no
@@ -163,11 +177,20 @@ if [ "${os}" = "linux" ] || [ "${os}" = "macos" ]; then
     check rustfmt
 fi
 
+# Lean4 is in the formal-verification shell only, not in commonPackages.
+if [ "${XRPL_DEVSHELL:-}" = "formal-verification" ]; then
+    echo
+    echo "Formal verification toolchain:"
+    check lean
+    check lake
+fi
+
 # GCC is the default compiler on Linux. macOS uses the system Apple Clang
 # instead, so GCC/g++/gcov are not expected there.
 if [ "${os}" = "linux" ]; then
     echo
     echo "GCC toolchain:"
+    gcc_version="$(major_version gcc)"
     check gcc
     check "gcc-${gcc_version}"
     check g++

bin/git/update-version.sh

@@ -1,56 +0,0 @@
-#!/bin/bash
-
-if [[ $# -ne 3 || "$1" == "--help" || "$1" = "-h" ]]; then
-    name=$(basename $0)
-    cat <<-USAGE
-    Usage: $name workbranch base/branch version
-
-    * workbranch will be created locally from base/branch. If it exists,
-        it will be reused, so make sure you don't overwrite any work.
-    * base/branch may be specified as user:branch to allow easy copying
-        from Github PRs.
-USAGE
-    exit 0
-fi
-
-work="$1"
-shift
-
-base=$(echo "$1" | sed "s/:/\//")
-shift
-
-version=$1
-shift
-
-set -e
-
-git fetch upstreams
-
-git checkout -B "${work}" --no-track "${base}"
-
-push=$(git rev-parse --abbrev-ref --symbolic-full-name '@{push}' \
-    2>/dev/null) || true
-if [[ "${push}" != "" ]]; then
-    echo "Warning: ${push} may already exist."
-fi
-
-build=$(find -name BuildInfo.cpp)
-sed 's/\(^.*versionString =\).*$/\1 "'${version}'"/' ${build} >version.cpp &&
-    diff "${build}" version.cpp && exit 1 ||
-    mv -vi version.cpp ${build}
-
-git diff
-
-git add ${build}
-
-git commit -S -m "Set version to ${version}"
-
-git log --oneline --first-parent ${base}^..
-
-cat <<PUSH
-
--------------------------------------------------------------------
-This script will not push. Verify everything is correct, then push
-to your repo, and create a PR as described in CONTRIBUTING.md.
--------------------------------------------------------------------
-PUSH

bin/nix/check-build-context-runtime.sh

@@ -0,0 +1,65 @@
+#!/usr/bin/env bash
+# Fail if a binary of a build-context Conan package loads anything from the Nix
+# store other than glibc, or cannot resolve a library at all.
+#
+# Only binaries linked by the Nix toolchain are checked, i.e. those recording a
+# store path as their interpreter or RUNPATH. Prebuilt upstream binaries (such
+# as the ones the cmake package ships) use the system loader instead.
+#
+# Build-context packages provide the tools that run during the build (protoc,
+# grpc_cpp_plugin, ...). Their package ID does not change when a Nix toolchain
+# update moves the GCC runtime to a new store path, so a cached binary has to
+# get by with the pinned glibc alone. See docs/build/nix.md.
+#
+# Usage: bin/nix/check-build-context-runtime.sh <graph.json>
+#   <graph.json> is the output of `conan install --format=json`.
+
+set -euo pipefail
+
+if [ "$#" -ne 1 ]; then
+    echo "usage: $0 <graph.json>" >&2
+    exit 2
+fi
+
+if [ "$(uname -s)" != "Linux" ]; then
+    echo "$0: Linux only" >&2
+    exit 2
+fi
+
+folders="$(jq -r '.graph.nodes[] | select(.context == "build" and .package_folder) | .package_folder' "$1" | sort -u)"
+
+checked=0
+failed=0
+
+while IFS= read -r file; do
+    case "$(file -b "${file}")" in
+        ELF*) ;;
+        *) continue ;;
+    esac
+    [[ "$(readelf -ldW "${file}")" == */nix/store/* ]] || continue
+    checked=$((checked + 1))
+
+    # `ldd` lists the interpreter and every library as the loader resolves them.
+    if deps="$(ldd "${file}" 2>&1)"; then
+        bad="$(printf '%s\n' "${deps}" |
+            grep -E 'not found|/nix/store/' |
+            grep -vE '/nix/store/[^/]+-glibc-[^/]+/' || true)"
+    else
+        case "${deps}" in
+            *"not a dynamic executable"*) continue ;;
+        esac
+        bad="${deps}"
+    fi
+    if [ -n "${bad}" ]; then
+        failed=$((failed + 1))
+        echo "::error file=${file}::loads a library from the Nix store other than glibc"
+        echo "${file}"
+        echo "${bad}" | sed 's/^/    /'
+    fi
+done < <(
+    # shellcheck disable=SC2086 # one folder per line, no spaces in Conan paths
+    [ -z "${folders}" ] || find ${folders} -type f \( -perm -u+x -o -name '*.so*' \)
+)
+
+echo "Build-context packages: checked ${checked} binaries, ${failed} failed."
+[ "${failed}" -eq 0 ]

bin/nix/check-nix-store-refs.sh

@@ -10,7 +10,7 @@
 # alone; the scripts in a Conan cache are all git hook samples and autotools
 # scratch, 36 false positives to 0 real.
 #
-# Usage: bin/check-nix-store-refs.sh <path>
+# Usage: bin/nix/check-nix-store-refs.sh <path>
 
 set -euo pipefail
 

bin/pre-commit/Dockerfile

@@ -23,7 +23,7 @@ apt-get clean
 rm -rf /var/lib/apt/lists/*
 EOF
 
-ARG PRE_COMMIT_VERSION=4.6.0
+ARG PRE_COMMIT_VERSION=4.6.2
 RUN pip install --no-cache --break-system-packages \
     pre-commit==${PRE_COMMIT_VERSION}
 

bin/pre-commit/clang_tidy_check.py

@@ -26,8 +26,6 @@ import sys
 import tempfile
 from pathlib import Path
 
-CLANG_TIDY_VERSION = 22
-
 # Extensions run-clang-tidy can analyse: `.cpp` translation units and, thanks to
 # the `verify_headers` build option, `.h`/`.hpp` headers (each has its own
 # compile_commands.json entry). `.ipp` fragments have no entry and are skipped.
@@ -39,8 +37,21 @@ TIDY_EXTENSIONS = {".cpp", ".h", ".hpp"}
 FILEPATH_RE = re.compile(r"^(\s*(?:-\s+)?FilePath:\s*)'((?:[^']|'')*)'\s*$")
 
 
-def find_tool(name: str) -> str | None:
-    for candidate in (f"{name}-{CLANG_TIDY_VERSION}", name):
+def clang_tidy_major() -> str | None:
+    """Major version of the `clang-tidy` on PATH, which run-clang-tidy invokes."""
+    if not (clang_tidy := shutil.which("clang-tidy")):
+        return None
+    output = subprocess.run(
+        [clang_tidy, "--version"], capture_output=True, text=True
+    ).stdout
+    m = re.search(r"LLVM version (\d+)", output)
+    return m.group(1) if m else None
+
+
+def find_tool(name: str, version: str | None) -> str | None:
+    """Prefer `<name>-<version>`, so a host tool of another version can't win."""
+    candidates = ([f"{name}-{version}"] if version else []) + [name]
+    for candidate in candidates:
         if path := shutil.which(candidate):
             return path
     return None
@@ -103,8 +114,9 @@ def main():
     if not files:
         return 0
 
-    run_clang_tidy = find_tool("run-clang-tidy")
-    clang_apply_replacements = find_tool("clang-apply-replacements")
+    version = clang_tidy_major()
+    run_clang_tidy = find_tool("run-clang-tidy", version)
+    clang_apply_replacements = find_tool("clang-apply-replacements", version)
     missing = [
         name
         for name, path in (
@@ -114,9 +126,10 @@ def main():
         if not path
     ]
     if missing:
+        tried = f" (tried the '-{version}' suffix too)" if version else ""
         print(
             f"clang-tidy check failed: TIDY is enabled but {' and '.join(missing)} "
-            f"was not found in PATH (tried the '-{CLANG_TIDY_VERSION}' suffix too).",
+            f"was not found in PATH{tried}.",
             file=sys.stderr,
         )
         return 1

cfg/xrpld-example.cfg

@@ -1368,41 +1368,23 @@
 #
 # [node_size]
 #
-#   DEPRECATED. Each size is now an alias for a [memory_limit] value:
-#   tiny = 4, small = 8, medium = 32, large = 64, huge = 128. Set
-#   [memory_limit] instead; setting this logs a warning at startup.
+#   Tunes the servers based on the expected load and available memory. Legal
+#   sizes are "tiny", "small", "medium", "large", and "huge". We recommend
+#   you start at the default and raise the setting if you have extra memory.
 #
-# [memory_limit]
+#   The code attempts to automatically determine the appropriate size for
+#   this parameter based on the amount of RAM and the number of execution
+#   cores available to the server. The current decision matrix is:
 #
-#   The memory budget, in gigabytes, that the server sizes its caches
-#   within. Cache sizes scale with the budget; the SHAMap tree node cache
-#   is capped to fit within half of it, enforced as it grows. Defaults to
-#   detected physical RAM (capped by the container limit when one is set);
-#   0 selects minimal sizes with no enforcement. Values above 1024 are
-#   rejected, and a value above detected RAM logs a warning.
-#   Set this when xrpld shares the machine with other services or runs in
-#   a container with a memory limit below the host's RAM. Thread counts
-#   are unrelated: they come from the core count and the [workers] /
-#   [io_workers] overrides.
-#
-#   Example:
-#       [memory_limit]
-#       16
-#
-# [tree_cache_age]
-#
-#   Seconds a SHAMap tree node stays cached after its last use. The default
-#   is 300. Accepted values are 10 to 3600.
-#
-# [ledger_cache_age]
-#
-#   Seconds a full ledger stays in the ledger cache after its last use. The
-#   default is 180. Accepted values are 10 to 3600.
-#
-# [ledger_fetch_size]
-#
-#   How many historical ledgers to acquire per fetch pass while backfilling.
-#   The default is 4. Accepted values are 1 to 16.
+#   |         |         Cores          |
+#   |---------|------------------------|
+#   |   RAM   |   1  | 2 or 3 |   ≥ 4  |
+#   |---------|------|--------|--------|
+#   |  < ~8GB | tiny |   tiny |   tiny |
+#   | < ~12GB | tiny |  small |  small |
+#   | < ~16GB | tiny |  small | medium |
+#   | < ~24GB | tiny |  small |  large |
+#   | < ~32GB | tiny |  small |   huge |
 #
 # [signing_support]
 #
@@ -1479,13 +1461,17 @@
 #
 # [beta_rpc_api]
 #
-#   0 or 1.
+#   0 or 1. The section must hold exactly one line carrying that value: a bare
+#   [beta_rpc_api] header with nothing under it leaves the flag off, and the
+#   server logs one line saying so.
 #
 #   0: Disable the beta API version for JSON-RPC and WebSocket [default]
 #   1: Enable the beta API version for testing. The beta API version
 #      contains breaking changes that require a new API version number.
 #      They are not ready for public consumption.
 #
+#   The beta API version is 3; see API-VERSION-3.md.
+#
 #-------------------------------------------------------------------------------
 #
 # 10. Example Settings

cmake/GitInfo.cmake

@@ -1,28 +0,0 @@
-include_guard()
-
-set(GIT_BUILD_BRANCH "")
-set(GIT_COMMIT_HASH "")
-
-find_package(Git)
-if(NOT Git_FOUND)
-    message(WARNING "Git not found. Git branch and commit hash will be empty.")
-    return()
-endif()
-
-set(GIT_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/.git)
-
-execute_process(
-    COMMAND
-        ${GIT_EXECUTABLE} --git-dir=${GIT_DIRECTORY} rev-parse --abbrev-ref HEAD
-    OUTPUT_STRIP_TRAILING_WHITESPACE
-    OUTPUT_VARIABLE GIT_BUILD_BRANCH
-)
-
-execute_process(
-    COMMAND ${GIT_EXECUTABLE} --git-dir=${GIT_DIRECTORY} rev-parse HEAD
-    OUTPUT_STRIP_TRAILING_WHITESPACE
-    OUTPUT_VARIABLE GIT_COMMIT_HASH
-)
-
-message(STATUS "Git branch: ${GIT_BUILD_BRANCH}")
-message(STATUS "Git commit hash: ${GIT_COMMIT_HASH}")

cmake/PatchNixBinary.cmake

@@ -17,7 +17,7 @@
    (runtime libraries resolved through the rpath) are skipped too.
    Everywhere else `patch_nix_binary` is a no-op.
 
-   The default loader is resolved by bin/default-loader-path.sh.
+   The default loader is resolved by bin/nix/default-loader-path.sh.
 #]===================================================================]
 
 include_guard(GLOBAL)
@@ -25,7 +25,7 @@ include_guard(GLOBAL)
 include(CompilationEnv)
 
 # Resolves the system default ELF loader path for the current architecture.
-set(_loader_path_script "${CMAKE_SOURCE_DIR}/bin/default-loader-path.sh")
+set(_loader_path_script "${CMAKE_SOURCE_DIR}/bin/nix/default-loader-path.sh")
 
 if(
     is_linux

cmake/XrplCore.cmake

@@ -81,7 +81,7 @@ include(target_link_modules)
 add_module(xrpl beast)
 target_link_libraries(xrpl.libxrpl.beast PUBLIC xrpl.imports.main)
 
-include(GitInfo)
+include(XrplVersion)
 add_module(xrpl git)
 target_compile_definitions(
     xrpl.libxrpl.git
@@ -111,6 +111,11 @@ target_link_libraries(
     xrpl.libxrpl.protocol
     PUBLIC xrpl.libxrpl.crypto xrpl.libxrpl.git xrpl.libxrpl.json
 )
+# Only on BuildInfo.cpp, so a new version does not rebuild the whole module.
+set_source_files_properties(
+    ${CMAKE_CURRENT_SOURCE_DIR}/src/libxrpl/protocol/BuildInfo.cpp
+    PROPERTIES COMPILE_DEFINITIONS XRPLD_VERSION="${XRPLD_VERSION}"
+)
 
 # Level 05
 add_module(xrpl protocol_autogen)
@@ -287,6 +292,14 @@ if(xrpld)
     )
     target_sources(xrpld PRIVATE ${sources})
 
+    rpcspec_generate_instantiations(
+        OUT_VAR rpcspec_instantiations
+        VALUE_TYPE "::json::Value"
+        VIEW_HEADER "xrpld/rpc/detail/JsonObjectView.hpp"
+        HANDLERS book_changes ledger transaction_entry
+    )
+    target_sources(xrpld PRIVATE ${rpcspec_instantiations})
+
     if(tests)
         file(
             GLOB_RECURSE sources
@@ -317,6 +330,7 @@ if(xrpld)
         # antithesis_instrumentation.h, which is not exported as INTERFACE
         target_include_directories(
             xrpld
+            SYSTEM
             PRIVATE ${CMAKE_SOURCE_DIR}/external/antithesis-sdk
         )
     endif()

cmake/XrplSanitizers.cmake

@@ -77,19 +77,24 @@ if(is_clang)
     message(STATUS "  Ignorelist: ${ignorelist_path}")
 endif()
 
-# Define SANITIZERS macro for BuildInfo.cpp
+# Define the SANITIZERS macro for BuildInfo.cpp, plus one of XRPL_ASAN,
+# XRPL_TSAN and XRPL_UBSAN per active sanitizer, so that code can test for a
+# specific one with #ifdef instead of parsing the dot-joined SANITIZERS string.
 set(sanitizers_list)
 if(SANITIZERS MATCHES "address")
     set(enable_asan ON)
     list(APPEND sanitizers_list "ASAN")
+    target_compile_definitions(common INTERFACE XRPL_ASAN)
 endif()
 if(SANITIZERS MATCHES "thread")
     set(enable_tsan ON)
     list(APPEND sanitizers_list "TSAN")
+    target_compile_definitions(common INTERFACE XRPL_TSAN)
 endif()
 if(SANITIZERS MATCHES "undefinedbehavior")
     set(enable_ubsan ON)
     list(APPEND sanitizers_list "UBSAN")
+    target_compile_definitions(common INTERFACE XRPL_UBSAN)
 endif()
 
 if(sanitizers_list)

cmake/XrplVersion.cmake

@@ -1,15 +1,75 @@
-#[===================================================================[
-   read version from source
-#]===================================================================]
+find_package(Git)
 
-file(STRINGS src/libxrpl/protocol/BuildInfo.cpp BUILD_INFO)
-foreach(line_ ${BUILD_INFO})
-    if(line_ MATCHES "versionString[ ]*=[ ]*\"(.+)\"")
-        set(xrpld_version ${CMAKE_MATCH_1})
-    endif()
-endforeach()
-if(xrpld_version)
-    message(STATUS "xrpld version: ${xrpld_version}")
-else()
-    message(FATAL_ERROR "unable to determine xrpld version")
+set(GIT_BUILD_BRANCH "")
+set(GIT_COMMIT_HASH "")
+
+if(DEFINED ENV{GITHUB_BRANCH_NAME})
+    set(GIT_BUILD_BRANCH $ENV{GITHUB_BRANCH_NAME})
+    set(GIT_COMMIT_HASH $ENV{GITHUB_HEAD_SHA})
+elseif(Git_FOUND AND EXISTS "${CMAKE_CURRENT_LIST_DIR}/../.git")
+    execute_process(
+        COMMAND ${GIT_EXECUTABLE} rev-parse --abbrev-ref HEAD
+        WORKING_DIRECTORY ${CMAKE_CURRENT_LIST_DIR}/..
+        OUTPUT_VARIABLE GIT_BUILD_BRANCH
+        OUTPUT_STRIP_TRAILING_WHITESPACE
+        COMMAND_ERROR_IS_FATAL ANY
+    )
+
+    execute_process(
+        COMMAND ${GIT_EXECUTABLE} rev-parse HEAD
+        WORKING_DIRECTORY ${CMAKE_CURRENT_LIST_DIR}/..
+        OUTPUT_VARIABLE GIT_COMMIT_HASH
+        OUTPUT_STRIP_TRAILING_WHITESPACE
+        COMMAND_ERROR_IS_FATAL ANY
+    )
 endif()
+
+message(STATUS "Git branch: ${GIT_BUILD_BRANCH}")
+message(STATUS "Git commit hash: ${GIT_COMMIT_HASH}")
+
+if(
+    DEFINED ENV{FORCE_XRPLD_VERSION}
+    AND NOT "$ENV{FORCE_XRPLD_VERSION}" STREQUAL ""
+)
+    message(
+        STATUS
+        "Using explicitly provided '$ENV{FORCE_XRPLD_VERSION}' as xrpld version"
+    )
+
+    set(XRPLD_VERSION "$ENV{FORCE_XRPLD_VERSION}")
+
+    # The rules beast::SemanticVersion::parse applies, so that an invalid version
+    # fails here rather than when xrpld starts. It reads each number as an int.
+    set(SEMVER_NUMBER "(0|[1-9][0-9]*)")
+    set(SEMVER_PRE_RELEASE "[A-Za-z1-9-][A-Za-z0-9-]*")
+    set(SEMVER_METADATA "[A-Za-z0-9-]+")
+    set(SEMVER_NUMBER_MAX 2147483647)
+    if(
+        NOT XRPLD_VERSION
+            MATCHES
+            "^${SEMVER_NUMBER}\\.${SEMVER_NUMBER}\\.${SEMVER_NUMBER}(-${SEMVER_PRE_RELEASE}(\\.${SEMVER_PRE_RELEASE})*)?(\\+${SEMVER_METADATA}(\\.${SEMVER_METADATA})*)?$"
+        OR CMAKE_MATCH_1 GREATER SEMVER_NUMBER_MAX
+        OR CMAKE_MATCH_2 GREATER SEMVER_NUMBER_MAX
+        OR CMAKE_MATCH_3 GREATER SEMVER_NUMBER_MAX
+    )
+        message(
+            FATAL_ERROR
+            "FORCE_XRPLD_VERSION '${XRPLD_VERSION}' is not a semantic version xrpld accepts, see https://semver.org"
+        )
+    endif()
+else()
+    message(STATUS "Using '0.0.0-dev+<git short rev>' as xrpld version")
+
+    if(GIT_COMMIT_HASH STREQUAL "")
+        message(
+            FATAL_ERROR
+            "Unable to determine xrpld version without git, set FORCE_XRPLD_VERSION"
+        )
+    endif()
+
+    string(SUBSTRING ${GIT_COMMIT_HASH} 0 7 GIT_COMMIT_HASH_SHORT)
+
+    set(XRPLD_VERSION "0.0.0-dev+${GIT_COMMIT_HASH_SHORT}")
+endif()
+
+message(STATUS "Build version: ${XRPLD_VERSION}")

conan.lock

@@ -3,7 +3,7 @@
     "requires": [
         "zlib/1.3.2#1cb806da49011867778ffb6ac7190fcb%1782392402.122708",
         "xxhash/0.8.3#681d36a0a6111fc56e5e45ea182c19cc%1782392402.420688",
-        "xrpl-rpc-spec/0.1.19#870b2d3abcfbbf13b61c2d3c69495060%1790348286.187549",
+        "xrpl-rpc-spec/0.1.21#d536f87a2ae7d313452746cfa3ac4404%1790869005.122975",
         "sqlite3/3.53.0#324ada52333108388a9a6108bfa96734%1782392403.185447",
         "soci/4.0.3#e726491a03468795453f7c83fc924a96%1782392402.679521",
         "snappy/1.1.10#968fef506ff261592ec30c574d4a7809%1782307151.633168",
@@ -20,7 +20,7 @@
         "libarchive/3.8.7#c446109bd1f1d8ba7936c94189bc50e6%1782392403.066892",
         "jemalloc/5.3.1#1fc58d55316041f10fbc1e8a2eae632a%1776700028.228",
         "gtest/1.17.0#5224b3b3ff3b4ce1133cbdd27d53ee7d%1782392402.791979",
-        "grpc/1.81.1#b87796a4269034856cbc1a2522db16eb%1788275071.530512",
+        "grpc/1.81.1#aaa93ab6cda2f2baa6a84490582c8adf%1791284951.826256",
         "fast_float/8.2.10#f6f28d6bb22112078e7dbda611caf681%1785888854.601666",
         "ed25519/2015.03#ae761bdc52730a843f0809bdf6c1b1f6%1782307148.15562",
         "date/3.0.4#862e11e80030356b53c2c38599ceb32b%1782392402.538492",
@@ -34,11 +34,15 @@
     "build_requires": [
         "zlib/1.3.2#1cb806da49011867778ffb6ac7190fcb%1782392402.122708",
         "strawberryperl/5.32.1.1#8d114504d172cfea8ea1662d09b6333e%1782395692.540639",
+        "re2/20251105#8579cfd0bda4daf0683f9e3898f964b4%1782392402.431897",
         "protobuf/6.33.5#ff253ead763bd8d9904a52979cd21e81%1782392410.233933",
+        "openssl/3.6.3#f806de8933e3bf6f01016c6a888cee2e%1783945160.863288",
         "nasm/2.16.01#31e26f2ee3c4346ecd347911bd126904%1782395690.33162",
         "msys2/cci.latest#d22fe7b2808f5fd34d0a7923ace9c54f%1770657326.649",
         "m4/1.4.19#1727f439cf74e83826ec96d0b4904eee%1784541921.659",
+        "grpc/1.81.1#aaa93ab6cda2f2baa6a84490582c8adf%1791284951.826256",
         "cmake/4.3.3#840cf00ea09777e05c2050a50a82c722%1782392418.696091",
+        "c-ares/1.34.6#545240bb1c40e2cacd4362d6b8967650%1782392402.681654",
         "b2/5.4.2#ffd6084a119587e70f11cd45d1a386e2%1782392402.624226",
         "automake/1.16.5#b91b7c384c3deaa9d535be02da14d04f%1755524470.56",
         "autoconf/2.71#51077f068e61700d65bb05541ea1e4b0%1731054366.86",

conan/global.conf

@@ -3,5 +3,13 @@
 core:non_interactive=True
 core.download:parallel={{ os.cpu_count() }}
 core.upload:parallel={{ os.cpu_count() }}
-tools.files.download:retry=5
+# Fall back to Conan Center's source backups when a recipe's upstream URL is down
+# (e.g. the GNU FTP mirrors), see
+# https://github.com/conan-io/conan-center-index/issues/28147#issuecomment-3183544772
+# The backups are only tried once every upstream URL has used up its retries,
+# so keep the retries low.
+core.sources:download_urls=["origin", "https://c3i.jfrog.io/artifactory/conan-center-backup-sources"]
+tools.files.download:retry=1
 tools.files.download:retry_wait=10
+# Fail fast on unreachable hosts (default connect timeout is 30s), keep the 60s read timeout.
+core.net.http:timeout=(5, 60)

conan/profiles/default

@@ -29,9 +29,9 @@ os.version={{ min_macos_version }}
 [conf]
 {# The Boost recipe builds with b2, which doesn't use Conan's toolchain files. #}
 {# Instead it hand-rolls the compiler for user-config.jam, #}
-{# and its fallback probes a version-suffixed binary (e.g. `g++-15`) before plain `g++`. #}
-{# Inside the Nix shell the wrapper only provides `g++`/`gcc` (no `-15` suffix), #}
-{# so on a host that also has a system `g++-15` the probe escapes Nix #}
+{# and its fallback probes a version-suffixed binary (e.g. `g++-<major>`) before plain `g++`. #}
+{# Inside the Nix shell the wrapper only provides `g++`/`gcc` (no `-<major>` suffix), #}
+{# so on a host that also has a system `g++-<major>` the probe escapes Nix #}
 {# and picks the system compiler, which is mismatched with the Nix libraries #}
 {# and breaks the build (e.g. Boost.Stacktrace link checks fail). #}
 {# Pinning the executables here short-circuits that probe so Boost (and the rest of the toolchain) #}
@@ -49,8 +49,31 @@ tools.build:compiler_executables={'c':'{{ cc_exe }}','cpp':'{{ cxx_exe }}'}
 user.package:cppstd_version=23
 tools.info.package_id:confs+=["user.package:cppstd_version"]
 
-{% if os == "Macos" %}
+{% if os == "Linux" and context == "build" %}
+{# Build-context executables (protoc, grpc_cpp_plugin, build tools) run during the build #}
+{# and would otherwise load libstdc++/libgcc from a Nix store path #}
+{# that might change with a Nix toolchain update. #}
+{# --as-needed drops the ones they link but don't use, #}
+{# such as libatomic for grpc_cpp_plugin on arm64. #}
+{% set static_runtime_flags = ["-static-libstdc++", "-static-libgcc", "-Wl,--as-needed"] %}
+tools.build:exelinkflags+={{ static_runtime_flags }}
+tools.info.package_id:confs+=["tools.build:exelinkflags"]
+{% endif %}
+
+{% if os == "Linux" and context == "build" %}
+{# b2 links itself with its own script, which ignores exelinkflags #}
+{# and only takes CXXFLAGS when use_cxx_env is set (see [buildenv] below). #}
+[options]
+b2/*:use_cxx_env=True
+{% endif %}
+
 [buildenv]
+{# gRPC emits thousands of compiler warnings that we cannot act on. #}
+{# CMake picks up CXXFLAGS, and unlike tools.build:cxxflags, #}
+{# this is not part of the package ID, so binaries stay shareable. #}
+grpc/*:CXXFLAGS=-w
+
+{% if os == "Macos" %}
 {# os.version adds -mmacosx-version-min to compiler command lines, #}
 {# but Boost.Context's b2 assembly (.S) rule ignores it, #}
 {# so those objects keep the host SDK version and still warn at link time. #}
@@ -58,3 +81,7 @@ tools.info.package_id:confs+=["user.package:cppstd_version"]
 {# Scoped to boost/* since it is the only gap. #}
 boost/*:MACOSX_DEPLOYMENT_TARGET={{ min_macos_version }}
 {% endif %}
+
+{% if os == "Linux" and context == "build" %}
+b2/*:CXXFLAGS={{ static_runtime_flags | join(" ") }}
+{% endif %}

conan/profiles/sanitizers

@@ -5,6 +5,9 @@ include(default)
 
 {% if not sanitizers %}
 {# Sanitizers not configured; no additional settings needed #}
+{% elif context == "build" %}
+{# Build-context packages are tools we run, not code we test, #}
+{# so don't instrument them #}
 {% else %}
 
 {% if compiler == "msvc" %}

conanfile.py

@@ -1,9 +1,13 @@
+import os
 import re
 
 from conan.tools.cmake import CMake, CMakeToolchain, cmake_layout
+from conan.tools.env import Environment
 
 from conan import ConanFile
 
+DEV_VERSION = "0.0.0-dev"
+
 
 class Xrpl(ConanFile):
     name = "xrpl"
@@ -36,7 +40,7 @@ class Xrpl(ConanFile):
         "nudb/2.0.9",
         "openssl/3.6.3",
         "soci/4.0.3",
-        "xrpl-rpc-spec/0.1.19",
+        "xrpl-rpc-spec/0.1.21",
         "zlib/1.3.2",
     ]
 
@@ -45,7 +49,8 @@ class Xrpl(ConanFile):
     ]
 
     tool_requires = [
-        "protobuf/6.33.5",
+        "grpc/<host_version>",
+        "protobuf/<host_version>",
     ]
 
     default_options = {
@@ -119,14 +124,12 @@ class Xrpl(ConanFile):
         "xxhash/*:shared": False,
     }
 
+    # default_options only reach the host context;
+    # give tool_requires (and their dependencies) the same dependency options.
+    default_build_options = {k: v for k, v in default_options.items() if "/" in k}
+
     def set_version(self):
-        if self.version is None:
-            path = f"{self.recipe_folder}/src/libxrpl/protocol/BuildInfo.cpp"
-            regex = r"versionString\s?=\s?\"(.*)\""
-            with open(path, encoding="utf-8") as file:
-                matches = (re.search(regex, line) for line in file)
-                match = next(m for m in matches if m)
-                self.version = match.group(1)
+        self.version = self.version or DEV_VERSION
 
     def configure(self):
         if self.settings.compiler == "apple-clang":
@@ -151,7 +154,7 @@ class Xrpl(ConanFile):
         self.requires("xxhash/0.8.3", transitive_headers=True)
 
     exports_sources = (
-        "bin/default-loader-path.sh",
+        "bin/nix/default-loader-path.sh",
         "CMakeLists.txt",
         "cfg/*",
         "cmake/*",
@@ -169,6 +172,17 @@ class Xrpl(ConanFile):
     generators = "CMakeDeps"
 
     def generate(self):
+        # The sources in the Conan cache have no git history, so the version
+        # comes from the reference, unless it is not one, like 'develop'.
+        if not os.path.exists(os.path.join(self.source_folder, ".git")):
+            version = str(self.version)
+            env = Environment()
+            env.define(
+                "FORCE_XRPLD_VERSION",
+                version if re.match(r"\d+\.\d+\.\d+", version) else DEV_VERSION,
+            )
+            env.vars(self).save_script("xrpld_version")
+
         tc = CMakeToolchain(self)
         tc.variables["tests"] = self.options.tests
         tc.variables["benchmark"] = self.options.benchmark

crates/CMakeLists.txt

@@ -80,13 +80,12 @@ function(add_xrpl_crate name)
     # `cc` picks its runtime flag from `crt-static` alone, so it compiles a
     # crate's C++ with `-MT`; Debug needs `-MTd` (to match cmake/XrplCompiler.cmake).
     if(is_msvc)
-        corrosion_set_env_vars(
-            ${ARG_CRATE}
-            "$<$<CONFIG:Debug>:CXXFLAGS=-MTd>"
-        )
+        corrosion_set_env_vars(${ARG_CRATE} "$<$<CONFIG:Debug>:CXXFLAGS=-MTd>")
     endif()
-    corrosion_add_cxxbridge(${name}_cxxbridge CRATE ${ARG_CRATE} FILES
-                            ${ARG_FILES}
+    corrosion_add_cxxbridge(
+        ${name}_cxxbridge
+        CRATE ${ARG_CRATE}
+        FILES ${ARG_FILES}
     )
     # Generated cxxbridge headers don't exist at configure time; CMake 3.28+
     # validates INTERFACE_SOURCES on consuming targets. Clear it to skip the

docs/Docker.md

@@ -4,7 +4,7 @@
 the `xrpld` DEB package installed on Ubuntu 26.04, running as the `xrpld` user.
 Each release is tagged with its version, `xrplf/xrpld:<version>`, and
 `xrplf/xrpld:develop` follows the `develop` branch.
-See [`package/README.md`](../package/README.md#docker-image) for how it is built
+See [`package/README.md`](../package/README.md#docker-images) for how it is built
 and tagged.
 
 ```bash

docs/build/environment.md

@@ -10,14 +10,15 @@ This document explains how to set one up.
 support it — see [compiler support for C++23][cpp23-support].
 The versions currently tested in CI are:
 
-| Compiler    | Version            |
-| ----------- | ------------------ |
-| GCC         | 15.2               |
-| Clang       | 22                 |
-| Apple Clang | 21                 |
-| MSVC        | Visual Studio 2026 |
+| Compiler    | Version                         |
+| ----------- | ------------------------------- |
+| GCC         | `gccVersion` in [packages.nix]  |
+| Clang       | `llvmVersion` in [packages.nix] |
+| Apple Clang | 21                              |
+| MSVC        | Visual Studio 2026              |
 
-LLVM tools (`clang-tidy` and `clang-format`) are also pinned to version 22.
+LLVM tools (`clang-tidy` and `clang-format`)
+come from the same LLVM release as Clang.
 
 ### Older compilers
 
@@ -156,3 +157,4 @@ version out of the box — run it via `run-clang-tidy`. No separate installation
 is needed.
 
 [cpp23-support]: https://en.cppreference.com/w/cpp/compiler_support/23
+[packages.nix]: ../../nix/packages.nix

docs/build/nix.md

@@ -183,24 +183,36 @@ at link or run time.
 > configuration CI covers, and no dependency binaries are published for it.
 
 This is checked rather than assumed.
-[`bin/check-nix-store-refs.sh`](../../bin/check-nix-store-refs.sh) takes one file
-or directory and fails if a binary under it resolves a store path at run time.
+[`bin/nix/check-nix-store-refs.sh`](../../bin/nix/check-nix-store-refs.sh) takes one
+file or directory and fails if a binary under it resolves a store path at run time.
 CI runs it over the build output and the Conan cache, and again in the upload job
 before anything is published. You can run it yourself:
 
 ```bash
-bin/check-nix-store-refs.sh build
-bin/check-nix-store-refs.sh ~/.conan2-nix
+bin/nix/check-nix-store-refs.sh build
+bin/nix/check-nix-store-refs.sh ~/.conan2-nix
 ```
 
 It works on Linux too, but asserts something narrower there: the toolchain always
-writes the store into `PT_INTERP` and `RUNPATH`, and CI builds inside an image
-whose store is fixed for its lifetime, so that is fine. Only the binaries
-[`PatchNixBinary.cmake`](../../cmake/PatchNixBinary.cmake) retargets to the
-system loader have to be clean, and those are what CI checks:
+writes the store into `PT_INTERP` and `RUNPATH`. That is fine for the pinned
+glibc, whose path does not move, but not for the GCC runtime, which moves with
+every GCC update. So [`conan/profiles/default`](../../conan/profiles/default)
+links build-context packages, whose executables run during the build, with
+`-static-libstdc++ -static-libgcc -Wl,--as-needed`, and
+[`conan/profiles/sanitizers`](../../conan/profiles/sanitizers) does not
+instrument them. CI checks that they load nothing from the store but glibc, from
+the graph `conan install --format=json` writes:
 
 ```bash
-bin/check-nix-store-refs.sh build/xrpld
+bin/nix/check-build-context-runtime.sh graph.json
+```
+
+Only the binaries [`PatchNixBinary.cmake`](../../cmake/PatchNixBinary.cmake)
+retargets to the system loader have to be fully clean, and those are what CI
+checks:
+
+```bash
+bin/nix/check-nix-store-refs.sh build/xrpld
 ```
 
 ### The libresolv stub

docs/build/nix_troubleshooting.md

@@ -178,11 +178,11 @@ A binary stops starting after a `nix flake update`, or after
 dyld[57271]: Library not loaded: /nix/store/…-libresolv-93/lib/libresolv.9.dylib
 ```
 
-[`bin/check-nix-store-refs.sh`](../../bin/check-nix-store-refs.sh) finds the same
-thing without having to run anything, and names the file:
+[`bin/nix/check-nix-store-refs.sh`](../../bin/nix/check-nix-store-refs.sh) finds the
+same thing without having to run anything, and names the file:
 
 ```
-$ bin/check-nix-store-refs.sh ~/.conan2-nix
+$ bin/nix/check-nix-store-refs.sh ~/.conan2-nix
 ::error file=/Users/you/.conan2-nix/p/b/c-area24ded30c388c/p/bin/adig::references the Nix store at run time
 /Users/you/.conan2-nix/p/b/c-area24ded30c388c/p/bin/adig
     /nix/store/p4lp3xq4imd1qzqh08x8vcq2zfhi7rca-libresolv-93/lib/libresolv.9.dylib

external/antithesis-sdk/CMakeLists.txt

@@ -6,7 +6,7 @@ project(antithesis-sdk-cpp VERSION 0.4.4 LANGUAGES CXX)
 add_library(antithesis-sdk-cpp INTERFACE antithesis_sdk.h)
 
 # Note, both sections below created by xrpld project
-target_include_directories(antithesis-sdk-cpp INTERFACE
+target_include_directories(antithesis-sdk-cpp SYSTEM INTERFACE
   $<INSTALL_INTERFACE:${CMAKE_INSTALL_INCLUDEDIR}>
   $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}>
 )

flake.lock

@@ -2,11 +2,11 @@
   "nodes": {
     "nixpkgs": {
       "locked": {
-        "lastModified": 1781173989,
-        "narHash": "sha256-fnzKKPvS+oieI/pTzotA5tkoM47EB1NpaBcgk4R97hE=",
+        "lastModified": 1791130267,
+        "narHash": "sha256-1sjwcQMcgAbmiip/VivBSiK8p2bTkQGOvCuO7vnwfx4=",
         "owner": "NixOS",
         "repo": "nixpkgs",
-        "rev": "8c91a71d13451abc40eb9dae8910f972f979852f",
+        "rev": "9013764fcc0ea99fa16cf7aa7decf8a5c3889dd2",
         "type": "github"
       },
       "original": {
@@ -47,11 +47,11 @@
         ]
       },
       "locked": {
-        "lastModified": 1784611586,
-        "narHash": "sha256-OfqgY+0hp/zseZB7uyH0U8kIDPS4scZZCyAurEplvG0=",
+        "lastModified": 1791189933,
+        "narHash": "sha256-Y8eN7ki0Urx4Ojf4w1xSpWg8uk/3lJqK+E0Oth77rH0=",
         "owner": "oxalica",
         "repo": "rust-overlay",
-        "rev": "14f58845249f3552a89b07772626b8d3c632fa86",
+        "rev": "e60029353d0c48d216bc4b065168ccd4079c166f",
         "type": "github"
       },
       "original": {

include/xrpl/basics/MathUtilities.h

@@ -3,9 +3,84 @@
 #include <algorithm>
 #include <cassert>
 #include <cstddef>
+#include <cstdint>
+#include <limits>
+#include <optional>
 
 namespace xrpl {
 
+/**
+ * Add two signed 64-bit integers, returning std::nullopt when the exact
+ * mathematical sum is not representable in std::int64_t.
+ */
+[[nodiscard]] constexpr std::optional<std::int64_t>
+checkedAdd(std::int64_t a, std::int64_t b) noexcept
+{
+    using L = std::numeric_limits<std::int64_t>;
+
+    if ((b > 0 && a > L::max() - b) || (b < 0 && a < L::min() - b))
+        return std::nullopt;
+
+    return a + b;
+}
+
+/**
+ * Subtract two signed 64-bit integers, returning std::nullopt when the exact
+ * mathematical difference is not representable in std::int64_t.
+ */
+[[nodiscard]] constexpr std::optional<std::int64_t>
+checkedSub(std::int64_t a, std::int64_t b) noexcept
+{
+    using L = std::numeric_limits<std::int64_t>;
+
+    if ((b > 0 && a < L::min() + b) || (b < 0 && a > L::max() + b))
+        return std::nullopt;
+
+    return a - b;
+}
+
+static_assert(checkedAdd(0, 0) == 0);
+static_assert(checkedAdd(1, -1) == 0);
+static_assert(checkedAdd(-5, 2) == -3);
+static_assert(!checkedAdd(std::numeric_limits<std::int64_t>::max(), 1).has_value());
+static_assert(!checkedAdd(std::numeric_limits<std::int64_t>::min(), -1).has_value());
+static_assert(
+    checkedAdd(std::numeric_limits<std::int64_t>::max() - 1, 1) ==
+    std::numeric_limits<std::int64_t>::max());
+static_assert(
+    checkedAdd(
+        std::numeric_limits<std::int64_t>::min(),
+        std::numeric_limits<std::int64_t>::max()) == -1);
+static_assert(
+    checkedAdd(
+        std::numeric_limits<std::int64_t>::max(),
+        std::numeric_limits<std::int64_t>::min()) == -1);
+static_assert(
+    !checkedAdd(std::numeric_limits<std::int64_t>::max(), std::numeric_limits<std::int64_t>::max())
+         .has_value());
+static_assert(
+    !checkedAdd(std::numeric_limits<std::int64_t>::min(), std::numeric_limits<std::int64_t>::min())
+         .has_value());
+
+static_assert(checkedSub(0, 0) == 0);
+static_assert(checkedSub(1, 1) == 0);
+static_assert(checkedSub(-5, 2) == -7);
+static_assert(checkedSub(-5, -2) == -3);
+static_assert(!checkedSub(std::numeric_limits<std::int64_t>::min(), 1).has_value());
+static_assert(!checkedSub(std::numeric_limits<std::int64_t>::max(), -1).has_value());
+static_assert(
+    checkedSub(std::numeric_limits<std::int64_t>::min() + 1, 1) ==
+    std::numeric_limits<std::int64_t>::min());
+static_assert(
+    checkedSub(-1, std::numeric_limits<std::int64_t>::max()) ==
+    std::numeric_limits<std::int64_t>::min());
+static_assert(
+    !checkedSub(std::numeric_limits<std::int64_t>::max(), std::numeric_limits<std::int64_t>::min())
+         .has_value());
+static_assert(
+    !checkedSub(std::numeric_limits<std::int64_t>::min(), std::numeric_limits<std::int64_t>::max())
+         .has_value());
+
 /**
  * Calculate one number divided by another number in percentage.
  * The result is rounded up to the next integer, and capped in the range [0,100]

include/xrpl/basics/Number.h

@@ -110,10 +110,10 @@ static_assert(
  *
  * However, it does not have sufficient precision to represent the full integer
  * range of int64_t values (-2^63 to 2^63-1), which are needed for XRP and MPT
- * values. The implementation of SingleAssetVault, and LendingProtocol need to
- * represent those integer values accurately and precisely, both for the
- * STNumber field type, and for internal calculations. That necessitated the
- * "large" scale.
+ * values. The implementation of SingleAssetVault, LendingProtocol, and
+ * MPTokensV2 need to represent those integer values accurately and precisely,
+ * both for the STNumber field type, and for internal calculations. That
+ * necessitated the "large" scale.
  *
  * The "Large" scales are intended to represent all values that can be represented
  * by an STAmount - IOUs, XRP, and MPTs. It has a min value of 10^18, and a max
@@ -134,8 +134,8 @@ struct MantissaRange final
     // NOLINTBEGIN(readability-enum-initial-value)
     // The values don't matter, except for Large
     enum class MantissaScale {
-        // Small can be removed when either featureSingleAssetVault or featureLendingProtocol are
-        // retired
+        // Small can be removed when any of featureSingleAssetVault, featureLendingProtocol, or
+        // featureMPTokensV2 are retired
         Small,
         // LargeLegacy can be removed when fixCleanup3_2_0 is retired
         LargeLegacy,
@@ -311,10 +311,10 @@ concept Integral64 = std::is_same_v<T, std::int64_t> || std::is_same_v<T, std::u
  *
  * The mantissa range may be changed at runtime via setMantissaScale(). The
  * default mantissa range is "large". The range is updated whenever transaction
- * processing begins, based on whether SingleAssetVault or LendingProtocol are
- * enabled. If either is enabled, the mantissa range is set to "large". If not,
- * it is set to "small", preserving backward compatibility and correct
- * "amendment-gating".
+ * processing begins, based on whether SingleAssetVault, LendingProtocol, or
+ * MPTokensV2 are enabled. If any is enabled, the mantissa range is set to
+ * "large". If not, it is set to "small", preserving backward compatibility and
+ * correct "amendment-gating".
  *
  * It is extremely unlikely that any more calls to setMantissaScale() will be
  * needed outside of unit tests.
@@ -344,8 +344,8 @@ concept Integral64 = std::is_same_v<T, std::int64_t> || std::is_same_v<T, std::u
  * set/getMantissaScale() functions may be most appropriate. However, if the
  * test has anything to do with transaction processing, it should enable or
  * disable the amendments that control the mantissa range choice
- * (SingleAssetVault and LendingProtocol), and/or check if either of those
- * amendments are enabled to determine which result to expect.
+ * (SingleAssetVault, LendingProtocol, and MPTokensV2), and/or check if any of
+ * those amendments are enabled to determine which result to expect.
  */
 class Number final
 {

include/xrpl/basics/StringUtilities.h

@@ -36,7 +36,7 @@ template <typename T>
 concept SomeChar = std::same_as<std::remove_cvref_t<T>, int8_t> ||
     std::same_as<std::remove_cvref_t<T>, char> || std::same_as<std::remove_cvref_t<T>, uint8_t>;
 
-inline constexpr std::array<std::optional<int>, 256> const kDigitLookupTable = []() {
+inline constexpr std::array<std::optional<int>, 256> const kDigitLookupTable = [] {
     std::array<std::optional<int>, 256> t{};
 
     for (int i = 0; i < 10; ++i)

include/xrpl/basics/TaggedCache.h

@@ -15,11 +15,9 @@
 #include <chrono>
 #include <cstddef>
 #include <cstdint>
-#include <deque>
 #include <functional>
 #include <memory>
 #include <mutex>
-#include <optional>
 #include <string>
 #include <thread>
 #include <type_traits>
@@ -76,24 +74,13 @@ public:
     using SharedPointerType = SharedPointer;
 
 public:
-    /**
-     * @param cacheHardCap When positive, a hard upper bound on the number of
-     *     strongly-cached entries, enforced by demoting the approximately
-     *     oldest entry whenever growth would exceed it. 0 disables the cap
-     *     (the periodic sweep alone bounds the cache).
-     * @param partitions Number of partitions the underlying map is split
-     *     into; defaults to the hardware concurrency. Exposed so tests can
-     *     pin a small, known partition count.
-     */
     TaggedCache(
         std::string const& name,
         int size,
         ClockType::duration expiration,
         ClockType& clock,
         beast::Journal journal,
-        beast::insight::Collector::Ptr const& collector = beast::insight::NullCollector::make(),
-        int cacheHardCap = 0,
-        std::optional<std::size_t> partitions = std::nullopt);
+        beast::insight::Collector::Ptr const& collector = beast::insight::NullCollector::make());
 
 public:
     /**
@@ -114,13 +101,6 @@ public:
     int
     getTrackSize() const;
 
-    /**
-     * Returns the number of strong-key slots evictForHardCap has examined
-     * since construction.
-     */
-    std::uint64_t
-    getEvictVisits() const;
-
     float
     getHitRate();
 
@@ -334,9 +314,6 @@ private:
     public:
         SharedWeakComboPointerType ptr;
         ClockType::time_point lastAccess;
-        // Stamped by queueStrong each time the entry becomes strong; the
-        // strong-key slot carrying the same seq is the entry's live slot.
-        std::uint64_t strongSeq{0};
 
         ValueEntry(ClockType::time_point const& lastAccess, SharedPointerType const& ptr)
             : ptr(ptr), lastAccess(lastAccess)
@@ -380,26 +357,6 @@ private:
 
     using CacheType = HardenedPartitionedHashMap<key_type, Entry, Hash, KeyEqual>;
 
-    // Counts an entry that just became strong and, under a hard cap, queues
-    // its key for eviction and evicts down to the cap. Caller holds mutex_.
-    void
-    addStrong(CacheType::Iterator const& it);
-
-    // Stamps the entry with a new strong seq and appends its key to
-    // strongRing_, dropping stale slots once they outnumber the live ones.
-    // Caller holds mutex_.
-    void
-    queueStrong(key_type const& key, Entry& entry);
-
-    // CLOCK eviction over strongRing_: pops slots from the front, discards
-    // stale ones, gives `keep` and entries used since they became strong a
-    // second chance at the back, and demotes the first other strong entry,
-    // repeating until the count is back under cacheHardCap_ or the demotion
-    // budget is spent. Amortized O(1) per insert. No-op for key caches;
-    // caller holds mutex_.
-    void
-    evictForHardCap(CacheType::Iterator const& keep);
-
     [[nodiscard]] std::thread
     sweepHelper(
         ClockType::time_point const& whenExpire,
@@ -433,38 +390,8 @@ private:
     // Desired maximum cache age
     ClockType::duration const targetAge_;
 
-    // Hard upper bound on strongly-cached entries, enforced by
-    // evictForHardCap whenever the strong count grows (fresh inserts and
-    // weak-to-strong revivals). 0 disables it (sweep-only sizing).
-    int const cacheHardCap_;
-
-    // Total hard-cap evictions (under mutex_); the first marks saturation
-    // onset for logging.
-    std::uint64_t hardCapEvictions_{0};
-
     // Number of items cached
     int cacheCount_{0};
-
-    // A key, the strong seq its entry had when the slot was queued, and the
-    // time it was queued.
-    struct StrongSlot
-    {
-        key_type key;
-        std::uint64_t seq;
-        ClockType::time_point since;
-    };
-
-    // Keys in the order their entries became strong, consumed front-first
-    // by evictForHardCap. Filled only when cacheHardCap_ > 0. A slot is
-    // stale once its entry is gone, weak, or strong again under a newer seq.
-    std::deque<StrongSlot> strongRing_;
-
-    // Source of strong seqs; advanced under mutex_.
-    std::uint64_t strongSeqNext_{0};
-
-    // Slots examined by evictForHardCap; read by getEvictVisits.
-    std::uint64_t evictVisits_{0};
-
     CacheType cache_;  // Hold strong reference to recent objects
     std::uint64_t hits_{0};
     std::uint64_t misses_{0};

include/xrpl/basics/TaggedCache.ipp

@@ -57,9 +57,7 @@ inline TaggedCache<
         ClockType::duration expiration,
         ClockType& clock,
         beast::Journal journal,
-        beast::insight::Collector::Ptr const& collector,
-        int cacheHardCap,
-        std::optional<std::size_t> partitions)
+        beast::insight::Collector::Ptr const& collector)
     : journal_(journal)
     , clock_(clock)
     , stats_(
@@ -69,8 +67,6 @@ inline TaggedCache<
     , name_(name)
     , targetSize_(size)
     , targetAge_(expiration)
-    , cacheHardCap_(cacheHardCap)
-    , cache_(partitions)
 {
 }
 
@@ -141,23 +137,6 @@ TaggedCache<Key, T, IsKeyCache, SharedWeakUnionPointer, SharedPointerType, Hash,
     return cache_.size();
 }
 
-template <
-    class Key,
-    class T,
-    bool IsKeyCache,
-    class SharedWeakUnionPointer,
-    class SharedPointerType,
-    class Hash,
-    class KeyEqual,
-    class Mutex>
-inline std::uint64_t
-TaggedCache<Key, T, IsKeyCache, SharedWeakUnionPointer, SharedPointerType, Hash, KeyEqual, Mutex>::
-    getEvictVisits() const
-{
-    std::scoped_lock const lock(mutex_);
-    return evictVisits_;
-}
-
 template <
     class Key,
     class T,
@@ -191,7 +170,6 @@ TaggedCache<Key, T, IsKeyCache, SharedWeakUnionPointer, SharedPointerType, Hash,
 {
     std::scoped_lock const lock(mutex_);
     cache_.clear();
-    strongRing_.clear();
     cacheCount_ = 0;
 }
 
@@ -210,7 +188,6 @@ TaggedCache<Key, T, IsKeyCache, SharedWeakUnionPointer, SharedPointerType, Hash,
 {
     std::scoped_lock const lock(mutex_);
     cache_.clear();
-    strongRing_.clear();
     cacheCount_ = 0;
     hits_ = 0;
     misses_ = 0;
@@ -242,141 +219,6 @@ TaggedCache<Key, T, IsKeyCache, SharedWeakUnionPointer, SharedPointerType, Hash,
     return true;
 }
 
-template <
-    class Key,
-    class T,
-    bool IsKeyCache,
-    class SharedWeakUnionPointer,
-    class SharedPointerType,
-    class Hash,
-    class KeyEqual,
-    class Mutex>
-inline void
-TaggedCache<Key, T, IsKeyCache, SharedWeakUnionPointer, SharedPointerType, Hash, KeyEqual, Mutex>::
-    addStrong(CacheType::Iterator const& it)
-{
-    ++cacheCount_;
-    if constexpr (!IsKeyCache)
-    {
-        if (cacheHardCap_ > 0)
-        {
-            queueStrong(it->first, it->second);
-            if (cacheCount_ > cacheHardCap_)
-                evictForHardCap(it);
-        }
-    }
-}
-
-template <
-    class Key,
-    class T,
-    bool IsKeyCache,
-    class SharedWeakUnionPointer,
-    class SharedPointerType,
-    class Hash,
-    class KeyEqual,
-    class Mutex>
-inline void
-TaggedCache<Key, T, IsKeyCache, SharedWeakUnionPointer, SharedPointerType, Hash, KeyEqual, Mutex>::
-    queueStrong(key_type const& key, Entry& entry)
-{
-    entry.strongSeq = ++strongSeqNext_;
-    strongRing_.push_back({key, entry.strongSeq, clock_.now()});
-
-    // Stale slots accumulate from sweep and del; drop them once
-    // they outnumber the live ones so the ring stays O(strong entries).
-    constexpr std::size_t kRingSlack = 1024;
-    if (strongRing_.size() > 2 * static_cast<std::size_t>(cacheCount_) + kRingSlack)
-    {
-        std::erase_if(strongRing_, [this](StrongSlot const& s) {
-            auto const it = cache_.find(s.key);
-            return it == cache_.end() || it->second.isWeak() || it->second.strongSeq != s.seq;
-        });
-    }
-}
-
-template <
-    class Key,
-    class T,
-    bool IsKeyCache,
-    class SharedWeakUnionPointer,
-    class SharedPointerType,
-    class Hash,
-    class KeyEqual,
-    class Mutex>
-inline void
-TaggedCache<Key, T, IsKeyCache, SharedWeakUnionPointer, SharedPointerType, Hash, KeyEqual, Mutex>::
-    evictForHardCap(CacheType::Iterator const& keep)
-{
-    if constexpr (!IsKeyCache)
-    {
-        key_type const keepKey = keep->first;
-
-        // Growth paths raise the count by one at a time, so a few demotions
-        // per call let eviction catch up without stalling them.
-        constexpr int kMaxDemotionsPerCall = 8;
-
-        for (int demotions = 0; cacheCount_ > cacheHardCap_ && demotions < kMaxDemotionsPerCall;
-             ++demotions)
-        {
-            // Every strong entry owns one live slot, and only `keep` can be
-            // re-queued twice in one call, so two passes over the ring reach
-            // a victim whenever one exists.
-            bool demoted = false;
-            for (std::size_t budget = 2 * strongRing_.size();
-                 !demoted && budget > 0 && !strongRing_.empty();
-                 --budget)
-            {
-                StrongSlot const slot = strongRing_.front();
-                strongRing_.pop_front();
-                ++evictVisits_;
-
-                auto it = cache_.find(slot.key);
-                if (it == cache_.end() || it->second.isWeak() || it->second.strongSeq != slot.seq)
-                    continue;  // stale: the entry is gone, weak, or re-queued since
-
-                if (slot.key == keepKey || it->second.lastAccess > slot.since)
-                {
-                    // The newest entry stays; one used since it became
-                    // strong gets a second chance at the back.
-                    queueStrong(slot.key, it->second);
-                    continue;
-                }
-
-                if (it->second.ptr.useCount() == 1)
-                {
-                    // Sole owner: release entirely.
-                    cache_.erase(it);
-                }
-                else
-                {
-                    // Others hold it: keep it weakly tracked.
-                    it->second.ptr.convertToWeak();
-                }
-                --cacheCount_;
-                demoted = true;
-
-                // First eviction marks saturation onset; then a heartbeat
-                // every 100k to avoid flooding.
-                ++hardCapEvictions_;
-                if (hardCapEvictions_ == 1 || hardCapEvictions_ % 100000 == 0)
-                {
-                    JLOG(journal_.warn()) << name_ << ": hard-cap eviction #" << hardCapEvictions_
-                                          << " (cap " << cacheHardCap_ << ", strong " << cacheCount_
-                                          << ") - cache saturated, growth now evicts";
-                }
-            }
-
-            if (!demoted)
-            {
-                JLOG(journal_.debug()) << name_ << ": over hard cap " << cacheHardCap_
-                                       << " but no strong entry other than the newest to demote";
-                return;
-            }
-        }
-    }
-}
-
 template <
     class Key,
     class T,
@@ -518,14 +360,11 @@ TaggedCache<Key, T, IsKeyCache, SharedWeakUnionPointer, SharedPointerType, Hash,
 
     if (cit == cache_.end())
     {
-        auto const emplacedIt = cache_
-                                    .emplace(
-                                        std::piecewise_construct,
-                                        std::forward_as_tuple(key),
-                                        std::forward_as_tuple(clock_.now(), data))
-                                    .first;
-        // The just-inserted entry is the newest; evictForHardCap keeps it.
-        addStrong(emplacedIt);
+        cache_.emplace(
+            std::piecewise_construct,
+            std::forward_as_tuple(key),
+            std::forward_as_tuple(clock_.now(), data));
+        ++cacheCount_;
         return false;
     }
 
@@ -575,12 +414,12 @@ TaggedCache<Key, T, IsKeyCache, SharedWeakUnionPointer, SharedPointerType, Hash,
             data = cachedData;
         }
 
-        addStrong(cit);
+        ++cacheCount_;
         return true;
     }
 
     entry.ptr = data;
-    addStrong(cit);
+    ++cacheCount_;
 
     return false;
 }
@@ -856,13 +695,7 @@ TaggedCache<Key, T, IsKeyCache, SharedWeakUnionPointer, SharedPointerType, Hash,
     ++misses_;
     auto const [it, inserted] = cache_.emplace(digest, Entry(clock_.now(), std::move(sle)));
     if (!inserted)
-    {
         it->second.touch(clock_.now());
-    }
-    else
-    {
-        addStrong(it);
-    }
     return it->second.ptr.getStrong();
 }
 // End CachedSLEs functions.
@@ -895,7 +728,7 @@ TaggedCache<Key, T, IsKeyCache, SharedWeakUnionPointer, SharedPointerType, Hash,
     if (entry.isCached())
     {
         // independent of cache size, so not counted as a hit
-        addStrong(cit);
+        ++cacheCount_;
         entry.touch(clock_.now());
         return entry.ptr.getStrong();
     }
@@ -950,7 +783,7 @@ TaggedCache<Key, T, IsKeyCache, SharedWeakUnionPointer, SharedPointerType, Hash,
         std::atomic<int>& allRemovals,
         std::scoped_lock<std::recursive_mutex> const&)
 {
-    return std::thread([&, this]() {
+    return std::thread([&, this] {
         int cacheRemovals = 0;
         int mapRemovals = 0;
 
@@ -1030,7 +863,7 @@ TaggedCache<Key, T, IsKeyCache, SharedWeakUnionPointer, SharedPointerType, Hash,
         std::atomic<int>& allRemovals,
         std::scoped_lock<std::recursive_mutex> const&)
 {
-    return std::thread([&, this]() {
+    return std::thread([&, this] {
         // NOLINTBEGIN https://github.com/XRPLF/rippled/issues/7056
         int cacheRemovals = 0;
         int mapRemovals = 0;

include/xrpl/basics/partitioned_unordered_map.h

@@ -17,7 +17,7 @@
 namespace xrpl {
 
 template <typename Key>
-static std::size_t
+std::size_t
 extract(Key const& key)
 {
     return key;

include/xrpl/beast/container/detail/aged_ordered_container.h

@@ -1604,7 +1604,7 @@ AgedOrderedContainer<IsMulti, IsMap, Key, T, Clock, Compare, Allocator>::erase(
     beast::detail::AgedContainerIterator<IsConst, Iterator> pos)
     requires(!IsBoostReverseIterator<Iterator>::value)
 {
-    unlinkAndDeleteElement(&*((pos++).iterator()));
+    unlinkAndDeleteElement(&*(pos++).iterator());
     return beast::detail::AgedContainerIterator<false, Iterator>(pos.iterator());
 }
 
@@ -1617,7 +1617,7 @@ AgedOrderedContainer<IsMulti, IsMap, Key, T, Clock, Compare, Allocator>::erase(
     requires(!IsBoostReverseIterator<Iterator>::value)
 {
     for (; first != last;)
-        unlinkAndDeleteElement(&*((first++).iterator()));
+        unlinkAndDeleteElement(&*(first++).iterator());
 
     return beast::detail::AgedContainerIterator<false, Iterator>(first.iterator());
 }

include/xrpl/beast/container/detail/aged_unordered_container.h

@@ -2404,7 +2404,7 @@ beast::detail::AgedContainerIterator<false, Iterator>
 AgedUnorderedContainer<IsMulti, IsMap, Key, T, Clock, Hash, KeyEqual, Allocator>::erase(
     beast::detail::AgedContainerIterator<IsConst, Iterator> pos)
 {
-    unlinkAndDeleteElement(&*((pos++).iterator()));
+    unlinkAndDeleteElement(&*(pos++).iterator());
     return beast::detail::AgedContainerIterator<false, Iterator>(pos.iterator());
 }
 
@@ -2424,7 +2424,7 @@ AgedUnorderedContainer<IsMulti, IsMap, Key, T, Clock, Hash, KeyEqual, Allocator>
     beast::detail::AgedContainerIterator<IsConst, Iterator> last)
 {
     for (; first != last;)
-        unlinkAndDeleteElement(&*((first++).iterator()));
+        unlinkAndDeleteElement(&*(first++).iterator());
 
     return beast::detail::AgedContainerIterator<false, Iterator>(first.iterator());
 }

include/xrpl/beast/hash/hash_append.h

@@ -390,7 +390,7 @@ void
 hash_append(Hasher& h, boost::container::flat_set<Key, Compare, Alloc> const& v) noexcept
     requires(IsContiguouslyHashable<Key, Hasher>::value)
 {
-    h(&(v.begin()), v.size() * sizeof(Key));
+    h(&v.begin(), v.size() * sizeof(Key));
 }
 // tuple
 

include/xrpl/beast/insight/HookImpl.h

@@ -8,7 +8,7 @@ namespace beast::insight {
 class HookImpl : public std::enable_shared_from_this<HookImpl>
 {
 public:
-    using HandlerType = std::function<void(void)>;
+    using HandlerType = std::function<void()>;
 
     virtual ~HookImpl() = 0;
 };

include/xrpl/beast/net/IPAddress.h

@@ -61,7 +61,7 @@ isMulticast(Address const& addr)
 inline bool
 isPrivate(Address const& addr)
 {
-    return (addr.is_v4()) ? isPrivate(addr.to_v4()) : isPrivate(addr.to_v6());
+    return addr.is_v4() ? isPrivate(addr.to_v4()) : isPrivate(addr.to_v6());
 }
 
 /**
@@ -70,7 +70,7 @@ isPrivate(Address const& addr)
 inline bool
 isPublic(Address const& addr)
 {
-    return (addr.is_v4()) ? isPublic(addr.to_v4()) : isPublic(addr.to_v6());
+    return addr.is_v4() ? isPublic(addr.to_v4()) : isPublic(addr.to_v6());
 }
 
 }  // namespace ip

include/xrpl/beast/type_name.h

@@ -34,7 +34,7 @@ typeName()
         name += " volatile";
     if (std::is_lvalue_reference_v<T>)
     {
-        name += "&";
+        name += '&';
     }
     else if (std::is_rvalue_reference_v<T>)
     {

include/xrpl/beast/unit_test/suite.h

@@ -20,7 +20,7 @@ namespace beast::unit_test {
 namespace detail {
 
 template <class String>
-static std::string
+std::string
 makeReason(String const& reason, char const* file, int line)
 {
     std::string s(reason);

include/xrpl/beast/unit_test/thread.h

@@ -47,8 +47,8 @@ public:
     template <class F, class... Args>
     explicit Thread(Suite& s, F&& f, Args&&... args) : s_(&s)
     {
-        std::function<void(void)> b = [f = std::forward<F>(f),
-                                       ... args = std::forward<Args>(args)]() mutable {
+        std::function<void()> b = [f = std::forward<F>(f),
+                                   ... args = std::forward<Args>(args)] mutable {
             std::invoke(f, args...);
         };
         t_ = std::thread(&Thread::run, this, std::move(b));
@@ -94,7 +94,7 @@ public:
 
 private:
     void
-    run(std::function<void(void)> f)
+    run(std::function<void()> f)
     {
         try
         {

include/xrpl/config/Constants.h

@@ -22,14 +22,11 @@ struct Sections
     static constexpr auto kIoWorkers = "io_workers";
     static constexpr auto kIps = "ips";
     static constexpr auto kIpsFixed = "ips_fixed";
-    static constexpr auto kLedgerCacheAge = "ledger_cache_age";
-    static constexpr auto kLedgerFetchSize = "ledger_fetch_size";
     static constexpr auto kLedgerHistory = "ledger_history";
     static constexpr auto kLedgerReplay = "ledger_replay";
     static constexpr auto kLedgerTxTables = "ledger_tx_tables";
     static constexpr auto kMaxSubscriptionsPerConnection = "max_subscriptions_per_connection";
     static constexpr auto kMaxTransactions = "max_transactions";
-    static constexpr auto kMemoryLimit = "memory_limit";
     static constexpr auto kNetworkId = "network_id";
     static constexpr auto kNetworkQuorum = "network_quorum";
     static constexpr auto kNodeDatabase = "node_db";
@@ -67,7 +64,6 @@ struct Sections
     static constexpr auto kSslVerifyFile = "ssl_verify_file";
     static constexpr auto kSweepInterval = "sweep_interval";
     static constexpr auto kTransactionQueue = "transaction_queue";
-    static constexpr auto kTreeCacheAge = "tree_cache_age";
     static constexpr auto kValidationSeed = "validation_seed";
     static constexpr auto kValidatorKeys = "validator_keys";
     static constexpr auto kValidatorKeyRevocation = "validator_key_revocation";

include/xrpl/core/Coro.ipp

@@ -54,7 +54,7 @@ JobQueue::Coro::post()
     }
 
     // sp keeps 'this' alive
-    if (jq_.addJob(type_, name_, [this, sp = shared_from_this()]() { resume(); }))
+    if (jq_.addJob(type_, name_, [this, sp = shared_from_this()] { resume(); }))
     {
         return true;
     }
@@ -130,7 +130,7 @@ inline void
 JobQueue::Coro::join()
 {
     std::unique_lock<std::mutex> lk(mutexRun_);
-    cv_.wait(lk, [this]() { return !running_; });
+    cv_.wait(lk, [this] { return !running_; });
 }
 
 }  // namespace xrpl

include/xrpl/json/json_value.h

@@ -3,11 +3,13 @@
 #include <xrpl/basics/Number.h>
 #include <xrpl/json/json_forwards.h>
 
+#include <concepts>
 #include <cstring>
 #include <iterator>
 #include <limits>
 #include <map>
 #include <string>
+#include <string_view>
 #include <vector>
 
 /**
@@ -198,6 +200,15 @@ public:
      */
     Value(StaticString const& value);
     Value(std::string const& value);
+    /**
+     * @brief Constructs a value from a string view.
+     *
+     * The characters are copied, so the view need not outlive the call and need
+     * not be NUL-terminated.
+     *
+     * @param value The characters to copy.
+     */
+    Value(std::string_view value);
     Value(bool value);
     Value(Value const& other);
     ~Value();
@@ -472,6 +483,32 @@ toJson(xrpl::Number const& number)
 bool
 operator==(Value const&, Value const&);
 
+/**
+ * Compares a value with a string view, reading the value's characters in place
+ * rather than building a Value from the view.
+ *
+ * Constrained to the exact type: a string literal converts equally well to a
+ * view and to a Value, so a plain overload makes `value == "literal"`
+ * ambiguous.
+ *
+ * @param x The value to compare.
+ * @param y The characters to compare it against.
+ * @return Whether `x` is a string whose characters up to its first NUL are
+ *         exactly the characters of `y`.
+ */
+template <class T>
+    requires std::same_as<T, std::string_view>
+bool
+operator==(Value const& x, T y)
+{
+    if (!x.isString())
+        return false;
+
+    // A string `Value` can hold a null pointer, which names no characters, so it equals no view.
+    char const* const s = x.asCString();
+    return s != nullptr && std::string_view{s} == y;
+}
+
 bool
 operator<(Value const&, Value const&);
 

include/xrpl/ledger/entries/AmendmentsEntry.h

@@ -1,11 +1,17 @@
 #pragma once
 
+#include <xrpl/basics/base_uint.h>
+#include <xrpl/basics/chrono.h>
 #include <xrpl/beast/utility/Journal.h>
 #include <xrpl/ledger/ApplyView.h>
 #include <xrpl/ledger/ReadView.h>
 #include <xrpl/ledger/entries/SLEBase.h>
 #include <xrpl/protocol/Indexes.h>
 #include <xrpl/protocol/LedgerFormats.h>
+#include <xrpl/protocol/SField.h>
+
+#include <map>
+#include <set>
 
 namespace xrpl {
 
@@ -25,6 +31,52 @@ public:
         : Base(keylet::amendments(), view, j)
     {
     }
+
+    /**
+     * Returns the set of amendments this entry reports as enabled.
+     *
+     * @return the set of enabled amendments.
+     */
+    [[nodiscard]] std::set<UInt256>
+    enabledAmendments() const
+    {
+        std::set<UInt256> amendments;
+
+        if (this->exists() && (*this)->isFieldPresent(sfAmendments))
+        {
+            auto const& v = (*this)->getFieldV256(sfAmendments);
+            amendments.insert_range(v);
+        }
+
+        return amendments;
+    }
+
+    /**
+     * Returns a map of amendments that have achieved majority, to the time
+     * majority was reached.
+     *
+     * @return a map of amendment to the time majority was reached.
+     */
+    [[nodiscard]] std::map<UInt256, NetClock::time_point>
+    majorityAmendments() const
+    {
+        std::map<UInt256, NetClock::time_point> ret;
+
+        if (this->exists() && (*this)->isFieldPresent(sfMajorities))
+        {
+            using TimePoint = NetClock::time_point;
+            using Duration = TimePoint::duration;
+
+            auto const majorities = (*this)->getFieldArray(sfMajorities);
+
+            for (auto const& m : majorities)
+            {
+                ret[m.getFieldH256(sfAmendment)] = TimePoint(Duration(m.getFieldU32(sfCloseTime)));
+            }
+        }
+
+        return ret;
+    }
 };
 
 using AmendmentsEntryR = AmendmentsEntry<ReadView>;

include/xrpl/ledger/entries/LedgerHashesEntry.h

@@ -1,11 +1,17 @@
 #pragma once
 
+#include <xrpl/basics/base_uint.h>
 #include <xrpl/beast/utility/Journal.h>
 #include <xrpl/ledger/ApplyView.h>
 #include <xrpl/ledger/ReadView.h>
 #include <xrpl/ledger/entries/SLEBase.h>
 #include <xrpl/protocol/Indexes.h>
 #include <xrpl/protocol/LedgerFormats.h>
+#include <xrpl/protocol/SField.h>
+#include <xrpl/protocol/STVector256.h>
+
+#include <cstddef>
+#include <optional>
 
 namespace xrpl {
 
@@ -25,6 +31,31 @@ public:
         : Base(keylet::skip(), view, j)
     {
     }
+
+    /**
+     * Looks up a hash `diff` slots back from the most recent entry in the
+     * sfHashes vector (diff == 0 is the most recent entry).
+     *
+     * Callers decide which skip list entry to read and how to translate a
+     * target ledger sequence into `diff`; this only does the bounds check
+     * and vector indexing shared by both the recent (stride 1) and distant
+     * (stride 256) skip lists.
+     *
+     * @param diff how many slots back from the most recent hash to look up;
+     * 0 is the most recent hash.
+     * @return the hash at that slot, or std::nullopt if the entry does not
+     * exist or `diff` is out of range.
+     */
+    [[nodiscard]] std::optional<UInt256>
+    hashAt(std::size_t diff) const
+    {
+        if (!this->exists())
+            return std::nullopt;
+        STVector256 const vec = (*this)->getFieldV256(sfHashes);
+        if (vec.size() > diff)
+            return vec[vec.size() - diff - 1];
+        return std::nullopt;
+    }
 };
 
 using LedgerHashesEntryR = LedgerHashesEntry<ReadView>;

include/xrpl/ledger/helpers/AMMHelpers.h

@@ -353,7 +353,7 @@ changeSpotPriceQuality(
         }
         if (auto const nTakerPaysPropose = (-b + root2(res)) / (2 * a); nTakerPaysPropose > 0)
         {
-            auto const nTakerPays = [&]() {
+            auto const nTakerPays = [&] {
                 // The fee might make the AMM offer quality less than CLOB
                 // quality. Therefore, AMM offer has to satisfy this constraint:
                 // o / i >= q. Substituting o with swapAssetIn() gives: i <= O /
@@ -372,8 +372,8 @@ changeSpotPriceQuality(
             auto const takerPays =
                 toAmount<TIn>(getAsset(pool.in), nTakerPays, Number::RoundingMode::Upward);
             // should not fail
-            if (auto amounts = TAmounts<TIn, TOut>{takerPays, swapAssetIn(pool, takerPays, tfee)};
-                Quality{amounts} < quality &&
+            auto amounts = TAmounts<TIn, TOut>{takerPays, swapAssetIn(pool, takerPays, tfee)};
+            if (Quality{amounts} < quality &&
                 !withinRelativeDistance(Quality{amounts}, quality, Number(1, -7)))
             {
                 JLOG(j.error()) << "changeSpotPriceQuality failed: " << to_string(pool.in) << " "
@@ -382,21 +382,19 @@ changeSpotPriceQuality(
                                 << " " << to_string(amounts.out);
                 Throw<std::runtime_error>("changeSpotPriceQuality failed");
             }
-            else
-            {
-                JLOG(j.trace()) << "changeSpotPriceQuality succeeded: " << to_string(pool.in) << " "
-                                << to_string(pool.out) << " "
-                                << " " << quality << " " << tfee << " " << to_string(amounts.in)
-                                << " " << to_string(amounts.out);
-                return amounts;
-            }
+
+            JLOG(j.trace()) << "changeSpotPriceQuality succeeded: " << to_string(pool.in) << " "
+                            << to_string(pool.out) << " "
+                            << " " << quality << " " << tfee << " " << to_string(amounts.in) << " "
+                            << to_string(amounts.out);
+            return amounts;
         }
         JLOG(j.trace()) << "changeSpotPriceQuality calc failed: " << to_string(pool.in) << " "
                         << to_string(pool.out) << " " << quality << " " << tfee;
         return std::nullopt;
     }
 
-    auto amounts = [&]() {
+    auto amounts = [&] {
         bool const inIntegral = getAsset(pool.in).integral();
         bool const outIntegral = getAsset(pool.out).integral();
 

include/xrpl/ledger/helpers/EscrowHelpers.h

@@ -2,8 +2,10 @@
 
 #include <xrpl/basics/Log.h>
 #include <xrpl/beast/utility/Journal.h>
+#include <xrpl/beast/utility/Zero.h>
 #include <xrpl/beast/utility/instrumentation.h>
 #include <xrpl/ledger/ApplyView.h>
+#include <xrpl/ledger/ReadView.h>
 #include <xrpl/ledger/helpers/AccountRootHelpers.h>
 #include <xrpl/ledger/helpers/MPTokenHelpers.h>
 #include <xrpl/ledger/helpers/RippleStateHelpers.h>
@@ -27,6 +29,291 @@
 
 namespace xrpl {
 
+/**
+ * Validate that @p account may lock @p amount of a token for later delivery
+ * to @p dest.
+ *
+ * The lock-side counterpart of escrowUnlockPreclaimHelper: every issuer
+ * control (locking opt-in, authorization, freeze/lock, transferability,
+ * spendable balance) that gates locking token value lives here, so any
+ * transactor that locks funds applies the same rules. The signature is
+ * view-based rather than PreclaimContext-based so it can also run from
+ * doApply.
+ */
+template <ValidIssueType T>
+TER
+escrowLockPreclaimHelper(
+    ReadView const& view,
+    AccountID const& account,
+    AccountID const& dest,
+    STAmount const& amount,
+    beast::Journal j);
+
+template <>
+inline TER
+escrowLockPreclaimHelper<Issue>(
+    ReadView const& view,
+    AccountID const& account,
+    AccountID const& dest,
+    STAmount const& amount,
+    beast::Journal j)
+{
+    auto const& issue = amount.get<Issue>();
+    auto const& issuer = amount.getIssuer();
+    // If the issuer is the same as the account, return tecNO_PERMISSION
+    if (issuer == account)
+        return tecNO_PERMISSION;
+
+    // If the lsfAllowTrustLineLocking is not enabled, return tecNO_PERMISSION
+    auto const sleIssuer = view.read(keylet::account(issuer));
+    if (!sleIssuer)
+        return tecNO_ISSUER;
+    if (!sleIssuer->isFlag(lsfAllowTrustLineLocking))
+        return tecNO_PERMISSION;
+
+    // If the account does not have a trustline to the issuer, return tecNO_LINE
+    auto const sleRippleState = view.read(keylet::trustLine(account, issuer, issue.currency));
+    if (!sleRippleState)
+        return tecNO_LINE;
+
+    STAmount const balance = (*sleRippleState)[sfBalance];
+
+    // If balance is positive, issuer must have higher address than account
+    if (balance > beast::kZero && issuer < account)
+        return tecNO_PERMISSION;  // LCOV_EXCL_LINE
+
+    // If balance is negative, issuer must have lower address than account
+    if (balance < beast::kZero && issuer > account)
+        return tecNO_PERMISSION;  // LCOV_EXCL_LINE
+
+    // If the issuer has requireAuth set, check if the account is authorized
+    if (auto const ter = requireAuth(view, issue, account); !isTesSuccess(ter))
+        return ter;
+
+    // If the issuer has requireAuth set, check if the destination is authorized
+    if (auto const ter = requireAuth(view, issue, dest); !isTesSuccess(ter))
+        return ter;
+
+    // If the issuer has frozen the account, return tecFROZEN
+    if (isFrozen(view, account, issue))
+        return tecFROZEN;
+
+    // If the issuer has frozen the destination, return tecFROZEN
+    if (isFrozen(view, dest, issue))
+        return tecFROZEN;
+
+    STAmount const spendableAmount =
+        accountHolds(view, account, issue.currency, issuer, FreezeHandling::IgnoreFreeze, j);
+
+    // If the balance is less than or equal to 0, return tecINSUFFICIENT_FUNDS
+    if (spendableAmount <= beast::kZero)
+        return tecINSUFFICIENT_FUNDS;
+
+    // If the spendable amount is less than the amount, return
+    // tecINSUFFICIENT_FUNDS
+    if (spendableAmount < amount)
+        return tecINSUFFICIENT_FUNDS;
+
+    // If the amount is not addable to the balance, return tecPRECISION_LOSS
+    if (!canAdd(spendableAmount, amount))
+        return tecPRECISION_LOSS;
+
+    return tesSUCCESS;
+}
+
+template <>
+inline TER
+escrowLockPreclaimHelper<MPTIssue>(
+    ReadView const& view,
+    AccountID const& account,
+    AccountID const& dest,
+    STAmount const& amount,
+    beast::Journal j)
+{
+    AccountID const issuer = amount.getIssuer();
+    // If the issuer is the same as the account, return tecNO_PERMISSION
+    if (issuer == account)
+        return tecNO_PERMISSION;
+
+    // If the mpt does not exist, return tecOBJECT_NOT_FOUND
+    auto const issuanceKey = keylet::mptokenIssuance(amount.get<MPTIssue>().getMptID());
+    auto const sleIssuance = view.read(issuanceKey);
+    if (!sleIssuance)
+        return tecOBJECT_NOT_FOUND;
+
+    // If the lsfMPTCanEscrow is not enabled, return tecNO_PERMISSION
+    if (!sleIssuance->isFlag(lsfMPTCanEscrow))
+        return tecNO_PERMISSION;
+
+    // If the issuer is not the same as the issuer of the mpt, return
+    // tecNO_PERMISSION
+    if (sleIssuance->getAccountID(sfIssuer) != issuer)
+        return tecNO_PERMISSION;  // LCOV_EXCL_LINE
+
+    // If the account does not have the mpt, return tecOBJECT_NOT_FOUND
+    if (!view.exists(keylet::mptoken(issuanceKey.key, account)))
+        return tecOBJECT_NOT_FOUND;
+
+    // If the issuer has requireAuth set, check if the account is
+    // authorized
+    auto const& mptIssue = amount.get<MPTIssue>();
+    if (auto const ter = requireAuth(view, mptIssue, account, AuthType::WeakAuth);
+        !isTesSuccess(ter))
+        return ter;
+
+    // If the issuer has requireAuth set, check if the destination is
+    // authorized
+    if (auto const ter = requireAuth(view, mptIssue, dest, AuthType::WeakAuth); !isTesSuccess(ter))
+        return ter;
+
+    // If the issuer has frozen the account, return tecLOCKED
+    if (isFrozen(view, account, *sleIssuance))
+        return tecLOCKED;
+
+    // If the issuer has frozen the destination, return tecLOCKED
+    if (isFrozen(view, dest, *sleIssuance))
+        return tecLOCKED;
+
+    // If the mpt cannot be transferred, return tecNO_AUTH
+    if (auto const ter = canTransfer(view, mptIssue, account, dest); !isTesSuccess(ter))
+        return ter;
+
+    STAmount const spendableAmount = accountHolds(
+        view,
+        account,
+        amount.get<MPTIssue>(),
+        FreezeHandling::IgnoreFreeze,
+        AuthHandling::IgnoreAuth,
+        j);
+
+    // If the balance is less than or equal to 0, return tecINSUFFICIENT_FUNDS
+    if (spendableAmount <= beast::kZero)
+        return tecINSUFFICIENT_FUNDS;
+
+    // If the spendable amount is less than the amount, return
+    // tecINSUFFICIENT_FUNDS
+    if (spendableAmount < amount)
+        return tecINSUFFICIENT_FUNDS;
+
+    return tesSUCCESS;
+}
+
+template <ValidIssueType T>
+TER
+escrowLockApplyHelper(
+    ApplyView& view,
+    AccountID const& issuer,
+    AccountID const& sender,
+    STAmount const& amount,
+    beast::Journal journal);
+
+template <>
+inline TER
+escrowLockApplyHelper<Issue>(
+    ApplyView& view,
+    AccountID const& issuer,
+    AccountID const& sender,
+    STAmount const& amount,
+    beast::Journal journal)
+{
+    // Defensive: Issuer cannot create an escrow
+    if (issuer == sender)
+        return tecINTERNAL;  // LCOV_EXCL_LINE
+
+    auto const ter =
+        directSendNoFee(view, sender, issuer, amount, !amount.holds<MPTIssue>(), journal);
+    if (!isTesSuccess(ter))
+        return ter;  // LCOV_EXCL_LINE
+    return tesSUCCESS;
+}
+
+template <>
+inline TER
+escrowLockApplyHelper<MPTIssue>(
+    ApplyView& view,
+    AccountID const& issuer,
+    AccountID const& sender,
+    STAmount const& amount,
+    beast::Journal journal)
+{
+    // Defensive: Issuer cannot create an escrow
+    if (issuer == sender)
+        return tecINTERNAL;  // LCOV_EXCL_LINE
+
+    auto const ter = lockEscrowMPT(view, sender, amount, journal);
+    if (!isTesSuccess(ter))
+        return ter;  // LCOV_EXCL_LINE
+    return tesSUCCESS;
+}
+
+template <ValidIssueType T>
+TER
+escrowUnlockPreclaimHelper(
+    ReadView const& view,
+    AccountID const& account,
+    STAmount const& amount,
+    bool checkFreeze = true);
+
+template <>
+inline TER
+escrowUnlockPreclaimHelper<Issue>(
+    ReadView const& view,
+    AccountID const& account,
+    STAmount const& amount,
+    bool checkFreeze)
+{
+    AccountID const& issuer = amount.getIssuer();
+    // If the issuer is the same as the account, return tesSUCCESS
+    if (issuer == account)
+        return tesSUCCESS;
+
+    // If the issuer has requireAuth set, check if the destination is authorized
+    if (auto const ter = requireAuth(view, amount.get<Issue>(), account); !isTesSuccess(ter))
+        return ter;
+
+    // If the issuer has deep frozen the destination, return tecFROZEN
+    if (checkFreeze &&
+        isDeepFrozen(view, account, amount.get<Issue>().currency, amount.getIssuer()))
+        return tecFROZEN;
+
+    return tesSUCCESS;
+}
+
+template <>
+inline TER
+escrowUnlockPreclaimHelper<MPTIssue>(
+    ReadView const& view,
+    AccountID const& account,
+    STAmount const& amount,
+    bool checkFreeze)
+{
+    AccountID const& issuer = amount.getIssuer();
+    // If the issuer is the same as the account, return tesSUCCESS
+    if (issuer == account)
+        return tesSUCCESS;
+
+    // If the mpt does not exist, return tecOBJECT_NOT_FOUND
+    auto const issuanceKey = keylet::mptokenIssuance(amount.get<MPTIssue>().getMptID());
+    auto const sleIssuance = view.read(issuanceKey);
+    if (!sleIssuance)
+        return tecOBJECT_NOT_FOUND;
+
+    // If the issuer has requireAuth set, check if the account is
+    // authorized
+    auto const& mptIssue = amount.get<MPTIssue>();
+    if (auto const ter = requireAuth(view, mptIssue, account, AuthType::WeakAuth);
+        !isTesSuccess(ter))
+        return ter;
+
+    // If the issuer has frozen the account, return tecLOCKED
+    if (checkFreeze && isFrozen(view, account, *sleIssuance))
+        return tecLOCKED;
+
+    return tesSUCCESS;
+}
+
+//------------------------------------------------------------------------------
+
 template <ValidIssueType T>
 TER
 escrowUnlockApplyHelper(
@@ -55,9 +342,6 @@ escrowUnlockApplyHelper<Issue>(
     bool createAsset,
     beast::Journal journal)
 {
-    auto const& issue = amount.get<Issue>();
-    Keylet const trustLineKey = keylet::trustLine(receiver, issue);
-    bool const recvLow = issuer > receiver;
     bool const senderIssuer = issuer == sender;
     bool const receiverIssuer = issuer == receiver;
 
@@ -67,6 +351,10 @@ escrowUnlockApplyHelper<Issue>(
     if (receiverIssuer)
         return tesSUCCESS;
 
+    auto const& issue = amount.get<Issue>();
+    Keylet const trustLineKey = keylet::trustLine(receiver, issue);
+    bool const recvLow = issuer > receiver;
+
     if (!ctx.view.exists(trustLineKey) && createAsset)
     {
         // Can the account cover the trust line's reserve?

include/xrpl/net/AutoSocket.h

@@ -103,7 +103,7 @@ public:
     void
     asyncHandshake(HandshakeType type, Callback cbFunc)
     {
-        if ((type == SslSocket::client) || (secure_))
+        if ((type == SslSocket::client) || secure_)
         {
             // must be ssl
             secure_ = true;

include/xrpl/nodestore/detail/EncodedBlob.h

@@ -67,7 +67,7 @@ class EncodedBlob
 
 public:
     explicit EncodedBlob(std::shared_ptr<NodeObject> const& obj)
-        : size_([&obj]() {
+        : size_([&obj] {
             XRPL_ASSERT(obj, "xrpl::node_store::EncodedBlob::EncodedBlob : non-null input");
 
             if (!obj)

include/xrpl/protocol/ApiVersion.h

@@ -6,31 +6,25 @@
 #include <xrpl/protocol/jss.h>
 
 #include <cstddef>
+#include <string_view>
 #include <type_traits>
 #include <utility>
 
 namespace xrpl {
 
 /**
- * API version numbers used in later API versions
+ * The `api_version` numbers this server serves.
  *
- * Requests with a version number in the range
- * [apiMinimumSupportedVersion, apiMaximumSupportedVersion]
- * are supported.
+ * A request naming a version in [kApiMinimumSupportedVersion,
+ * kApiMaximumSupportedVersion] is served. With `[beta_rpc_api]` set to `1` in
+ * the config the range extends to kApiBetaVersion.
  *
- * If [beta_rpc_api] is enabled in config, the version numbers
- * in the range [apiMinimumSupportedVersion, apiBetaVersion]
- * are supported.
- *
- * Network Requests without explicit version numbers use
- * apiVersionIfUnspecified. apiVersionIfUnspecified is 1,
- * because all the RPC requests with a version >= 2 must
- * explicitly specify the version in the requests.
- * Note that apiVersionIfUnspecified will be lower than
- * apiMinimumSupportedVersion when we stop supporting API
- * version 1.
- *
- * Command line Requests use apiCommandLineVersion.
+ * A request naming no version is served at kApiVersionIfUnspecified, which is 1
+ * because a request wanting any later version states it. A WebSocket message is
+ * one flat object and names it at its top level at every version. A JSON-RPC
+ * request names it in its parameters, or at its own top level: an entry of a
+ * `"method": "batch"` body at every version, a lone request from
+ * kApiMinimumSpecVersion up.
  */
 
 namespace rpc {
@@ -46,6 +40,31 @@ static constexpr auto kApiCommandLineVersion = kApiVersion<1>;  // TODO Bump to
 static constexpr auto kApiBetaVersion = kApiVersion<3>;
 static constexpr auto kApiMaximumValidVersion = kApiBetaVersion;
 
+/**
+ * First API version that follows the JSON-RPC 2.0 specification.
+ *
+ * From this version up a lone JSON-RPC request may state its `api_version` at
+ * its own top level, beside the members the specification defines there, as a
+ * WebSocket message always has. The member is an XRPL extension: the
+ * specification defines no version member.
+ *
+ * Distinct from kApiBetaVersion, the same number today, which says instead that
+ * the version needs [beta_rpc_api] to be reachable.
+ */
+static constexpr auto kApiMinimumSpecVersion = kApiVersion<3>;
+
+/**
+ * Whether @p apiVersion follows the JSON-RPC 2.0 specification.
+ *
+ * @param apiVersion The version a request asked for.
+ * @return Whether that version follows the specification.
+ */
+[[nodiscard]] constexpr bool
+isSpecVersion(unsigned apiVersion)
+{
+    return apiVersion >= kApiMinimumSpecVersion;
+}
+
 static_assert(kApiInvalidVersion < kApiMinimumSupportedVersion);
 static_assert(
     kApiVersionIfUnspecified >= kApiMinimumSupportedVersion &&
@@ -57,6 +76,16 @@ static_assert(kApiMaximumSupportedVersion >= kApiMinimumSupportedVersion);
 static_assert(kApiBetaVersion >= kApiMaximumSupportedVersion);
 static_assert(kApiMaximumValidVersion >= kApiMaximumSupportedVersion);
 
+/**
+ * Values accepted in the `ripplerpc` request field, which selects the shape of
+ * the JSON-RPC reply envelope. Distinct from `kJsonRpcVersion` in JsonRpc.h,
+ * which names the JSON-RPC protocol itself, and from the `api_version`
+ * constants above, which select the content of the response.
+ */
+inline constexpr std::string_view kRippleRpcVersion1{"1.0"};
+inline constexpr std::string_view kRippleRpcVersion2{"2.0"};
+inline constexpr std::string_view kRippleRpcVersion3{"3.0"};
+
 inline void
 setVersion(json::Value& parent, unsigned int apiVersion, bool betaEnabled)
 {

include/xrpl/protocol/Book.h

@@ -55,7 +55,7 @@ hash_append(Hasher& h, Book const& b)
     using beast::hash_append;
     hash_append(h, b.in, b.out);
     if (b.domain)
-        hash_append(h, *(b.domain));
+        hash_append(h, *b.domain);
 }
 
 Book

include/xrpl/protocol/ErrorCodes.h

@@ -3,6 +3,7 @@
 #include <xrpl/json/json_value.h>
 
 #include <string>
+#include <string_view>
 
 namespace xrpl {
 
@@ -144,7 +145,58 @@ enum ErrorCodeI {
     RpcEntryNotFound = 98,
     RpcUnexpectedLedgerType = 99,
 
-    RpcLast = RpcUnexpectedLedgerType  // rpcLAST should always equal the last code.
+    // submit + simulate
+    RpcInvalidTransaction = 100,
+    RpcInternalSubmit = 101,
+    RpcInternalJson = 102,
+    RpcInternalSimulate = 103,
+
+    // transaction_entry
+    RpcFieldNotFoundTransaction = 104,
+    RpcNotYetImplemented = 105,
+    RpcTransactionNotFound = 106,
+
+    // transaction_entry + ledger_entry
+    RpcMalformedRequest = 107,
+
+    // ledger_accept
+    RpcNotStandAlone = 108,
+
+    // ledger_entry, API version 1 only
+    RpcUnknownOption = 109,
+
+    // ledger_entry field validation, one code per malformed field. The ledger_entry helpers report
+    // invalidParams (31) for all of them, so each token needs a row of its own. Alphabetical by
+    // token here only: the enum is append-only once a code ships.
+    //
+    // `malformedIssue` duplicates `issueMalformed` (93): same message, same status, two tokens,
+    // both on the wire already. Do not add a third spelling.
+    RpcMalformedAccount = 110,
+    RpcMalformedAddress = 111,
+    RpcMalformedAuthorized = 112,
+    RpcMalformedAuthorizedCredentials = 113,
+    RpcMalformedBridgeAccount = 114,
+    RpcMalformedBroker = 115,
+    RpcMalformedCurrency = 116,
+    RpcMalformedDirRoot = 117,
+    RpcMalformedDocumentID = 118,
+    RpcMalformedIssue = 119,
+    RpcMalformedIssuingChainDoor = 120,
+    RpcMalformedLockingChainDoor = 121,
+    RpcMalformedMPTIssuanceID = 122,
+    RpcMalformedMPTokenIssuance = 123,
+    RpcMalformedOwner = 124,
+    RpcMalformedSeq = 125,
+    RpcMalformedSponsee = 126,
+    RpcMalformedSponsor = 127,
+    RpcMalformedXChainOwnedClaimID = 128,
+    RpcMalformedXChainOwnedCreateAccountClaimID = 129,
+
+    // subscribe
+    RpcApiVersionConflict = 130,
+
+    // RpcLast should always equal the last code.
+    RpcLast = RpcApiVersionConflict
 };
 
 /**
@@ -180,11 +232,6 @@ struct ErrorInfo
     {
     }
 
-    constexpr ErrorInfo(ErrorCodeI code, char const* token, char const* message)
-        : code(code), token(token), message(message), httpStatus(200)
-    {
-    }
-
     constexpr ErrorInfo(ErrorCodeI code, char const* token, char const* message, int httpStatus)
         : code(code), token(token), message(message), httpStatus(httpStatus)
     {
@@ -202,6 +249,18 @@ struct ErrorInfo
 ErrorInfo const&
 getErrorInfo(ErrorCodeI code);
 
+/**
+ * Returns the error code that owns @p token.
+ *
+ * A linear scan over views measured at compile time, run once per error reply.
+ * A duplicate token is a build error, so the answer is never ambiguous.
+ *
+ * @param token The error token to resolve.
+ * @return The code the table gives @p token, or RpcUnknown if no row names it.
+ */
+ErrorCodeI
+codeForToken(std::string_view token);
+
 /**
  * Add or update the json update to reflect the error code.
  */

include/xrpl/protocol/JsonRpc.h

@@ -0,0 +1,45 @@
+#pragma once
+
+#include <xrpl/json/json_forwards.h>
+
+#include <string_view>
+
+namespace xrpl::rpc {
+
+/**
+ * Constants of the JSON-RPC 2.0 protocol itself.
+ *
+ * Kept apart from the `api_version` and `ripplerpc` constants in ApiVersion.h,
+ * which go when support for API versions 1 and 2 goes.
+ */
+
+/**
+ * Value of the `jsonrpc` member of a request and of its reply, fixed at "2.0"
+ * by the JSON-RPC specification.
+ */
+inline constexpr std::string_view kJsonRpcVersion{"2.0"};
+
+/**
+ * Codes for the `code` member of a JSON-RPC error object.
+ *
+ * The specification reserves -32768 to -32000 for the protocol and leaves
+ * -32000 to -32099 of it to the implementation.
+ *
+ * kJsonRpcServerError is the code for an error an XRPL handler reports. The
+ * XRPL token and code travel in the error's `data` member, so renumbering an
+ * XRPL error cannot change a JSON-RPC code.
+ *
+ * The codes from kJsonRpcServerOverloaded on lie outside the
+ * implementation-defined sub-range, which the specification does not allow.
+ * They are the codes every shipped version reports, so moving one breaks the
+ * clients matching on it.
+ */
+inline constexpr json::Int kJsonRpcServerError{-32000};
+inline constexpr json::Int kJsonRpcInvalidRequest{-32600};
+inline constexpr json::Int kJsonRpcMethodNotFound{-32601};
+inline constexpr json::Int kJsonRpcInvalidParams{-32602};
+inline constexpr json::Int kJsonRpcServerOverloaded{-32604};
+inline constexpr json::Int kJsonRpcForbidden{-32605};
+inline constexpr json::Int kJsonRpcWrongVersion{-32606};
+
+}  // namespace xrpl::rpc

include/xrpl/protocol/LedgerFormats.h

@@ -208,7 +208,10 @@ enum LedgerEntryType : std::uint16_t {
                                                                                                                                    \
     LEDGER_OBJECT(Sponsorship,                                                                                                     \
         LSF_FLAG(lsfSponsorshipRequireSignForFee, 0x00010000)                                                                      \
-        LSF_FLAG(lsfSponsorshipRequireSignForReserve, 0x00020000))
+        LSF_FLAG(lsfSponsorshipRequireSignForReserve, 0x00020000))                                                                 \
+                                                                                                                                   \
+    LEDGER_OBJECT(LoanBroker,                                                                                                      \
+        LSF_FLAG(lsfLoanBrokerPrivate, 0x00010000))
 
 // clang-format on
 

include/xrpl/protocol/LedgerShortcut.h

@@ -1,28 +0,0 @@
-#pragma once
-
-namespace xrpl {
-
-/**
- * @brief Enumeration of ledger shortcuts for specifying which ledger to use.
- *
- * These shortcuts provide a convenient way to reference commonly used ledgers
- * without needing to specify their exact hash or sequence number.
- */
-enum class LedgerShortcut {
-    /**
-     * The current working ledger (open, not yet closed)
-     */
-    Current,
-
-    /**
-     * The most recently closed ledger (may not be validated)
-     */
-    Closed,
-
-    /**
-     * The most recently validated ledger
-     */
-    Validated
-};
-
-}  // namespace xrpl

include/xrpl/protocol/STObject.h

@@ -457,9 +457,7 @@ private:
     // The remove_cv and remove_reference are necessitated by the STBitString
     // types.  Their value() returns by const ref.  We return those types
     // by value.
-    template <
-        typename T,
-        typename V = std::remove_cv_t<std::remove_reference_t<decltype(std::declval<T>().value())>>>
+    template <typename T, typename V = std::remove_cvref_t<decltype(std::declval<T>().value())>>
     V
     getFieldByValue(SField const& field) const;
 

include/xrpl/protocol/STValidation.h

@@ -188,7 +188,7 @@ private:
 template <class LookupNodeID>
 STValidation::STValidation(SerialIter& sit, LookupNodeID&& lookupNodeID, DeserializeOptions options)
     : STObject(validationFormat(), sit, sfValidation, options.requireCanonicalOrder)
-    , signingPubKey_([this]() {
+    , signingPubKey_([this] {
         auto const spk = getFieldVL(sfSigningPubKey);
 
         if (publicKeyType(makeSlice(spk)) != KeyType::Secp256k1)

include/xrpl/protocol/Serializer.h

@@ -252,7 +252,7 @@ public:
     {
         auto success = (offset + (Bits / 8)) <= data_.size();
         if (success)
-            memcpy(data.begin(), &(data_.front()) + offset, (Bits / 8));
+            memcpy(data.begin(), &data_.front() + offset, (Bits / 8));
         return success;
     }
 

include/xrpl/protocol/TER.h

@@ -449,7 +449,7 @@ public:
     // Trait tells the requires-clause which types are allowed for construction.
     template <typename T>
     constexpr TERSubset(T rhs)
-        requires(Trait<std::remove_cv_t<std::remove_reference_t<T>>>::value)
+        requires(Trait<std::remove_cvref_t<T>>::value)
         : code_(TERtoInt(rhs))
     {
     }

include/xrpl/protocol/TxFlags.h

@@ -226,6 +226,10 @@ inline constexpr FlagValue tfUniversalMask = ~tfUniversal;
         TF_FLAG(tfLoanUnimpair, 0x00040000),                                                                                                                   \
         MASK_ADJ(0))                                                                                                                                           \
                                                                                                                                                                \
+    TRANSACTION(LoanBrokerSet,                                                                                                                                 \
+        TF_FLAG(tfLoanBrokerPrivate, 0x00010000),                                                                                                              \
+        MASK_ADJ(0))                                                                                                                                           \
+                                                                                                                                                               \
     TRANSACTION(SponsorshipSet,                                                                                                                                \
         TF_FLAG(tfSponsorshipSetRequireSignForFee, 0x00010000)                                                                                                 \
         TF_FLAG(tfSponsorshipClearRequireSignForFee, 0x00020000)                                                                                               \
@@ -238,6 +242,12 @@ inline constexpr FlagValue tfUniversalMask = ~tfUniversal;
         TF_FLAG(tfSponsorshipEnd, 0x00010000)                                                                                                                  \
         TF_FLAG(tfSponsorshipCreate, 0x00020000)                                                                                                               \
         TF_FLAG(tfSponsorshipReassign, 0x00040000),                                                                                                            \
+        MASK_ADJ(0))                                                                                                                                          \
+                                                                                                                                                               \
+    TRANSACTION(ConfidentialMPTHolderKeyUpdate,                                                                                                                \
+        TF_FLAG(tfHolderKeyRotation, 0x00010000)                                                                                                               \
+        TF_FLAG(tfHolderKeyRecovery, 0x00020000)                                                                                                               \
+        TF_FLAG(tfCancelRecovery, 0x00040000),                                                                                                                 \
         MASK_ADJ(0))
 
 // clang-format on

include/xrpl/protocol/TxMeta.h

@@ -12,10 +12,12 @@
 #include <xrpl/protocol/STObject.h>
 #include <xrpl/protocol/Serializer.h>
 #include <xrpl/protocol/TER.h>
+#include <xrpl/protocol/UintTypes.h>
 
 #include <boost/container/flat_set.hpp>
 
 #include <cstdint>
+#include <flat_set>
 #include <optional>
 
 namespace xrpl {
@@ -115,6 +117,9 @@ public:
         parentBatchID_ = id;
     }
 
+    [[nodiscard]] std::flat_set<MPTID>
+    getAffectedMPTs() const;
+
 private:
     UInt256 transactionID_;
     std::uint32_t ledgerSeq_;

include/xrpl/protocol/detail/features.macro

@@ -20,6 +20,7 @@ XRPL_FEATURE(SmartEscrow,                 Supported::No,  VoteBehavior::DefaultN
 XRPL_FEATURE(LendingProtocolV1_2,         Supported::No,  VoteBehavior::DefaultNo)
 XRPL_FIX    (Cleanup3_5_0,                Supported::Yes, VoteBehavior::DefaultNo)
 XRPL_FEATURE(ConfidentialMPTKeyRotation,  Supported::No,  VoteBehavior::DefaultNo)
+XRPL_FIX    (BatchV1_2,                   Supported::Yes, VoteBehavior::DefaultYes)
 XRPL_FIX    (Cleanup3_4_0,                Supported::Yes, VoteBehavior::DefaultNo)
 XRPL_FEATURE(Sponsor,                     Supported::Yes, VoteBehavior::DefaultNo)
 XRPL_FEATURE(BatchV1_1,                   Supported::Yes, VoteBehavior::DefaultNo)