Amendment Idea: Ephemeral Data Blobs

[Platonenkov]

  title: Ephemeral Data Blobs
  author: Aleksandr Platonenkov (@Platonenkov), StaticBit.io
  status: Idea
  category: Amendment

This is deliberately a conditional proposal. It answers one question: if the community
decides the ledger must carry bulk data, what shape costs node operators least? Our own position
is that it should not — the case against this document is in section 4, and we find it strong.
Posting it anyway because the memo cap discussion is happening now and "raise the cap" currently
has no counter-design next to it.

Measurements referenced below: cost-of-data-on-xrpl
(1,000-ledger mainnet sample, tools, raw data), and the data-backed comment on
#413.

Abstract

A transaction commits to a payload without carrying it: it holds a hash and a size, while the
payload travels beside the transaction over the peer protocol, is served for a bounded number of
ledgers, and may then be dropped. Bulk data becomes priced by size and temporary by construction.

Unlike EIP-4844, availability is not a condition of validity at any point. Ethereum's consensus
nodes refuse a block until blob sidecars verify against their KZG commitments, which is what makes
"drop it after 18 days" safe there. Nothing here provides that guarantee, so this is a strictly
weaker primitive than the thing it borrows from, and the borrowing stops at "bounded retention".

1. Why not simply price memo bytes

Pricing memo bytes (XLS #413) is
necessary and we support it. What price cannot answer is duration: a memo is part of the
transaction, so whatever is written there is permanent for anyone keeping history, whatever it cost.
Raising the memo cap to ~1.3 MB makes that permanence the network's dominant storage term.

2. Mechanism

Field	Type	Description
DataHash	Hash256	SHA-512Half of the payload
DataSize	UInt32	Payload length in bytes, bounded by a network maximum

The payload is not part of the transaction and does not enter the transaction tree, the state tree
or the ledger hash. The signature commits to it through DataHash, so it cannot be substituted.

A server that has accepted a blob SHOULD serve it for DataRetentionLedgers ledgers and MAY drop it
afterwards. A server MAY never have received it at all — because it started later, was offline, or
gossip did not reach it — so the API needs both dataExpired and dataNotFound, and callers must
treat the two as indistinguishable in the general case.

Transaction validity never depends on holding the payload: a server that has never seen it still
applies the transaction. This keeps availability out of consensus. It does not make the proposal
consensus-free — new fields, a new fee formula and new result codes are all amendment-gated.

2.1. Fee

DataSize is priced per byte through fee-voted parameters, the way XLS-413 prices memo bytes.
EscrowFinish is the in-protocol precedent for size-dependent pricing:
base * (32 + size/16), about 0.625 drops per byte.

Because the retention obligation is bounded rather than perpetual, a blob byte can cost less than a
permanent memo byte — which is the incentive to want, since it pulls bulk data out of memos.

3. Unsolved problems, stated plainly

These are not details. Any one of them may be fatal.

1. Bandwidth is spent before the fee is paid. A blob propagates when the transaction is relayed —
   before it reaches a ledger and before any fee is burned. A transaction that dies in the queue, or
   on LastLedgerSequence, has already cost every peer that relayed it. This is a free amplifier
   and it needs relay rules of its own: accept a blob only alongside a transaction, verify
   SHA-512Half(blob) == DataHash and len == DataSize before forwarding, penalise peers that miss.
2. A per-ledger budget needs consensus. A per-transaction size limit does not bound total blob
   volume per ledger. Bounding it means validators rejecting proposals that exceed it — a consensus
   rule, not an API convention. Either the aggregate is unbounded or the "availability stays out of
   consensus" framing does not extend to bandwidth.
3. DataSize may not be enforceable at fee time. The fee is charged from a declared size, while
   the payload arrives out of band. Understating it must be caught at relay and made unprofitable;
   the mechanism for that is not specified here.
4. Nothing compels anyone to publish the payload. A sender can commit to data nobody can read.
   See below — this is the hole that eats the use cases.
5. Missing engineering. Peer protocol messages and their amendment gating; backfill for a server
   syncing inside the window with no incentive for peers to answer; deduplication when two
   transactions share a DataHash; whether resubmission restarts the window; what tx/account_tx
   return and under what size limits; DoS surface of downloading before hash verification; hash
   domain separation with rippled's HashPrefix.
6. Fee voting is the wrong lever for a bandwidth ceiling. The maximum blob size sets hardware
   requirements for every node. Fee voting has always set prices and reserves, not machine specs.

4. The case against this document

The strongest argument against this proposal comes from our own measurements.

The memo cap already makes bulk storage expensive and slow: 12.64 XRP and over a million
transactions per gigabyte. A byte price on memos makes the cost of a gigabyte roughly independent of
where the cap sits. Live traffic shows nobody storing files in memos at all — the median memo is 84
bytes. XLS-413 with sensible constants, plus leaving the 1 KB cap alone, makes bulk storage
expensive enough that nobody bothers — with no new peer-protocol layer, at the cost of one amendment
that is being discussed anyway.

What it does not do — and cannot, because a price answers "how much" and never "for how long" — is
bound retention. Our own upload is the demonstration: 3.3 MB for four cents, permanent. Under
XLS-413's defaults it would have cost twenty cents, and still be permanent. While the cap is 1 KB
that difference is academic, because nobody will pay 65 XRP for a gigabyte of permanence. If the cap
rises, it is the only difference that matters.

And the availability hole empties the use cases: a receipt or an attachment nobody can fetch is
worthless, while proof-of-existence needs only 32 bytes of hash in a memo today, with no protocol
change at all. The honest question a reviewer will ask first is "how is this better than a hash in a
memo plus external storage?" — and the only candidate answer, that every peer saw the data at
inclusion time, is exactly what the design declines to guarantee.

So this belongs in a drawer unless the cap is raised. If it is raised, this is the shape we would
argue for, because bounded retention is the only lever left once you accept that no XRPL mechanism
pays operators to store anything.

5. Prior art

• rippled#3007 (2019) and
  rippled#4259 (2022) — memo fee scaling, both closed
  unmerged.
• XLS #276 (2025) — escalating memo fees,
  closed; the objection was that rate-based rules are incompatible with deterministic consensus.
  A fee derived from DataSize inside calculateBaseFee is a pure function of the transaction and
  does not inherit that problem.
• XLS #413 (2025) — memo byte pricing, open.

6. Open questions

1. Should DataRetentionLedgers be fixed by amendment rather than voted, so expectations stay stable?
2. Is a plain hash enough given that availability is explicitly not guaranteed, or does anything
   weaker than a KZG commitment make the whole construction pointless?
3. Should the memo cap be lowered if this ever exists?