Why a BRC-20 token loses data during indexing
BRC-20 is not a separate protocol with its own consensus, but a layer on top of Ordinals: balances are not stored anywhere on the network; they are calculated by an indexer by parsing inscriptions in blocks.
This is the root of the problem — the network records entries, while the token state exists only in the accounting system of whoever reads those entries.
A typical failure looks like this: inscriptions in blocks are in place, transactions are confirmed, but holder balances diverge from what is visible during independent parsing. There are three causes.
The first — restarting indexing from the wrong checkpoint or a full pass through history after an interruption: some blocks are processed twice, some are skipped.
The second — different interpretation of Ordinals records: invalid JSON, a repeated issuance with the same ticker, an inscription on a “dangling” output — one indexer considers them valid, another discards them, and the BRC-20 issuance stops reconciling.
The third — two-step transfer: first an inscription for the transfer, then binding to an output; if only the first step is counted, the token hangs between addresses.
Blockchain reorganization also hits separately: when a branch is rolled back, the indexer must remove the effect of canceled blocks and replay them.
Without this, the discrepancy between accounting and the network remains in the database forever and only grows — each subsequent operation is calculated from an incorrect state.
What makes such a failure silent is the absence of reconciliation: as long as no one compares the indexer result with independent parsing by heights, the error does not manifest until withdrawal or listing.
This is closed by delta reconciliation for each block, reproducible reindexing from a checkpoint, and a single canonical interpretation of records — below we discuss how this is arranged in our implementation.
Effect of launch: issuance time, accounting accuracy, class of failures
After a well-designed issuance, timelines change by orders of magnitude.
Marking a batch of satoshis, forming inscriptions, and signing the series happen in one reproducible run instead of manual operations in a wallet — from task definition to the first confirmed transaction takes days, not weeks. Repeated issuance follows the same scenario with changed parameters.
Confirmation speed stops depending on luck. Engineers calculate the fee rate based on queue load, split issuance into batches, and leave headroom for chain reorganization, so transactions enter a block predictably — without manual resending and loss of position within the series.
Accounting accuracy is maintained by a proprietary indexer: it assembles state from Ordinals blocks and reconciles it with issuance down to the last unit.
The share of reconciliations done manually falls to almost zero — a discrepancy surfaces during block parsing, not in reporting to holders.
A whole class of failures goes away: duplicate inscriptions, loss of change remainder, violation of order within a series, damage to marked satoshis during transfer. Some of them were not caught at all before and were discovered only when trying to sell the asset.
Indexing resilience is a separate circuit. Chain reorganization, redelivery, and parallel requests are processed idempotently, so balances and transaction history are restored without manual intervention and service downtime.
Methods of issuing a BRC-20 token: comparison of approaches
BRC-20 is not a smart contract, but an entry in Ordinals inscription data that an indexer interprets. The token itself does not exist on the network: balances, mint limits, and transfers are determined by the parsing logic used by wallets, platforms, and exchanges.
Therefore, choosing an issuance method is first of all choosing who calculates the token state and by what rules.
Issuance modes are set at the same level: deploy with open mint, mint with a per-operation limit and total cap, issuance with subsequent transfer.
Accounting constraints that determine compatibility with external services include the order of inscriptions within a block, simultaneous mints into one limit, invalid and repeated records, and chain reorganization — the index must correctly roll back already accounted operations.
Comparison of issuance approaches
| Option | When it fits | What it limits |
|---|---|---|
| Ready-made tooling | fast launch, standard issuance mode, demand validation | accounting rules are set by the platform, no proprietary balance index, non-standard mints and snapshots are unavailable |
| Wrapper on an open indexer | need your own mint rules and your own balance interface | block parsing logic is someone else’s, reindexing speed after a failure is limited |
| Proprietary indexer | non-standard issuance modes, balance snapshots for distributions, fault-tolerance requirements | longer timelines, ongoing support needed when the standard and platform rules change |
A proprietary indexer is justified where mint and accounting rules need to be changed for the task, rather than fitting the task to someone else's platform.
Work stages: task audit, issuance scheme, verification, handover
We structure the work order so that each next step relies on the fixed result of the previous one. At the input — task assessment: token type, issuance logic, who holds the keys, what constraints exist on fees and record volume.
This removes the main issuance risk — irreversibility: a record in the blockchain cannot be rolled back, so an error in parameters or recipient address can only be corrected by a new issuance.
- Task audit. We analyze share distribution, per-operation limits, the number of future records, and who confirms issuance. Output — a risk map and requirements for wallets and access.
- Issuance scheme. We fix the total volume, issuance step, unlocking rules, and reserve address. We agree on the scheme before the first record — after issuance it cannot be changed.
- Issuance setup. We assemble records, set input ordering and fee headroom so issuance does not get stuck in the queue during peak network load.
- Testnet verification. We run the full cycle: issuance, transfer, limit triggers, wallet recovery from backup. Separately, we verify indexing — balances in the internal wallet and in third-party explorers must match down to the record.
- Acceptance by checklist. We check each item with the expected result; discrepancies are closed before handover, not after.
- Management handover. We hand over access and the signing scheme, instructions for the on-call shift, and procedures for actions when fees or limits change.
After handover, we remain in touch during the support period — changes to the issuance scheme are discussed separately and made only through approval.
Handover package: configurations, accounting schemes, procedures
The handover package is not a folder of files “just in case,” but a set of artifacts your team can use to issue a token independently, read its state, and maintain it without our involvement.
We fix the system at the moment of delivery: what is deployed, where keys are stored, how balance is determined, and what to do when nodes diverge.
- Node and indexing configurations — working parameters for synchronization, block storage, and inscription parsing, with a note on which values were changed and why exactly so.
- Accounting flow schemes — the path from issuance to crediting to an address: where the transfer is formed, how the remainder is calculated, at what moment the balance becomes final.
- Key access policies — separation of issuance, mint, and transfer signing roles, multisignature thresholds, rotation and backup storage procedures.
- Operations regulations — scheduled checks, response to chain reorganization, resending, and index divergence, maintenance windows, and the procedure for taking a node out of service.
- Team instructions — step-by-step scenarios: issuing the next batch, adding a token, rolling back a failed operation, recovery from backup.
- Load-test report and observation log — what was tested and under what load, what bottlenecks remain, and how to monitor them.
Case study: how asset accounting stopped diverging from the network
The client came not with a request to “issue a token,” but with a problem: the accounting of an issued asset diverged from the network state.
Inscriptions created tokens, while the internal registry lived separately — emissions were confirmed manually, some transfers between addresses were entered from memory, and the discrepancy surfaced only when trying to withdraw the asset to an external address.
The discrepancy was eliminated as a class. We raised an indexer that rebuilds asset state directly from Bitcoin Ordinals blocks and attached daily balance reconciliation with the issuance journal to it.
Each batch was assigned an identifier, so resending does not create a duplicate — the operation is simply cut off by an immutable attribute.
Issuance was moved into an automated loop: batch preparation, signing, network confirmation, and accounting entry follow one scenario with checks before sending. The engineer sees a discrepancy before the transaction leaves, not a week later in an export.
Result in numbers
- Daily reconciliation: 5–6 hours of manual matching — 20 minutes for exception review.
- Share of operations processed manually: 40% — 3% (only non-standard cases).
- Balance discrepancies found post factum: 5–7 per month — zero over the observation quarter.
- Issuing an asset batch: a working day — 15 minutes from preparation to confirmation.
- Recovering accounting from scratch along the chain: a day — 40 minutes of automatic recalculation.
Automation of issuance delivered the main thing: the registry stopped being a separate reality living its own life. Reconciliation can be restarted at any moment and produce the same state — this is the guarantee that accounting matches the network, not the operator’s memory.
Ready-made service or proprietary indexer: what to choose?
A ready-made service covers the standard scenario: Ordinals marks inscriptions, and a public indexer calculates BRC-20 balances according to the standard rules — deploy, mint, transfer. Starting takes days, and no proprietary infrastructure is required. The boundaries begin where your logic diverges from the standard.
Logic customization is the first reason to move to your own.
A balance snapshot at a fixed block height for distribution, separate accounting rules for game mechanics, selection only by your own sets, state updates without the delay of a public service — a ready-made indexer does not provide this, and workarounds run into incomplete data.
The second argument is accounting scaling. A public service limits request rate and does not guarantee sample completeness: under peak load you do not see the entire transfer flow and learn about it after the fact.
A proprietary node removes the issue — you accept each block yourself, parse inscriptions with your own filter, and store state in your own database.
The trade-off of the solution is a full copy of the blockchain, time for synchronization and re-parsing history, and maintenance.
In return — a deterministic result, the ability to replay state from scratch after accounting rule changes, and independence from the availability and limits of someone else’s service.
Therefore, at the start a service is usually enough, while a proprietary indexer and node are justified as volumes grow or with non-standard logic.
We often assemble a hybrid: the node as the primary source, the service as a second circuit for reconciliation and catching discrepancies.
Frequent technical questions about asset issuance and accounting
Engineering doubts about BRC-20 usually concern not issuance itself, but how the asset will behave under load and what can be done with it after launch.
There are four questions: network load during mint, storage of signing keys, accounting behavior during confirmation delays, and changes after deploy.
The answers below are about how this is arranged in the implementation, not about theory. BRC-20 is inscriptions in Bitcoin blocks, so everything concerning the transaction queue and finality works exactly the same as with ordinary transfers.
How much does issuance load the network, and what happens with fees during mint?
Mint, transfer, and sale are ordinary transactions that compete for space in a block. During peak hours the fee rate rises, and cheap operations sit in the queue.
Therefore, we mint in batches with a fee cap and a replacement rule: an underpaid request is replaced or canceled, while already issued inscriptions are not affected.
How are the keys that sign inscriptions protected?
Signing keys are not stored on the server and do not enter the repository. Roles are separated: a separate key for issuance, a separate one for fee payment, a separate one for changing accounting rules.
Critical operations require multiple signatures so that a single leak does not give control over emission, and the signing log allows any operation to be analyzed after the fact.
What happens to accounting if confirmation is delayed or a block is rolled back?
We calculate balances from confirmed blocks. While a transaction is in the queue, it is shown as “processing” and does not enter accounting — there is no discrepancy between the user’s balance and the network state.
After a chain rollback, operations from the canceled block are recalculated; there is no double crediting.
Can the token be modified after launch?
The ticker, total supply, and per-operation limit are recorded in the first inscription and do not change — only a new ticker can be issued. Everything else can be modified: accounting rules in the indexer, distribution logic, interface, reporting.
Support includes monitoring the queue of unconfirmed transactions and discrepancies between indexers when the standard changes.
Let’s discuss the task: preparation for an estimate and issuance plan
To come back with an estimate and work plan rather than general words, we need project inputs. Below is the minimum set that removes most questions at the calculation stage.
If some data is not available yet, note it directly: we will build assumptions for it into the issuance scheme.
- Issuance parameters: ticker, total volume, number of decimals, per-address limit, and mint rules.
- Distribution logic: team and community shares, whether vestings and address disclosure are needed.
- Expected load: order of the number of mint participants and peak transaction frequency — the fee strategy and division of issuance into stages depend on this.
- Infrastructure: proprietary or external indexer, whether integration with wallets and trading platforms is needed.
- Security: who holds the issuer keys, whether a multisignature circuit is needed, and who confirms issuance.
- Compliance and disclosure: requirements of your jurisdiction and whether public token documentation is needed.
- Acceptance criteria: what we consider a successful issuance — confirmed mint, working indexer, transaction report.
- Timelines and roles: release date, your technical contact, and decision approval procedure.
With this set, we will come back with an estimate of effort, a staged issuance scheme, and a work plan with control points. To discuss the task, it is enough to describe it in free form — we will analyze bottlenecks and agree on the start.