BRC2.0 module - BRC20 Knowledgebase

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:

Parse the inscription

Extract BRC2.0 JSON from the Ordinals envelope.

Validate the operation

Check signature, nonce, and gas limits.

Execute EVM bytecode

Run the transaction in the local EVM instance.

Update state

Commit storage changes, logs, and balance updates.

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:

Domain	Contents
BRC-20 state	Traditional token balances tracked by BRC-20 inscriptions
BRC2.0 contract state	EVM 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..."
}

string

required

Protocol identifier. Must equal "brc20-prog".

string

required

Operation type. "deploy" or shorthand "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>"
}

string

required

Operation type. "call" or shorthand "c".

string

required

Address of the deployed contract to call.

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>"
}

string

required

Operation type. "transact" or shorthand "t".

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

Create deposit inscription

Inscribe a deposit operation specifying the ticker and amount.

Send to OP_RETURN

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

Indexers lock BRC-20 balance

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

Mint internal token balance

The contract receives an equivalent ERC-20-compatible balance.

{
  "p": "brc-20",
  "op": "deposit",
  "tick": "ordi",
  "amt": "1000"
}

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"
}

string

required

Must equal "brc20-module".

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.

Supported

Solidity syntax and features
Standard library contracts (OpenZeppelin, etc.)
Events and logs
Storage operations (SSTORE, SLOAD)
Standard opcodes (ADD, MUL, CALL, etc.)

Modified behavior

Property	BRC2.0 behavior
Block time	~10 minutes (Bitcoin’s block interval)
`block.number`	Refers to Bitcoin block height
`block.timestamp`	Bitcoin block time (less granular; can go backwards)
Gas model	Different costs due to indexer execution constraints
Address format	EVM addresses generated from Bitcoin-native addresses (`bc1p...`); these addresses cannot sign messages
`msg.value`	Native ETH value does not exist; use token deposits instead

Not supported

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

Immutability

Contract bytecode inscribed on Bitcoin cannot be changed. All operations are permanently recorded.

Determinism

All indexers must produce identical state given the same inscriptions. The protocol is a deterministic state machine.

Upgradability

Use proxy patterns (similar to Ethereum) for upgradeable contracts.

Precompile trust

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

Write Solidity contracts

Use Hardhat, Foundry, or Remix as usual.

Test locally

Deploy to a local BRC2.0 node or testnet.

Compile to bytecode

Generate deployment bytecode and ABI.

Inscribe contract

Create a deploy inscription with the bytecode.

Wait for confirmation

A Bitcoin block must confirm (~10 minutes).

Interact via inscriptions

Call functions by inscribing call operations.

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

Use BRC-20 when
Use BRC2.0 when

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

​What BRC2.0 adds to BRC-20

​Architecture and execution model

​State separation

​Operation types

​Deploy

​Call

​Transact

​Deposit and withdraw mechanics

​Deposit flow

​Withdraw flow

​EVM compatibility

​Gas model

​Security model and trust assumptions

​Development workflow

​When to use BRC2.0 vs BRC-20

What BRC2.0 adds to BRC-20

Architecture and execution model

State separation

Operation types

Deploy

Call

Transact

Deposit and withdraw mechanics

Deposit flow

Withdraw flow

EVM compatibility

Gas model

Security model and trust assumptions

Development workflow

When to use BRC2.0 vs BRC-20