Cohort ended · self-paced
beginner 35 min

Accessing & Working with Public On-Chain Data

Pull real XRP Ledger data yourself: the public servers and explorer APIs, the four methods you need, how to page through history without getting rate limited, and four Python exercises that end with a payments dataset and a value-flow graph ready for modelling.

Prerequisites

Complete these before starting this module:

What you'll learn

  • Choose a public Mainnet server or explorer API and explain the trade-offs between them.
  • Fetch a full ledger and an account's history with xrpl-py, paging correctly with markers.
  • Download data responsibly: pinned ranges, caching, and back-off when a server is busy.
  • Normalise raw transactions into a table using delivered_amount and TransactionResult.
  • Build a directed, weighted value-flow graph and read basic fan-in, fan-out and pass-through statistics from it.
Complete this module by a quiz and self-assessment. Jump to assessment

Overview

At the hackathon you'll pull the data yourself. There is no dataset handed to you, and that's the point: the XRP Ledger's entire history is public, and anyone can read it for free. This module shows you where to read it from, how to download it without getting rate limited, and how to turn raw transactions into a table and a graph you can feed to a model.

This is the hands-on module. In the live session you'll run two short Python scripts against Mainnet (the real ledger, read-only, no wallet or XRP needed), Exercises 1 and 3, and finish with a CSV of payments and a value-flow graph. Exercise 2 is optional: do it after the session, it's the one you'll need for tracing on the day.

What you need

  • Python 3.10 or later, locally or in Google Colab (prefix the install line with !).
  • The official Python library, xrpl-py, plus the usual data stack:
pip install xrpl-py==5.2.0 pandas networkx scikit-learn

Prefer JavaScript? The same methods exist in xrpl.js (npm install xrpl), and every request below has the same name and fields there. The examples here use Python because most data and ML teams will.

Reading the ledger needs no account, no seed and no XRP. Never paste a secret key into a notebook for this hackathon: you don't need one.

Where the data lives

You talk to the ledger through servers, over JSON-RPC (HTTP) or WebSocket. Several operators run free public servers:

Network Server JSON-RPC URL Notes
Mainnet Ripple, full history https://s2.ripple.com:51234/ Every ledger since the beginning
Mainnet Ripple, general https://s1.ripple.com:51234/ Recent history only
Mainnet InFTF, full history https://xrplcluster.com/ Enforces a per-minute usage quota
Testnet Ripple https://s.altnet.rippletest.net:51234/ Test network, not real activity

Use Mainnet. Testnet is for building apps; it has no real-world behaviour to detect.

Indexed explorer APIs sit on top of the raw ledger and add convenience, most usefully labels:

  • XRPScan API (https://api.xrpscan.com/api/v1): account transactions, account info, and a list of well-known account names (exchanges, issuers, services) at /names/well-known. The free tier has a daily request limit.
  • Bithomp API: rich account data and usernames; needs a free API key.

Labels are off-ledger attribution made by the explorer. They're extremely useful for features ("sent to a known exchange") but treat them as evidence, not truth.

The four methods you'll use

Method Question it answers Paging
ledger (with transactions and expand) Everything that happened in ledger N One call per ledger
account_tx Everything that touched account X Uses a marker
account_info Balance, flags and sequence of account X right now None
account_lines Which tokens account X holds Uses a marker

Two download strategies follow from this:

  • Ledger sweep: fetch every ledger in a range and keep all payments. Best for building a network-wide graph of a time window.
  • Account crawl: start from a seed account and follow account_tx outward, hop by hop. Best for tracing where specific funds went.

Be a good citizen: rate limits

Public servers are shared by everyone, including every other team in the room on the same Wi-Fi. They protect themselves with quotas: when you exceed them, the server answers with a tooBusy or slowDown error instead of data. Deep history scans are expensive, so a single careless loop can lock your team out for minutes.

  • Pin your range to fixed ledger numbers instead of "all history". It's cheaper and it makes your dataset reproducible.
  • Cache everything to disk (CSV or Parquet) and build your model from the cache, never from live calls.
  • Back off and retry when the server says it's busy. Every script below does this.
  • Spread the load: different team members can use different servers.
  • Start small (20 ledgers), check the output, then scale up.

Exercise 1: snapshot one ledger

Fetch the latest validated ledger with every transaction expanded and count what's inside.

You should see a few hundred transactions, mostly Payment and OfferCreate, and a handful of tec failures. Notice that the current reserves come straight from the server: never hard-code them.

Exercise 2 (optional, after the session): download an account's history

Page through account_tx for one account and normalise each transaction into a row. The two lines that matter most are reading delivered_amount (not Amount) and pinning the ledger range.

How pagination works: when a response contains a marker, there's more. Send the exact same query again with that marker, and stop when no marker comes back. Markers expire after a few minutes, so don't save them for later.

Exercise 3: build a value-flow graph

Sweep a range of ledgers, keep the successful XRP payments, and build a directed, weighted graph where each node is an account and each edge is the total XRP sent from one account to another.

Look at the output. You'll almost certainly see one or two accounts sending hundreds of payments worth a fraction of a cent: that's dust spam, not laundering. You'll also see accounts that forward almost exactly what they received. Hold on to that observation; it's the starting point of the next module.

Going further

Once the basics work, the same toolkit scales to a real hackathon dataset:

  • Tokens, not just XRP: extend xrp_delivered to keep issued-token amounts, keyed by currency.issuer. Stablecoin flows are where a lot of real-world value moves.
  • Account enrichment: for each account in your graph, call account_info (balance, flags such as RequireDest) and look up the XRPScan well-known name.
  • Funding parents: the first transaction in an account's history (account_tx with forward=True, limit=1) is usually the Payment that created it.
  • WebSocket streams: subscribe to the transactions stream to watch the ledger live, useful for a demo.
  • BigQuery: a community-maintained public BigQuery table of XRPL history exists (see the resources), which can save hours of downloading. Check that it covers your window before you rely on it.

Check

You're done when you have xrp_payments.csv and a graph built from it, you can explain what a marker does, and you know why your team should cache data instead of calling the server inside a training loop. Submit the hash of one transaction from your dataset.

Assignments

0 of 4 complete

Unlocks

Finishing this module opens up: