dangell7

6-Month Roadmap — Performance Network & Staging/Canary Network

Companion to: takeover-network-and-capacity-testing.md Author: Denis Angell, Director of Technology Window: Jul – Dec 2026 Note: This is the time-bound execution plan. The proposal itself is deliberately timeline-free; scheduling lives here.

---

Workstreams

dangell7

Validation relay loss on mainnet — one-ledger cohort drops at the s1/s2 vantage

Status: investigated (2026-08-02), monitor cross-check shipped (xrplf-release-notifier, uncommitted), root-cause candidates ranked from code; perfnet repro pending Origin: observatory LOW_QUORUM alert, ledger 106013031 ("25/35 UNL validations, need 28"). Investigation proved the network was healthy and the alert was a vantage artifact — which surfaced the real finding: Ripple's public s1/s2 clusters intermittently lose a cohort of validators' validations for exactly one ledger. Relevant to the capacity campaign because relay redundancy, not consensus, was the layer that degraded under load.

dangell7

Design: generational (N-segment) NodeStore for online_delete

Concrete implementation design for the fix in online-delete-generational-gc.md. Target: Transia-RnD/rippled, branch dangell7/online-delete-generational-gc (own work off develop).

Problem restated (one paragraph)

Today DatabaseRotating keeps two append-only backends (writable + archive). Every deleteInterval_ ledgers, SHAMapStoreImp::run() walks the entire current state (visitNodes(copyNode)) and re-stores every live node into a fresh writable backend, then drops the old archive. Because the writable is recreated each rotation, the whole live set is re-written

dangell7

Weakness #0 — consensus liveness under job-queue saturation

Status: investigated (2026-08-01), fix PR in progress Origin: the "XRPL falls over at 20–25M accounts" stress campaign. On a real 5-validator perf net under sustained live account creation, consensus lost liveness — LoadMonitor:WRN Job: AcceptLedger run: 19s, validators fell behind, dropped quorum, and the network deep-forked with no self-heal (only a genesis reset recovered it). Masked operationally by resizing validators 8→16 vCPU; the protocol weaknesses remain.

Three read-only investigations (code refs against Transia develop). Weakness #0 is not one bug

dangell7

  xls: TBD
  title: Attestations
  description: Unilateral, revocable on-ledger statements about arbitrary 32-byte subjects, signed by the attesting account.
  implementation: none yet
  author: Denis Angell (@dangell7)
  category: Amendment
  status: Draft
  proposal-from: TBD
 created: 2026-08-05

dangell7

xls: TBD (draft, candidate XLS-104)
title: Destinationless Payment Channels & Escrow
description: Allow PaymentChannelCreate and EscrowCreate without a Destination; the destination is bound at claim/finish time.
implementation: none yet
author: Denis Angell <dangell7@xrpl-labs.com> (XRPL-Labs)
category: Amendment
status: Draft
requires: XLS-85 (token escrow, referenced), XLS-93 (token paychan, referenced)
created: 2026-08-05

dangell7

  xls: XX
  title: Repo
  description: Bilateral repurchase agreements with on-ledger collateral and time-proportional interest.
  author: Denis Angell (@dangell7)
  category: Amendment
  status: Draft
  proposal-from: TBD
  requires: XLS-85
 created: 2026-08-04

dangell7

XRPL 2027 Amendment Portfolio — Feasibility Assessment

Why each proposed amendment is worth building, or is not. For every item: the addressable market with a real number, what already solves the problem, and a verdict. Figures researched August 2026 with sources named. Where a market is small or the demand is speculative, this says so.

Verdicts: SHIP (build it, the case is made), GATE (real but needs a decision first), PARK (defensible idea, wrong year).

dangell7

IOU vs MPT on the XRPL — Ecosystem Review and Client Decision Guide

Date: July 14, 2026 Scope: Protocol comparison (grounded in rippled source), XRPL ecosystem adoption 2024–mid-2026, tradfi/RWA tokenization landscape, and a client-facing decision matrix. Thesis under test: "the future is MPT."

---

1. Executive summary

• MPT (XLS-33, Multi-Purpose Tokens) is the institutional token standard on XRPL. Its flag set — RequireAuth allowlisting, per-holder and global lock, clawback, fixed supply caps, integer amounts, on-chain metadata, per-issuance transfer fees — maps one-to-one onto what regulation now requires (GENIUS Act seize/freeze/burn, MiCA EMT controls, SEC transfer-agent regimes).

dangell7

Starter

Starter is the simplest possible hook: it just accepts all transactions and logs that it is running.

to test:

• in the develop pane, compile starter.c
• in the deploy pane, deploy it to Alice account
• set up payment transaction from Alice to Bob
• run it and see in the debug stream 'Accept.c: Called.'