XRPLF PR #8095 Would Add Peak Object Counts to `get_counts`

Direct answer: peak counts are proposed, not released

[Confirmed] XRPLF opened PR #8095 on August 24, 2026 UTC to replace xrpld's CountedObject registry plumbing and expose current and maximum per-type counts through get_counts. The pull request targets the develop branch and remains open, so it is proposed code, not a released xrpld change. Operators should treat the new response shape as unsettled until release. [1][2]

The timing matters. GitHub records the first PR commit at 01:58 UTC on August 24, the second at 02:37 UTC, and the pull request as open after those commits. In Central Time, those events fell on the evening of August 23. The record is therefore genuinely newer than the prior SHAMap acquisition report, but it is still a code-review event rather than a network event. [1][3]

[Confirmed] The material change is observability. XRPLF says the proposal replaces a lazy singleton with a constinit registry of per-type static counters, fixes a concurrency bug during counter insertion, tracks current and maximum counts, and changes the get_counts JSON shape. [1] [Bounded inference] That makes the proposal relevant to node operators and monitoring authors who use object counts as an early warning signal, but it does not establish a performance gain, a memory leak, a validator incident, or any XRP market effect. [1][4]

Section sources[1][4][2][5]

What CountedObject measures inside an xrpld server

[Confirmed] CountedObject is an internal C++ base that increments a per-type counter when a counted object is constructed and decrements it when the object is destroyed. The PR changes those counters from signed integers to 32-bit unsigned atomics, adds a maximum value, and registers each counter in a global intrusive list that can be iterated by the RPC handler. These are implementation details in the proposed branch, not fields that a public XRP transaction can set. [1]

The existing get_counts method is an administrator-only health endpoint. XRPL documentation describes it as returning statistics about what the server currently holds in memory, including object counts and other health fields, and accepts min_count as an unsigned threshold. The documentation's sample is an illustration of response format, not a live Mainnet measurement. [2]

[Independent technical context] C++ atomic operations make concurrent reads and writes to an atomic object well-defined, but the selected memory order determines what else is ordered around them. cppreference describes relaxed operations as guaranteeing atomicity without synchronizing unrelated memory accesses. That distinction is useful here: the PR's atomic counters can make increments and decrements safe to observe, but the source does not by itself prove that every snapshot across all server subsystems is simultaneous or globally consistent. [6]

Section sources[1][4][7]

The get_counts response would become a compatibility boundary

[Confirmed] Today, the published get_counts example places names such as Transaction, Ledger, and NodeObject directly inside result alongside status, uptime, database statistics, and cache metrics. PR #8095 moves counted-object entries under a counters object. Each returned type becomes an object with current and maximum values, while the PR leaves the other health fields at the response's top level. [1][2]

That is a schema change, not a cosmetic rename. A monitoring script that currently reads result.Transaction would need to look under result.counters and then select either current or maximum. A parser that assumes every result member is numeric could also fail when it meets the counters object. The min_count filter remains part of the request, but the filtering target becomes the current counter value. [1][2]

The proposed difference is easier to see as a contract comparison:

[Bounded inference] The new structure is more expressive because it can distinguish a live count from a retained high-water count. It is also more demanding for integrators because a field that was previously a number becomes a nested object. The current documentation has not yet been updated to show this proposal, and the PR's open status means the exact released names, ordering, and compatibility policy could still change. [1][2]

Section sources[1][4]

What a maximum count can tell an operator, and what it cannot

[Confirmed] In the proposed code, increment raises the current count and updates maxCount when the new value is higher. The RPC response reports maximum as the greater of the stored maximum and the current value. Decrement lowers current and triggers an assertion if the counter would underflow. The result is a high-water signal for each counted type over the life of the running process. [1]

[Bounded inference] A high-water value could help an operator distinguish a normal burst from a population that never returns toward its previous baseline. It could support a troubleshooting timeline alongside uptime, ledger sync, database, and cache metrics. That is a diagnostic use, not proof of a leak. A maximum can rise because traffic, history queries, synchronization, or a legitimate workload temporarily created more objects. [1][2][4]

The ceiling is just as important as the signal. The proposed maximum is a count of instrumented C++ objects, not bytes of resident memory. It does not measure disk usage, CPU utilization, network bandwidth, peer count, validator count, transaction throughput, or XRP held by a server. XRPL's capacity guidance says memory requirements also depend on node size and client traffic, while get_counts is one source of additional health information. [4]

[Unresolved] The PR does not say whether maximum counts will be persisted across restart, exported through a new public schema, or used by official alert thresholds. Because the counter is held in process memory and the proposal does not describe persistence, readers should not assume it is an archival metric. A future release note or documentation update must answer that operational question. [1][2]

Section sources[1][4][5]

The registry rewrite addresses initialization and concurrency risks

[Confirmed] The proposal removes CountedObjects::getInstance and replaces the lazy singleton with an inline constinit registry whose counters form an intrusive lock-free list. The PR says the old insertion path had a concurrency bug that could corrupt the list of counters. It also makes counters non-copyable and non-movable because their addresses are published in that list. [1]

[Independent technical context] cppreference explains that constant initialization is guaranteed to finish before other static or thread-local dynamic initialization begins. That helps explain the design goal behind constinit: the registry object is available without relying on a function-local singleton being created at first use. It does not mean every per-type counter or every counted object is safe to construct during global initialization. [5]

The code comments preserve that caveat. The proposed CountedObject template warns that objects created during dynamic initialization in other translation units can have increments discarded when their counter is dynamically initialized, and advises against creating counted objects before main begins. This is an important boundary for reviewers: the PR narrows one registry race while documenting a separate initialization rule that callers still need to respect. [1]

[Unresolved] No independent benchmark in the reviewed record quantifies the old corruption risk, the new registry's overhead, or the effect of relaxed counter updates on a production node. The proposal includes tests and assertions, but open code review is not the same as a completed release qualification. Those measurements remain a watch item, not an established outcome. [1][5][6]

Section sources[1][6][7]

Boost demangling and CRTP checks tighten the developer-facing edge

[Confirmed] A second commit removes xrpld's Beast type-name helper and routes type-name rendering through boost::core::demangle. The PR says that removes a low-level dependency and manual memory management. It also acknowledges one compatibility distinction: Boost's helper does not reconstruct top-level const, volatile, or reference qualifiers, although the author says existing callers did not pass those decorated types. [1][3]

[Independent technical context] Boost documents demangle as a conventional way to turn implementation-specific typeid names into human-readable names, while cppreference warns that type_info::name itself is implementation-defined and can return mangled names on GCC and Clang. The replacement therefore standardizes the project utility around a maintained external facility, but it does not turn C++ type names into a cross-platform protocol identifier. [7][8]

The CountedObject template also gains a CRTP constraint requiring the template parameter to be a class, and a friend relationship that rejects the copy-paste error of deriving one class from another class's counter. A static assertion checks that CountedObject remains an empty base class. Those changes protect compile-time accounting assumptions; they do not add a new ledger transaction, amendment, RPC permission, or consensus rule. [1]

For application developers, the practical lesson is to separate internal diagnostics from stable API contracts. A release that carries this work could improve names and debugging signals, but libraries should not depend on the current PR's class names, counter ordering, or JSON shape until XRPLF publishes a merged implementation and updated reference documentation. [1][2][7]

Section sources[1][3][8][9]

Implications for node operators, monitoring tools, and XRP readers

For node operators, the immediate action is review rather than upgrade. PR #8095 is open against develop, has no listed reviews on the public page, and is not a release tag. Operators should wait for a merged commit, a tagged xrpld release, and explicit upgrade guidance before changing a production node or treating a maximum counter as an established operational metric. [1]

For monitoring authors, the likely work is a compatibility layer. A robust parser can accept the current flat fields and the proposed counters object, record whether a maximum is available, and avoid treating an object-valued counters field as a numeric health value. It should record server version, uptime, threshold, and collection time beside any current or maximum count so a restart is not mistaken for a drop in workload. [1][2][4]

For indexers, explorers, and infrastructure vendors, the proposal is relevant only to admin telemetry, not ledger data. It does not change transaction serialization, validated ledger contents, amendment voting, account balances, or the XRP Ledger's consensus process. [Confirmed] No source reviewed reports a Mainnet rollout, validator instruction, user-facing deployment, XRP transaction effect, XRP demand change, or price response tied to PR #8095. [1][2]

For XRP holders and market readers, the defensible conclusion is therefore limited. Better object accounting could eventually help maintainers diagnose server behavior, but that is a possible reliability benefit, not present adoption or a market catalyst. [Unresolved] The release status, final response schema, compatibility window, and any measured production impact remain unknown. [1][4]

Section sources[1][4][5]

What to watch before calling the new telemetry live

[Confirmed] The first milestone is review and merge. Watch PR #8095 for reviewer comments, changed commits, and a move from an open request into XRPLF's develop history. A merge would establish that the code entered a development branch; it would not by itself establish a stable release or Mainnet deployment. [1]

The second milestone is documentation and release treatment. The get_counts reference should show the nested counters object, current and maximum fields, threshold behavior, and any compatibility note. A tagged xrpld release should identify whether the response change is breaking, whether old field names remain temporarily, and whether operators must update parsers. [1][2]

The third milestone is evidence from tests and running nodes. Look for concurrency tests, underflow and overflow assertions, initialization coverage, API response fixtures, and an observed maximum that behaves predictably across object creation, destruction, and restart. A benchmark comparing the old and new registry is useful, but it should not be confused with a claim about ledger throughput or XRP demand. [1][5][6]

[Unresolved] As of the source snapshot reviewed August 23 to 24, 2026, PR #8095 is an open develop-branch proposal with no published release, no documented Mainnet activation, and no independent evidence of a production incident or performance outcome. The accountable description remains: XRPLF is proposing richer per-type server object telemetry and a new get_counts contract, with the useful peak signal still awaiting review, release, and field verification. [1][2]

Section sources[1][4][6][7]