Skip to content

Instantly share code, notes, and snippets.

@dangell7
Created August 7, 2026 21:40
Show Gist options
  • Select an option

  • Save dangell7/de397adc93e465d81bcddbf7c2dd3a20 to your computer and use it in GitHub Desktop.

Select an option

Save dangell7/de397adc93e465d81bcddbf7c2dd3a20 to your computer and use it in GitHub Desktop.
XRPL 2027: amendment feasibility assessment + the performance programme

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).


1. Trading and DeFi

AMM V2 (swappable curves) — SHIP

Adds alternative pricing curves to AMM pools instead of only constant product.

Market. Curve holds about $2.1B TVL and roughly $15B in 30-day volume on a single specialisation: stablecoin swaps, where its stableswap invariant keeps slippage on a $1M USDC/USDT trade under one basis point. Uniswap runs about $1.94B in 24-hour volume at roughly 27% of all DEX volume. The point is not that Curve is bigger than Uniswap, it is that an entire top-tier venue exists purely because one curve shape suits one asset class.

Competition. Curve and Balancer on Ethereum, and Uniswap v4 hooks, which let anyone attach custom curve logic to a pool.

Why XRPL. XRPL already has a protocol-native AMM (XLS-30) and a native central limit order book, which almost no other chain has. Today that AMM has exactly one curve, so every stablecoin and pegged-asset pair on XRPL prices on a formula designed for volatile pairs. Stablecoins are roughly $300B and tokenized Treasuries about $13.5B; both are pegged assets that constant product handles badly.

Risk. Uniswap v4 hooks arguably solve this more generally. XRPL's answer is that a protocol-level curve needs no contract deployment and no per-pool audit.

RFQ / OfferQualifiers — SHIP

All-or-none, minimum quantity and post-only qualifiers on DEX orders.

Market. Professional market making is where order-book volume comes from, and post-only is not a nicety for that audience, it is the difference between quoting and not quoting. A maker who cannot guarantee they will not cross the spread cannot run a passive strategy without taker-fee leakage and adverse selection. Every serious venue, centralized and decentralized, ships these order types.

Competition. Every CEX. On-chain, dYdX, Hyperliquid and Vertex offer full professional order types, and Hyperliquid in particular has shown that a credible on-chain order book attracts real market makers.

Why XRPL. XRPL has had a native CLOB since 2012 and it is missing the order types that make a CLOB quotable. This is the cheapest credibility gain in the portfolio: the book exists, the liquidity venue exists, the missing piece is three qualifiers.

Risk. Order types alone do not bring market makers; fee structure and latency matter too.

Options (XLS-62) — PARK

On-ledger options including stop-loss.

Market, honestly. Crypto options are enormous and almost entirely centralized. Deribit alone traded about $79.5B in BTC options in February 2026 and roughly $1.875T across options and futures in 2025. On-chain is a rounding error against that: Aevo has done about $700M cumulative, and Lyra/Derive around $369M monthly while holding over 70% of the decentralized options market. Coinbase bought Deribit for $2.9B, which tells you where the volume actually is.

Verdict. The market is real and the on-chain share of it is not. Options are also the most complex item in this cluster. Park until the CLOB is professional-grade, since options need a functioning underlying market first.

SmartAMM — GATE (follows XLS-101)

Custom AMM curve logic via WASM contracts. Strictly downstream of both AMM V2 and Smart Contracts; no independent decision to make.

Conditional and Pegged Offers — idea tier

Oracle-triggered and oracle-priced offers. Pairs naturally with RFQ, and the draft spec exists. Promote when RFQ lands.


2. Payments and settlement

TokenPaychan (XLS-93) — SHIP (approved)

Payment channels for IOUs and MPTs, not only XRP.

Market. XRPL has had payment channels since 2017 and they only work for XRP, which means every issued asset on the ledger, including every stablecoin, is excluded from the ledger's own streaming-payment primitive. Stablecoins are ~$300B and are what people actually transact in.

Competition. Lightning for BTC, Superfluid and Sablier for streaming ERC-20s.

Verdict. Already approved and near merge. The clawback addition closes a real hole: without it, tokens locked in a channel are invisible to issuer clawback, which is a compliance problem for any regulated issuer.

Subscriptions (XLS-78) — SHIP

Pull payments: authorize a counterparty to charge up to a limit on a cadence.

Market. Recurring payment rails are among the largest payment categories in existence. SEPA Direct Debit and ACH move enormous volumes precisely because the payee can pull. Crypto has essentially no native equivalent: every "subscription" in crypto is either a custodial arrangement or a smart-contract allowance with unbounded risk.

Competition. Stripe Billing and GoCardless off-chain; ERC-20 approve allowances on-chain, which are the single largest source of wallet-drain losses precisely because they are unbounded and permanent.

Why XRPL. A protocol-level pull payment with an explicit cap and cadence is strictly safer than an unbounded token allowance. That is a genuine security argument, not just a convenience one.

Risk. Adoption needs merchant tooling, not just the primitive.

Destinationless Channels and Escrow (XLS-104) — SHIP

Destination becomes optional; the recipient binds at claim time.

Market. This is enabling infrastructure rather than a product, so sizing it directly is not meaningful. What it unlocks: bounties and atomic reveals (lock funds behind a preimage, whoever satisfies it collects), and pre-funded open channels where a payer funds once before knowing which counterparty they will settle with. Today the latter costs one channel per candidate counterparty, each with reserve and a settle-delay wind-down.

Verdict. Small, cheap, and it makes two existing primitives strictly more useful. The recipient-naming claim format also closes a front-running hole that a naive version of this feature would open.

CouponPayments — GATE

Bond-style periodic distributions from an issuer to holders.

Market. Tokenized private credit is around $8B and tokenized Treasuries around $10B of the roughly $22B tokenized RWA AUM. Coupon-bearing instruments are exactly this segment. The catch is that most tokenized debt today is either zero-coupon or accrues in NAV rather than paying out, which is how BUIDL and USYC work.

Verdict. Real segment, uncertain timing. Gate it on a named issuer who wants it, rather than building on the assumption that coupon-paying tokenized bonds arrive on XRPL in 2027.

Vouchers — DROP

Funded single-use value claims. Destinationless escrow with a condition is the same object. Removed from the portfolio.


3. Tokenization and RWA

MPT Structured Data — SHIP

Protocol-validated structured data on token issuances, with an immutable schema and a shared SchemaHash.

Market. Tokenized RWA on public chains reached about $31B by July 2026, having grown over 400% since January 2025 excluding stablecoins. Forecasts for 2030 range from McKinsey's ~$2T to BCG's $16T; the spread is large because they measure different things, but every one of them assumes machine-readable, reportable token data.

Competition. ERC-1400 and ERC-3643/T-REX handle permissioned security tokens on Ethereum, all in contract code. XRPL's own XLS-89 covers display metadata but is category Ecosystem, meaning the ledger validates only the blob's length. A "compliant" token today is one that client libraries agree to call compliant.

Why XRPL. Consensus-enforced structure is something a smart-contract chain cannot easily offer, because there the schema is just more contract code. Two issuances sharing a SchemaHash are provably the same shape, which is what makes an indexer or wallet able to decode across thousands of tokens.

Verdict. Implemented and fully verified already. Cheapest audit-ready amendment in the portfolio.

IOU V2 (Native Issuance) — GATE (spec 2027, audit 2028)

Issuance objects for IOUs: supply caps, MPT convertibility, par crossing. Sensible, large in scope, and correctly sequenced behind the smaller wins.

Vault fund-feature extensions — GATE

Fee schedule, delegated fund-manager role, DID-bound fund metadata, investor-count and concentration limits on XLS-65 vaults.

Market. Tokenized fund AUM is the fastest-growing RWA segment (USYC ~$3B, BUIDL ~$2.4B). Real funds charge management and redemption fees and have a manager distinct from the owner, none of which XLS-65 models today.

Verdict. Coordinate with the XLS-65 authors. The closed-ended lifecycle is already being handled upstream, so this is the remaining gap, not a competing design.

DEX Timeseries — SHIP

OHLCV candles, trades and AMM analytics served from the node itself.

Market. Market data is a real industry: Kaiko, Amberdata, The Graph and Dune all sell what is essentially indexed chain data. Every XRPL DEX front-end today either runs its own indexer or depends on someone else's.

Why XRPL. Non-consensus node feature, so no amendment risk, and it removes an entire class of ecosystem dependency. Implementation already runs on the timeseries node.


4. Security and identity

Firewall (XLS-86) — SHIP

Account-level transaction firewall: outbound rules, whitelists, OTP-style overrides.

Market. Chainalysis put 2025 crypto theft above $3.4B. More relevant than the headline is the shape of it: 158,000 personal-wallet compromises hit 80,000 victims for $713M in 2025, and personal wallets were about 20% of all value stolen. Wallet-drainer phishing specifically fell to $83.9M in 2025 from $494M in 2024, which shows the problem is tractable when defences improve.

Competition. Hardware wallets, multisig, Safe modules, and transaction simulation tools like Blowfish. All of them sit above the protocol, so all of them can be bypassed by a signature the user was tricked into producing.

Why XRPL. A protocol-enforced outbound rule cannot be phished, because the ledger refuses the transaction regardless of who signed it. That is a categorically different guarantee from a wallet warning.

Passkey (XLS-84) — SHIP

P-256/WebAuthn transaction signing.

Market. The FIDO Alliance counts about 5 billion passkeys in use as of World Passkey Day 2026, with 75% of people having enabled at least one and 49% using them regularly. This is now the mainstream consumer authentication method.

Competition. Account abstraction with P-256 precompiles on Ethereum (RIP-7212). Note that this needed a precompile to be practical, which is evidence the curve support belongs at protocol level.

Why XRPL. Every XRPL key today is something a user must back up and can lose. Passkeys move signing into hardware people already own and already use for everything else. The spec is XLS-84d, authored by intelliot, so XRPLF is implementing rather than authoring.

Beneficiary (XLS-91) — SHIP

Inheritance: a beneficiary can claim an account after a defined period of inactivity.

Market. Lost keys are the oldest unsolved problem in the industry, with widely cited estimates putting millions of BTC permanently inaccessible. The failure mode is specific and permanent: the holder dies, and without the private key the assets are gone regardless of any legal instrument.

Competition. Safe recovery modules, Argent guardians, Casa inheritance, and off-chain arrangements where an executor holds a key, which trades inheritance risk for theft risk during the holder's life.

Why XRPL. Inactivity-triggered claim at protocol level requires no third party and no key sharing, which is exactly what makes the existing options unattractive.

Attestations — SHIP (promote from idea tier)

Unilateral, revocable, timestamped statements about any 32-byte subject.

Market. The direct comparison is Ethereum Attestation Service, which is deployed across mainnet and most major L2s and is used as public-good infrastructure. Its existence and spread is the demand evidence.

Why XRPL. XLS-70 Credentials cannot cover this: a credential's subject must be an account and must accept. A git commit cannot accept anything. Attestations are the unilateral half of that space.

Verdict. Smallest full amendment in the portfolio, roughly 1 to 1.5 engineer-months, and it subsumes the older source-code-validation idea by providing the primitive underneath it.

ConfidentialVoting — GATE

Encrypted-tally ballots. The implementation exists and the crypto is the expensive part to review. Real but not urgent; gate on a governance consumer who needs it.

Quantum (XLS-103) — GATE, correctly

ML-DSA-44 post-quantum signatures.

Honest position. NIST finalized the post-quantum standards (FIPS 203/204/ 205) in 2024, so the algorithms are settled. What is not settled is the timeline for cryptographically-relevant quantum computers, and no chain has migrated its signature scheme in production. The engineering cost is real: Dilithium signatures and keys are far larger than Ed25519, which touches serialization, fees, manifests and multisig.

Verdict. Funding the migration study in 2027 and gating the amendment on its findings is the right call. Shipping a PQ signature scheme before the study would be building on an unexamined assumption about the hardest part, which is migration, not the algorithm.


5. Platform

Smart Contracts (XLS-101) — GATE (H1 platform decision)

WASM contracts as first-class ledger objects. The largest item in the portfolio at roughly 5 engineer-months of development plus 3 of review, and it carries the Hooks-versus-XLS-101 decision that also determines the Evernode answer. Opening this gate is what activates the engineering capacity reserve, which is why the decision comes before the build.

Evernode migration — scoping

Bringing a project from another chain. H1 scoping study; the platform decision it produces steers XLS-101.


What the portfolio says as a whole

Three groups, and they are not equally strong.

Strongest case: security and identity. Firewall, Passkey, Beneficiary and Attestations all address problems with measured, recurring costs, and all four are things a protocol can do that a wallet cannot. The theft numbers are not forecasts, they are losses that already happened.

Strongest strategic fit: trading. XRPL has a native CLOB and a native AMM, which is rare. AMM V2 and RFQ finish primitives the ledger already committed to, rather than adding new surface.

Largest market, least certain timing: tokenization. Tokenized RWA at ~$31B growing 400% year over year is real, and the 2030 forecasts are enormous, but XRPL's share of it depends on issuers choosing this chain, which no amendment guarantees. MPT Structured Data is the right bet here because it is nearly free (already implemented and verified) and it makes token data machine-usable, which every one of those forecasts assumes.

The honest omissions. Options is parked because on-chain options volume does not justify the complexity yet. Vouchers is dropped because destinationless escrow covers it. Coupon payments is gated on a real issuer rather than an assumption. Saying so is more useful than a portfolio where everything scores well.

The Performance Program — what we found and what we are fixing

Companion to the 2027 protocol work menu. The menu lists performance items as one-line entries, which undersells them. This is the actual programme, and the reason it exists.

How this started

We built a real 5-validator performance network and grew it under sustained live account creation, rather than benchmarking a static ledger. The network fell over between 20 and 25 million accounts. Not degraded: it lost consensus liveness, dropped quorum, and deep-forked with no self-heal. Only a genesis reset recovered it.

That single campaign produced the findings below. Every item here is evidence-led and traceable to a measurement, not a hunch about what might be slow.

The two protocol weaknesses behind the wall

Weakness 0 — consensus liveness under job-queue saturation

Under load the validators logged LoadMonitor:WRN Job: AcceptLedger run: 19s, fell behind, and lost quorum. Reading the code found the root cause:

In LoadManager::run(), the per-tick load-feedback block that raises the local fee when the job queue is overloaded sits outside the while (true) loop, at function scope after the loop's closing brace. The loop's only exit is break on shutdown. So the fee adjustment executes exactly once, at server shutdown, where it can do nothing.

The consequence: the local load fee is never raised while a server is under load. The primary back-pressure mechanism protecting a validator from saturation has been inert. Operationally this was masked by resizing validators from 8 to 16 vCPU, which is why it survived this long.

That is one misplaced brace disabling load-fee escalation on every server on the network.

Weakness 1 — online_delete is a stop-the-world copying garbage collector

online_delete reclaims NodeStore space by keeping two append-only backends and, every deleteInterval ledgers, walking the entire current state and re-storing every live node into a fresh backend before dropping the old one.

Because the writable backend is recreated each rotation, the whole live set is rewritten every cycle. That is an O(total-state) operation running forever, on a state that only grows. Measured at 1.3M accounts it wrote about 5.4 GB per rotation. Extrapolated, the rotation eventually exceeds the rotation interval and stalls ledger acceptance.

Our conclusion: that cliff, not memory exhaustion, is the real 20-25M wall. Fix the collector, not the backend.

The fix: replace copy-and-swap with a ring of N append-only generations. New nodes append to the newest generation and stay there. A generation is dropped only once it holds no live nodes, with the few cold survivors evacuated forward first. Amortized store cost per rotation falls from O(live) to roughly O(live / N), because a cold node is re-stored once every N rotations instead of every rotation. N is a tunable disk-versus-copy trade-off.

The mainnet finding: validation relay loss

Separately, an observatory LOW_QUORUM alert on mainnet ledger 106013031 reported 25 of 35 UNL validations against a quorum of 28.

The investigation proved the network was never in danger. An independent vantage point (the xrplwin xPOP validation store) held 33 of 35 UNL validations for that ledger, including 8 of the 10 we saw as missing, all signed on time with the correct hash.

So the alert was a vantage artifact. But proving that surfaced the real finding: Ripple's public s1/s2 clusters intermittently lose an entire cohort of validations for exactly one ledger, and the lost cohort is the latest signing bucket of that ledger's validation burst. The layer that degraded was relay redundancy, not consensus.

This matters because monitoring the network from one vantage point cannot distinguish "the network is unhealthy" from "our view of it is". Any operator watching a single provider's stream will eventually raise a false alarm, or miss a real one.

The optimization work

Each of these is an active branch with a measurement behind it.

Plan Work Status
1 Parallel apply: access-set scheduler applying non-conflicting transactions concurrently Spike findings recorded, branch active
3 Batch signature verification Parked branch
6 Flat-state lookup Code complete, ~3-5x apply lift measured
7 Deferred SHAMap Quantified, combined with plan 6
8 Top-of-book cache for the order book Active
14 Tree-cache RAM scaling with saturation telemetry Active
SHAMap subtree shedding, with gate and RPC telemetry Active
NuDB bloom filter to kill negative-lookup disk reads Active
Capacity hardening: reserved worker threads for consensus-critical jobs Active
Load-fee escalation fix (Weakness 0) Active
Generational NodeStore GC (Weakness 1) Active
Pathfinder O(n²) to O(1) dedup PR open upstream

The rig

The performance network is deliberately sized to match Ripple's published benchmark hardware: z1d.2xlarge equivalent at 8 cores, 64 GB and 300 GB NVMe per node, 9 nodes as 5 validators plus 4 client and P2P nodes.

That is the rig behind both published RippleX performance reports (the XLS-30 AMM report and the MPT-DEX report) and the internal account-growth study. Matching it is the whole point: a result is only comparable to their published figures if the hardware is the same. Running bigger boxes would measure our hardware instead of reproducing their result.

Why this is the strategic work

Amendments add capability. This programme decides whether the ledger can carry the capability once it is used. A chain that deep-forks at 25 million accounts under live load has a ceiling, and until this campaign nobody had measured where it was, because nobody had grown a network to find out instead of benchmarking a fixed one.

Two of the three findings so far are protocol defects that no amount of hardware fixes, and one of them is a misplaced brace.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment