How We Inscribed 1,500 Ordinals on Bitcoin: A Developer's Honest Account

There's a version of this story that sounds clean: we built a 1,500-piece Bitcoin Ordinals collection, piece #1 sold at Sotheby's for $139,700, and the collection became a blue-chip. That's true. It's also incomplete.

The version worth telling is messier — about inscribing on a blockchain with no rollback, tooling that was weeks old, and a deployment process where a single malformed transaction could corrupt the entire collection permanently. That's the version that's actually useful to other developers.

I was a Bitcoin developer on the Pizza Ninjas team. Here's what actually happened.

What Ordinals Actually Are

Skip the marketing. From a developer's perspective, Ordinals is a numbering scheme for satoshis — the smallest unit of Bitcoin (0.00000001 BTC). Casey Rodarmor's protocol, released in January 2023, assigns an ordinal number to every satoshi ever mined, in the order they were created. The numbering is deterministic: first satoshi of the first block is ordinal 0, and so on.

That's it. That's the core primitive.

The interesting part is what you can do with that numbering. Because satoshis can be tracked through the UTXO model, you can "own" a specific satoshi by controlling the UTXO it lives in. And since Bitcoin's Taproot upgrade (November 2021) allowed witness data to be much larger, you can attach arbitrary data — images, HTML, JavaScript, SVG — to a satoshi when you spend it. That attachment is called an inscription.

An inscription is not a smart contract. There's no on-chain logic, no bytecode, no execution. It's data committed to the Bitcoin blockchain via the witness field of a Taproot transaction. The ord protocol defines a convention for encoding that data, and ord-compatible indexers know how to read it back out.

This distinction matters. When people say "Bitcoin NFTs," they're often importing mental models from Ethereum that don't apply. There's no ERC-721.ownerOf() call. Ownership is the Bitcoin UTXO model — you own the satoshi, you own the inscription. No smart contract manages a mapping. The blockchain itself is the source of truth, and the ord indexer is how you read it.

The upside: it's as permanent as Bitcoin. The downside: it's as immutable as Bitcoin.

The Project — Pizza Ninjas

Pizza Ninjas is a 1,500-piece PFP (profile picture) collection inscribed on Bitcoin in January 2024. The art was generative — algorithmically assembled from layered traits — designed by Boozy, the project's artist. The theme was deliberately irreverent: ninja characters with a pizza aesthetic, leaning hard into Bitcoin culture.

Every piece was inscribed as a recursive inscription — more on that below. The collection launched during peak Ordinals mania, which meant mempool congestion, fee spikes, and a deployment window where timing mattered.

Piece #1, "The Angel," sold at Sotheby's for $139,700. That number still surprises me when I say it out loud. At the time of inscription, it was a JPEG-equivalent of data on a blockchain. The auction result was a signal that the institutional market was watching Bitcoin NFTs seriously — not as a crypto experiment but as collectible digital art with provenance on the most secure chain in existence.

The Tooling Landscape in January 2024

This is where I want to be genuinely honest, because the Ordinals developer tooling in January 2024 was young. Not bad — but young.

The primary tool was ord, Casey Rodarmor's reference implementation written in Rust. It ran a full Bitcoin node internally (or pointed at one), maintained its own index of inscriptions, and exposed a CLI for inscribing and a basic web UI for browsing. The core ord binary handled everything: indexing, wallet management, transaction construction, and broadcast.

What it did not have: robust batch inscription tooling, clean error handling for fee estimation failures, or much documentation beyond the README and the source code itself. For a single inscription, ord wallet inscribe worked fine. For 1,500 coordinated inscriptions with recursive dependencies, you were writing your own orchestration layer on top.

The alternative tools at the time included:

• Ordinalsbot and similar services: Abstracted away the full node requirement but gave you less control over transaction construction and fee management.
• Custom ord forks: Several teams had forked ord and added batch tooling. Community quality varied.
• Direct PSBT construction: For teams who wanted full control, constructing Partially Signed Bitcoin Transactions manually and signing them via an external wallet. Extremely flexible, extremely tedious.

We used a combination — ord as the core indexing and broadcasting layer, custom scripting for orchestration, and manual validation steps at each phase before moving forward.

In 2026, the tooling picture is considerably better. Tools like ord itself have matured, dedicated inscription services have production-grade APIs, and there are now higher-level SDKs that abstract batch operations cleanly. The core principles are the same, but the rough edges have been filed down. If you're inscribing today, you have significantly better scaffolding than we did.

Recursive Inscriptions and Why They Matter

Standard inscriptions are self-contained blobs of data. A 50KB image gets inscribed as-is. For a 1,500-piece generative collection, that approach is wasteful and architecturally clumsy: you'd be duplicating shared trait layers across every piece.

Recursive inscriptions change this. They let an inscription reference other inscriptions by their ID. An HTML or JavaScript inscription can fetch and render another inscription at runtime using a special URL pattern: /content/<inscription_id>.

For a generative PFP collection, this is the right architecture:

1. Inscribe all the base trait layers once — bodies, heads, accessories, backgrounds.
2. Inscribe a renderer — the JavaScript or HTML that knows how to composite layers.
3. Inscribe each piece as a small JSON or parameter file that references which traits to use.
4. Each piece's inscription calls the renderer, which fetches the trait inscriptions and composites the final image.

The result: the actual per-piece inscription data is tiny. The heavy assets live on-chain once and are reused across the entire collection. This reduces inscription fees substantially and creates a cleaner separation between the art assets and the collection logic.

For Pizza Ninjas, this meant Boozy's trait layers were inscribed as the foundational layer, and each of the 1,500 pieces referenced those layers via the recursive mechanism. The collection had genuine on-chain provenance for every component — not just the final rendered output but the underlying generative system itself.

Coordinating Art, Metadata, and Deployment

The coordination between generative art, metadata, and on-chain deployment is where most of the real complexity lived. In a typical EVM collection, you deploy a contract, set a base URI, and the metadata lives off-chain (usually IPFS). The contract just references it. You can update the URI if something goes wrong.

On Bitcoin, there is no update. What you inscribe is what exists.

This forced a level of rigor that I honestly think is healthy but that felt brutal in the moment. The pipeline looked like this:

Phase 1 — Art generation. Boozy's generative system produced all 1,500 pieces with full trait metadata. Each piece had a deterministic set of layers. This output had to be final before anything touched the chain.

Phase 2 — Trait verification. We validated the full output set: uniqueness checks, rarity distribution checks, visual spot-checks of composited outputs, metadata consistency validation. Every anomaly got resolved before proceeding.

Phase 3 — Parent inscription. We inscribed the collection's parent inscription first — effectively the root of the collection hierarchy that all child inscriptions would reference. The parent inscription ID becomes part of the collection's permanent identity.

Phase 4 — Trait layer inscription. The shared trait assets went on-chain. Each inscription ID was captured and mapped to its logical name in our configuration. These IDs would be referenced by the per-piece inscriptions.

Phase 5 — Piece-by-piece inscription. The 1,500 pieces inscribed in batches, with the recursive references populated from Phase 4's captured IDs. Each batch was verified before the next started.

At each phase transition, we stopped and validated. Nothing automated a phase boundary. This was deliberate. A bad trait inscription in Phase 4 would corrupt every piece that referenced it in Phase 5. There was no patch path.

What Went Wrong

Some things.

Fee estimation was unreliable during high-congestion periods. The mempool was volatile in January 2024 — Ordinals activity was spiking, and mempool depth shifted fast. We had transactions stall in the mempool longer than expected, which meant some inscription batches confirmed out of the expected order. The collection still inscribed correctly, but the inscription IDs didn't have the clean sequential numbering we'd hoped for.

One of the trait inscriptions had a subtle encoding issue that only showed up in a specific browser environment. The asset rendered correctly in the ord web UI and in Chromium-based browsers but produced a slight color shift in Safari. This was a pure frontend issue with how Safari handled a specific SVG attribute — nothing to do with the inscription itself — but it was stressful to diagnose against the backdrop of "this is permanent."

The orchestration scripts had an edge case around fee bumping via Child Pays For Parent (CPFP) when a parent transaction stalled. Handling CPFP correctly in a recursive inscription context — where the parent inscription ID needs to be known before child inscriptions are constructed — required careful ordering. We worked through it, but it wasn't something the tooling handled gracefully out of the box.

None of these were catastrophic. But each required diagnosis and resolution under pressure, on a blockchain where the cost of an error isn't a failed transaction you retry — it's a permanent artifact in the collection.

Bitcoin vs ETH and Solana

After building on Ethereum and Solana projects and then doing a deep dive on Bitcoin, the differences are more fundamental than most people appreciate.

The execution model is gone. On Ethereum, smart contracts are the product. You write logic that lives on-chain and executes deterministically. On Bitcoin, there is no logic. Data lives on-chain. Logic lives off-chain (in indexers, in applications). This sounds like a limitation, and in some ways it is. But it also means there's no attack surface for exploitable contract logic. Pizza Ninjas cannot be drained by a reentrancy bug.

The tooling maturity gap is real. Ethereum has a decade of Hardhat, Foundry, OpenZeppelin, and Etherscan. Solana has Anchor and a maturing ecosystem. Bitcoin Ordinals tooling in 2024 was where Ethereum was around 2017. You were frequently reading source code because the docs didn't cover your case.

Permanence changes your relationship to the work. On EVM chains, you develop a certain casualness — test on testnet, deploy to mainnet, upgrade proxy if needed, patch the logic, iterate. Bitcoin doesn't give you that. Once it's inscribed, it exists as inscribed. That raises the stakes of every decision in a way that enforces discipline. I found this clarifying more than frustrating.

Fee markets behave differently. Bitcoin's fee market is based on block space denominated in virtual bytes. Inscription sizes directly translate to fees in a way that EVM gas costs don't map to cleanly. You spend a lot more time thinking about the byte count of your inscriptions than you spend thinking about EVM opcode costs.

The audience is different. Bitcoin holders are, on average, less likely to be degenerate apes flipping for a quick exit and more likely to be long-term conviction holders. This shapes the culture of what you're building for. Pizza Ninjas didn't need to design for someone flipping in a week — it needed to be something worth holding for years.

What I Learned

A few things that actually matter:

Verify everything before it touches mainnet. Not "mostly confident" — verified. The absence of rollback on Bitcoin concentrates your quality work into the pre-inscription phase in a healthy way.

Understand the UTXO model deeply before you start. If you're coming from an account-based chain, the UTXO mental model requires real recalibration. Ownership of an inscription is ownership of the satoshi. Sending a UTXO without understanding what's in it is how inscriptions get burned accidentally. This happened to people in 2023 and 2024.

Recursive inscriptions are worth the complexity. The on-chain asset architecture they enable is genuinely better for generative collections — both economically and structurally.

The permanence is a feature. Sotheby's didn't auction a JPEG. They auctioned a data artifact that is provably inscribed on the most secure blockchain in existence, with a clear chain of custody traceable back to the original satoshi. That provenance is structural, not asserted. It doesn't depend on a company's servers staying up or a smart contract staying uncompromised.

The Pizza Pets project that came after — the first fully on-chain pet game on Bitcoin, with over a million feeding interactions in Season 1 — pushed the recursive inscription architecture further, with game state encoded on-chain and seasonal logic operating through the same primitives. The foundation we built with Pizza Ninjas made that possible.

If you're building on Bitcoin Ordinals — whether a collection, an on-chain game, or something else — and you want a technical advisor who has been through a mainnet launch on this stack, I consult on exactly this.

The full story — outcomes, stack choices, and what the Sotheby's result actually meant — is in the Pizza Ninjas case study →

Web3 consulting →