BRC2.0 常见问题

Wednesday, 2 July 2025

BRC2.0 FAQ

Hello Bitcoin Fam! We appreciate the huge interest in BRC2.0, the long-awaited step forward for BRC20, soon launching on mainnet to enable smart contracts on Bitcoin’s base layer. 🛠️🟧

As momentum builds, the Bitcoin community has raised thoughtful questions about what’s possible, how it works, and what’s next. Here are the most frequently asked questions and their answers:

BRC2.0 Basics

What is BRC2.0?

BRC2.0 is an upgrade to the original BRC20 token standard that introduces EVM-compatible smart contracts directly on Bitcoin’s Layer 1, with native settlement and security.

It brings programmability to Bitcoin, making thousands of battle-tested EVM contracts and dApps deployable on the mother chain.

How does BRC2.0 differ from BRC20?

The original BRC20 standard allowed basic token minting and transfers but lacked programmability. BRC2.0 introduces smart contract capabilities, enabling advanced financial applications such as DeFi, stablecoins, DeFAI, DAOs, RWAs and more.

Does BRC2.0 require multisigs, sequencers, or off-chain approvals?

No. Users can deploy or interact with EVM-compatible contracts via standard Bitcoin transaction inscriptions. There’s no need for multi-sig wallets, sequencers, or off-chain approvals.

Is BRC2.0 secure?

BRC2.0 builds on Bitcoin’s proof-of-work security and decentralization. It keeps execution on-chain and avoids external dependencies, following trusted and widely tested smart contract standards.

How do I deploy a smart contract using BRC2.0?

Deployment involves standard Bitcoin transactions inscribed with contract code. Currently, this can be done on Signet using Best in Slot’s public UI:

Which wallets support BRC2.0?

Wallets such as xVerse, Leather, OKX Wallet, Unisat, Phantom, and others that can sign Bitcoin transactions can already interact with BRC2.0 to some extent. However, full smart contract functionality may require technical upgrades, especially for wallets not using our API. Dedicated compatibility updates and integration guides will be shared soon.

Token Upgrades, Ordinals, and What's Coming

What will happen to the 4-byte tickers? Can existing tokens like ORDI or SATS upgrade to BRC2.0?

All existing BRC20 tokens, including 4-byte tickers like ORDI and SATS, will become programmable after Phase 2 at Block 914,888 (~Sept 17, This target may shift based on integration progress). They can adopt BRC2.0 modules through a smooth and simple process. BiS and BRC20 ecosystem partners are actively coordinating this upgrade across the ecosystem.

Who would opt ORDI, SATS etc. into the upgraded modules? How would that work?

Token holders can easily opt into BRC2.0 by making a deposit. It’s a permissionless and modular system, requiring no changes to the token itself.

What is the release timeline?

BRC2.0 mainnet rollout occurs in two phases:

Phase 1: 6-byte Programmable Tickers
- Block Height: 909,969 (approximately August 14)
- New 6-character tickers introduced and immediately compatible with BRC2.0 smart contracts.
Phase 2: Full BRC200 Compatibility
- Target Block Height: 914,888 (approximately September 17)
- All existing BRC20 assets, including tokens such as ORDI and SATS, become programmable through BRC2.0.
- Date may shift depending on other BRC20 indexer integrations.

Why are you creating 6-byte tickers?

6-byte tickers immediately introduce programmability, facilitating a smooth transition into BRC2.0 capabilities without disrupting the existing BRC20 ecosystem. This step is the best way to ensure everything goes well with the upgrade.

Are there going to be any launchpads?

Yes. We're working on delivering the best possible launchpad experience for Bitcoin native assets. With native smart contracts and Ordinals-aware functionality, BRC2.0 provides everything needed for trustless token launches, gating mechanics, and more. Other teams in the ecosystem are also actively exploring similar products.

How does Ordinals-aware work?

BRC2.0 is Ordinals-aware, meaning smart contracts can recognize and interact with inscriptions and collections. This is enabled by Ordinal Lockers, which use Bitcoin's native time-lock and signature checks to securely lock inscriptions for a set duration.

Smart contracts can detect this locked status and use it to enable features like staking, token minting, and other functions that require holding an inscription. Everything runs on Bitcoin’s native mechanics, with no need for off-chain components.

Can you issue tokens specifically for Ordinal collections?

Yes. BRC2.0 enables linking tokens with Ordinal collections, making token issuance directly associated with Ordinals possible. We're designing the best experience in our BRC2.0 products to make this process as easy as possible for the collections.

Is there a connection between BiS ARTIFACTS and BRC2.0?

Yes. BiS ARTIFACTS (The first lockable Ordinal collection) can be connected to BRC2.0 via Ordinal Lockers. We're planning to expand on this and will share more details soon.

Are there any other Ordinals projects planning to launch on BRC2.0 or using Ordinal Lockers?

Yes. Some holders from collections like Goosinals and Bitcoin Puppets have already locked more than 100 assets using Ordinal Lockers. Many other Ordinals projects are also building on BRC2.0 or preparing to launch staking / locking functionality.

What is the purpose of building a gasless app-chain for BTCfi?

Bitcoin’s 10-minute block time makes it difficult to support fast, complex dapps directly on layer-1. A gasless app-chain offers a high-performance environment for BTCfi applications, removing latency and fee barriers while still anchoring back to Bitcoin. It enables smoother UX and broader design space without compromising on base-layer security

What kinds of applications will launch first with BRC2.0?

BRC2.0 is already attracting builders across the Bitcoin ecosystem. From DeFi, SocialFi to gaming and beyond, a wide range of applications are on the way including DEXs, AMMs, token launchpads, collections, and more.

[Redacted] – Gasless app-chain for high-performance BTCfi dApps
[Redacted] - Launchpad for Bitcoin native assets
BiS SWAP - BRC2.0 Swaps
BiS DEX - Professional Trading Experience for BRC20
Trio DEX – BRC20 DEX and more tooling by @trio_xyz
Cat Swap – BRC2.0 swap by @CatSwap_Fun
CoinCooker – No-code token creation suite for Bitcoin native assets
SocialFi dApp by @One2ThreeLabs
Hippodrome – Web3 game to test miner integrity by @horsedev42
100Layer – Wrapped BTC solution for BRC2.0
More BRC2.0 tooling by @OrangeCryptoX
Adderels – BRC2.0 Ordinals Collection
EarlyBirds – BRC2.0 Ordinals Collection

Testnet and Developer Questions

Why does BRC2.0 require the withdraw and deposit functions? What is the purpose of this design?

We adopted this design for all BRC20 upgrades. These are called "Modules." So basically, you can go into a module—in this case, BRC2.0—do your operations, then get out (withdraw) back to the base BRC20.

This design is part of the modular upgrade path for BRC20. You enter a module—like BRC2.0—to perform operations, then withdraw back to the base BRC20. It helps preserve clarity and security, especially on Bitcoin's 10-minute block time, where efficient state transitions matter.

Are there any effective methods for handling contract data queries?

Yes. Most Ethereum-compatible developer tools can be used with BRC2.0, meaning existing methods for querying contract data (e.g., via tools like The Graph, Ethers.js, or custom indexers) will be applicable.

If the EVM executes the smart contract, and the user has an ORDI and wants to execute the smart contract operation, does it need a bridge, or can it be operated directly?

No, you don’t need to cross-chain operations. As a user, you will most likely just click a few buttons, and everything will be abstracted away.

Our project is currently being developed on Ethereum, Base, Polygon or other EVM chains using Solidity. Will it be easy to port it to BRC2.0 later? Are things like proxy contracts supported?

Yes, porting your Solidity project to BRC2.0 will be straightforward, and proxy contracts are supported.

Is there a possibility for BRC20 to upgrade and store data in OP_RETURN? Will contract data be placed in OP_RETURN or in the witness?

It’ll use witness data since it is more efficient for relatively bigger data.