BRC-20 Programmable Module

Activated on Bitcoin Mainnet in 2025

BRC2.0 extends the BRC-20 metaprotocol with a deterministic execution layer that allows EVM-compatible smart contract logic to be expressed via Bitcoin inscriptions.

BRC-20 defines fungible token state using structured JSON operations such as deploy, mint, and transfer. The programmable module builds on that same inscription framework, adding executable semantics. Instead of inscribing static token instructions only, developers can inscribe compressed EVM bytecode and ABI-encoded calldata, which are interpreted and executed by programmable module indexers.

BRC2.0 remains a metaprotocol. Bitcoin consensus does not execute contracts and does not validate contract state transitions. Bitcoin provides block ordering, timestamping, and settlement finality. Contract execution is performed by deterministic EVM runtimes implemented within indexers, which replay confirmed inscriptions strictly in block order to derive canonical contract state.

This design enables composable DeFi primitives, including vaults, AMMs, liquidity mining systems, lending logic, and governance contracts, to operate natively on Bitcoin without modifying base consensus rules or introducing bridge dependencies.

---

Architecture

The BRC-20 Programmable Module operates as a Bitcoin metaprotocol.

All programmable operations are expressed as Bitcoin on-chain Ordinals inscriptions and ordered canonically by Bitcoin block inclusion. Contract execution and state computation are performed deterministically by indexers that integrate the Programmable Module execution engine.

Bitcoin provides canonical transaction ordering, block-level timestamping, data availability, and final settlement. The Programmable Module derives contract state by replaying ordered inscription operations according to the module specification.

This architecture enables smart contract execution without reliance on bridges, multisigs, Layer 2 systems, sequencers, validator networks, or external consensus mechanisms.

Bitcoin Onchain Ordering

All programmable actions are encoded as structured inscriptions under the brc20-prog namespace.

These inscriptions are embedded in Taproot transactions and activated via standard commit–reveal flows, typically by sending the reveal transaction to the designated module identifier (e.g., OP_RETURN BRC20PROG).

Bitcoin provides:

• Canonical transaction ordering

• Block-level timestamping

• Immutable data availability

• Final settlement guarantees

The Programmable Module does not introduce new consensus. Instead, indexers consume ordered inscription data and execute operations through the integrated execution engine to compute deterministic contract state.

Namespace isolation via brc20-prog ensures programmable operations are logically separated from standard BRC-20 transfer inscriptions while preserving compatibility with ordinal-based indexing systems.

Execution Engine (Deterministic EVM Runtime)

Smart contract execution is performed by indexers that integrate the Programmable Module execution engine.

The execution engine is a customized EVM runtime (built using revm) responsible solely for virtual machine execution and state computation. It does not perform block production, validation, or consensus functions.

Indexers:

• Parse inscriptions within the brc20-prog namespace

• Interpret operation types including deploy ("op": "d"), call ("op": "c"), and transact ("op": "t")

• Decode and decompress calldata or bytecode from the "b" or "d" fields (supporting NADA and Zstandard compression formats)

• Execute operations using the integrated EVM runtime

• Replay inscriptions strictly in canonical Bitcoin block order

For each indexed block, operations are executed deterministically according to the module specification. All indexers processing the same ordered inscription set will compute identical contract state.

Determinism is derived from canonical Bitcoin transaction ordering. The Programmable Module does not rely on sequencers, validator sets, leader election, or alternative consensus mechanisms.

State Derivation Model

The Programmable Module does not persist contract state on Bitcoin. State is derived deterministically from ordered inscription data.

Each indexer:

• Processes Bitcoin blocks sequentially

• Extracts valid inscriptions within the brc20-prog namespace

• Executes operations using the integrated EVM runtime

• Applies resulting state transitions to a local state database

State transitions are deterministic because:

• Instruction ordering is fixed by canonical Bitcoin block ordering

• Execution rules are defined by the Programmable Module specification

• The EVM runtime produces deterministic output given identical inputs

Any indexer can reconstruct complete contract state by replaying the ordered inscription set from genesis to the current block.

This replay-based architecture enables independent state verification without modifying Bitcoin’s consensus rules.

Address Derivation Model

Contracts and externally controlled accounts exist within the Programmable Module’s EVM-compatible address space.

Contract addresses are generated according to standard EVM deployment rules within the execution engine.

Externally controlled accounts are derived from Bitcoin scriptPubKey values using the following translation method:

evm_addr = keccak256(bitcoin_pkscript_bytes).slice(-20 bytes)

These derived EVM addresses do not possess private keys. Signature verification is performed using the module’s BIP-322 precompile, after which the derived EVM address is treated as the verified caller address within the runtime.

This model enables:

• Taproot-controlled accounts to interact with deployed contracts

• ERC-20 compatible token logic within the execution engine

• Standard ABI-encoded contract calls

• Deterministic address mapping across all indexers

Address derivation is deterministic and replayable, ensuring consistent account representation across independent indexers.

---

Operation Types

The BRC-20 Programmable Module defines a minimal set of execution primitives.

Each operation is expressed as a structured inscription under the brc20-prog namespace and interpreted deterministically by indexers.

These primitives define how contracts are created and how state transitions occur.

1) Deploy op: "d"

Deploy instantiates a new smart contract within the programmable module runtime.

Envelope Format

{ 
  "p": "brc20-prog",
  "op": "d",
  "b": "<compressed_bytecode>"
}

Fields

• p identifies the programmable module namespace

• op: "d" signals contract deployment

• b contains NADA-compressed EVM bytecode

Execution Model

1. The deploy inscription is committed via commit–reveal.

2. Upon reveal confirmation, indexers:

   • Decompress bytecode

   • Validate bytecode format

   • Instantiate the contract in the local EVM runtime

3. A deterministic contract address is derived from deployment context.

4. The contract’s initial state is recorded in the indexer’s state database.

Deployment is immutable once confirmed in a Bitcoin block. The bytecode cannot be altered after settlement.

2) Call op: "c"

Call invokes a function on an existing deployed contract.

Envelope Format

{ 
  "p": "brc20-prog",
  "op": "c",
  "c": "<contract_address>",
  "b": "<compressed_calldata>"
}

Semantics

• op: "c" signals contract execution

• c specifies the target contract address

• b contains ABI-encoded calldata, compressed via NADA

Execution Model

1. The calldata is decompressed.

2. ABI decoding is performed.

3. The function selector and arguments are applied to the contract.

4. The EVM runtime executes the call.

5. State transitions are applied deterministically.

All execution follows strict Bitcoin ordering. If a call reverts under runtime rules, state changes are not applied.

3) Transact (Value-Aware Execution)

Within the programmable module, token transfers and contract interactions are modeled as transactions encoded through op: "c" calls.

This includes:

• ERC-20 transfer

• approve

• transferFrom

• Liquidity provisioning

• Vault deposits

• Governance voting

Although no native ETH-equivalent gas asset exists, execution semantics mirror EVM transaction behavior:

• Caller identity is derived from the Bitcoin-controlled address

• State changes occur only upon successful execution

• Indexers enforce deterministic execution rules

The programmable module does not introduce new Bitcoin opcodes. Instead, it transports execution instructions via inscription payloads and OP_RETURN-anchored data.

---

Execution

Programmable Module execution follows a fixed lifecycle. Instructions are transported as Bitcoin inscriptions and become executable only after Bitcoin confirmation. Indexers then deterministically replay those instructions to derive canonical state.

1

Inscription Submission

A user constructs a Programmable Module envelope under the brc20-prog namespace and broadcasts it using the standard inscription flow.

• Deploy uses op: "d" with NADA-compressed bytecode in b

• Call uses op: "c" with target contract address in c and NADA-compressed calldata in b

The instruction is expressed as onchain data. No execution occurs at submission time.

2

Block Confirmation

The inscription confirms in a Bitcoin block.

Bitcoin provides:

• Global ordering (block height, transaction order)

• Settlement finality

• An immutable execution log (the inscription history)

Once confirmed, the instruction becomes part of the canonical replay stream.

3

Indexer Detection

Programmable-module indexers scan blocks and detect valid Programmable Module inscriptions by filtering for:

• Valid JSON envelopes

• p: "brc20-prog"

• Supported operation types (op: "d" or op: "c")

• Required fields (b for deploy, c and b for call)

Indexers ingest these instructions strictly in block order.

4

Execution

For each detected instruction, the indexer:

• Decompresses the NADA payload in b

• For deploy: instantiates contract bytecode in the EVM runtime

• For call: ABI-decodes calldata and executes the function in the EVM runtime

• Applies standard EVM semantics for opcode execution, storage writes, and revert behavior

Execution must be deterministic. Given the same ordered input stream, indexers must compute identical results.

5

State Update

If execution completes successfully:

• Contract storage is updated

• Internal balances and mappings are updated according to contract logic

• Any derived token accounting performed through the module’s rules is updated deterministically

If execution reverts, state changes are not applied.

Canonical state is the result of replaying all confirmed instructions from genesis to the current tip.

6

Log Emission

During execution, the runtime emits logs and events.

Indexers record:

• Execution receipts

• Event topics and data

• Post-state changes resulting from the instruction

Logs become part of the observable audit trail for application UIs, explorers, and downstream analytics.

---

BRC20 ↔ BRC2.0 Token Interaction Model

The Programmable Module defines a structured interaction model between standard BRC-20 balances and BRC2.0 contract-level state. Asset movement is coordinated through inscription-defined operations and deterministic state interpretation by indexers.

Bitcoin provides ordering and settlement. The module defines execution semantics.

Deposit

Deposits represent the movement of BRC-20 balances into contract-controlled state within the Programmable Module.

Flow:

1. A user inscribes a valid BRC-20 transfer operation.

2. The transfer inscription is sent to the designated programmable deposit address.

3. Upon confirmation, programmable-module indexers detect the transfer.

4. The deposited amount is credited to the corresponding contract context.

Key Properties:

• The underlying BRC-20 transfer follows standard metaprotocol rules.

• Indexers validate ticker, amount, and available balance.

• Contract state is updated only after confirmed inclusion in a Bitcoin block.

• No separate bridge or wrapped representation is required at the base layer.

Deposit validity is derived from canonical BRC-20 state plus inscription ordering.

Withdrawal

Withdrawals move assets from contract-controlled state back into standard BRC-20 balances.

Flow:

1. A contract call is inscribed via the brc20-prog namespace.

2. The EVM runtime processes the withdrawal logic.

3. If conditions are met, a withdrawal instruction is emitted.

4. Indexers reconcile contract state with BRC-20 balance adjustments.

Properties:

• Withdrawals must be authorized by contract logic.

• State transitions are applied only after deterministic execution.

• BRC-20 balances are updated according to replayed execution results.

• No custodial intermediary performs asset release.

Withdrawals are state-derived outcomes of valid contract execution.

State Reconciliation

The system maintains consistency between:

• BRC-20 canonical balances

• Programmable contract storage

• Deposit and withdrawal history

Reconciliation rules:

• Contract balances are derived from confirmed deposit inscriptions.

• Withdrawal events reduce contract-controlled balances.

• All calculations are replayable from genesis.

• Any indexer reconstructs identical balances.

There is no off-ledger ledger or shadow accounting layer.

The programmable module does not custody assets.

It defines execution semantics over inscription-encoded token state.

Asset integrity derives from Bitcoin ordering and open replay rules, not from centralized coordination.

---

EVM Compatibility & Differences

The Programmable Module implements an EVM-compatible runtime for deterministic execution of smart contract bytecode expressed via brc20-prog inscriptions. Compatibility is defined at the execution semantics layer, not at the consensus layer.

Bitcoin does not execute contracts. Execution is performed by programmable indexers that replay inscriptions under a fixed runtime specification.

Solidity Support

Contracts compiled with standard Solidity toolchains targeting the EVM bytecode format can be deployed, provided:

• The compiler targets a compatible EVM instruction set

• Bytecode is ABI-compliant

• The compiled output fits within inscription size constraints after compression

The module executes raw EVM bytecode. Solidity is supported indirectly through compilation to EVM bytecode.

There is no direct source-level interpretation. Only bytecode is executed.

ABI Compatibility

The runtime supports standard ABI encoding and decoding conventions:

• Function selectors (first 4 bytes of calldata)

• Standard ABI parameter encoding

• Return data handling

• Event log emission

Calldata is ABI-encoded off-chain and inscribed in compressed form. Indexers decompress and execute against the EVM-compatible runtime.

Precompiles

Precompile availability is determined by the runtime specification implemented by programmable indexers.

If precompiles are supported, they must:

• Be explicitly defined in the runtime specification

• Produce deterministic results across all indexers

• Avoid reliance on external or non-canonical state

There is no reliance on Bitcoin script opcodes for EVM execution. All contract logic executes within the EVM-compatible environment maintained by indexers.

Opcode Support

The runtime implements a defined subset or specification-aligned set of EVM opcodes.

Constraints include:

• No dynamic opcode upgrades

• No miner-controlled opcode changes

• Fixed execution semantics across blocks

Unsupported or restricted opcodes, if any, are rejected deterministically by indexers.

All implementations must produce identical results for identical bytecode and calldata inputs.

Differences from Ethereum L1

Key architectural differences:

Consensus vs. Metaprotocol

• Ethereum L1 enforces execution at the consensus layer.

• The Programmable Module enforces execution at the metaprotocol layer through deterministic replay.

Gas Market

• Ethereum uses dynamic gas metering and gas auctions.

• The module abstracts gas; computation cost is expressed through Bitcoin transaction fees and inscription size.

State Storage

• Ethereum stores contract state directly in consensus-layer storage.

• The module derives state off-chain from ordered inscriptions.

Block Time

• Ethereum has ~12-second blocks.

• Bitcoin has ~10-minute blocks, impacting transaction throughput and confirmation cadence.

Finality

• Ethereum finality depends on consensus checkpoints.

• The module inherits Bitcoin settlement finality after sufficient block confirmations.

Runtime Constraints

Runtime is constrained by:

• Block-ordered replay

• Fixed runtime specification

• No access to external network calls

• No non-deterministic randomness

• No mutable global execution rules

All state transitions must be:

• Fully reproducible

• Independent of execution environment

• Deterministic across compliant implementations

Ensures:

• Verifiable contract state

• Infrastructure neutrality

• Replay-based auditability

EVM compatibility is achieved without modifying Bitcoin consensus rules, while preserving deterministic state derivation and canonical replay guarantees.

Full BRC2.0 Specification | GitHub | BRC-20 Programmable Module