BRC20 六字节代号与抢注保护

6-byte BRC20 tickers - dropping on mainnet at block 912,690 - will now have snipe protection! 🚀

Hello Bitcoin fam, BRC2.0 momentum is growing stronger every day, and we are getting closer to launch. As mentioned in our earlier updates, Phase 1 moved to block 912,690 on ~2 September, in which 6‑byte tickers will be immediately programmable for smart‑contract use. ⚡️

Below we’ve prepared a concise summary, and wanted to let the community know that this upgrade will now include snipe protection and a limited charset.

Introduction

The accepted proposal above introduces the new namespace extension for BRC20 tokens, allowing 6-byte tickers - which will include snipe protection and a limited charset. The goal is to expand the expressive capacity of BRC20 while maintaining full compatibility with the Programmable Module and future composable tooling.

To ensure predictable behavior, especially in contexts requiring case normalization or cross-protocol matching, the 6-byte tickers will have a constrained character set: uppercase and lowercase English alphanumerics (A-Z, a–z, 0–9) and dash (-) only. The namespace is always treated as case-insensitive.

We're also introducing a snipe protection mechanism to prevent malicious actors from preemptively claiming 6-byte tickers before their deployment. 🛡️

Rationale

Expanding to 6 bytes without affecting 4 and 5 bytes increases combinatorial capacity without breaking existing semantics or bloating the protocol.

BRC2.0 is the first consumer of this 6-byte namespace, and limiting the launch of 6-byte initially will allow us to avoid affecting existing BRC20 namespaces.

Enforcing a strict subset of ASCII characters ensures cross-system compatibility and simplifies downstream parsing.

New Limitation

✅ 6-byte tickers must:

• Be exactly 6 characters long
• Only contain letters (A-Z or a-z), digits (0-9), or dash (-)
• Be treated case-insensitively

⛔️ Rejected inputs include:

• Symbols or extended Unicode (foo✓ar, foøbar) except for the dash (-)
• Tickers longer than 6 characters

Tickers of 4 or 5 bytes remain governed by existing rules and are not affected.

Self Mint Rules

Following self-mint rules from 5-byte tickers, BRC20 tokens with 6-byte tickers can be specified in the deploy operation as self-minted tokens.

If the self-mint field is set to "true", it only allows the owner of the deploy inscription to mint the token. If it's unset, or set to any other value other than "true", it defaults to false, meaning anyone can mint the token.

Snipe Protection via Pre-deploy Inscription

To prevent sniping attacks on 6-byte tickers, we introduce a snipe protection mechanism with a pre-deploy command.

In short: you first inscribe a double sha256 of the ticker, a salt, and your pkscript without revealing your ticker; three blocks later, you deploy the ticker with the same salt, and indexers verify the hash, which stops anyone else from claiming it.

Visit GitHub for the full snipe protection details.

Conclusion

6-byte tickers offer a meaningful namespace expansion for BRC20, enabling broader token design and future growth. The restricted charset is a deliberate constraint to preserve compatibility, security, and simplicity, especially as BRC20 expands into programmable and composable territory.

Snipe protection via pre-deploy inscriptions ensures that the namespace remains fair and accessible, preventing malicious actors from front-running legitimate deployments.

For the full technical scope, please visit: https://github.com/bestinslot-xyz/brc20-proposals/blob/main/001-6-byte-namespace/index.md Please contact us if you’d like help securing your ticker. BiS will provide a 6-byte ticker registration service to ensure a fair and orderly distribution. 🗳️

If you plan to build on BRC2.0, start with OPI, the canonical indexer. Running it prepares your stack for 6-byte tickers and the Programmable Module. https://github.com/bestinslot-xyz/OPI

For more questions or feedback, join our Telegram and Discord communities. We’d love to chat with you anytime! 🧡