Start here
What the data covers
The span of the record, whose histories were read, and the rules the series follows.
- Published
- Ledger index
107030551
Contents
- How to read and check these articles
- What the ledger cannot tell anyone
- The span of the record
- Whose histories were read in full
- The rules
Accounts marked “flow-connected to” an activation tree are those the CULT and OBEY token flow reaches from it at its widest flow threshold, 10 CULT paid in total one way; the token-flow article sets out how it is followed, and the groups at every other threshold. Accounts flow-connected to both activation trees: 17 at 10 CULT, 0 at 30 CULT, 0 at 50 CULT. Being flow-connected does not make an account the activation tree's.
What the series is built from, what it leaves out, and the rules it follows where the ledger leaves a choice. Every other article rests on this one. Every figure comes from the XRP Ledger's own record and nothing else: prices are the market's own trades and pools, not a quote from any exchange or aggregator.
How to read and check these articles
Every row resting on a single event names its transaction identifier — the long string of capital letters and digits. Paste one into any public XRP Ledger explorer and the same transaction comes back: who sent it, what moved, when.
Table 1. What the marks written beside accounts and figures mean.
| what you see | what it is |
|---|---|
a string starting with r |
an account, written in full and never shortened |
| (Pheanor), (Hodler) beside an address | one of the 5 named wallets, with the name it goes by |
| (Pheanor, CULT Treasury) and the like | a named wallet and the label it is publicly known by |
| (Pheanor activation tree, generation 2) | an account in a named wallet's activation tree: created (activated) by a named wallet (generation 1), or by an account one of those created (2), and so on. A named wallet is generation 0, even one another named wallet created |
| LP tokens | liquidity-provider tokens: a pool's shares, handed to whoever puts assets into an AMM pool and handed back to take its share of the pool out |
| single-asset | a pool deposit or withdrawal of one asset alone; taking a token alone out raises its price as buying it would, putting it alone in lowers it as selling would |
| flow link | two accounts that paid each other CULT or OBEY, LP tokens included, at least the flow threshold in total one way |
| step | how many flow links separate an account from the nearest activation tree account |
| connection score, band | the score is how many of five kinds of record (token flow, XRP flow, creation, destination tags, behaviour) connect an account to the activation trees; the four bands group the scores: strong, token flow only, token flow on one payment, one other kind only |
| family | accounts that, followed up the record of who created whom, meet at the same top account: the last account below an exchange or service, or where the record ends |
| units | amounts of a token followed through transfers one by one, to say where what an account holds had been: first in, first out (the oldest units leave first) and, as a check, last in, first out (the newest leave first) |
| moved inside an activation tree | units whose last move was a transfer between two accounts of the same activation tree |
| units coming back | units that passed through an activation tree, left it, and came back to it from an account outside it |
| (flow-connected to Pheanor's activation tree) | an account reached by following CULT and OBEY payments, LP tokens included, from Pheanor's activation tree; the token-flow article sets out the rule. Reached by the tokens, not by creation |
| (Bybit), (Coinbase), (xrp.cafe) and other names | a public name for the account, as listed by public XRP Ledger explorers; the ledger itself records no owner |
| (own domain: example.com) | a name the account set for itself in its own domain field, not checked by anyone |
| (CULT/XRP pool) and the like | an automated market maker pool: an account no key can sign for |
| (received the whole CULT issue), (received the whole OBEY issue) | an account an issuer sent an issue of its token to, straight from the issuer |
| a long string of capitals and digits | one transaction, which can be looked up directly |
| a destination tag | a number a service gives a customer so it knows whose deposit is whose |
every row: download reading-guide.csv.
What the ledger cannot tell anyone
Table 2. Three things the ledger never records, and what follows from each for everything in this series.
| the limit | what follows |
|---|---|
| It never records who owns an account. | Anyone can pay to bring anyone's account into existence. A signing key can be shared. A destination tag can be passed on. So nothing here says an account belongs to somebody. Accounts are grouped only by the ledger's record of one creating another, and where a person's own words are used they are marked. |
| It never records what a received token cost. | It records that tokens arrived. A payment is therefore not a sale, and any total counting received tokens rests on an assumption. Both ends of every such assumption are shown. |
| Inside a pool, tokens are mixed. | A pool holds one balance of each asset. What goes in joins everybody's, and what comes out is a share of the whole. So a unit's path is followed right up to a pool and starts again when it comes out. Who holds the pool's LP tokens, and what they can take out, is shown instead. |
every row: download ledger-limits.csv.
The span of the record
Table 3. The stretch of the market record: every transaction in the CULT and OBEY markets. The accounts' own full histories, which the account and creation tables use, reach further back.
| first ledger | first transaction | last ledger | last transaction | transactions read |
|---|---|---|---|---|
| 91,895,675 | 2024-11-05 02:34:10 UTC | 107,030,551 | 2026-09-16 18:45:11 UTC | 275,869 |
every row: download span.csv.
Whose histories were read in full
Table 4. Every account with a token balance change in the market record, pool accounts included, by how much of its own history was read.
| status | accounts | what it means |
|---|---|---|
| read in full | 1,877 | every transaction the account ever made was read |
| a pool account | 1,627 | a pool account: everything it did is in the market's own record |
| too large to read in full | 169 | too many transactions to read in full; its dealings in this market are still counted |
| read for a stretch of time | 76 | read for a stretch of time around its dealings in this market |
| automated trader, left out | 32 | an automated trader left out of the study of who is connected to whom; its trades are still counted |
every row: download coverage.csv.
The pool accounts here are every pool a transaction in the market record passed through, pools of other tokens included, which routed payments cross on their way. The market articles list only the pools ever opened with CULT or OBEY.
Table 5. The groups the later articles are about, by how much of each account's history was read.
| group | accounts | read in full | never touched CULT or OBEY | other |
|---|---|---|---|---|
| Pheanor's activation tree | 35 | 22 | 13 | 0 |
| Hodler's activation tree | 8 | 5 | 3 | 0 |
| flow-connected to Pheanor's activation tree | 53 | 53 | 0 | 0 |
| flow-connected to Hodler's activation tree | 10 | 10 | 0 | 0 |
| flow-connected to both activation trees | 17 | 17 | 0 | 0 |
every row: download coverage-by-group.csv.
An account that never touched either token was not read in full. Its creation is on record, and so is every XRP payment between it and an account that was read; its other XRP payments are not.
The rules
Table 6. Where the ledger leaves a choice, the rule this series follows.
| question | the rule |
|---|---|
| Which accounts belong to an activation tree? | An account a named wallet paid to create, and every account those created, down to the last. Nothing else puts an account in an activation tree. Pools an account opened are listed apart: nobody holds a key for a pool. |
| Which accounts are connected to an activation tree beyond it? | Two measures, never added to an activation tree. The CULT and OBEY token flow: payments of the two tokens, LP tokens included and reward payouts left out, followed both ways from the activation tree accounts until nothing new is added, at several flow thresholds. And connection profiles: every account any of five kinds of record connects to the activation trees — token flow, XRP flow, creation, a shared destination tag at an exchange, shared behaviour — scored by how many kinds it has. |
| What is a profit, and at what price? | Counted only in XRP that moved: for every transaction that changed an account's CULT, OBEY or LP tokens, its own XRP balance change in that transaction is XRP paid in or taken out. Nothing along the way is valued at a market price; putting CULT into a pool is not a sale, and tokens received by payment cost no XRP. What is still held, LP tokens included, is valued at each pool's price at the last ledger, and at what selling it into the pools would pay. |
| When an account sends tokens, which ones leave? | The ledger does not say. Figures that trace tokens through transfers use first in, first out — the oldest units leave first — and the connection profiles give last in, first out beside it, so a figure that rests on the rule shows both ends. |
| What is a purchase or a sale? | An account's own CULT balance going up or down in a swap, an offer or a filled standing offer, counted net within each transaction. |
| What did tokens received by payment cost? | The ledger does not say. Results are given both ways: at the market price of the hour they arrived, and at nothing. |
| Who owns an account? | The ledger never records it. The series states it only where a holder publicly names a wallet as his own: Pheanor's four named wallets and Hodler's one. Every other name is the name a wallet goes by, and every other connection is a record, not an owner. |
every row: download rules.csv.
← Previous: The data
Next: CULT and OBEY, from issue to now →