Skip to main content
The simplest way to think about BRC2.0 is: Ethereum execution, but blocks are Bitcoin blocks. Smart contracts run in a standard EVM and follow familiar Ethereum semantics. What changes is how transactions enter the system and how execution is paid for.

​
Same as Ethereum vs. different

ConceptEthereumBRC2.0
Smart contract languageSoliditySolidity
Execution environmentEVMEVM (identical semantics)
Contract storagePersistent key-value storePersistent key-value store
ABI encodingStandardStandard
Events and logsEVM event modelEVM event model
Transaction submissionEVM mempoolOrdinals inscription
Block orderingEthereum validatorsBitcoin miners
Account modelECDSA keypairs (EOAs)Derived from Bitcoin pkscript
Signature schemeecrecover (ECDSA)BIP-322 via precompile
Gas pricingDynamic (base fee + priority)Fixed per inscription byte
Gas tokenETHNone
Finality~12 seconds (PoS)~10 minutes (Bitcoin blocks)

​
Blocks

Bitcoin blocks define execution ordering. Operations are processed in the order their inscriptions appear on-chain. There is no separate block producer, proposer role, or mempool for the EVM layer. If a Bitcoin transaction is reorged, the corresponding EVM execution is replayed accordingly. You can treat this the same way you would treat an Ethereum reorg: state reverts to the last consistent point and re-executes from there.
BRC2.0 has no parallel block production. Every execution step traces back to a confirmed Bitcoin block. This makes the ordering model simpler than many Layer 2 designs, but it means finality is governed by Bitcoin.

​
Transactions

There is no EVM mempool. What would normally be an Ethereum transaction is represented as an Ordinals inscription. Deployments, contract calls, and signed EVM transactions are all submitted as inscription data and activated by sending them to the module address. From a contract’s perspective, execution is identical to a normal EVM call. From a user’s perspective, all interaction happens through Bitcoin transactions.

​
Gas

There is no gas token and no dynamic gas price. Execution limits are derived from inscription size:
  • Each inscribed byte grants a fixed gas allowance
  • Larger inscriptions allow more computation
  • Gas is effectively prepaid by paying higher Bitcoin fees for larger transactions
You never need to reason about gas markets, base fees, or priority fees. The cost of computation is directly and predictably tied to Bitcoin’s fee market and the size of your inscription.
This means optimization in BRC2.0 is about packing more computation into fewer bytes, not chasing gas prices. Smaller calldata and bytecode directly reduce your Bitcoin fees.

​
How the layers relate

┌─────────────────────────────────┐
│         Your Solidity Contract  │
├─────────────────────────────────┤
│         EVM Execution Layer     │  ← standard semantics
├─────────────────────────────────┤
│     BRC2.0 Programmable Module  │  ← indexes inscriptions, drives EVM
├─────────────────────────────────┤
│         Bitcoin (Ordinals)      │  ← ordering, settlement, identity
└─────────────────────────────────┘
Bitcoin acts as the settlement and ordering layer. The EVM is a deterministic execution module layered on top. This model avoids the trust tradeoffs common in rollups and Layer 2 bridges: there is no validator set to trust for ordering, and no bridge for exits.

​
What works without modification

Most existing Solidity code works unchanged, provided it does not rely on Ethereum-specific assumptions:
  • ERC-20 and ERC-721 token logic
  • AMM and bonding curve math
  • Vault and escrow patterns
  • Event emission and off-chain indexing
  • Multi-contract composition within a single execution

​
What requires attention

The following Ethereum patterns do not work in BRC2.0 and must not be used in your contracts:
  • ecrecover — EVM addresses have no private keys; use the BIP-322 precompile instead
  • tx.origin — there is no EOA-originated call chain
  • Gas-price-based logic (tx.gasprice) — there is no dynamic gas price
  • Assumptions about sub-second finality — Bitcoin block times are ~10 minutes
See Accounts & Identity for how to handle authentication correctly, and Limitations for a complete list of constraints.