How We Exported 18,178,808 Pi Network Accounts Without Running a Full Node

18,178,808 addresses. One frozen ledger. Zero full nodes.

We needed to create a one-time snapshot of every public Pi Network Mainnet account with a positive native balance.

The requirements sounded simple:

• Include only live accounts
• Keep every address from the same blockchain state
• Exclude duplicates and deleted records
• Preserve exact balances
• Make the result independently verifiable

It quickly became clear that this was not just another API export.

Why the obvious approaches failed

Horizon and RPC can return information about a known account, but they cannot enumerate the complete account state by key.

Running a full Pi node was technically possible, but it would have required a large stellar-core, Horizon and PostgreSQL stack, hundreds of gigabytes of storage, and a lengthy synchronization process.

That was excessive for a one-time snapshot.

The standard Stellar SDK ingestion path also failed. Pi Network’s History Archive did not expose the per-checkpoint History Archive State files expected by the default reader. The first request returned HTTP 403.

The archive was accessible. The data existed. But the standard reader could not consume its publication layout.

The solution we built

Instead of deploying heavier infrastructure, we created a focused Go pipeline that reads the live BucketList directly from Pi Network’s public History Archive.

The pipeline:

1. Reads the root History Archive State once and freezes the checkpoint for the entire run.
2. Uses only currentBuckets, excluding hot-archive buckets containing historical or deleted data.
3. Downloads and verifies every bucket against its content-addressed SHA-256 hash.
4. Processes records from newest to oldest.
5. Resolves CAP-20 tombstones so deleted accounts suppress older live versions.
6. Selects account entries with a native balance greater than zero.
7. Converts every account key into its public G... address.
8. Writes the final dataset using an external merge sort.

That final step became important.

Our first implementation accumulated the results in memory before sorting them. At roughly 18 million records, the container was terminated with exit code 137.

We replaced the in-memory sort with a chunked external merge:

• Sort one million records at a time
• Write temporary runs to disk
• Merge them through a min-heap
• Deduplicate across chunk boundaries
• Stream directly into the final files

Memory usage dropped to approximately 200 MB.

The result

For checkpoint 28,087,871, verified on August 7, 2026, the pipeline produced:

• 18,178,808 accounts with a positive native balance
• 19,387,210 total live account records examined
• 1,208,402 outdated or suppressed records
• 21 of 21 buckets verified by SHA-256
• 0 duplicates in the final output
• 8 minutes 26 seconds processing time with cached buckets
• A 1.04 GB address file
• A 1.20 GB address-and-balance file

The number itself was not the most important result.

The important part was being able to prove where every row came from.

Alongside the dataset, the pipeline creates metadata containing:

• The exact checkpoint
• The BucketList hash
• Every source bucket hash
• Processing counters
• Integrity status
• Complete data provenance

The same snapshot can be reproduced with a single Docker command.

What we learned

Protocol compatibility does not always mean tooling compatibility.

A network may use the same underlying data model while publishing its archive in a way the standard reader does not expect.

We also learned that the heaviest solution is not automatically the safest one. For a targeted export, a small deterministic reader can be easier to audit and reproduce than an entire synchronized node stack.

Finally, blockchain statistics require timestamps and checkpoints.

18,178,808 is not a claim about the current number of Pi Network users or wallets. It is the number of qualifying public account records found in one specific verified blockchain state.

That distinction matters.

Would you have deployed a full node for this task, or built a purpose-specific archive reader?

Full technical case study:
https://wemaide.com/work/pi-blockchain

Built by WeMAIde. We are not affiliated with or endorsed by Pi Network.