Skip to main content
BRC2.0 extends BRC-20’s inscription-based token standard with an EVM-compatible execution layer, enabling smart contracts, DeFi primitives, and composable applications on Bitcoin. While BRC-20 provides token operations (deploy, mint, transfer), BRC2.0 provides a programmable computing environment where Solidity contracts can execute with full access to Bitcoin’s state. The core insight: BRC2.0 maintains the metaprotocol model — execution happens off Bitcoin’s base layer with results tracked by indexers — but adds computational expressiveness previously impossible with BRC-20 alone.

​
What BRC2.0 adds to BRC-20

BRC2.0 introduces four major capabilities:
  • Smart contracts: Deploy Solidity contracts inscribed on Bitcoin, with state transitions validated by indexers running EVM execution.
  • Deposit/withdraw bridge: Move BRC-20 tokens into BRC2.0 contracts as ERC-20-compatible assets.
  • Bitcoin precompiles: Native access to Bitcoin transaction verification, signature validation (BIP-322), and UTXO queries.
  • Event system: Contract logs that applications can subscribe to for real-time updates.

​
Architecture and execution model

BRC2.0 indexers run an EVM-compatible execution environment alongside traditional BRC-20 state tracking. When a BRC2.0 operation is inscribed (deploy contract, call function, deposit tokens), indexers execute a deterministic pipeline:
1

Parse the inscription

Extract BRC2.0 JSON from the Ordinals envelope.
2

Validate the operation

Check signature, nonce, and gas limits.
3

Execute EVM bytecode

Run the transaction in the local EVM instance.
4

Update state

Commit storage changes, logs, and balance updates.
5

Achieve consensus

All indexers must produce identical state transitions.
This creates a deterministic state machine whose history is anchored in Bitcoin inscriptions but whose execution happens off-chain.

​
State separation

BRC2.0 maintains two distinct state domains:
DomainContents
BRC-20 stateTraditional token balances tracked by BRC-20 inscriptions
BRC2.0 contract stateEVM storage, contract accounts, and internal token balances
Assets can move between domains using deposit/withdraw operations, creating a bridge between Bitcoin-native tokens and smart contract applications.

​
Operation types

BRC2.0 defines three new operation types using the "brc20-prog" protocol identifier, beyond BRC-20’s deploy/mint/transfer.

​
Deploy

Deploy a Solidity contract to the BRC2.0 execution layer. Indexers execute the constructor and assign the contract an address derived from the inscription ID. 
{
  "p": "brc20-prog",
  "op": "deploy",
  "d": "0x608060405234801561001057600080fd5b50..."
}
​
p
string
required
Protocol identifier. Must equal "brc20-prog".
​
op
string
required
Operation type. "deploy" or shorthand "d".
​
d
string
required
Compiled Solidity deployment bytecode as a hex string. Generate with Hardhat, Foundry, or Remix.

​
Call

Invoke a function on a deployed contract. Indexers validate gas limits and update contract state accordingly. 
{
  "p": "brc20-prog",
  "op": "call",
  "c": "<contract_address>",
  "b": "<calldata>"
}
​
op
string
required
Operation type. "call" or shorthand "c".
​
c
string
required
Address of the deployed contract to call.
​
b
string
required
ABI-encoded calldata for the function invocation.

​
Transact

Combined deposit/withdraw with contract call — moves BRC-20 tokens into a contract and invokes a function in one operation. This is the primary pattern for DeFi interactions: deposit tokens, execute trade/stake/lend, and optionally withdraw results. 
{
  "p": "brc20-prog",
  "op": "transact",
  "b": "<calldata>"
}
​
op
string
required
Operation type. "transact" or shorthand "t".
​
b
string
required
ABI-encoded calldata including deposit parameters and function arguments.

​
Deposit and withdraw mechanics

BRC2.0 includes a built-in bridge for moving BRC-20 tokens into smart contracts.

​
Deposit flow

1

Create deposit inscription

Inscribe a deposit operation specifying the ticker and amount.
2

Send to OP_RETURN

Send the inscription to OP_RETURN "BRC20PROG" to route it into the BRC2.0 module.
3

Indexers lock BRC-20 balance

Tokens move from BRC-20 state to “deposited” state.
4

Mint internal token balance

The contract receives an equivalent ERC-20-compatible balance.
{
  "p": "brc-20",
  "op": "deposit",
  "tick": "ordi",
  "amt": "1000"
}
​
op
string
required
Must equal "deposit".
​
tick
string
required
Ticker of the BRC-20 token to deposit.
​
amt
string
required
Amount to deposit as a stringified integer.

​
Withdraw flow

To withdraw, inscribe a withdraw operation and send it to any address other than OP_RETURN. This credits the BRC-20 balance back to the sender. 
{
  "p": "brc20-module",
  "op": "withdraw",
  "tick": "ordi",
  "amt": "10",
  "module": "BRC20PROG"
}
​
p
string
required
Must equal "brc20-module".
​
op
string
required
Must equal "withdraw".
​
tick
string
required
Ticker of the token to withdraw.
​
amt
string
required
Amount to withdraw as a stringified integer.
​
module
string
required
Module identifier. Must equal "BRC20PROG".
This creates a trustless bridge — no multisig or validator set is required. Indexers enforce the rules deterministically based on inscriptions and EVM execution.

​
EVM compatibility

BRC2.0 aims for Solidity compatibility but has key differences from Ethereum.
  • Solidity syntax and features
  • Standard library contracts (OpenZeppelin, etc.)
  • Events and logs
  • Storage operations (SSTORE, SLOAD)
  • Standard opcodes (ADD, MUL, CALL, etc.)
PropertyBRC2.0 behavior
Block time~10 minutes (Bitcoin’s block interval)
block.numberRefers to Bitcoin block height
block.timestampBitcoin block time (less granular; can go backwards)
Gas modelDifferent costs due to indexer execution constraints
Address formatEVM addresses generated from Bitcoin-native addresses (bc1p...); these addresses cannot sign messages
msg.valueNative ETH value does not exist; use token deposits instead
  • Native ETH (msg.value) — use BRC-20 token deposits
  • Ethereum-style key-based message signing from contract-generated addresses

​
Gas model

BRC2.0 uses a Bitcoin-anchored gas model:
  • Gas limits prevent infinite loops during indexer execution.
  • If execution exceeds the gas limit, the transaction reverts and state is not updated — standard EVM behavior.
  • Gas costs differ from Ethereum due to indexer execution constraints.

​
Security model and trust assumptions

Contract bytecode inscribed on Bitcoin cannot be changed. All operations are permanently recorded.
All indexers must produce identical state given the same inscriptions. The protocol is a deterministic state machine.
If indexers diverge, the community must choose the canonical implementation. Reference implementations and test suites are essential.
Use proxy patterns (similar to Ethereum) for upgradeable contracts.
Bitcoin verification precompiles rely on correct implementation in indexer code.
BRC2.0 security depends on indexer correctness. If the EVM implementation has bugs or deviates from specification, contract execution may diverge across indexers.

​
Development workflow

1

Write Solidity contracts

Use Hardhat, Foundry, or Remix as usual.
2

Test locally

Deploy to a local BRC2.0 node or testnet.
3

Compile to bytecode

Generate deployment bytecode and ABI.
4

Inscribe contract

Create a deploy inscription with the bytecode.
5

Wait for confirmation

A Bitcoin block must confirm (~10 minutes).
6

Interact via inscriptions

Call functions by inscribing call operations.
7

Monitor events

Subscribe to indexer APIs for contract logs.
The cycle time is slower than Ethereum due to Bitcoin’s block interval, but inscriptions provide permanent on-chain history of all interactions.

​
When to use BRC2.0 vs BRC-20

  • Simple token operations suffice (hold, send, receive)
  • You want maximum compatibility with existing wallets and tools
  • Lower complexity and gas costs are priorities
  • No programmable logic is required