BRC2.0 programmable module

BRC2.0 adds EVM-compatible smart contract execution to Bitcoin through the same inscription-based metaprotocol architecture as BRC-20.

BRC2.0 is a programmable execution layer built on top of BRC-20. It adds EVM-compatible smart contracts to Bitcoin through the same inscription-based metaprotocol architecture. Where BRC-20 gives you token operations (deploy, mint, transfer), BRC2.0 gives you a full computing environment — Solidity contracts that execute with direct access to Bitcoin’s state through specialized precompiles.

Like BRC-20, BRC2.0 is a metaprotocol. Bitcoin nodes don’t execute smart contracts. Instead, specialized indexers run EVM execution engines that process contract bytecode inscribed on Bitcoin. This lets you build DeFi protocols, DAOs, and complex financial applications directly on Bitcoin — without wrapping assets or trusting bridge validators.

Operation types

BRC2.0 extends BRC-20’s inscription model with three new operation types.

Deploy

Inscribe compiled Solidity contract bytecode to Bitcoin. Indexers execute the constructor and assign the contract a Bitcoin-native address.

{
  "p": "brc20-prog",
  "op": "deploy",
  "d": "0x608060405234801561001057600080fd5b50..."
}

Call

Invoke a function on a deployed contract. Indexers execute the call in their EVM environment and update contract state.

{
  "p": "brc20-prog",
  "op": "call",
  "d": "0xA9059CBB..."
}

Transact

Combine a BRC-20 token deposit with a contract call in a single operation. This is the primary pattern for DeFi interactions — deposit tokens and trigger contract logic atomically.

{
  "p": "brc20-prog",
  "op": "transact",
  "tick": "ordi",
  "amt": "1000",
  "d": "0xA9059CBB..."
}

Each operation is inscribed on Bitcoin, creating an immutable audit trail of all state transitions. Indexers execute EVM bytecode deterministically — all indexers must produce identical results, enforced by the same social consensus model as BRC-20.

Deposit and withdraw

BRC2.0 includes a trustless bridge between BRC-20 token state and contract state. No validators, no multisigs, no external dependencies.

1. Deposit

   Inscribe a deposit operation. Indexers lock your BRC-20 balance, and the contract receives an equivalent ERC-20-style balance internally.

2. Use inside contracts

   Your deposited tokens are now available to smart contracts. Swap them on a DEX, provide liquidity, use them as collateral, or pass them to another contract.

3. Withdraw

   The contract burns the internal token balance and emits a Withdraw event. Indexers detect the event and credit the BRC-20 balance back to your address.

Tokens can only be withdrawn if the contract properly burns them. The bridge rules are enforced by the same indexer consensus that validates BRC-20 operations — there is no separate bridge contract or authority.

Execution model

When you inscribe a contract call, execution follows this sequence:

1. Inscription — you inscribe a call or transact operation on Bitcoin
2. Confirmation — the Bitcoin block confirms (~10 minutes)
3. Indexer execution — indexers process the inscription and execute the EVM bytecode
4. State update — contract storage is updated and events are emitted
5. Consensus — all indexers produce identical post-state

State finality inherits Bitcoin’s model: contract state changes are considered final after the transaction confirms on Bitcoin (~10 minute average block time). This is slower than Ethereum’s 12-second finality, but benefits from Bitcoin’s security and hashrate.

BRC2.0 has no mempool for smart contracts — you cannot see pending contract calls before they confirm. This eliminates front-running at the contract level. Inscription-level MEV via Bitcoin fee races still exists, but contracts themselves cannot be sandwiched.

What you can build

BRC2.0 unlocks application categories that are impossible with BRC-20 alone:

Decentralized exchanges

Constant-product AMMs (Uniswap-style) with instant swaps inside contracts. No PSBT coordination, no fragmented liquidity across marketplaces.

Lending protocols

Collateralized lending with algorithmic interest rates, liquidations, and risk management — all executed deterministically by indexers.

Yield farming

Staking contracts that reward liquidity providers with programmatic token emissions over time.

DAOs and governance

Token-weighted voting with on-chain proposal execution and timelock mechanisms.

Options and derivatives

Complex financial instruments with automated settlement based on oracle data or Bitcoin state.

NFT marketplaces

Programmable royalties, Dutch auctions, and collection-wide operations.

The fundamental unlock is composability — contracts can call other contracts. Lending protocols can integrate with DEXes for liquidations, yield farms can auto-compound through swap contracts, and so on.

BRC-20 vs BRC2.0

BRC2.0 is a superset of BRC-20. All BRC-20 tokens can be deposited into contracts and withdrawn back to BRC-20 state. You can start with simple BRC-20 tokens and add programmability when you need it — no redeployment, no wrapping.

Feature	BRC-20	BRC2.0
Operations	Deploy, Mint, Transfer	Deploy contracts, Call functions, Transact
Programmability	None (fixed operations)	Full Solidity support
Trading	PSBT marketplaces only	AMMs, order books, auctions
DeFi	Not possible	Lending, staking, derivatives
Execution	Indexer validates JSON	Indexer runs EVM bytecode
State model	Token balances only	Contract storage + balances
Composability	Cannot combine operations	Contracts call other contracts
Block time	~10 min Bitcoin blocks	~10 min Bitcoin blocks (instant execution within contracts)

EVM compatibility

BRC2.0 aims for maximum Solidity compatibility, but there are key differences from Ethereum to understand before you deploy.

What works the same

Standard Solidity syntax, OpenZeppelin contracts, events and logs, storage operations, and familiar development tools (Hardhat, Foundry, Remix) all work with minimal or no changes.

What is different

• Block time is ~10 minutes (Bitcoin’s interval), not 12 seconds
• Gas costs differ due to indexer execution rather than validator execution
• Addresses use Bitcoin’s bc1p... format, not Ethereum’s 0x... format
• There is no native ETH equivalent

What has limited support

Some time-dependent features work differently due to 10-minute blocks. Certain Ethereum-specific opcodes may have limited support. Check the architecture limitations page before relying on timing assumptions.

Bitcoin-specific precompiles

BRC2.0 adds specialized precompiled contracts that give your Solidity code native access to Bitcoin: transaction introspection, UTXO queries, and BIP-322 signature verification. These have no Ethereum equivalent.

If you’re coming from Ethereum, most of your existing Solidity code will run unchanged. The main adjustments are for Bitcoin-specific address formats and any logic that assumes 12-second block times.