Overview
The BRC-20 Indexer Rules provided by Best in Slot (BiS) define a strict validation and indexing policy for BRC-20 inscriptions. These rules are designed to ensure consistent behavior across indexers, to prevent conflicts, and to maintain protocol safety when processing deploy, mint, and transfer inscriptions. The specification emphasizes strict MIME and JSON validation, clear typing requirements for numeric fields, precise decimal handling, and robust treatment of edge cases such as inscriptions sent as miner fees and blockchain reorgs.
Core Capabilities
- Strict MIME and JSON validation: Only inscriptions with MIME Type equal to text/plain or application/json are considered; JSON must be valid JSON (not JSON5).
- Protocol field enforcement: The JSON must contain p, op, and tick where p == "brc-20" and op is one of deploy, mint, or transfer.
- Typed numeric handling: All numeric fields (max, lim, amt, dec, etc.) must be strings; numeric formatting rules and decimal constraints are enforced.
- Balance tracking by scriptPubKey: Balances and availability are tracked using scriptPubKey rather than addresses to account for wallets without address mappings.
- Safety against indexing conflicts and reorgs: The rules include behaviors for deployments, mint limits, transfer usage, and reorg handling to avoid inconsistent state.
Main Features
-
Strict MIME and JSON checks: Validate the inscription's MIME type by splitting on ";" and checking the first segment exactly; only accept text/plain or application/json. Verify the payload is valid JSON (no JSON5), and check for the required fields p, op, and tick.
-
Operation-specific validation: Enforce operation rules: for deploy require a max string (optional lim and dec), for mint and transfer require an amt string. Apply default semantics (dec defaults to 18 if absent; lim defaults to max if absent) and ensure tick is exactly 4 bytes wide when encoded in UTF-8.
-
String-typed numeric fields and decimal precision: Numeric fields must be strings and cannot be trimmed/stripped. The dec field must consist only of digits (0-9) and have a maximum of 18. Other numeric fields may include a single decimal dot but cannot start or end with a dot. Decimal digit counts are strictly compared to dec, and extra digits (even trailing zeros) can invalidate an inscription.
-
Fee, transfer, and mint semantics: Inscriptions sent as miner fees at creation are ignored. If a transfer is sent as a fee on its first transfer, the amount must be returned to the sender. Mint and transfer rules limit actions to available balances; the last mint mints remaining tokens up to max.
-
Robust balance tracking and reorg awareness: Track both overall and available balances per scriptPubKey. A transfer inscription becomes used after its first transfer. The indexer must handle reorgs carefully because order matters; JavaScript implementations should use BigInt to avoid 53-bit precision issues.
How the Protocol Works
- A deploy inscription sets the token rules. Subsequent deploys for the same case-insensitive ticker are invalid.
- Mint inscriptions increase a wallet's overall and available balance up to the deploy's max and within lim constraints. The final mint can mint the remaining tokens.
- Transfer inscriptions reduce the original owner's overall balance only when the transfer is actually moved (not when inscribed), and a transfer becomes invalid/used after its first successful transfer.
Implementation Considerations
- Always check UTF-8 byte length for tick validation rather than character count.
- Treat numeric strings strictly; do not parse permissively (avoid accepting "123asd" as 123).
- Be careful with inscriptions used as miner fees and ensure correct reversal/return behavior when required.
- Prepare for reorgs: any reordering can change balances and token validity.
Why Follow These Rules
Following these rules provides deterministic, interoperable indexing behavior across services and avoids conflicts with other indexers. The detailed typing, decimal, and fee-handling rules minimize ambiguity and protect token supply and balances from indexing errors. Adhering to these constraints helps maintain protocol integrity and consistent user-facing state.
