Development of Ordinals inscriptions and NFT collections on Bitcoin

Ordinals development: where indexing breaks under load

An inscription lives in two states, and the whole trap lies between them. A transaction is already visible in the mempool, but its number, owner, and position within the collection are fixed only after inclusion in a block.

In Bitcoin, the order is set not by our service but by consensus: during a chain reorg, some already displayed records change their number, and a storefront reading the network "directly" begins to diverge from the actual state.

Peak network load hits exactly at this moment.

The mempool is clogged, transactions with the same fee replace each other, some reveal transactions do not make it into a block — and the collection mint hangs in the middle: half of the tokens are indexed, half hang unconfirmed, numbering "floats." Inscription indexing built on "polling once a minute" at such a moment lags behind the chain tip by hundreds of blocks.

Then the domino effect kicks in. Storefront desynchronization means the buyer sees a lot that does not exist yet, or does not see one already minted; support receives a stream of requests, and marketing, having paid for an announcement, drives traffic to an empty page.

A stuck collection mint does not roll back on its own — resubmission breeds duplicates and breaks numbering for good.

All this is cured not by "server power" but by the design of the indexer: idempotent writes, checkpoints, a buffer between the network and the storefront, separate handling of chain reorgs. Let's break down how this is closed.

What a custom indexing and metadata layer provides

Standard explorers deliver data on their own schedule and know nothing about your metadata model. A custom indexer reads Bitcoin blocks and stores them in a database in the form needed by the collection storefront: owner, rarity, transfer history, mint request status.

Storefront response speed

The storefront reads prepared views instead of recalculating owners on every request.

Request caching with pinpoint invalidation by block number keeps catalog output in tenths of a second for tens of thousands of inscriptions — instead of seconds of waiting when querying an external source.

Share of desynchronizations

The indexer compares its own height with the network and logs every discrepancy. Strict processing order and a confirmation threshold reduce the share of desynchronizations to isolated cases per month instead of daily manual reconciliations.

Eliminated failure class during re-indexing

Re-indexing goes into a separate schema and is switched over by a single operation after checksum verification. An interrupted process no longer leaves the storefront in a half-disassembled state: the old output continues to work until the new one converges.

Predictability of minting at peaks

At peak minting, requests come in hundreds per minute. A queue and concurrency limit prevent the storefront from falling over — minting time remains even, and a failure of one stage does not drag down the rest.

Approaches to Ordinals development: comparison of minting modes

The minting mode determines three things: who holds the keys during the sale stage, where the collection metadata lives, and how the network fee is distributed under peak load. Below are four schemes that are actually chosen between.

Where the boundary is between a custom storefront and a hybrid

A custom storefront is justified when there are owner roles and access based on ownership: then the storefront becomes the entry point to the product.

A hybrid is cheaper to develop but requires synchronization — a sale on the marketplace must immediately reflect on your own frontend, otherwise there is double listing and disputed lots.

When batch minting is mandatory

Batch mode is needed as soon as there are more than a few dozen units. It relies on queue management and transaction reassembly when fees spike: otherwise part of the mint gets stuck unconfirmed, and the collection numbering breaks.

Implementation stages: from schema audit to handover

The work order is the same for a collection of several hundred inscriptions and for a mass-mint series — only the depth of checks changes.

We run the scheme so that each stage closes with a measurable result, not a "done" status: otherwise the divergence between what the holder sees and what is recorded on-chain surfaces after the mint, when fixing is expensive.

1. Collection schema audit. We analyze numbering rules, rarity distribution, and relationships between objects and metadata. The output is a schema map and a list of places where it will not withstand scaling.
2. Mint and metadata design. We fix the metadata format, write order, and reveal logic. Here we also describe behavior on re-mint and the rollback scenario.
3. Node and indexing setup. We bring up the node and configure indexing so that the storefront delivers the current state without manual edits. We check index recovery from scratch and behavior during chain reorgs.
4. Test batch. We mint a limited set on the real network and compare against the design: numbering, metadata, display for the holder. We fix discrepancies in the schema, not on the live collection.
5. Storefront load testing. We run mass requests to the index and collection page delivery, measure response time and degradation points.
6. Handover and training. We hand over accesses, configurations, and the mint regulation, and go through typical operations and emergency scenarios with your team.

Readiness criteria: data and minting

The stage is closed when the test batch matches the design in numbering and metadata, and the index recovers without manual edits in a predictable time. Separately, we verify that the holder sees exactly the object recorded on-chain.

Readiness criteria: storefront and handover

Here the criterion is stable response time under load and a reproducible mint regulation. Handover is complete when your team conducts a trial mint independently, without our support.

Deliverables: configurations, schemas, and regulations

The project ends not with a demonstration of a finished collection, but with a package your team can work with without us.

We hand over not only code but also configurations, schemas, and regulations — so that minting the next series does not turn into negotiations with a contractor.

• Node and indexer configurations: which parameters affect recalculation depth and rebuild time, how to bring up the environment from scratch.
• Collection metadata schema: fields, numbering rules, link between the record and inscription content.
• Access and key policies: roles, signature thresholds, rotation and revocation procedure.
• Mint regulation: sequence of inscribing, checks before publication, rollback points.
• Documentation: architecture, external integrations, incident analysis.
• Recovery plan: from which data the node is brought up, how the index is rebuilt, and in what time.

What the configurations reveal

We hand over node and indexer configurations with comments: which parameter is responsible for recalculation depth, what changes as the collection grows, where the bottleneck is.

Alongside is the metadata schema, according to which a new mint is assembled without renegotiating the structure.

What the regulations reveal

The mint regulation describes roles and signature thresholds, the order of checks before inscribing, and rollback points. The recovery plan answers the question of how long it takes to bring up the node and rebuild the index from backups.

Case study: a collection of 10,000 inscriptions — metrics before and after

Before the rework, minting a collection of 10,000 inscriptions went in a single stream: the transaction was written to the database, and the storefront read status directly from the network node.

At peak, storefront response went to 4–6 seconds, and discrepancies between the chain and the database surfaced in 7% of mints — each was investigated manually using logs.

We separated writes and reads: the mint transaction goes into a queue and is considered confirmed only after inclusion in a block, while the storefront works with its own Ordinals index and a metadata cache.

Processing of each block is idempotent and tied to height, so a repeated pass after a reorg does not create duplicates, and the index converges to the required height without a full rebuild.

What measurements were taken and how

We measured four values. Storefront response time — at the ninety-fifth percentile under load close to peak minting. Share of desynchronizations — by comparing control addresses of the index with node data after each block.

Recovery time — by intentionally stopping the indexer at different heights. Share of mints without manual intervention — from the operations log.

After the rework, storefront response stays within one second instead of four–six, the share of desynchronizations dropped to 0.4%, the index comes up in a couple of minutes instead of forty, and 98% of mints proceed without manual intervention. The peak collection mint was handled without stopping the storefront.

How does an inscription differ from a BRC-20 standard token?

An inscription is data written directly into the blockchain and tied to a specific minimal unit of the coin: the instance exists in a single copy and is non-fungible.

A BRC-20 standard token is designed as a layer on top of inscriptions: ticker registration, minting, and transfer are formalized as text records of a fixed format, and balances are stored not in the blockchain but in an index built by third-party explorers.

Hence the main practical difference is fungibility. BRC-20 units are equal to each other and can be divided and transferred in parts.

An inscription is a single object with its own identifier: it cannot be exchanged "one-to-one" without losing the value of the specific instance.

The standard's limitations also affect the choice: there is no built-in logic in it, only basic operations are available, and balance calculation depends on indexing rules — different explorers may show different balances.

Therefore we determine the mint format before work starts: whether fungibility and circulation on marketplaces are needed, or unique instances with their own metadata.

Technical doubts we address before work starts

The minting order on Bitcoin leaves almost no room for error: an inscription is written to the block forever, it cannot be quietly rewritten, and a metadata error is visible to all holders. Below are doubts we address before the start so as not to address them after a public sale.

Can the metadata schema be changed after minting?

Before the first public mint — yes, after — only with a new mint. When editing, we maintain backward compatibility: old fields remain readable, new ones are added as separate keys, otherwise some marketplaces will stop showing attributes.

What about minting order if many requests come in at once?

The network does not guarantee transaction order within a block, so "first come, first served" distribution creates races and disputed numbers. We fix the pair "request — satoshi number" in advance and issue it after confirmation.

How to move a collection to another marketplace?

Metadata and content are in the record itself; the marketplace is just a storefront. The move comes down to re-indexing on the new storefront's side: it is important that media links do not depend on a single domain.

How do you verify correctness before a public sale?

A run on the test network: display on indexers, number matching, correctness of metadata and royalties. Only after that do we open the sale.

Let's discuss the task: what data is needed for an estimate and plan

To come back with an estimate and plan, and not general formulations, we need a set of input data for the project.

The more precisely the idea is described, the fewer assumptions in the schedule and architecture — and the fewer reworks at the stage when data is already recorded on-chain and cannot be changed.

• Collection type and volume: how many unique records, what exactly is inscribed — images, text, audio, or software artifacts, whether recursive assembly from multiple parts is needed, whether ready-made source files exist.
• Metadata model: where attributes live — inside the record, in an external index, or hybrid; whether you plan to update descriptions and ratings without re-recording to the main network.
• Storefront requirements: whether display in third-party explorers is enough or a custom interface is needed with search, filters, ownership history, and secondary circulation.
• Expected load: how many index requests occur at peak minting, whether a cache is needed, and how quickly the storefront must serve a card during a spike.
• Launch timeline: whether there is a fixed opening date, how much time is allocated for verification before the public announcement, and how much the schedule depends on network load.
• Accesses and infrastructure: where we host nodes and the index, who holds the keys, what information security and role separation requirements apply at your organization.
• Post-launch support: whether transaction progress monitoring, resubmission under network congestion, and secondary circulation support after launch are needed.

Describe the task to the extent you have it: the collection type and load requirements set the order of timelines, the metadata model determines the architecture, and the launch date determines the sequence of work.

We will come back with an estimate and plan: stages, team composition, your decision points, and a post-launch support option.