Inside XRPL Ledgers 1–32570

Ask any full-history XRPL server what it holds and it answers with the same floor: complete_ledgers: 32570-105910479. Ledger 32570 closed at 2013-01-01T03:21:10Z, and everything before it was lost early in the network’s life. It has never been recovered.

That makes 32570 the initial condition of all recorded XRPL history — and because an XRPL ledger carries complete state rather than deltas, it is also a full snapshot of everything that existed at that instant. That snapshot is what lets us work backwards.

Its state tree holds 260 objects. That is the entire XRP Ledger as of 1 January 2013:

For reference the ledger today carries hundreds of millions of objects. The whole of XRPL at the dawn of its recorded history fits in a file smaller than this page.

AccountRoot   SHA512Half( 0x0061 || AccountID )
OwnerDir      SHA512Half( 0x004F || AccountID )
Offer         SHA512Half( 0x006F || AccountID || Sequence )
RippleState   SHA512Half( 0x0072 || lowID || highID || currency )

Every one of those takes account IDs as input, and we have 136 candidates — so each index can simply be recomputed and checked. Do that across the whole state tree and the question becomes: is there any object whose address the known accounts cannot produce? One would mean an account we have never seen.

Nothing is unaccounted for. The five order-book directories name their issuers independently of the accounts — USD/XRP, JPY/USD and BTC/USD — and all four resolve to accounts already in the set. Sweeping every address-bearing field in all 260 objects turns up 137 distinct addresses: the 136, plus rrrrrrrrrrrrrrrrrrrrBZbvji, which is not an account at all but noAccount()— the protocol’s placeholder, appearing once per trustline as the balance issuer. And all 183 internal pointers between objects resolve to objects we hold; none dangles toward something missing. So the 136 are not merely what was found. Nothing in the entire state tree requires a 137th account to exist.

Not from these transactions, at least. An account reveals its public key every time it signs, so any founding account that transacted after the horizon published its key into surviving history. Collecting those gives 117 of the 136 — the other 19 have never signed anything that still exists.

Two things come out of that. Every one of the 117 reproduces its own address through RIPEMD160(SHA256(pubkey)), which confirms they are master keys rather than delegated signers, and re-verifies the derivation on live data. And there is no key reuse at all — 117 accounts, 117 distinct keys. That is a real negative result: a shared key is the cleanest evidence of common control there is, and if several of these wallets had been generated carelessly by one operator it would show here. It does not. (It does not prove the opposite either; one operator generating 136 proper keys leaves exactly this trace.)

It fails, and it fails for a reason worth knowing: an empty ledger is not an unchanged one. Every close runs updateSkipList(), which appends the parent hash to the rolling 256-entry list — so the state tree, and therefore account_hash, moves even when nothing was transacted. Ledger 32,569’s state is not 32,570’s.

Rebuilding it means rolling that list back one step. And the list holds exactly 256:

if (hashes.size() == 256)
    hashes.erase(hashes.begin());   // drop the oldest
hashes.push_back(mParentHash);

At ledger 32,570 the window covers 32,314–32,569. One ledger earlier it covered 32,313–32,568 — so the reconstruction needs the hash of ledger 32,313, which was evicted the instant 32,570 closed, and which is not a multiple of 256 so the skip-list never kept it either. We are one hash short, and the mechanism that destroyed it is the same rolling window that preserved the other 382. That is where this data ends.

And knowing the keys still does not open the transaction hashes, which is worth showing in numbers. The first transaction after the silence serialises to 183 bytes: 33 of public key, 79 of everything else — type, sender, recipient, amount, fee, sequence — and 71 bytes of signature. Grant yourself the public key and every other field, and the signature alone leaves 2⁵⁶⁸ possibilities to search. The observable universe holds about 2²⁶⁶ atoms. The hash covers all 183 bytes.

The same reasoning is what makes the 163 recovered transaction hashes a dead end, and it is worth being clear about the asymmetry. A transaction ID is SHA512Half("TXN\0" ‖ the whole signed transaction) — the client computes it over every field, signature included, which is a different hash from the one it signs with. Recovering a sender from it would mean guessing a 70-byte ECDSA signature along with everything else. An account index hashes 20 bytes drawn from a set of 136. One search finishes instantly; the other never finishes at all.

Every XRPL account stores a Sequence that increments once per transaction it submits. In 2013 sequences started at 1, so Sequence − 1 is a per-account transaction count. Summed across all 136 accounts: 368.

Separately, the ledger header’s total_coins is 99,999,999,999.996320 XRP. XRP is only ever destroyed by transaction fees, so the shortfall against the original 100 billion is the total fee burn of the lost era: 3,680 drops.

There is a sharper test than the average, and it is worth running because the average alone is one equation with 368 unknowns — a transaction that paid nothing would be invisible if another overpaid by the same amount. So check each account separately. Every payment in this era moved a whole number of XRP, which means an account’s balance should land back on a whole XRP once you add back the fees it spent — balance + 10 × (Sequence − 1). It does, for all 136 accounts. Try any other fee and only the 100 accounts that never transacted still fit, because for them the term is zero.

That converts one aggregate equation into 36 independent ones, each contributed by an account that actually sent something. It pins every sender’s totalfee spend exactly, and for the 10 accounts that sent precisely once it pins that single transaction’s fee at 10 drops outright. The remaining 358 sit inside multi-transaction accounts, where the total is fixed but the split across transactions is not — a 0 and a 20 would leave the same trace. Uniform 10 is the overwhelmingly likely reading, and it is the era’s base fee, but the ledger evidences the totals rather than each line.

The count is complete rather than a lower bound: AccountDelete did not exist until 2020, so no account could have been created and then removed before the snapshot. Every transaction ever submitted in the lost era came from one of these 136 accounts.

For scale: 368 transactions across 32,569 ledgers. The wall-clock span can be estimated rather than guessed, because one lost ledger does carry a real timestamp — 32,570’s header records its parent’s close time, putting ledger 32,569 at 2013-01-01 03:21:00 UTC. Run the clock back from there at the measured close rate just after the horizon (18.110 seconds per ledger, averaged over the next 1,000) and the lost era spans about 6 days 20 hours, putting ledger 1 around 25 December 2012. Use instead the average over a window exactly as long as the lost era — 21.576 s/ledger — and it stretches to 8 days 3 hours, moving ledger 1 back to the 24th. So: roughly a week, with about a day of slack.

That rests on the network never having stopped, which is the one assumption in it — and it survives an outside check. The XRP Ledger’s own documentation, describing the loss, says in passing that it represents “approximately the first week of ledger history”. Our figure was derived the other way round — from a recovered timestamp and a measured close rate, with no reference to that sentence — and lands in the same place. Worth noting because the network is often said to date from June 2012; that is when work on it began, not when ledger 1 closed. Either way the lost history is far emptier than its reputation suggests: the gap is mostly silence.

Higher counts for the lost era circulate — one figure put about is 534. Both can be true, because they measure different things, and the surviving data says exactly which.

Sequence only advances when a transaction is applied against an account, so 368 is the count of transactions that consumed a sequence. Nothing is missing from it: account deletion did not exist until 2020, so no sender could have disappeared before the snapshot took their counter with them.

The fee burn then pins the rest. Exactly 3,680 drops were destroyed, and XRP is destroyed only by fees. At the era’s 10-drop fee that is 368 fee-paying transactions on the nose. For 534 the average would have to be 6.89 drops — not a fee any node charged.

The client of that era settles what 368 covers, and it can be read: the commit below is dated 1 January 2013, the same day ledger 32,570 closed. A transaction only reached a ledger down one of three paths, and every one of them advanced the sender’s sequence — including the path that exists purely to claim a fee from a failed transaction, which sets the counter explicitly. Everything else was rejected and never written. So within those ledgers, sequence-consuming and ledger-written are the same set, and 368 counts it.

One thing the client does change: a zero fee was legal. Declare no fee and the fee routine returned success without destroying anything, and the required fee was only checked while a ledger was still open. Earlier still, negative and non-XRP fees were possible. Both were closed off on 26 December 2012 — inside the lost window, while these very ledgers were closing:

Which makes the 10.00 drops a finding rather than an assumption. Nothing compelled those 368 transactions to pay anything at all; that they average exactly the reference fee, to the drop, is evidence about how the network was actually used — not a property it was forced to have.

Every ledger keeps LedgerHashes objects: a rolling list of the previous 256 ledger hashes, plus a skip-list holding every 256th hash going back to the start. Ledger 32570 carries both — so its own state hands back the hashes of ledgers it can no longer show us.

A second haul comes from the objects themselves. Every ledger entry records PreviousTxnID — the transaction that last modified it — yielding 163 transaction hashes from transactions whose contents no longer exist. Query one against a full-history node and it returns txnNotFound: a real, verifiable identifier pointing at nothing.

Every datable event on this page falls between ledger 7 and ledger 32,359. Nothing in the surviving state points earlier than 7 or later than 32,359, so that is the window the evidence actually covers.

The same fields prove which ledgers were busy: 163 distinct indices in the range 7–32,359 are provably non-empty — 0.5% of the 32,569 lost ledgers. The earliest is ledger 7.

Stated precisely: ledger 7 is the earliest ledger we can prove contained a transaction — not proof that ledgers 1–6 were empty. PreviousTxnLgrSeq records only the last modification of an object, so a transaction in an early ledger whose effects were later overwritten leaves no trace.

The top of the range is different, and stronger. Every transaction bumps its sender’s account — sequence up, fee deducted — so the highest index across all accounts is the last ledger that contained any transaction at all. That figure is 32,359, and nothing could have overwritten it because 32,570 is the snapshot. Ledger 32,570 itself carries zero transactions. So ledgers 32,360–32,570 are provably empty — 211 consecutive ledgers in which nothing happened.

And they are not where the silence ends. Ledger 32,570 survives, so we can simply look at what follows it: every ledger from there to 38,128 is empty too, and the next transaction on the XRP Ledger does not land until ledger 38,129, at 06:43:20 UTC on 2 January 2013. That is 5,769 consecutive empty ledgers — about 27 and a half hours — of which only the first 210 are lost. Recorded XRPL history does not begin at a moment of activity. It begins in the middle of a day-long silence, and the horizon falls where it does for reasons that have nothing to do with what the network was doing.

The low end gives nothing back, and it is worth being blunt about the scale. Only 163 of the 32,569 lost ledgers left any trace in the surviving state — 99.5% carry none at all. Ledgers 1–6 are not a special blind spot, just the first six of 32,406; there are far larger runs, the worst being 3,744 consecutive ledgers between 4,175 and 7,918 about which the ledger says precisely nothing. Slightly more than half of the 368 transactions — 205 of them — are known to exist by arithmetic while being impossible to place in any particular ledger.

The recovery is concrete, not statistical. One hundred accounts still had Sequence 1 at ledger 32,570 — they had never sent a transaction — and each carries a PreviousTxnID pointing at a specific transaction inside a ledger nobody has a copy of, together with the ledger index it landed in.

One caveat, stated plainly. PreviousTxnID records the last transaction to modify an account, not its first. For an account that never sent anything and received only its funding Payment, the two are the same transaction — but a second incoming payment would overwrite the link, and the snapshot alone cannot rule that out. The case for these being the funding payments is circumstantial and strong rather than proven: the balances sit exactly on the observed grant tiers (10,000 and 2,000 XRP), and at ledger indices this low there is barely any window for a top-up to have happened first.

On that reading each row recovers four things — the exact ledger, the transaction hash, the account brought into existence, and the amount delivered. The sender is unrecoverable either way.

The ledger hashes come back the same way — real identifiers for ledgers whose contents are gone:

The last row is the load-bearing one. Ledger 32,569’s hash, recovered from the skip-list, is byte-identical to the parent_hash that ledger 32,570 independently records. The recovery validates itself.

The specimens above recover transactions. This recovers counterparties — with one assumption, which is worth stating before the table rather than after it.

Nine transaction hashes appear on more than one account, and seven of those pair a sender with an account that never sent anything, which fixes the direction. Calling them payments would go further than the evidence: a TrustSet can stamp both accounts too, which is verifiable in surviving history — ledger 193,722contains three that do exactly that. Three of the nine below moved a trustline in the same transaction and are therefore trustline operations rather than XRP sends. For the remaining six there is no line between the pair at all, which makes an XRP payment the overwhelmingly likely reading — though a line opened and later closed would leave the same trace, so “almost certainly” is as far as this goes:

Two of the nine go the other way and are provably notpayments. At ledgers 8,897 and 8,901 both parties’ entire transaction budgets are accounted for by trustlines they own, so neither had a payment to spend — and creating a trustline threads the transaction onto both parties’ account records, which is exactly the trace we see. Contact without a transfer.

The amounts carry two caveats. Where the recipient never sent anything, its balance is everything it ever received, which equals this payment only if it received nothing else — the counterparties and the ledger are exact; the amount is exact provided that was its only inbound payment. And in three of these nine, a trustline moved in the same transaction, which means it may have been an IOU payment or a TrustSet rather than an XRP send. There the balance proves nothing about the amount, so the table declines to state one.

Nine edges out of 368 transactions is a thin slice, and it is thin for a structural reason: only the last transaction to touch an account leaves a pointer. Every earlier payment was overwritten by whatever came next. What survives is the final act of each account — which is why the recovered set skews so heavily toward the closing ledgers.

Bucketing every object by the ledger that last touched it gives the shape of activity across the lost range. It is dramatically front-loaded — the founders distributed the supply almost immediately, then the network fell quiet for weeks at a time.

Seven accounts held 98.11% of all XRP. The remaining 129 accounts shared 1.89% between them.

The distribution was plainly scripted. Every one of the 136 allocations is a whole number of XRP, and they cluster hard on round tiers — counted here by what each account received rather than what it holds, since an account that has since paid a fee reads 9,999.99999 and would otherwise look like a tier of its own:

Forty-five accounts were granted exactly 10,000 XRP — the standard small allocation. Forty of them still hold it untouched to the drop. The other five read 9,999.99996 to 9,999.99999 because they have each sent between one and four transactions since, and the missing 10 to 40 drops are precisely the fees. One more sits at 10,001, topped up rather than granted twice.

rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh is the account the protocol creates at ledger 1, holding the entire 100 billion XRP supply. Every XRP that has ever existed was issued into that one account at the moment the network started; none has been created since.

Which means the practical origin of every XRP lineage is not the genesis account but r8TR1AeB… — 79,997,608,219 XRP, 80% of the supply, sitting at Sequence 3. Two transactions sent, ever.

Genesis sent only 46 transactions, but 136 accounts existed. Even if every one of those transactions created an account, that leaves at least 89 accounts funded by someone other than genesis. The tree was already branching before history begins.

The transaction budget accounts for itself neatly: 135 account creations (136 accounts, less genesis itself), ~53 TrustSets to open the trustlines, at least 4 OfferCreates, leaving roughly 176 for payments and IOU issuance. That is the complete pre-history of the XRP Ledger.

One hundred accounts never sent a transaction at all — their Sequence is still 1. For those, the ledger recorded in PreviousTxnLgrSeq is the funding payment itself, giving a tight upper bound on when each was created:

Four accounts in the first four active ledgers, each with exactly 10,000 XRP. The distribution began immediately and ran to a script.

Ranking the 136 accounts by transactions sent gives the operators of the lost era. Between them, these ten account for 281 of all 368 transactions:

The XRP Ledger was written by three engineers — David Schwartz, Jed McCaleb and Arthur Britto — and two of the three appear in this snapshot. Set side by side, the attributions are lopsided in a way worth stating carefully.

The two accounts curated to Britto hold a billion XRP each and were funded at ledgers 85 and 87 — inside the first three-tenths of one percent of the lost range, which makes them the earliest large allocations in recoverable XRPL history. Both are terminal: they received, and never sent anything, before or since.

Across all 136 accounts, only the eight mandatory AccountRoot fields appear. Not one account had set Domain, RegularKey, MessageKey, EmailHash or TransferRate, and every single Flags value is zero. No account settings had been changed by anyone, anywhere, ever.

Worth noting for anyone doing lineage forensics: domain-based identity verification, which underpins most modern XRPL attribution, has nothing to work with in this era.

Three order books were open at the snapshot — USD/XRP, JPY/USD and BTC/USD — alongside 53 trustlines in six currencies:

Dating them matters, and the objects date themselves. Each carries PreviousTxnLgrSeq, so we get an upper bound on when each was created — it existed at or before that ledger:

Every figure in that table is a last-touched ledger, so each is a ceiling rather than a birthday. A payment flowing through a trustline, or a partial fill against an offer, rewrites the field — so the real median trustline creation is at or below 8,901, possibly well below.

So the ledger opened for accounts at ledger 7, but the first datable trustline is ledger 147 and the four resting orders are late: 10,084, 17,819, 17,826 and 17,835 — between a third and two-thirds of the way through the lost range, not at its start. Trading was not switched on with the network; it arrived after the supply had been handed out.

And it was scaffolding, not a market. Only 3 of 53 trustlines carried a non-zero balance — 2 USD and 1 unit of a currency called MEA. Total IOU circulation on the XRP Ledger was three units of value.

The four offers imply mutually contradictory XRP prices ($10.50 against $1.15), so they are test orders rather than a price signal. The BTC/USD offer prices bitcoin at $13.33, which is close to its real market price over the days this range covers — a reasonable sanity check on the snapshot, though with one order it is a plausibility check and not a measurement.

Everything above stops at the horizon. But the 136 accounts did not, and what became of them is in surviving history where anyone can check it. Twenty-five days after ledger 32,570, the account holding 80% of all XRP emptied itself.

On 26 January 2013, between 22:35:20 and 22:40:40 UTC, r8TR1AeB… sent twelve payments totalling 79,000,000,000 XRP to exactly nine addresses. Seventy-nine percent of every XRP that will ever exist moved in five minutes and twenty seconds, in round eight- and nine-billion blocks, on a metronome:

Those twelve are not quite the whole day. Forty-seven minutes before the run, the account sent 100,000,000 XRP to its operational account, and two minutes after it, a final 800,000,000 topped up one of the nine — 79.9 billion moved on 26 January in all. The five-minute window is the event; the table is exact within it, and all fourteen are one account_tx call away.

The nine hold 856.10 XRP between them today — about a millionth of one percent of what passed through. And the pattern holds for the cohort as a whole: all 136 founding accounts still exist, none was ever deleted, and together they now hold 49,681,555.5 XRP of the 100 billion they started with. 0.0497%.

Which is worth holding next to the reconstruction above. The lost ledgers are treated as the great unknown of XRP’s history, and they are genuinely gone — but the concentration they created did not survive them by much. The single account that held 80% of the supply at the horizon kept it for twenty-five days.

The XRP Ledger’s documentation attributes the loss to “a mishap early in the XRP Ledger’s history” and does not say what the mishap was. The client of the time is public, and its commit history over those three weeks is fairly explicit.

Two separate things are visible there. The first is that the restart was deliberate. Three days after a commit making breaking changes to the ledger and transaction formats, Arthur Britto removed dead error codes “in prep for ledger wipe” — on 25 December 2012, at 00:06 UTC. Our own estimate, derived from the recovered timestamp and the measured close rate with no knowledge of this commit, puts ledger 1 of the current chain at about 07:30 UTC that same morning. The two land seven hours apart.

  assert (getAccountHash() == mAccountStateMap->getHash());
  assert (getTransHash()   == mTransactionMap->getHash());

+ // Save the ledger header in the hashed object store
+ Serializer s(128);
+ s.add32(sHP_Ledger);
+ addRaw(s);
+ theApp->getHashedObjectStore().store(hotLEDGER, mLedgerSeq, s.peekData(), mHash);

The addition is the tell. Before this commit, a server that closeda ledger never wrote that ledger’s header into the hashed object store — the content-addressed pool that servers fetch from each other by hash. Checking the parent commit directly: saveAcceptedLedger went from its asserts straight into the SQL block, and the only thing Ledger.cpp put in the store was hotACCOUNT_NODE, the account-state tree. The one place in the whole codebase that stored a hotLEDGER header was the acquisition path — LedgerAcquire::takeBase, which files a header away after fetching it from a peer. A header could be passed around once somebody had it; no server ever seeded its own.

So a server missing a ledger could ask its peers for that ledger’s state tree and get it, and ask for its transaction tree and get it, and never obtain the header that binds the two together and states which ledger they belong to. Without a header there is no ledger. History could not be backfilled from the network at all, by anyone, until this line existed.

That is exactly the asymmetry this whole reconstruction runs on, thirteen years later. Everything on this page comes out of a state tree— balances, sequence numbers, trustlines, the hash index — because state was the part being stored in a form that survived. Not one lost ledger’s header survives, which is why no lost ledger has a transaction root, and why ledger 32,569’s close time reaches us only as a field inside its child.

One caveat on all of this: the commits prove a wipe was planned and that header data was absent from the recoverable store until 13 January 2013. They do not, on their own, prove that the wipe is what removed ledgers 1 to 32,569 — those are ledgers of the chain that followed it. The defensible reading is that the current chain began with the December restart, and that whatever became of its first week of ledgers locally, the missing header path is why they could never be fetched back. The fix landed twelve days after the horizon. Everything already gone stayed gone.

Transaction bodies are gone for good. We have 163 hashes and the ledgers they landed in, but no senders, destinations, amounts or memos, and no way to map a hash to the account it created. Intermediate balances are unrecoverable — only the final position survives.

Ledgers 1–255 have no recoverable hash at all, since the skip-list begins at 256, as do all non-multiples of 256 below 32314. And reconstructing an actual ledger is infeasible: knowing ledger 32569’s hash makes any candidate checkable, not derivable. You would have to guess 368 exact transactions and their precise ordering.

Everything here comes from ledger 32570’s own state tree, pulled from a full-history node with ledger_data (260 objects over two pages) and ledger for the header. Transaction counts derive from account Sequence fields; the fee burn from total_coins; ledger hashes from the two LedgerHashes objects; activity timing from PreviousTxnLgrSeq.

These values are permanent. Ledger 32570 closed in January 2013 and cannot change, so every figure on this page is fixed for as long as the XRP Ledger exists.

None of it needs an API key, an archive, or any access you do not already have. Two public JSON-RPC calls against any full-history server reproduce the core numbers — the header for total_coins and the hashes, then the state tree for everything else:

N=https://s1.ripple.com:51234/

# 1 — header: total_coins and the hash chain
curl -s $N -H 'Content-Type: application/json' \
  -d '{"method":"ledger","params":[{"ledger_index":32570}]}'

# 2 — the full state tree, 260 objects over two pages
#     (repeat with "marker" from the response until it stops coming back)
curl -s $N -H 'Content-Type: application/json' \
  -d '{"method":"ledger_data","params":[{"ledger_index":32570,"limit":2000}]}'

# then, from those two responses alone:
#   objects        260
#   accounts       136   AccountRoot entries
#   transactions   368   sum of (Sequence - 1)
#   drops burned  3680   100,000,000,000 XRP - total_coins
#   fee per tx      10   3680 / 368

Every other figure on this page — the 382 recovered hashes, the 163 transaction IDs, the distribution tiers, the per-ledger timing — comes out of that same second response. Nothing here is privileged information; it is one public ledger, read carefully.