Security Considerations

Interacting with the Universal BRC-20 Extension requires understanding its security model, which differs from Bitcoin's native security. This protocol relies heavily on the correct and consistent interpretation of on-chain data by indexers.

• Indexer Reliance

  The BRC-20 token state (balances, supply) is not enforced by Bitcoin miners. It is an interpretation layer built by independent indexers following this protocol specification. Your BRC-20 balance is only meaningful if the indexer(s) you and your counterparties use agree on the state. Choose indexers carefully. Decentralization of indexers is key to the robustness of the overall system.

• UTXO Ownership and Token Association

  In this model, your BRC-20 token balance for a specific token is conceptually tied by the indexer to the specific UTXOs you own that were the recipient of a valid BRC-20 mint or transfer operation for that token.

  • Risk of Token Loss: Spending a UTXO that an indexer associates with a token balance in a standard Bitcoin transaction without including a valid BRC-20 transfer OP_RETURN for that specific token might cause the indexer to consider that balance "lost" or unspendable, as the association is broken without a proper transfer instruction. This applies even if the UTXO also contained BTC which is spent normally.
  • Mitigation: Always use wallets or tools specifically designed for this OP_RETURN BRC-20 standard. These tools MUST track which of your UTXOs carry which token balances (according to their connected indexer) and MUST ensure that when you intend to move tokens, the transaction correctly includes the necessary OP_RETURN transfer operation and spends the appropriate token-bearing input UTXOs.

• Transaction Validation is Crucial

  Before signing and broadcasting any BRC-20 transaction (deploy, mint, or transfer), use a reliable tool to decode the raw transaction (decoderawtransaction). Carefully inspect the OP_RETURN content to ensure the operation, ticker, and amount are correct, and that the format is valid according to the technical specifications (especially the 80-byte limit and ticker length). Verify that the inputs being spent are the intended ones (especially if they carry token balances) and that the outputs are directed to the correct addresses with appropriate satoshi values for proportional distribution.

• Dust Outputs

  Token amounts allocated by indexers to standard outputs that fall below the Bitcoin dust limit may be lost, as these outputs might not be included in blocks. Ensure tools prevent creating dust outputs where token allocation is intended.

• Shared Namespace Risks

  The rule that the first valid deploy (Ordinals or OP_RETURN) wins for a given exact ticker string is critical. Be cautious of potential front-running or confusion if attempting to deploy a ticker already used elsewhere. Rely on indexers to check existing deployments across both standards before attempting a deploy. While allowing tickers >4 chars provides more options, it doesn't change the conflict rule for any specific ticker string.

• Potential for Invalid Operations

  Any transaction containing an OP_RETURN that attempts to be a BRC-20 operation but violates any of the Consensus Rules (e.g., incorrect JSON, wrong p value, exceeding OP_RETURN size, invalid ticker format or existing ticker) will be considered invalid by compliant indexers and ignored. While this doesn't harm the Bitcoin transaction itself (as long as it follows Bitcoin rules), it means the intended BRC-20 operation fails silently at the indexing layer. Users must rely on their tools/indexers to report such failures.