Consensus Rules

These are the specific rules that indexers MUST apply when interpreting OP_RETURN BRC-20 transactions to maintain a consistent token state. Transactions that violate any of these rules are considered invalid within the BRC-20 protocol layer and MUST be ignored by indexers, even if they are valid Bitcoin transactions confirmed by miners.

1. OP_RETURN Structure: The transaction MUST contain exactly one OP_RETURN output, and it MUST be the first output (vout 0).
2. OP_RETURN Data Format: The data payload immediately following the OP_RETURN opcode and its length prefix MUST be the hex encoding of a valid minified JSON string starting with {"p":"brc-20"}.
3. OP_RETURN Size Limit: The total size of the OP_RETURN data payload (the JSON bytes) MUST NOT exceed 80 bytes (current standard policy limit). This is a critical constraint, impacting the maximum possible length of fields like tick, m, l, etc., as the entire JSON must fit within this limit.
4. Valid JSON and Fields: The data payload MUST be valid JSON and contain the required keys (p, op, tick, etc.) for the specified operation type (deploy, mint, transfer). Required fields MUST NOT be empty strings if a value is expected.
5. Protocol Identifier: The p field MUST be exactly the string "brc-20".
6. Operation Type: The op field MUST be one of "deploy", "mint", or "transfer". Indexers MUST ignore operations with other op values.
7. Ticker Format (Deploy): For a deploy operation to be valid, the tick value MUST be a non empty string. The maximum length is limited by the 80-byte OP_RETURN payload size constraint.
8. Ticker Namespace Uniqueness (Deploy): For a deploy operation to be valid, the specified tick string MUST NOT have been previously deployed by any prior valid BRC-20 deploy transaction (either Ordinals inscription or OP_RETURN) as determined by on-chain order. The first valid deploy transaction for a given exact ticker string establishes that ticker. Subsequent deploys for the same ticker string are invalid.
9. Valid Token Reference (Mint/Transfer): For mint or transfer operations to be valid, the specified tick string MUST correspond to a ticker that has been validly deployed by a prior valid deploy transaction (using the exact same ticker string). Operations for non-existent or invalidly deployed tickers are invalid.
10. Mint Limits: For a mint operation to be valid:
    • The amt value MUST be a positive integer string.
    • If the token deploy included an l (limit per operation), the amt MUST be less than or equal to l.
    • The sum of all previously validly minted amounts for this token plus the current amt MUST NOT exceed the total maximum supply m specified in the deploy.
11. Transfer Balance: For a transfer operation to be valid, the sender (identified by the set of input UTXOs being spent) MUST, according to the indexer's state, possess an aggregate available token balance for the specified tick that is greater than or equal to the amt specified in the OP_RETURN.
12. Transfer Limits: If the token deploy included an l (limit per operation), the amt in a transfer operation MUST be less than or equal to l.
13. Output Requirements: Standard outputs (non-OP_RETURN) MUST meet the Bitcoin network's consensus policies.
14. Input Validity: Input UTXOs MUST be valid and unspent according to Bitcoin network rules. The indexer validates the sender's token balance by looking up the token amounts it associated with these specific input UTXOs.
15. Extraneous Data: Any data within the OP_RETURN script after the expected and validated BRC-20 payload (including any unexpected push opcodes or bytes) renders the entire OP_RETURN invalid, causing the BRC-20 operation to be ignored by indexers.