dangell7

  xls: 91d
  title: Beneficiary
  description: An inheritance mechanism: a designated account gains the regular key after a chosen period of account inactivity.
  author: Chris Dangerfield (@xrpl365), Denis Angell (@dangell7)
  category: Amendment
  status: Draft
  proposal-from: Standards discussion 269
  created: 2025-02-25
 updated: 2026-09-11

dangell7

Tally — deterministic credit records derived from validated XRPL ledger data

Status: draft, hosted by the XRP Ledger Foundation. MIT licensed. The standard it implements is headed for the XRPL-Standards repository as an Ecosystem XLS.

The problem

XLS-66 deliberately keeps credit assessment off-chain. A Loan Broker decides whether to lend; the ledger records the loan and enforces its terms. That leaves two questions nobody can answer today without building their own indexer:

dangell7

Amendment Manager (role definition)

A new XRPLF position. XRPL has a well-defined process for getting code into xrpld and amendments activated; there is no equivalent end-to-end ownership of getting an amendment successfully into the ecosystem. The Amendment Manager owns that gap: one owner per amendment from spec to product, every stage of the pipeline in amendment-duties.md, for the amendments assigned to them. It is a hybrid seat, half management and half hands-on development. The management half runs the people and vendors who build the protocol layer; the dev half personally builds the ecosystem layer around it, because

dangell7

Amendment Devnet Dashboard

A per-amendment dashboard on the devnet that measures how the amendment's new transaction types are actually being used, with an AI layer that analyzes the usage and reports what the numbers alone don't show. It exists to answer one question with data: is this primitive ready to activate? Built and operated by the Amendment Manager (role duties 11 and 12); the output feeds the activation readiness call and loops findings back into the spec and docs.

Scope

dangell7

  title: NuDB — bloom-filter negative lookups + mmap key reads
  description: Perf work on the vendored NuDB store — lock-free bloom filter built from key-file buckets on open() to short-circuit fetch/insert misses, hash-first pool find, and POSIX mmap read path for bucket fetches.
  author: Denis Angell (@dangell7)
  status: Active
  created: 2026-08-04
  updated: 2026-08-04
  repos:
    - xrplf/NuDB @ master

dangell7

plan-14 — SHAMap tree-cache RAM scaling (the cache OOM design fix)

Companion code branch: xrpld → dangell7/tree-cache-ram-scaling (off develop). Surfaced by the 25M-account capacity soak (see soak-issues-to-fix.md #5/#6).

Problem

[node_size] (tiny…huge) picks a fixed entry-count target for the SHAMap tree-node cache (Config.cpp TreeCacheSize = 262 144 … 8 388 608 entries). That number has no relationship to the machine's RAM and no memory bound:

dangell7

Plan 3 — Batch Signature Verification: Design (corrected after code + crypto research)

Workspace: /Users/infinityworks/projects/xrplf/xrpld-batch-sign, branch dangell7/batch-sig-verify, off develop @ 2f3558c61.

Status: Design / decision point. No code written yet — research invalidated two premises of the original todo.md Plan 3 and the scope must be re-decided on the corrected facts.

---

The two findings that change everything

dangell7

Plan 8 — Top-of-book cache (best-price pointer)

Goal: for every active orderbook (and AMM-augmented book), maintain a sticky pointer to the keylet of the best-quality directory page. The path engine reads the top of book by dereferencing one pointer instead of issuing a SHAMap succ() from the book's base keylet.

Scope: a single, narrow optimization at the orderbook semantic layer. Composes with Plan 6 (flat state lookup) — they sit at different layers and stack. No protocol change, no amendment, no consensus impact.

---

1. The problem

dangell7

Plan 6 — Flat keylet-indexed state lookup (read-side)

Goal: materialize XRPL state as a flat keylet→SLE map. Apply does dual-write (SHAMap stays authoritative, flat map indexes reads). Reads go to the flat map only — no fallback path. This is the pure NoSQL 2-writes-for-1-read pattern. Direct TPS lift is moderate-to-large; indirect value is the larger story — this unlocks downstream consumers (indexers, light clients, hooks, AMM bots, sidecar services) that currently can't query XRPL state at scale.

Why this is Plan 6: the SHAMap is a NoSQL substrate (keylet→SLE Merkle trie) currently being used in a SQL access pattern (descend the index on every read). Plan 6 finishes what the substrate was designed for: materialize the read view. Plan 5 (incremental hashing) becomes mostly obsolete once Plan 7 (deferred SHAMap, the structural follow-on to this plan) lands.

---

1. The problem

dangell7

Plan 1 — Account-sharded parallel transaction application

Goal: remove the master-mutex serial-apply ceiling. Target: 5–10× sustained TPS lift (from ~159 TPS payment baseline to 800–1500+ on commodity multi-core hardware, scaling further with cores).

Headline approach: Solana-style static conflict-graph scheduling, not Block-STM. XRPL transactions already carry a small, statically-determinable access set per tx type; we extract it, build a conflict graph, dispatch independent groups to a worker pool, and merge per-account writes at the end of the round. No speculation, no abort cost.

---

VERIFICATION STATUS