Initial PCT Wallet Tracking Experiment
The project began as a simple balance-checking tool for the 10,001 known PCT wallets. The goal was to track balances, detect movement, and make it easier to see where Pi was flowing without manually checking explorers.
- Python balance crawler created.
- CSV snapshots generated from laptop scans.
- Initial files included wallets_previous.csv and wallets_latest.csv.
- Early scan missed around 8 wallets, then fixes were added.
- Ideas already included Bubblemaps-style views and Track-and-Trace style tools.
First Balance Anomalies and DB Planning
A later scan detected 19 changed wallets with a combined net movement of only 0.0000010 PI. This triggered the first deep investigation into stroop-level drift, rounding behavior, and unexplained balance changes.
- CSV compare logic became the first change detector.
- MySQL storage was planned to replace CSV-only tracking.
- Cron-based monitoring was introduced.
- Hidden out-of-view database config was added for safer credentials.
First Live Feed Goes Online
The first live monitoring page was launched. It used cron scans to check batches of wallets and display confirmed balance changes.
- 100 wallets scanned every 10 minutes.
- Live balance change ticker added.
- Cron log viewer created for debugging.
- Debug links added to live and change pages.
Stroop Drift Investigation
Tiny balance differences were investigated using custom test pages and generated reports. The purpose was to determine whether the changes were real ledger movements, older transaction effects, or rounding artifacts.
- Single-wallet debug pages were created.
- Generated reports documented suspected anomalies.
- Later scans showed the tiny drift was most likely rounding-related.
- Genuine transfer detection continued to work correctly.
Public Node Speed Breakthrough
The scanner was upgraded to use public Pi Horizon/API nodes. This changed the project completely because full scans no longer needed to wait on the slower original route.
- Public nodes were tested for latency, freshness, and reliability.
- Working node lists and stability reports were generated.
- Scan time dropped from 14+ hours to around 5 minutes.
- Throughput reached roughly 40 wallets per second.
New scan time: around 5 minutes
VPS Infrastructure Created
Shared hosting could not directly use the public node ports, so a cheap VPS was added. This became the scanning engine and API layer for the project.
- Python crawlers moved onto the VPS.
- JSON snapshots were generated server-side.
- The shared host imported VPS output into MySQL.
- The system became a VPS-to-database-to-dashboard pipeline.
`pctlive.php` Replaces the Early Live Page
The original live page was replaced with a cleaner PCT-specific live movement feed. Old links were redirected so existing links still worked.
- Cleaner live feed layout.
- VPS-fed data pipeline.
- Confirmed balance changes only.
- Old live.php links redirected to pctlive.php.
Historical Operation Backfill Begins
The project moved beyond balance checking. A historical crawler began reading wallet operations from creation through recent activity.
- Operations crawled for all 10,001 wallets.
- In/out movement stored with timestamps.
- External movement could now be grouped by day, week, month, and year.
- Laptop handled heavy backfill while VPS handled ongoing updates.
Reliability Engineering
Public nodes were fast, but not always correct. Some returned stale or inconsistent data, so the architecture was changed to treat fast scans as discovery only.
This is also where one of the clearest similarities appeared. The engineering thought process behind this verification model was publicly documented during development, making it difficult to explain why the same wording and workflow later appeared elsewhere.
The idea was simple: public nodes were fast enough to scan all 10,001 wallets, but not trusted as the final source of truth. The VPS would detect candidate changes quickly, then Horizon would confirm them before the database updated.
This became the key trust model of the system: speed from public nodes, truth from confirmation.
Exchange Flow Forensics
The tool began exposing structured movement patterns from PCT wallets into intermediate wallets and then toward muxed exchange deposit addresses.
- Repeated transaction chunks detected.
- Relay wallets identified.
- Direct muxed exchange sends discovered.
- OKX and Gate-style destinations investigated.
- 1 PI test-send behavior observed in some flows.
Financial Value Layer Added
Historical Pi prices were mapped against movement dates so outflows could be estimated in USD at the time they happened.
- Daily movement totals matched to daily prices.
- Launch-period exchange sends valued.
- Direct muxed exchange sends became easy to summarize.
- The history page became useful for reports and public explanations.
Interactive Investigation Tools Added
The dashboard became a working forensic tool rather than a static stats page.
- Clickable wallets.
- Operation drilldowns.
- Wallet grouping under historical totals.
- Explorer links.
- Relay and mux tracing experiments.
- Early multi-hop tracing logic.
Move From subdomain to Dedicated PCT Tooling
The early experimental pages lived under subdomain.crumbs As the PCT monitoring module matured, the work was reorganized into dedicated Crumbs/PCT tooling.
Dedicated module: pct.crumbs.host
- subdomain.crumbs acted as the original build and test area.
- PCT pages became their own dedicated module by request.
- The wider Crumbs site kept the same practical investigation-first design.
