> ## Documentation Index
> Fetch the complete documentation index at: https://docs.brc20.build/llms.txt
> Use this file to discover all available pages before exploring further.

# BRC2.0 module

> Technical reference for the BRC2.0 EVM-compatible execution layer built on Bitcoin, covering operation formats, deposit/withdraw mechanics, EVM compatibility, and the security model.

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:

<Steps>
  <Step title="Parse the inscription">
    Extract BRC2.0 JSON from the Ordinals envelope.
  </Step>

  <Step title="Validate the operation">
    Check signature, nonce, and gas limits.
  </Step>

  <Step title="Execute EVM bytecode">
    Run the transaction in the local EVM instance.
  </Step>

  <Step title="Update state">
    Commit storage changes, logs, and balance updates.
  </Step>

  <Step title="Achieve consensus">
    All indexers must produce identical state transitions.
  </Step>
</Steps>

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.

```json theme={null}
{
  "p": "brc20-prog",
  "op": "deploy",
  "d": "0x608060405234801561001057600080fd5b50..."
}
```

<ParamField body="p" type="string" required>
  Protocol identifier. Must equal `"brc20-prog"`.
</ParamField>

<ParamField body="op" type="string" required>
  Operation type. `"deploy"` or shorthand `"d"`.
</ParamField>

<ParamField body="d" type="string" required>
  Compiled Solidity deployment bytecode as a hex string. Generate with Hardhat, Foundry, or Remix.
</ParamField>

***

### Call

Invoke a function on a deployed contract. Indexers validate gas limits and update contract state accordingly.

```json theme={null}
{
  "p": "brc20-prog",
  "op": "call",
  "c": "<contract_address>",
  "b": "<calldata>"
}
```

<ParamField body="op" type="string" required>
  Operation type. `"call"` or shorthand `"c"`.
</ParamField>

<ParamField body="c" type="string" required>
  Address of the deployed contract to call.
</ParamField>

<ParamField body="b" type="string" required>
  ABI-encoded calldata for the function invocation.
</ParamField>

***

### 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.

```json theme={null}
{
  "p": "brc20-prog",
  "op": "transact",
  "b": "<calldata>"
}
```

<ParamField body="op" type="string" required>
  Operation type. `"transact"` or shorthand `"t"`.
</ParamField>

<ParamField body="b" type="string" required>
  ABI-encoded calldata including deposit parameters and function arguments.
</ParamField>

***

## Deposit and withdraw mechanics

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

### Deposit flow

<Steps>
  <Step title="Create deposit inscription">
    Inscribe a deposit operation specifying the ticker and amount.
  </Step>

  <Step title="Send to OP_RETURN">
    Send the inscription to `OP_RETURN "BRC20PROG"` to route it into the BRC2.0 module.
  </Step>

  <Step title="Indexers lock BRC-20 balance">
    Tokens move from BRC-20 state to "deposited" state.
  </Step>

  <Step title="Mint internal token balance">
    The contract receives an equivalent ERC-20-compatible balance.
  </Step>
</Steps>

```json theme={null}
{
  "p": "brc-20",
  "op": "deposit",
  "tick": "ordi",
  "amt": "1000"
}
```

<ParamField body="op" type="string" required>
  Must equal `"deposit"`.
</ParamField>

<ParamField body="tick" type="string" required>
  Ticker of the BRC-20 token to deposit.
</ParamField>

<ParamField body="amt" type="string" required>
  Amount to deposit as a stringified integer.
</ParamField>

### 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.

```json theme={null}
{
  "p": "brc20-module",
  "op": "withdraw",
  "tick": "ordi",
  "amt": "10",
  "module": "BRC20PROG"
}
```

<ParamField body="p" type="string" required>
  Must equal `"brc20-module"`.
</ParamField>

<ParamField body="op" type="string" required>
  Must equal `"withdraw"`.
</ParamField>

<ParamField body="tick" type="string" required>
  Ticker of the token to withdraw.
</ParamField>

<ParamField body="amt" type="string" required>
  Amount to withdraw as a stringified integer.
</ParamField>

<ParamField body="module" type="string" required>
  Module identifier. Must equal `"BRC20PROG"`.
</ParamField>

<Note>
  This creates a trustless bridge — no multisig or validator set is required. Indexers enforce the rules deterministically based on inscriptions and EVM execution.
</Note>

***

## EVM compatibility

BRC2.0 aims for Solidity compatibility but has key differences from Ethereum.

<AccordionGroup>
  <Accordion title="Supported">
    * Solidity syntax and features
    * Standard library contracts (OpenZeppelin, etc.)
    * Events and logs
    * Storage operations (`SSTORE`, `SLOAD`)
    * Standard opcodes (`ADD`, `MUL`, `CALL`, etc.)
  </Accordion>

  <Accordion title="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                                             |
  </Accordion>

  <Accordion title="Not supported">
    * Native ETH (`msg.value`) — use BRC-20 token deposits
    * Ethereum-style key-based message signing from contract-generated addresses
  </Accordion>
</AccordionGroup>

***

## 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

<AccordionGroup>
  <Accordion title="Immutability">
    Contract bytecode inscribed on Bitcoin cannot be changed. All operations are permanently recorded.
  </Accordion>

  <Accordion title="Determinism">
    All indexers must produce identical state given the same inscriptions. The protocol is a deterministic state machine.
  </Accordion>

  <Accordion title="Social consensus">
    If indexers diverge, the community must choose the canonical implementation. Reference implementations and test suites are essential.
  </Accordion>

  <Accordion title="Upgradability">
    Use proxy patterns (similar to Ethereum) for upgradeable contracts.
  </Accordion>

  <Accordion title="Precompile trust">
    Bitcoin verification precompiles rely on correct implementation in indexer code.
  </Accordion>
</AccordionGroup>

<Warning>
  BRC2.0 security depends on indexer correctness. If the EVM implementation has bugs or deviates from specification, contract execution may diverge across indexers.
</Warning>

***

## Development workflow

<Steps>
  <Step title="Write Solidity contracts">
    Use Hardhat, Foundry, or Remix as usual.
  </Step>

  <Step title="Test locally">
    Deploy to a local BRC2.0 node or testnet.
  </Step>

  <Step title="Compile to bytecode">
    Generate deployment bytecode and ABI.
  </Step>

  <Step title="Inscribe contract">
    Create a deploy inscription with the bytecode.
  </Step>

  <Step title="Wait for confirmation">
    A Bitcoin block must confirm (\~10 minutes).
  </Step>

  <Step title="Interact via inscriptions">
    Call functions by inscribing call operations.
  </Step>

  <Step title="Monitor events">
    Subscribe to indexer APIs for contract logs.
  </Step>
</Steps>

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

<Tabs>
  <Tab title="Use BRC-20 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
  </Tab>

  <Tab title="Use BRC2.0 when">
    * Building DeFi protocols (DEXes, lending, staking)
    * Requiring conditional logic or multi-party interactions
    * Implementing governance or DAO functionality
    * You need access to Bitcoin state (transaction verification, locks)
    * Building composable applications that interact with other contracts
  </Tab>
</Tabs>