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

<Tabs>
  <Tab title="Deploy">
    Inscribe compiled Solidity contract bytecode to Bitcoin. Indexers execute the constructor and assign the contract a Bitcoin-native address.

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

  <Tab title="Call">
    Invoke a function on a deployed contract. Indexers execute the call in their EVM environment and update contract state.

    ```json theme={null}
    {
      "p": "brc20-prog",
      "op": "call",
      "d": "0xA9059CBB..."
    }
    ```
  </Tab>

  <Tab title="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.

    ```json theme={null}
    {
      "p": "brc20-prog",
      "op": "transact",
      "tick": "ordi",
      "amt": "1000",
      "d": "0xA9059CBB..."
    }
    ```
  </Tab>
</Tabs>

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.

<Steps>
  <Step title="Deposit">
    Inscribe a deposit operation. Indexers lock your BRC-20 balance, and the contract receives an equivalent ERC-20-style balance internally.
  </Step>

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

  <Step title="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.
  </Step>
</Steps>

<Note>
  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.
</Note>

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

<Info>
  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.
</Info>

## What you can build

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

<CardGroup cols={2}>
  <Card title="Decentralized exchanges" icon="arrow-right-arrow-left">
    Constant-product AMMs (Uniswap-style) with instant swaps inside contracts. No PSBT coordination, no fragmented liquidity across marketplaces.
  </Card>

  <Card title="Lending protocols" icon="landmark">
    Collateralized lending with algorithmic interest rates, liquidations, and risk management — all executed deterministically by indexers.
  </Card>

  <Card title="Yield farming" icon="seedling">
    Staking contracts that reward liquidity providers with programmatic token emissions over time.
  </Card>

  <Card title="DAOs and governance" icon="people-group">
    Token-weighted voting with on-chain proposal execution and timelock mechanisms.
  </Card>

  <Card title="Options and derivatives" icon="chart-line">
    Complex financial instruments with automated settlement based on oracle data or Bitcoin state.
  </Card>

  <Card title="NFT marketplaces" icon="image">
    Programmable royalties, Dutch auctions, and collection-wide operations.
  </Card>
</CardGroup>

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.

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

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

  <Accordion title="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](/architecture/limitations) page before relying on timing assumptions.
  </Accordion>

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

<Tip>
  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.
</Tip>