Permanent archive · Bitcoin · 2024
Project Spartacus
I worked on the Bitcoin inscription pipeline that mapped 76,911 Afghan War Diary records into a verifiable archive that could resume safely across many blocks.
- Product
- A Bitcoin archive pipeline for all 76,911 Afghan War Diary records.
- Delivery scope
- Canonical manifests, hashing, many-block batching, funding, broadcast states, confirmation, reconciliation, and recovery.
- Public evidence
- 2public sources
Project constraints
- 0176,911 individually accountable records
- 02Changing fees across many blocks
- 03Partial completion without duplication
Portfolio context
The technology and delivery problem behind this work.
Use these signals to compare this case study with the closest relevant work.
The challenge
Preserve 76,911 public records without losing a file, breaking sequence, or confusing broadcast state with confirmed archival state.
At this scale, permanence depends on operations as much as protocol choice. Tens of thousands of files had to be normalized, identified, hashed, batched, funded, broadcast, confirmed, and reconciled across changing fee conditions. The system needed to prove exactly which records had reached Bitcoin and recover cleanly when only part of a batch completed.
Architecture and decisions
Canonical archive manifest
Every source record was tied to a stable identifier, content hash, order, destination, and processing status so the archive could be audited against one canonical inventory.
Multi-block batch planning
The archive was divided into controllable units that could move through many Bitcoin blocks and fee windows without turning the entire 76,911-file run into one fragile job.
Explicit execution states
Prepared, signed, broadcast, confirmed, and failed were treated as different states. That distinction prevented a transaction in the mempool from being mistaken for a permanently archived record.
Reconciliation and recovery
Hashes, transaction references, and confirmations could be checked back against the manifest, allowing incomplete batches to resume without duplicating records already settled on-chain.
My role
-
01
Worked on the inscription pipeline built to move the complete 76,911-file archive across many Bitcoin blocks.
-
02
Implemented a manifest-first operating model for ordering, content hashes, transaction references, confirmations, and recovery state.
-
03
Designed batching around mempool conditions and fee windows rather than committing the archive to one fixed-cost assumption.
-
04
Made partial completion recoverable so operators could identify confirmed records and resume outstanding work without starting over.
What changed
A recoverable Bitcoin archive built for all 76,911 public records.
The work turned a 76,911-record public dataset into an archive that could move safely across many Bitcoin blocks. Project Spartacus and OrdinalsBot could launch the complete Afghan War Diary scope with a process built for changing fees and incomplete batches, showing that Ordinals infrastructure could preserve public-interest records as well as collectibles.
- The pipeline made the complete 76,911-record archive addressable as verifiable units instead of one opaque bulk job.
- Independent coverage documented the many-block plan and public support from Gabriel Shipton.
- The project applied Bitcoin infrastructure to a censorship-resistant public archive rather than another collectible launch.
Tools and technologies
Sources
Relevant services
Start from the service closest to this work.
These services match the decisions, delivery, or evidence shown in this case study.