# Account and Identity Model
Source: https://docs.brc20.build/architecture/account-and-identity-model
The account model differs fundamentally from Ethereum and is important to
understand before writing any authorization logic.
## **No Private Keys for EVM Addresses**
EVM addresses in this system **do not have associated private keys**.
An EVM address is deterministically derived from a Bitcoin wallet’s output
script (pkscript) using:
`evm_address = keccak256(bitcoin_pkscript_bytes)[12:]`
This address exists solely as an execution identity inside the EVM.\
It cannot sign messages and cannot produce Ethereum-style signatures.
As a result, any authentication scheme that assumes the existence of an ECDSA
key for an EVM address will not work.
## **Bitcoin Wallet as Identity**
A user’s **Bitcoin wallet is their identity**.
Ownership and intent are proven by signing messages using Bitcoin keys and
submitting those signatures alongside contract calls. The EVM address derived
from the wallet script serves as the canonical on-chain identifier for that
user.
Multiple Bitcoin addresses or scripts correspond to different EVM addresses,
even if controlled by the same wallet software.
## **BIP-322 Instead of ecrecover**
Ethereum’s ecrecover precompile cannot be used for authentication.
Instead, authentication can be performed using **BIP-322 message signatures**,
verified inside smart contracts via a dedicated precompiled contract.
The recommended flow is:
1. The user signs a message using their Bitcoin wallet (BIP-322).
2. The signature and signed message are passed as calldata.
3. The contract calls the BIP-322 verification precompile.
4. If verification succeeds, the derived EVM address is treated as the
authenticated user.
Helper libraries are provided to standardize this pattern.
## **Interpreting msg.sender**
msg.sender represents the **derived EVM address of the Bitcoin script** that
initiated the operation.
It should be interpreted as:
“The Bitcoin script that authorized this execution,”
Not as an Ethereum-style externally owned account.
Because this address cannot sign, msg.sender should not be used as proof of
cryptographic intent by itself. Any action that requires explicit user consent
must additionally verify a BIP-322 signature.
## **Recommended Authorization Patterns**
### **Recommended**
* Verify BIP-322 signatures inside the contract and map them to derived EVM
addresses
* Use explicit signed messages for sensitive actions (withdrawals, approvals,
upgrades)
* Treat msg.sender as a stable identifier, not a signer
* Store permissions and balances against derived EVM addresses
### **Anti-Patterns**
* Using ecrecover or Ethereum-style signature assumptions
* Assuming msg.sender can produce signatures
* Relying on tx.origin
* Designing replayable actions without explicit nonce or domain separation
If contracts treat Bitcoin wallets as the root of identity and use BIP-322 for
intent verification, authorization remains explicit, verifiable, and compatible
with existing Bitcoin wallet infrastructure.
# Bitcoin-Native Superpowers
Source: https://docs.brc20.build/architecture/bitcoin-native-superpowers
By leveraging Bitcoin as the base layer, smart contracts gain abilities that are
impossible or impractical on Ethereum or other EVM chains. These “superpowers”
let developers build Bitcoin-native dApps with deep protocol awareness.
## **Transaction Introspection**
Contracts can inspect Bitcoin transactions directly via precompiled contracts.
This allows you to:
* Verify that a user sent a specific UTXO or satoshis before executing logic
* Build token bonding curves pegged to Bitcoin flows
* Enforce custom asset entry conditions without relying on off-chain bridges
Effectively, contracts can reason about the **Bitcoin ledger itself**.
## **Satoshi Location**
Contracts can determine the exact location of a satoshi within a transaction
output. This enables:
* Precision tracking of scarce or ordinalized satoshis
* Conditional execution based on which satoshi or output a user controls
* Novel NFT-like use cases tied directly to individual satoshis
This level of granularity is **impossible on Ethereum**, where native assets are
fungible and abstracted.
## **Timelock Script Generation**
Contracts can generate Bitcoin timelock scripts programmatically:
* Enforce time- or height-based release of funds
* Build vaults, escrows, and delayed payouts without any external oracle
* Combine with on-chain contract logic for hybrid BTC+EVM workflows
These scripts are fully compatible with Bitcoin, meaning users can move funds in
and out without leaving the Bitcoin security model.
## **Examples of What Ethereum Cannot Do**
1. **Ordinalized Asset Control:** Track specific satoshis, not just fungible
balances.
2. **BTC-Backed AMMs and Bonding Curves:** Accept and reason about raw Bitcoin
inputs natively, without wrapping or trust intermediaries.
3. **Hybrid Contracts:** Combine EVM logic with Bitcoin timelocked ordinals,
UTXO proofs, or ordinals in a single execution.
4. **Fully On-Chain Settlement:** Exit BRC20 tokens back to Bitcoin directly,
with no bridge or multisig dependency.
In short: these superpowers let you **write contracts that are both EVM-native
and Bitcoin-native**, opening a class of applications that simply cannot exist
on Ethereum alone.
# Contract lifecycle
Source: https://docs.brc20.build/architecture/contract-lifecycle
Follow a smart contract from deployment through calls, state persistence, event emission, and withdrawal back to BRC-20.
Smart contracts in BRC2.0 follow a familiar lifecycle. The key difference from Ethereum is how each action is submitted: rather than broadcasting to an EVM mempool, every operation is inscribed onto Bitcoin and processed when confirmed.
## Overview
```
Deploy Call Persist State Emit Logs Withdraw
│ │ │ │ │
Inscribe Inscribe Committed Standard Released
bytecode → calldata → on success → EVM events → to BRC-20
to module to module Replayed from Reproducible No bridge
Bitcoin history by indexers required
```
## Deploy
Compile your Solidity contract to EVM bytecode using the standard toolchain (Hardhat, Foundry, etc.). The output is identical to what you would deploy on Ethereum.
```bash theme={null}
forge build
```
Create an Ordinals inscription that contains your compiled bytecode and submit it to the BRC2.0 Programmable Module address. This is the equivalent of sending a deployment transaction on Ethereum.
The deployment is executed deterministically when the inscription is indexed. The contract address is derived using standard EVM creation semantics — the same formula as `CREATE` on Ethereum.
Once indexed, the contract is part of the global execution state. Any subsequent inscription can call it.
There is no deployment transaction in the Ethereum sense. Deployment is triggered by a Bitcoin transaction carrying the inscription data. The contract address is deterministic and can be computed before the Bitcoin transaction confirms.
## Call
Contracts are invoked by inscribing calldata and submitting it to the module.
From the contract's perspective, the call behaves exactly like a normal EVM transaction:
* Calldata is ABI-encoded
* Execution either succeeds or reverts
* All EVM opcodes behave as expected
```solidity theme={null}
// Standard ABI-encoded calldata — no changes needed
bytes memory calldata = abi.encodeWithSelector(
MyContract.transfer.selector,
recipient,
amount
);
```
Calls may be authenticated using either:
* **Bitcoin-native identity** — via BIP-322 signature passed as calldata
* **Signed EVM transactions** — using the `transact` operation, if explicitly supported
Multiple contracts can be composed and called within a single execution, subject to gas limits derived from inscription size.
Minimize calldata size to reduce Bitcoin fees. Use tightly packed ABI encoding and consider compression (NADA or ZSTD) for large payloads.
## Persist state
Contract state is persisted exactly as in Ethereum:
* Storage writes are committed on successful execution
* Reverted calls do not modify state
* State transitions are deterministic and replayable
State is **not stored on Bitcoin directly**. Instead, it is reconstructed by replaying all valid inscriptions in order. As long as two indexers process the same Bitcoin history, they will arrive at identical contract state.
This is conceptually similar to Ethereum archive node replay. Any compliant indexer can reconstruct the full state from the Bitcoin chain alone — no external data source is required.
## Emit logs
Contracts emit standard EVM events. These logs:
* Follow Ethereum's event model exactly (`emit`, indexed topics, ABI-encoded data)
* Can be indexed by off-chain services and frontends using standard EVM tooling
* Are deterministic and replayable from Bitcoin history
```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
function transfer(address to, uint256 amount) external {
// ... transfer logic
emit Transfer(msg.sender, to, amount);
}
```
Logs are not written to Bitcoin. They are derived from execution and can be reproduced by any compliant indexer.
Standard Ethereum event indexers and subgraph tooling can be adapted to consume BRC2.0 logs, since the event format is identical to Ethereum.
## Withdraw back to BRC-20
Contracts can release assets back to base BRC-20 balances via withdrawals.
How it works:
* Assets are locked under contract control during execution
* A withdrawal reduces the contract's internal balance
* The corresponding BRC-20 balance becomes spendable on Bitcoin again
Withdrawals are finalized through Bitcoin transactions and **do not rely on bridges or custodians**. From your contract's perspective, this behaves like exiting from a smart contract back to the base asset layer, with Bitcoin providing final settlement.
```solidity theme={null}
// Conceptual example — actual withdrawal interface defined in protocol docs
function withdraw(address recipient, uint256 amount) external {
require(balances[msg.sender] >= amount, "Insufficient balance");
balances[msg.sender] -= amount;
// Triggers BRC-20 release back to the recipient's Bitcoin address
BRC20_MODULE.withdraw(recipient, amount);
}
```
Withdrawals are finalized on Bitcoin and are irreversible once confirmed. Ensure your contract's authorization logic is correct before releasing assets.
## Lifecycle summary
| Phase | Submitted as | Ethereum equivalent |
| ----------------- | ---------------------- | ----------------------------------------- |
| Deploy | Inscription (bytecode) | `eth_sendTransaction` (contract creation) |
| Call | Inscription (calldata) | `eth_sendTransaction` (contract call) |
| State persistence | Deterministic replay | EVM state trie update |
| Logs | Derived from execution | EVM receipt logs |
| Withdraw | Bitcoin transaction | N/A (exits to native BTC layer) |
# Gas and Cost Intuition
Source: https://docs.brc20.build/architecture/gas-and-cost-intuition
While there is no native gas token, execution is **still limited and metered**.
Understanding how gas works in this environment is critical for writing
efficient contracts and predicting costs.
## **Inscription Size ↔ Maximum Execution**
Each inscription on Bitcoin pre-pays execution resources:
* Gas is **directly proportional to the size of the inscription**
* Larger inscriptions allow more computation and state changes
* Each byte of an inscription grants a fixed gas allowance
Think of it as “your transaction byte size is your gas budget.” Unlike Ethereum,
there’s no dynamic pricing—**execution cost is baked into the transaction size
and Bitcoin fee**.
## **How to Think About Optimization**
* Smaller calldata and bytecode = lower fees, faster indexing, and fewer block
constraints
* Reuse logic and precompiled contracts where possible to reduce instruction
count
* Compress calldata using NADA or ZSTD to minimise fees where it matters
Optimization is about **packing more computation into fewer bytes**, rather than
chasing gas prices.
## **Why Padding Exists and When to Use It**
* JSON padding allows developers to **increase the gas limit artificially** for
an operation without changing its logic
* Useful when an operation requires more computation than the current calldata
size allows
* Must be done responsibly: padding increases Bitcoin fees and should only be
used to cover legitimate computational needs
## **Rough Cost Envelopes (Not Promises)**
Costs scale with:
1. **Byte size of the inscription**
2. **Bitcoin network fee rate**
As a guideline:
* Small calls (\~100 bytes) are inexpensive
* Large deployments (\~10–100 KB) can be significant
* Compression often reduces fees by 3–5x depending on calldata patterns
Always estimate gas requirements **before inscribing**, and consider padding
strategically. The key principle: **execution cost is deterministic and
proportional to the resources you allocate in Bitcoin**.
# Limitations and Sharp Edges
Source: https://docs.brc20.build/architecture/limitations-and-sharp-edges
While the system offers powerful Bitcoin-native smart contract capabilities, it
comes with important constraints and behavioral differences that developers must
understand.
## **Latency**
* Execution depends on Bitcoin block confirmation
* Transactions are not instantaneous, expect multiple-minute delays
* User-facing dApps should design for asynchronous flows and optimistic UI
updates
## **No Synchronous Bitcoin State**
* Contracts cannot query Bitcoin state in real-time
* All operations are based on **indexed, confirmed inscriptions**
* Any assumptions of instant UTXO or balance visibility might lead to incorrect
logic
## **Indexer Determinism Assumptions**
* Contract state is reconstructed by **deterministic replay of inscriptions**
* Indexers must process inscriptions in order and handle reorgs gracefully
* For developers, this means contracts should not assume simultaneous or
out-of-order execution
* Conceptually similar to Ethereum replay tests, but the underlying chain is
Bitcoin
# Mental Model: EVM Developer Edition
Source: https://docs.brc20.build/architecture/mental-model-evm-developer-edition
The simplest way to think about this system is:
* **Ethereum execution, but blocks are Bitcoin blocks.**
Smart contracts run in an EVM and follow familiar Ethereum semantics. The
difference is how transactions enter the system and how execution is paid for.
## **Blocks**
Instead of Ethereum blocks, **Bitcoin blocks define ordering**.
Operations are processed in the order their inscriptions appear on Bitcoin.
There is no separate block production, proposer role, or mempool for the EVM
layer.
If a Bitcoin transaction is reordered or reorged, the corresponding EVM
execution is replayed accordingly.
## **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, interaction happens entirely 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 amount of gas
* Larger inscriptions allow more computation
* Gas is prepaid by paying higher Bitcoin fees for larger transactions
This means:
* You never reason about gas markets or base fees
* There is no priority fee or bidding mechanism
* The cost of computation is directly tied to Bitcoin’s fee market
## **What Feels the Same as Ethereum**
* Solidity smart contracts
* EVM execution semantics
* Contract storage and state persistence
* ABI encoding and calldata
* Events and logs
* ERC-style token logic
Most existing Solidity code works unchanged, provided it does not rely on
Ethereum-specific assumptions.
## **What Is Different**
* Accounts do not have private keys; identity is derived from Bitcoin scripts
* ecrecover is not usable for authentication, and BIP-322 can be used instead
* There is no notion of gas price or gas refunds
* Transactions are not instantaneous and follow Bitcoin block times
* Execution is triggered by inscriptions, not by an EVM mempool
If you treat Bitcoin as the settlement and ordering layer, and the EVM as a
deterministic execution module layered on top, the system behaves predictably
and avoids the trust tradeoffs common in rollups and Layer 2 designs.
# What is BRC2.0?
Source: https://docs.brc20.build/architecture/what-is-brc20-point-0
BRC2.0 is **EVM execution anchored to Bitcoin**, using Ordinals inscriptions as
the data and ordering layer, and designed to be **fully compatible with BRC-20
assets**.
* Developers write and deploy **standard Solidity smart contracts**.
* Users interact with those contracts by submitting **Bitcoin transactions**.
* Contract state is computed deterministically by replaying inscriptions through
an EVM execution engine.
* Bitcoin provides transaction ordering and the fee market.
* The EVM provides programmability.
Everything else is intentionally minimized.
There are:
* No bridges
* No multisignature custodians
* No sequencers
* No validator networks
* No gas token
* No Layer 2 trust assumptions
For Ethereum developers, the mental model is straightforward:
* Execution semantics follow the EVM
* EVM bytecode and calldata are delivered via Bitcoin blocks and inscriptions
* Gas is prepaid through inscription size, not a native token
For builders accustomed to Layer 2 systems:
* Users do not need new wallets
* Assets are not wrapped or bridged
* Withdrawals do not depend on committees or challenge periods
* Failure modes are explicit and verifiable on Bitcoin
Why this matters:
* You get expressive smart contracts without departing from Bitcoin’s security
model
* You reuse the existing Solidity and EVM tooling ecosystem (such as Foundry,
Hardhat)
* You can build Bitcoin-native applications that interact directly with **BRC-20
tokens and introspecting Bitcoin transactions.**
* Users only pay Bitcoin transaction fees—there are no additional protocol-level
costs
Don’t think it’s “Ethereum on Bitcoin”. It is **Bitcoin as the base layer, with
the EVM as a programmable execution module**, designed to integrate cleanly with
existing developer workflows while avoiding new trust assumptions.
# Writing Contracts Safely
Source: https://docs.brc20.build/architecture/writing-contracts-safely
Most Solidity contracts can be deployed and executed without modification.
However, some common Ethereum assumptions do not hold and should be addressed
explicitly.
## **Solidity Version and EVM Assumptions**
The execution environment follows standard EVM semantics and supports modern
Solidity versions.
You can assume:
* Deterministic EVM execution
* Standard storage, memory, and calldata behavior
* ABI encoding and decoding identical to Ethereum
You should not assume:
* Ethereum-style externally owned accounts
* A gas price market
* A synchronous transaction lifecycle
Contracts should be written as if execution is deterministic and replayable,
with all user intent explicitly provided as input.
## **What Breaks**
Certain patterns common in Ethereum contracts are incompatible or unsafe in this
environment.
* **ecrecover**EVM addresses do not have private keys (as they are generated
using Bitcoin pkscripts). Any authentication logic relying on ecrecover will
fail or be meaningless. Use BIP-322 verification via the provided precompile
instead.
* **tx.origin Assumptions** There is no concept of a user-controlled EOA
originating a call chain. Relying on tx.origin for authorization or security
checks is unsafe.
## **Gas-Price-Based Logic**
There is no dynamic gas price, base fee, or priority fee. Contracts that rely on
gas price for:
* Anti-front-running logic
* Fee estimation
* Dynamic pricing
will not behave as intended. Execution limits are determined by inscription
size, not by runtime bidding.
## **What Works Well**
Several common contract patterns translate cleanly and predictably.
**ERC-20 / ERC-721 Logic -** Token standards, balances, allowances, and
transfers behave as expected. These patterns are well-suited for managing assets
within the execution environment.
**Bonding Curves and AMM-Style Math -** Purely deterministic pricing logic works
well, especially when combined with Bitcoin transaction introspection for
BTC-denominated flows.
**Vaults and Escrows -** Contracts that custody assets under explicit rules,
timelocks, or conditional releases are a strong fit, particularly when exits are
settled back to base BRC-20 balances.
**Bitcoin-Aware Contracts via Precompiles** Precompiled contracts enable direct
interaction with Bitcoin data, including:
* Transaction inspection
* Satoshi location tracking
* Timelock script generation
These capabilities allow contracts to enforce Bitcoin-native constraints that
are not possible on Ethereum.
**As a general rule:** If your contract logic is explicit, deterministic, and
does not rely on Ethereum-specific account or fee assumptions, it will behave
predictably and safely in this environment.
# Deploy a BRC2.0 Smart Contract
Source: https://docs.brc20.build/guides/deploy-a-brc20-smart-contract
WIP
# Deploy a token
Source: https://docs.brc20.build/guides/deploy-a-brc20-token
Step-by-step guide to deploying a BRC-20 token on Bitcoin using Ordinals inscriptions.
BRC-20 tokens live entirely on Bitcoin. You deploy, mint, and transfer them by inscribing structured JSON into satoshis — no smart contracts required. Off-chain indexers read those inscriptions in order to derive balances and token state.
You can create BRC-20 inscriptions using platforms such as [UniSat](https://unisat.io) or [Ordinals Wallet](https://ordinalswallet.com). These tools handle the Bitcoin transaction construction for you — you supply the JSON, they handle the rest.
Every BRC-20 operation is a JSON object inscribed onto a satoshi. The `deploy` operation defines a new token and sets its rules. All subsequent mints are bound by these rules.
The required and optional fields are:
| Field | Required | Description |
| ----------- | -------- | --------------------------------------------------------- |
| `p` | Yes | Protocol identifier. Always `"brc-20"`. |
| `op` | Yes | Operation type. `"deploy"` for this step. |
| `tick` | Yes | Ticker symbol (see step 2 for length rules). |
| `max` | Yes | Maximum total supply, as a stringified integer. |
| `lim` | No | Maximum amount any single mint inscription can claim. |
| `self_mint` | No | Set to `"true"` to restrict minting to the deployer only. |
```json theme={null}
{
"p": "brc-20",
"op": "deploy",
"tick": "ordi",
"max": "21000000",
"lim": "1000"
}
```
The first valid deploy inscription for a ticker is canonical. Any later deploy inscription for the same ticker is ignored by indexers.
The ticker length determines which namespace your token occupies and which rules apply.
**4-byte tickers** (e.g. `ordi`, `sats`) are the original BRC-20 namespace. Most are already claimed on mainnet.
**5-byte tickers** support self-minting. They are isolated from the 4-byte namespace so legacy indexers that do not support self-minting will ignore them.
**6-byte tickers** were introduced with BRC2.0 Phase 1 and are designed for programmable and composable use cases. They must:
* Be exactly 6 characters
* Match the regex `^[A-Za-z0-9-]{6}$`
* Be treated case-insensitively
**Ticker sniping is real.** Once you broadcast your desired ticker in any public channel, someone can race to inscribe it first. For 6-byte tickers, use the **pre-deploy mechanism** to commit to a ticker before revealing it.
The pre-deploy inscription binds the ticker to your wallet's pkscript and a secret salt using a double-SHA256 commitment:
```
hash = sha256(sha256(ticker_bytes + salt_bytes + deployer_pkscript))
```
First, inscribe the commitment:
```json theme={null}
{
"p": "brc-20",
"op": "predeploy",
"hash": ""
}
```
Then, at least 3 Bitcoin blocks later, inscribe the actual deploy **as a child** of the pre-deploy inscription:
```json theme={null}
{
"p": "brc-20",
"op": "deploy",
"tick": "ticker",
"salt": "",
"self_mint": "true",
"max": "21000000",
"lim": "1000"
}
```
Pre-deploy inscriptions do not expire. The deploy must be a child of the pre-deploy and must be confirmed at least 3 blocks after it.
Construct the JSON for your token. The examples below cover the two main issuance models.
**Public mint** — anyone can mint until the supply cap is reached:
```json theme={null}
{
"p": "brc-20",
"op": "deploy",
"tick": "ordi",
"max": "21000000",
"lim": "1000"
}
```
**Self-mint** — only the deployer can mint. Requires a 5-byte or 6-byte ticker:
```json theme={null}
{
"p": "brc-20",
"op": "deploy",
"self_mint": "true",
"tick": "token",
"max": "21000000",
"lim": "1000"
}
```
Under self-mint semantics you can also set `"max": "0"` to indicate unlimited supply (bounded only by the indexer's uint64 ceiling). Tokens cannot be destroyed, and sending to an unspendable address does not reduce the mint capacity.
```json Public mint deploy theme={null}
{
"p": "brc-20",
"op": "deploy",
"tick": "ordi",
"max": "21000000",
"lim": "1000"
}
```
```json Self-mint deploy theme={null}
{
"p": "brc-20",
"op": "deploy",
"self_mint": "true",
"tick": "token",
"max": "21000000",
"lim": "1000"
}
```
```json Self-mint with unlimited supply theme={null}
{
"p": "brc-20",
"op": "deploy",
"self_mint": "true",
"tick": "token",
"max": "0",
"lim": "1000"
}
```
Inscribe this JSON as a text/plain inscription onto a satoshi and broadcast the Bitcoin transaction.
BRC-20 state is derived from the **ordered sequence of confirmed Bitcoin inscriptions**. Your deploy inscription only takes effect once the Bitcoin block containing it is confirmed.
Bitcoin produces a new block approximately every 10 minutes. Until confirmation, indexers will not recognise your token as deployed.
One confirmation is sufficient for the token to appear in indexers. You do not need to wait for multiple confirmations before proceeding to mint.
Once your deploy inscription is confirmed, anyone (or only you, for self-mint tokens) can mint tokens up to the `lim` amount per inscription.
```json theme={null}
{
"p": "brc-20",
"op": "mint",
"tick": "ordi",
"amt": "1000"
}
```
* `amt` must be a stringified integer and cannot exceed the `lim` value set at deploy time.
* Minting stops once the cumulative minted supply reaches the `max` value. Any mint inscription that would exceed the cap is ignored by indexers.
* For self-mint tokens, each mint inscription must be inscribed as a **child** of the original deploy inscription. Mint inscriptions without this parent relationship are invalid.
Transferring BRC-20 tokens is a **two-step process**:
1. **Inscribe a transfer inscription** to lock the specified amount against your address.
2. **Send the satoshi containing that inscription** to the recipient's Taproot address (`bc1p...`).
**Step 1 — inscribe the transfer:**
```json theme={null}
{
"p": "brc-20",
"op": "transfer",
"tick": "ordi",
"amt": "500"
}
```
There is no recipient address in the JSON. The inscription simply moves the `amt` from your available balance into a "pending transfer" state.
**Step 2 — send the satoshi to the recipient:**
Send the satoshi that carries the transfer inscription to the recipient's Taproot address. When indexers see this Bitcoin transaction, they credit the recipient's balance for the specified amount.
If you send the transfer inscription satoshi to yourself or to a non-Taproot address, the transfer may be credited back to you or treated as invalid depending on the indexer. Always verify the recipient address before broadcasting.
# Use with AI
Source: https://docs.brc20.build/guides/use-with-ai
Connect BRC20 docs to your AI tools for free via MCP
The BRC20 documentation exposes an [MCP (Model Context Protocol)](https://modelcontextprotocol.io) server, allowing AI tools like Claude, Cursor, and ChatGPT to query the docs directly — no per-message fees.
## Claude Desktop
Add the following to your `claude_desktop_config.json`:
```json theme={null}
{
"mcpServers": {
"brc20-docs": {
"type": "http",
"url": "https://docs.brc20.build/mcp"
}
}
}
```
## Cursor
Open the command palette, search for **Open MCP settings**, and add:
```json theme={null}
{
"mcpServers": {
"brc20-docs": {
"url": "https://docs.brc20.build/mcp"
}
}
}
```
## VS Code
Add the following to `.vscode/mcp.json` in your project:
```json theme={null}
{
"servers": {
"brc20-docs": {
"type": "http",
"url": "https://docs.brc20.build/mcp"
}
}
}
```
## Claude Code
```bash theme={null}
claude mcp add --transport http brc20-docs https://docs.brc20.build/mcp
```
Once connected, your AI assistant can search and reference the BRC20 documentation in real-time.
# BRC20 Documentation
Source: https://docs.brc20.build/index
Develop applications and protocols that leverage the security and permanence of
Bitcoin.
## Contents
### Overview
* [What is BRC-20?](overview/what-is-brc20.md)
* [BRC20 Programmable Module](overview/brc20-programmable-module.md)
* [Historical and Social Context](overview/historical-and-social-context.md)
* [Existing Documentation](overview/existing-documentation.md)
### Architecture
* [What is BRC2.0?](architecture/what-is-brc20-point-0.md)
* [Mental Model (EVM Developer Edition)](architecture/mental-model-evm-developer-edition.md)
* [Account & Identity Model](architecture/account-and-identity-model.md)
* [Contract Lifecycle](architecture/contract-lifecycle.md)
* [Writing Contracts Safely](architecture/writing-contracts-safely.md)
* [Bitcoin-Native Superpowers](architecture/bitcoin-native-superpowers.md)
* [Gas & Cost Intuition](architecture/gas-and-cost-intuition.md)
* [Limitations & Sharp Edges](architecture/limitations-and-sharp-edges.md)
### Protocol
* [BRC-20](protocol/brc20.md)
* [BRC20 Programmable Module](protocol/brc20-programmable-module.md)
* [BiS AMM](protocol/bis-amm.md)
### Guides
* [Deploy a BRC-20 Token](guides/deploy-a-brc20-token.md)
* [Deploy a BRC2.0 Smart Contract](guides/deploy-a-brc20-smart-contract.md)
* [Use with AI](guides/use-with-ai.md)
## External Links
* [BRC2.0 Block Explorer](https://explorer.brc20.build)
* [BRC2.0 Network Stats](https://explorer.brc20.build/stats)
* [Best in Slot](https://bestinslot.xyz)
# BRC2.0 programmable module
Source: https://docs.brc20.build/overview/brc20-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.
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..."
}
```
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..."
}
```
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..."
}
```
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.
Inscribe a deposit operation. Indexers lock your BRC-20 balance, and the contract receives an equivalent ERC-20-style balance internally.
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.
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:
Constant-product AMMs (Uniswap-style) with instant swaps inside contracts. No PSBT coordination, no fragmented liquidity across marketplaces.
Collateralized lending with algorithmic interest rates, liquidations, and risk management — all executed deterministically by indexers.
Staking contracts that reward liquidity providers with programmatic token emissions over time.
Token-weighted voting with on-chain proposal execution and timelock mechanisms.
Complex financial instruments with automated settlement based on oracle data or Bitcoin state.
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.
Standard Solidity syntax, OpenZeppelin contracts, events and logs, storage operations, and familiar development tools (Hardhat, Foundry, Remix) all work with minimal or no changes.
* **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
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.
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.
# Existing Documentation
Source: https://docs.brc20.build/overview/existing-documentation
## Primary protocol specifications
The foundational BRC-20 documentation exists across two authoritative sources:
Domo's original specification and the Layer1 Foundation's updated protocol
documentation.
### Original BRC-20 whitepaper
* **URL:** [https://domo-2.gitbook.io/brc-20-experiment](https://domo-2.gitbook.io/brc-20-experiment)
* **Type:** Original protocol specification
* **Source:** Official/Primary (authored by [@domodata](https://x.com/domodata),
BRC-20 creator)
* **Description:** The "definitive brc-20 white paper" containing the three core
operations (deploy, mint, transfer), JSON inscription format specifications,
balance state rules, and technical constraints including uint128 standard with
max 18 decimals. Explicitly designated as unalterable.
### Layer1 Foundation protocol documentation
* **URL:**
[https://layer1.gitbook.io/layer1-foundation/protocols/brc-20/documentation](https://layer1.gitbook.io/layer1-foundation/protocols/brc-20/documentation)
* **Type:** Updated protocol documentation
* **Source:** Official/Primary (Layer1 Foundation)
* **Description:** Current official documentation incorporating all protocol
updates: block 816,000 ord version freeze (v0.90), Jubilee upgrade (ord 0.14),
and block 837,090 additions including self-mint functionality, 5-byte tickers,
and burn mechanism via OP\_RETURN.
### Layer1 Foundation governance portal
* **URL:** [https://layer1.foundation/brc20](https://layer1.foundation/brc20)
* **Type:** Governance and organization portal
* **Source:** Official/Primary
* **Description:** Official non-profit organization page listing governance
structure (President: Domo; Vice President: Isabel Foxen Duke), lead
maintainers (Best in Slot, UniSat), and partner organizations. Links to
official forum at [https://l1f.discourse.group/](https://l1f.discourse.group/).
### Protocol improvement proposals
* **URL:**
[https://layer1.gitbook.io/layer1-foundation/protocols/brc-20/proposals](https://layer1.gitbook.io/layer1-foundation/protocols/brc-20/proposals)
* **Type:** Protocol improvement proposals
* **Source:** Official/Primary
* **Description:** Documents approved and pending proposals including Modular
Complexity, Ord Version Freeze, Core Function Cleanup, and BRC20 IP1 (Issuance
and Burn Enhancements).
## BRC2.0 technical documentation
BRC2.0 introduces EVM smart contract execution to Bitcoin's Layer 1 without
bridges or Layer 2 solutions. Gas costs are handled at the indexer level—users
pay only Bitcoin transaction fees.
### BRC2.0 programmable module repository
* **URL:** [https://github.com/bestinslot-xyz/brc20-programmable-module](https://github.com/bestinslot-xyz/brc20-programmable-module)
* **Type:** Core implementation repository
* **Source:** Official/Primary (Best in Slot)
* **Description:** Rust implementation using revm (Rust EVM) execution engine.
Provides JSON-RPC 2.0 server supporting standard eth\_\* methods plus custom
brc20\_\* methods.
### Layer1 Foundation BRC2.0 proposal
* **URL:**
[https://l1f.discourse.group/t/brc2-0-programmable-module-proposal/766](https://l1f.discourse.group/t/brc2-0-programmable-module-proposal/766)
* **Type:** Protocol specification/technical whitepaper
* **Source:** Official/Primary (published March 31, 2025)
* **Description:** Complete architectural specification detailing EVM execution
engine, address translation formula, smart contract deployment via
inscriptions, and custom Bitcoin precompiles at addresses 0x...ff through
0x...fb.
### BRC2.0 proposals repository
* **URL:** [https://github.com/bestinslot-xyz/brc20-proposals](https://github.com/bestinslot-xyz/brc20-proposals)
* **Type:** Protocol improvement proposals
* **Source:** Official/Primary
* **Description:** Formal BRC improvement proposals including:
* 000: Programmable Module specification
* 001: 6-byte ticker namespace
* 002: BRC20 precompile removal
* 003: EVM upgrade to Prague
* 004: Bitcoin transaction ID precompile
### BRC2.0 explorer
* **Explorer URL** **(Mainnet):**
[https://explorer.brc20.build](https://explorer.brc20.build/)
* **Explorer URL (Signet):** [https://explorer.bestinslot.xyz/signet](https://explorer.bestinslot.xyz/signet)
* **Type:** Development tools
* **Source:** Official
* **Description:** BRC2.0 chain with contract and transaction explorer.
Activation height 230,000 on Signet, 923690 on Mainnet.
## Ordinals protocol documentation
BRC-20 operates as a layer built on Ordinals. Understanding the underlying
ordinal theory is essential for protocol development.
### Ordinal Theory Handbook
* **URL:** [https://docs.ordinals.com/](https://docs.ordinals.com/)
* **Type:** Official protocol documentation
* **Source:** Official/Primary (Casey Rodarmor, Raph Japh)
* **Description:** Definitive guide covering ordinal numbering scheme, five
notation systems (Integer, Decimal, Degree, Percentile, Name), rarity
classification, inscriptions documentation, and Runes specification. Available
in 14 languages.
### ord GitHub repository
* **URL:** [https://github.com/ordinals/ord](https://github.com/ordinals/ord)
* **Type:** Reference implementation
* **Source:** Official/Primary
* **Stars:** 3,900+
* **Description:** Index, block explorer, and command-line wallet. Current
release v0.24.2 (November 2025).
### Ordinals BIP (draft)
* **URL:** [https://github.com/ordinals/ord/blob/master/bip.mediawiki](https://github.com/ordinals/ord/blob/master/bip.mediawiki)
* **Type:** Technical specification
* **Source:** Official/Primary (Casey Rodarmor)
* **Description:** 15-line algorithm specification for ordinal assignment,
Python pseudocode for subsidy calculation, satpoint notation, and
compatibility analysis for covenants and Lightning Network.
### Casey Rodarmor's technical writings
* **URL:** [https://rodarmor.com/blog/ordinal-theory/](https://rodarmor.com/blog/ordinal-theory/)
* **Type:** Original technical introduction (July 21, 2022)
* **URL:** [https://rodarmor.com/blog/how-ordinals-came-to-be/](https://rodarmor.com/blog/how-ordinals-came-to-be/)
* **Type:** Technical history (September 5, 2024)
* **Source:** Official/Primary
* **Description:** First public introduction of ordinal theory and development
timeline, including inspiration from Satoshi's "atoms" concept.
## GitHub repositories and implementations
### Best in Slot Open Protocol Indexer (OPI)
* **URL:** [https://github.com/bestinslot-xyz/OPI](https://github.com/bestinslot-xyz/OPI)
* **Type:** Reference indexer implementation
* **Source:** Official/Primary (Lead Maintainer)
* **Stars:** 220+
* **Description:** Open-source indexing client using fork of ord 0.23.2. Modules
for BRC-20, Bitmap, SNS, and Runes. PostgreSQL backend with reorg protection
and block hash verification.
### BRC-20 indexer rules documentation
* **URL:** [https://docs.bestinslot.xyz/brc-20-indexer-rules](https://docs.bestinslot.xyz/brc-20-indexer-rules)
* **Type:** Implementation specification
* **Source:** Official/Primary
* **Description:** Critical indexer rules: MIME type must be "text/plain" or
"application/json"; ALL JSON fields must be strings (not numbers); use byte
count for UTF-8 emoji tickers; reorg handling requirements.
### Additional repositories
| | | |
| --------------------- | ------------------------------------------------------------------------------------------------------ | ------------------------ |
| **Repository** | **URL** | **Type** |
| BRC-20 Devs Org | [https://github.com/brc20-devs](https://github.com/brc20-devs) | Development organization |
| UniSat BRC-20 Indexer | [https://github.com/unisat-wallet/libbrc20-indexer](https://github.com/unisat-wallet/libbrc20-indexer) | Go indexer library |
| OKX BRC20 Indexer | [https://github.com/okx/ord](https://github.com/okx/ord) | Protocol implementation |
| Next-DAO Indexer | [https://github.com/Next-DAO/brc20\_indexer](https://github.com/Next-DAO/brc20_indexer) | Node.js indexer |
## Indexer API documentation
Four major indexers provide developer APIs for BRC-20 data access.
### Best in Slot API
* **URL:**
[https://docs.bestinslot.xyz/reference/api-reference/ordinals-and-brc-20-and-runes-and-bitmap-v3-api-mainnet+testnet+signet/brc-20](https://docs.bestinslot.xyz/reference/api-reference/ordinals-and-brc-20-and-runes-and-bitmap-v3-api-mainnet+testnet+signet/brc-20)
* **Base URL:** [https://api.bestinslot.xyz/v3/](https://api.bestinslot.xyz/v3/)
* **Type:** REST API documentation
* **Source:** Official
* **Authentication:** API key via x-api-key header
* **Rate limits:** Free tier (10 calls/min, 1000/day), Grow ($99/mo), Scale
($699/mo)
* **Key endpoints:** /v3/brc20/wallet\_balances, /v3/brc20/tickers,
/v3/brc20/ticker\_info, /v3/brc20/holders, enterprise historical data endpoints
### UniSat API
* **URL:** [https://docs.unisat.io/dev/open-api-documentation/api-for-bitcoin](https://docs.unisat.io/dev/open-api-documentation/api-for-bitcoin)
* **Base URL:** [https://open-api.unisat.io](https://open-api.unisat.io)
* **Swagger:** [https://open-api.unisat.io/swagger.html](https://open-api.unisat.io/swagger.html)
* **Type:** REST API documentation
* **Source:** Official
* **Authentication:** JWT Bearer token
* **Key endpoints:** `/v1/indexer/brc20/list`, `/v1/indexer/brc20/{ticker}/info`,
`/v1/indexer/brc20/{ticker}/holders`, `/v2/inscribe/order/create/brc20-*`
### OKX API
* **URL:** [https://www.okx.com/web3/build/docs/waas/marketplace-ordinals-api](https://www.okx.com/web3/build/docs/waas/marketplace-ordinals-api)
* **Base URL:** [https://www.okx.com/api/v5/explorer/brc20/](https://www.okx.com/api/v5/explorer/brc20/)
* **Type:** REST API documentation
* **Source:** Official
* **Authentication:** OK-ACCESS-KEY + signature + timestamp + passphrase
* **Key endpoints:** /api/v5/explorer/brc20/token-list,
/api/v5/explorer/brc20/token-details, /api/v5/mktplace/nft/ordinals/\*
### Hiro Ordinals API
* **URL:** [https://docs.hiro.so/en/apis/ordinals-api](https://docs.hiro.so/en/apis/ordinals-api)
* **Base URL:** [https://api.hiro.so/ordinals/v1/](https://api.hiro.so/ordinals/v1/)
* **Type:** REST API documentation
* **Source:** Official
* **Rate limits:** Free 500 RPM, higher limits via API key
* **Description:** Complete BRC-20 token data with caching optimization, powered
by reorg-aware Bitcoin Indexer.
## Wallet SDK and integration documentation
### Sats Connect (Xverse)
* **URL:** [https://docs.xverse.app/sats-connect](https://docs.xverse.app/sats-connect)
* **npm:** sats-connect (\~2M downloads)
* **Type:** Official SDK
* **Languages:** JavaScript/TypeScript
* **Description:** Primary library for Bitcoin wallet connections. Supports
wallet\_connect, signPsbt, ord\_getInscriptions, createInscription. Compatible
with Xverse, Leather, and other Bitcoin wallets.
### UniSat wallet integration
* **URL:** [https://docs.unisat.io/dev/unisat-developer-center](https://docs.unisat.io/dev/unisat-developer-center)
* **GitHub:** [https://github.com/unisat-wallet/unisat-dev-docs](https://github.com/unisat-wallet/unisat-dev-docs)
* **npm:** @unisat/wallet-utils
* **Type:** Official SDK
* **Description:** Browser extension API via window\.unisat object. Methods
include requestAccounts(), signMessage(), signPsbt(), sendInscription().
### Leather/Hiro Connect
* **URL:** [https://docs.hiro.so/stacks/connect/packages/connect](https://docs.hiro.so/stacks/connect/packages/connect)
* **npm:** @stacks/connect
* **Type:** Official SDK
* **Description:** RPC-based interface using request() method. Supports BTC,
STX, Ordinals, and BRC-20 via Leather wallet.
### Core Bitcoin libraries
| | | |
| ----------------- | -------------------------------------------------------------------------------------------------- | -------------------------------------------------- |
| **Library** | **URL** | **Purpose** |
| bitcoinjs-lib | [https://github.com/bitcoinjs/bitcoinjs-lib](https://github.com/bitcoinjs/bitcoinjs-lib) | Core Bitcoin transactions, PSBT (BIP-174), Taproot |
| micro-ordinals | [https://github.com/paulmillr/micro-ordinals](https://github.com/paulmillr/micro-ordinals) | Minimal inscriptions library |
| @scure/btc-signer | [https://www.npmjs.com/package/@scure/btc-signer](https://www.npmjs.com/package/@scure/btc-signer) | Audited PSBT/Taproot signing |
| msigner | [https://github.com/me-foundation/msigner](https://github.com/me-foundation/msigner) | PSBT signer for Ordinals marketplaces |
## Relevant Bitcoin Improvement Proposals
BRC-20 and Ordinals depend on Taproot (activated block 709,632, November 2021)
and PSBT for marketplace transactions.
### Taproot BIPs (foundation for inscriptions)
| | | | |
| ------- | ------------------ | -------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------- |
| **BIP** | **Title** | **URL** | **Relevance** |
| BIP-340 | Schnorr Signatures | [https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki) | 64-byte signatures, batch verification |
| BIP-341 | Taproot | [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki) | 4MB witness limit enables inscriptions |
| BIP-342 | Tapscript | [https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki](https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki) | Script execution for Taproot |
### PSBT BIPs (marketplace transactions)
| | | | |
| ------- | ------------------- | -------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------- |
| **BIP** | **Title** | **URL** | **Relevance** |
| BIP-174 | PSBT Format | [https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki](https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki) | Core format for BRC-20 atomic swaps |
| BIP-370 | PSBT Version 2 | [https://github.com/bitcoin/bips/blob/master/bip-0370.mediawiki](https://github.com/bitcoin/bips/blob/master/bip-0370.mediawiki) | Enhanced transaction construction |
| BIP-371 | Taproot PSBT Fields | [https://github.com/bitcoin/bips/blob/master/bip-0371.mediawiki](https://github.com/bitcoin/bips/blob/master/bip-0371.mediawiki) | Required for inscription transactions |
## Technical comparisons to other Bitcoin token standards
| | | | | |
| -------------- | ----------------------- | ------------------------ | ------------- | ------------------- |
| **Protocol** | **Data Storage** | **State Validation** | **Lightning** | **Smart Contracts** |
| BRC-20 | Witness (4MB) | Off-chain indexers | Limited | None |
| BRC2.0 | Witness + OP\_RETURN | Off-chain indexers + EVM | Limited | Yes (full EVM) |
| Runes | OP\_RETURN (\<80 bytes) | UTXO-native | Native | None |
| RGB | Commitments only | Client-side | Native | Yes (AluVM) |
| Taproot Assets | Merkle roots | Universe servers | Native | Limited |
**Key architectural difference:** BRC-20 stores all data on-chain but token
balances depend entirely on correct indexer interpretation, introducing
centralization risks absent in UTXO-native protocols like Runes. Casey Rodarmor
designed Runes specifically to reduce UTXO proliferation caused by BRC-20.
### Security analysis resources
### CertiK risk analysis
* **URL:**
[https://www.certik.com/resources/blog/ordinals-and-the-brc-20-standard-overview-and-risk-analysis](https://www.certik.com/resources/blog/ordinals-and-the-brc-20-standard-overview-and-risk-analysis)
* **Type:** Security audit/analysis
* **Source:** Community (reputable blockchain security firm)
* **Key findings:** BRC-20 tokens don't inherit Bitcoin's full security
model—indexer operators can theoretically manipulate balances; indexer logic
flaws could enable double-spending; low barriers enable fraudulent projects.
### Cyberscope audit services
* **URL:** [https://www.cyberscope.io/brc20-smart-contract-audit](https://www.cyberscope.io/brc20-smart-contract-audit)
* **Type:** Commercial audit service
* **Focus areas:** Indexer logic verification, off-chain database security,
balance record integrity, JSON parsing vulnerabilities.
# Historical and Social Context
Source: https://docs.brc20.build/overview/historical-and-social-context
## **The Ordinals Catalyst (2023)**
BRC-20 emerged in March 2023, just two months after Casey Rodarmor launched the
Ordinals protocol in January. Ordinals introduced a method to track and inscribe
data to individual satoshis, initially focused on creating NFT-like "digital
artifacts" on Bitcoin.
[@domodata](https://twitter.com/domodata) created the BRC-20 standard as an
experiment, a tongue-in-cheek nod to Ethereum's ERC-20. The first BRC-20 token,
ordi, was deployed on March 8, 2023, with a simple JSON structure anyone could
replicate. Within weeks, hundreds of tokens launched, and a speculative frenzy
began.
## **The Metaprotocol Debate**
BRC-20's metaprotocol design sparked fundamental questions about Bitcoin's
purpose:
**Critics** argued it was spam, clogging mempools with "useless" JSON
inscriptions and driving up transaction fees for regular Bitcoin users. Some
questioned whether metaprotocols that require off-chain indexers truly inherit
Bitcoin's security guarantees, or if they introduce new trust assumptions.
**Supporters** contended that anyone willing to pay fees has a legitimate claim
to block space—that Bitcoin is permissionless and should not discriminate
between transaction types. They argued that metaprotocols represent valid
experimentation on Bitcoin's most secure settlement layer, and that indexer
consensus is no different from how Bitcoin infrastructure has always worked
(exchanges, wallets, and explorers all run their own validation).
During peak BRC-20 activity in May 2023 and later surges, transaction fees
spiked dramatically, creating friction between traders and Bitcoin purists who
saw it as an attack on the network's intended use.
## **Market Dynamics and Ecosystem Growth**
The ordi token, initially minted for fractions of a cent, reached a market cap
exceeding \$1 billion by late 2023, demonstrating real demand for Bitcoin-native
tokens despite technical limitations. This success spawned an ecosystem:
* **Marketplaces** like [UniSat](https://unisat.io/) and Best in Slot enabled
trading inscribed satoshis
* **Indexers** competed to provide the canonical state of BRC-20 tokens, with
services like Best in Slot becoming de facto standards
* **Wallets** added BRC-20 support, creating UX patterns for managing inscribed
tokens
* **Alternative standards** emerged (ORC-20, Runes) as the community
experimented with different metaprotocol designs
## **The Evolution to Programmability (2024-2025)**
Recognizing BRC-20's limitations—no smart contracts, limited composability,
purely manual operations—the community developed **BRC2.0** throughout 2024.
This extension adds an EVM-compatible execution layer while maintaining BRC-20's
inscription-based model.
BRC2.0's launch in 2025 represents a watershed moment: transitioning from simple
metaprotocol token ledgers to a programmable computing environment on Bitcoin.
The addition of smart contracts enables:
* Decentralized applications on Bitcoin
* DeFi primitives (DEXs, lending protocols, staking systems)
* Native Bitcoin operations via precompiles (transaction verification, signature
validation)
* Complex financial logic previously impossible with BRC-20 alone
This evolution positions the BRC-20 ecosystem not just as a token standard, but
as a comprehensive application platform built on Bitcoin's security model.
## **Cultural Impact**
BRC-20's emergence validated that Bitcoin's block space has value beyond simple
value transfers. It demonstrated:
1. **Fee market dynamics**: Users will pay premium fees for functionality they
value, regardless of Bitcoin maximalist opinions
2. **Permissionless innovation**: No one needed approval to experiment with a
new metaprotocol—this is Bitcoin's core value proposition
3. **Bitcoin's flexibility**: The base layer, unchanged since before Ordinals,
could support entirely new use cases through creative interpretation
4. **Metaprotocol viability**: Off-chain indexers with social consensus can
enable complex systems while still leveraging Bitcoin's immutability
Whether viewed as innovation or spam, BRC-20 fundamentally altered how
developers think about building on Bitcoin. BRC2.0's introduction of
programmability takes this further—establishing Bitcoin not just as a settlement
layer for wrapped assets, but as a direct platform for application development
with native smart contract capabilities.
**Further
reading**:[Ordinals and BRC-20 History](https://trustmachines.co/learn/what-is-brc-20/)
|[Bitcoin Block Space Demand Analysis](https://insights.glassnode.com/bitcoin-ordinals-inscriptions/)
# What is BRC-20?
Source: https://docs.brc20.build/overview/what-is-brc20
BRC-20 is a metaprotocol for fungible tokens on Bitcoin, using Ordinals inscriptions and indexer consensus to track token state.
BRC-20 is a **metaprotocol** for fungible tokens on Bitcoin. It uses the Ordinals protocol to inscribe JSON data directly into Bitcoin transactions. Bitcoin nodes don't understand or enforce BRC-20 rules — specialized indexers interpret that inscribed data to maintain token state and validate operations.
Unlike Ethereum's ERC-20, which relies on smart contracts enforced by the network itself, BRC-20 relies on **social consensus**: participants agree to follow the same ruleset for interpreting inscriptions, and indexers provide the canonical state of all tokens.
## How it works
BRC-20 tokens use a three-operation model: deploy, mint, and transfer.
Create a new token by inscribing deployment parameters — ticker symbol, maximum supply, and per-mint limit — as a JSON inscription on Bitcoin.
Inscribe mint operations to claim tokens from the deployed supply, up to the per-mint limit per inscription.
Inscribe a transfer operation to allocate tokens for sending, then send the inscribed satoshi to move the tokens to a new owner.
Each operation is a JSON inscription committed into a Bitcoin transaction. Indexers scan these inscriptions in block order to maintain the current state of all BRC-20 tokens — who owns what, total supply, and transfer history.
### Deploy inscription
```json theme={null}
{
"p": "brc-20",
"op": "deploy",
"tick": "ordi",
"max": "21000000",
"lim": "1000"
}
```
| Field | Description |
| ------ | ----------------------------------------------- |
| `p` | Protocol identifier — always `"brc-20"` |
| `op` | Operation type: `deploy`, `mint`, or `transfer` |
| `tick` | Four-letter ticker symbol |
| `max` | Maximum total supply |
| `lim` | Maximum tokens claimable per mint inscription |
### Mint inscription
```json theme={null}
{
"p": "brc-20",
"op": "mint",
"tick": "ordi",
"amt": "1000"
}
```
### Transfer inscription
```json theme={null}
{
"p": "brc-20",
"op": "transfer",
"tick": "ordi",
"amt": "500"
}
```
The transfer operation is a two-step process: first inscribe the transfer to allocate the amount, then send the satoshi that holds that inscription to the recipient's address.
## Key characteristics
BRC-20 is purely data inscriptions interpreted by indexers following agreed-upon rules. Bitcoin's consensus layer does not validate BRC-20 operations — correctness depends on indexers implementing the same specification.
Token tickers are claimed on a first-inscription basis. Anyone can deploy any four-letter ticker, but only the first valid deploy inscription for a given ticker is recognized. There is no registration authority.
Tokens exist within specific satoshis. This means transfers require careful UTXO management — accidentally spending the satoshi that holds an inscription will destroy the tokens it represents.
Different indexers may diverge if they implement the rules differently. Major indexers converge on a canonical interpretation, but you should verify which indexer a marketplace or wallet uses before relying on its state.
## Trading BRC-20 today
BRC-20 tokens are traded on-chain through **PSBT-based marketplaces** such as UniSat, Best in Slot, Magic Eden, and OKX Web3. These platforms use Partially Signed Bitcoin Transactions (PSBTs) to enable trustless atomic swaps: sellers sign offers with specific `SIGHASH` flags that allow any buyer to complete the transaction.
The ecosystem has processed over 71,000 BTC in cumulative trading volume (\~\$7 billion) and generated 6,922 BTC in miner fees since launch.
This architecture has real limitations worth understanding before you build:
* **No automated market makers** — AMMs require off-chain components because there is no on-chain execution environment.
* **Fragmented liquidity** — order books live on individual marketplaces with no cross-platform aggregation.
* **Front-running via fee races** — because transactions compete in Bitcoin's mempool, users can outbid pending transactions by paying higher fees.
BRC2.0 is the next evolution of this ecosystem. It adds EVM-compatible smart contract execution on top of BRC-20's inscription model, enabling AMMs, lending protocols, DAOs, and other DeFi primitives directly on Bitcoin. Read the [BRC2.0 Programmable Module](/overview/brc20-programmable-module) overview to learn more.
# BiS AMM
Source: https://docs.brc20.build/protocol/bis-amm
Technical reference for the Best in Slot AMM sequencer architecture, covering smart wallets, batch settlement, BLS signatures, BTC-frBTC wrapping, and the security model.
The Best in Slot (BiS) AMM is a non-custodial automated market maker built on BRC2.0. It uses BLS12-381 cryptography and Bitcoin batch settlement to deliver trustless DeFi on Bitcoin.
***
## Smart wallets
### Non-custodial design
Users hold their own BLS12-381 private keys. The sequencer never has access to user funds or signing capabilities. All operations are signed client-side before submission.
### BIP-322 signature verification
All operations — deposits, swaps, liquidity operations, and withdrawals — require a BIP-322 signature from the user's Bitcoin wallet as an additional security layer. This is enforced by the sequencer to protect users from unauthorized operations.
The first operation for every wallet is a deposit, which establishes the binding between the Bitcoin wallet and the BLS public key. The deposit authorization message format is:
```text theme={null}
Deposit Order:
Bitcoin Address:
BLS Public Key:
Token Address:
By signing this message, you authorize the creation of a deposit order with the above parameters.
```
### Pubkey index system
To optimize on-chain storage, public keys are assigned a sequential index. This allows operations to reference a compact identifier instead of the full 256-byte BLS public key, significantly reducing transaction sizes and inscription costs.
### Replay protection via nonces
Each wallet maintains a nonce that is atomically incremented with every operation. The nonce is included in the signed message, preventing replay attacks:
```javascript theme={null}
message = keccak256(pubkey) || nonce || op_type || params_hash
```
If a user loses access to their Bitcoin wallet, the associated smart wallet cannot be recovered. This is by design — the system is non-custodial and there is no recovery mechanism. Users must secure their private keys.
***
## Bitcoin batch settlement
### Operation queue
User operations (swaps, liquidity adds/removes, withdrawals) are queued by the sequencer, which monitors pending operations and aggregates them into batches.
### Batching triggers
A new batch is created when either condition is met:
| Trigger | Condition |
| ------------------- | ------------------------------------------------------------------ |
| Operation threshold | 500 or more pending operations in the queue |
| Withdrawal priority | Any pending withdrawal operations AND no currently pending batches |
This ensures withdrawals are processed promptly while maintaining efficient batching for regular operations.
### Compression
Batch data is compressed before inscription to minimize fees:
1. **Zstd compression** (level 22, maximum) is attempted first.
2. **NADA encoding** is used as fallback if it produces smaller output.
3. A 1-byte prefix indicates the encoding: `0x01` = NADA, `0x02` = Zstd.
The envelope format inscribed on-chain:
```json theme={null}
{ "p": "brc20-prog", "op": "t", "b": "" }
```
### Sequential execution
Once the batch is inscribed and mined, the BRC-20 EVM executes operations sequentially at the mined block height.
The system uses the **transact** command (signed EVM transactions) rather than simple calls for two reasons:
* **Key rotation resilience**: If the batch sender wallet key is compromised, operations can continue from a different wallet without interruption.
* **Nonce-based ordering**: The EVM transaction nonce enforces sequential execution on the BRC-20 side, preventing out-of-order processing.
***
## BLS signatures
### Cryptographic foundation
The system uses **BLS12-381**, a pairing-friendly elliptic curve providing 128-bit security. This curve is widely used in blockchain systems (Ethereum 2.0, Zcash) and enables efficient signature aggregation.
Signatures are computed on the G1 curve (shorter representation), while public keys reside on G2. This optimizes for aggregation efficiency since signatures are aggregated more frequently than public keys.
```javascript theme={null}
const P = bls12_381.G1.hashToCurve(msg_buf, {
DST: 'BLS_SIG_BLS12381G1_XMD:SHA-256_SSWU_RO_NUL_'
});
```
### Message format
Each operation's signed message is constructed as:
```javascript theme={null}
keccak256(pubkey) || nonce (4 bytes) || op_type (1 byte) || params_hash
```
For unwrap operations specifically:
```javascript theme={null}
keccak256(pubkey) || nonce || 0x06 || keccak256(pkscript) || amount || fee
```
### Signature aggregation
Individual signatures from multiple operations are aggregated into a single signature per batch:
```javascript theme={null}
const aggregated_sigs = bls12_381.shortSignatures.aggregateSignatures(signatures);
const neg_aggregated_sigs = aggregated_sigs.negate();
```
The negated aggregated signature is submitted to the sequencer contract's `processBatch()` function for on-chain verification.
**N signatures compress to 1 aggregated signature**, providing constant verification cost regardless of batch size. This dramatically reduces on-chain verification costs and inscription sizes.
***
## BTC-frBTC wrapping
### Wrap: BTC to frBTC
User constructs a `wrapAndExecute2()` call inscription.
BTC is sent to the handler wallet in the send-to-OP\_RETURN transaction.
The sequencer checks transaction structure and signatures, fee rate within acceptable range, and mempool acceptance via `testmempoolaccept`.
Upon inscription confirmation, frBTC is minted to the user's balance.
The wrap data includes:
* Token address
* Ticker index
* User pubkey and pubkey index
* BLS signature for emergency withdrawal
* EC signature for index verification
### Unwrap: frBTC to BTC
User submits a request containing: public key and nonce, output pkscript (destination), and amount and BTC fee.
The sequencer verifies the signature against the message:
```javascript theme={null}
keccak256(pubkey) || nonce || 0x06 || keccak256(pkscript) || amount || fee
```
The operation is queued and processed in the next batch.
A BTC output is created to the specified pkscript.
Minimum unwrap amount: **1000 satoshis**.
### Custody model
The BTC handler wallet is secured by a multisig arrangement operated by Subfrost.
| Aspect | Current state | Planned |
| ------------ | --------------------- | ----------------------------- |
| Custody type | Multisig | Committee-based |
| Signers | Subfrost team members | Independent committee members |
**Roadmap**: The custody model will transition from internal Subfrost signers to an independent committee approach, distributing trust across multiple parties external to the core team.
***
## Security
### Trust model
| Component | Trust assumption |
| -------------- | ------------------------------------------------------------------------------ |
| **User** | Holds private keys, signs all operations |
| **Sequencer** | Trusted for liveness only, not custody. Cannot forge signatures or steal funds |
| **Bitcoin** | Provides finality and data availability |
| **BRC-20 EVM** | Executes state transitions deterministically |
**Roadmap — Force exit mechanism**: A force exit mechanism is planned to eliminate sequencer liveness trust. This will allow users to withdraw funds directly on-chain if the sequencer becomes unresponsive, ensuring users are never locked out of their assets.
### Bitcoin finality and reorg handling
The system monitors block hashes on both Bitcoin and BRC-20 chains. On reorg detection:
Block hash mismatch triggers the reorg handler.
System waits for BRC-20 to process the reorg.
Locate the last confirmed (correct) block height.
Clear executed batches and operations after the divergence point.
Verified historical balances and pairs up to the last correct block are retained.
Re-execute all blocks to rebuild current state.
### Emergency stop
The sequencer includes a circuit breaker that activates automatically when unexpected failures or state mismatches are detected. When active, all new operations are rejected until the issue is resolved. This protects user funds from being processed during an inconsistent state.
### Transaction ordering
Operations are processed in **strict FIFO (First In, First Out) order**. The sequencer cannot reorder transactions within a batch, eliminating the possibility of sequencer-initiated front-running or MEV extraction.
***
## Audits
The smart contracts have been audited by Hashlock, an independent security firm.
| Auditor | Scope | Date | Rating |
| -------- | ------------------------------------------------- | ------------- | ------ |
| Hashlock | BiS\_Swap, bls12lib.sol & Uniswap Smart Contracts | November 2025 | Secure |
For the full audit report and additional information, visit [hashlock.com/audits/best-in-slot](https://hashlock.com/audits/best-in-slot).
# BRC-20 protocol
Source: https://docs.brc20.build/protocol/brc20
Complete reference for the BRC-20 token standard built on Bitcoin Ordinals, including all operation formats, self-mint mechanics, and snipe protection.
**BRC-20** is a token standard built on top of the Bitcoin Ordinals protocol, enabling the creation and trading of fungible tokens on the Bitcoin blockchain by inscribing structured JSON data into satoshis. The ordinal/inscription layer stores raw text on-chain, and off-chain indexers and wallets interpret that text to derive token state such as deployments, minting, and transfers.
## Common fields
Every BRC-20 inscription must be valid JSON. Two fields appear in all operations:
Protocol identifier. Must equal `"brc-20"`.
Token ticker symbol. Typically 3–6 characters. See [namespace isolation](#namespace-isolation) for length rules.
***
## Operations
### Deploy
Creates a new token definition. The first valid deploy inscription for a ticker becomes the canonical definition of that token.
```json theme={null}
{
"p": "brc-20",
"op": "deploy",
"tick": "ordi",
"max": "21000000",
"lim": "1000"
}
```
Operation type. Must equal `"deploy"`.
Ticker symbol for the new token.
Maximum token supply as a stringified integer. Under self-mint semantics, `"0"` means unlimited supply.
Maximum amount mintable per individual mint inscription. Optional.
Set to `"true"` to enable restricted issuance mode (deployer-only minting). Any other value or omission defaults to public minting.
***
### Mint
Issues token units from a previously deployed token, up to the defined supply cap.
```json theme={null}
{
"p": "brc-20",
"op": "mint",
"tick": "ordi",
"amt": "1000"
}
```
Operation type. Must equal `"mint"`.
Ticker of the token to mint.
Amount to mint as a stringified integer. Must not exceed the `lim` value defined in the deploy inscription.
***
### Transfer
Moves token balance to another address. BRC-20 transfers are a **two-step process**:
1. **Inscribe** a transfer inscription on a satoshi (this locks the specified balance).
2. **Send** that satoshi (ordinal) to the recipient's Taproot address.
The recipient address is not included in the JSON — the transfer is completed by physically sending the ordinal to the destination.
```json theme={null}
{
"p": "brc-20",
"op": "transfer",
"tick": "ordi",
"amt": "500"
}
```
Operation type. Must equal `"transfer"`.
Ticker of the token to transfer.
Amount to transfer as a stringified integer.
Transfers require the recipient to have a Taproot address (`bc1p...`). Sending to non-Taproot addresses is not supported.
***
## Self-mint
### Overview
The default BRC-20 issuance model is permissionless: once a token is deployed, anyone may mint until the supply cap is reached. Self-minting is a restricted issuance mode where **only the deployer** is allowed to mint tokens after deployment.
This is achieved via an explicit opt-in flag on the deploy inscription. Indexers enforce the parent inscription requirement.
### Enabling self-mint
Add `"self_mint": "true"` to the deploy inscription:
```json theme={null}
{
"p": "brc-20",
"op": "deploy",
"tick": "token",
"max": "21000000",
"lim": "1000"
}
```
```json theme={null}
{
"p": "brc-20",
"op": "deploy",
"self_mint": "true",
"tick": "token",
"max": "21000000",
"lim": "1000"
}
```
When `self_mint` is enabled:
* All subsequent mint inscriptions **must use the deploy inscription as their parent**. Mint inscriptions without this parent relationship are invalid.
* `max=0` is redefined to mean **unlimited supply**, bounded only by indexer max-uint64 constraints.
### Unlimited supply via `max=0`
```json theme={null}
{
"p": "brc-20",
"op": "deploy",
"self_mint": "true",
"tick": "ordi",
"max": "0",
"lim": "1000"
}
```
`max` still represents the global mint ceiling. BRC-20 tokens cannot be destroyed, and transfers to unspendable addresses do not reduce mint capacity.
***
## Namespace isolation
To avoid collisions with existing assets and legacy indexers, tickers are segmented by byte length:
| Ticker length | Rules | Self-mint support |
| ------------- | ---------------------------------------- | ----------------- |
| 4 bytes | Legacy namespace, unchanged | No |
| 5 bytes | Extended namespace | Yes |
| 6 bytes | Extended namespace with snipe protection | Yes |
Indexers that do not support extended namespaces will ignore 5-byte and 6-byte tickers.
***
## 6-byte tickers and snipe protection
The BRC-20 ticker namespace was extended to support **6-byte tickers** with Phase 1 of BRC2.0, while preserving compatibility with existing 4- and 5-byte semantics.
### Ticker constraints
6-byte tickers must:
* Be exactly 6 characters
* Match the regex `^[A-Za-z0-9-]{6}$`
* Be treated case-insensitively
Invalid examples include unicode, symbols other than `-`, or incorrect length. 4- and 5-byte tickers remain unchanged and unaffected.
### Snipe protection via pre-deploy commitment
To prevent ticker sniping and front-running, 6-byte tickers require a **pre-deploy commitment** before the actual deploy.
Pre-deploy inscriptions commit to a ticker without revealing it by inscribing a hash:
```text theme={null}
hash = sha256(sha256(ticker_bytes + salt_bytes + deployer_pkscript))
```
This binds the ticker to both a salt and the deployer's `pkscript`, preventing replay or theft.
#### Step 1: Pre-deploy inscription
```json theme={null}
{
"p": "brc-20",
"op": "predeploy",
"hash": ""
}
```
Must equal `"predeploy"`.
`sha256(sha256(ticker_bytes + salt_bytes + deployer_pkscript))` encoded as hex.
#### Step 2: Deploy inscription
```json theme={null}
{
"p": "brc-20",
"op": "deploy",
"tick": "ticker",
"salt": "",
"self_mint": "true",
"max": "21000000",
"lim": "1000"
}
```
The same salt used to compute the pre-deploy hash. Indexers recompute and validate the commitment.
### Deployment rules
* The deploy inscription **must be a child** of the pre-deploy inscription.
* The deploy must occur **at least 3 blocks after** the pre-deploy.
* Indexers must reject deploys that violate ordering or hash validation.
* Pre-deploy inscriptions do not expire and remain valid if transferred.
Pre-deploy inscriptions are accepted starting 10 blocks before the 6-byte namespace activation height (`912690`).
***
## Required tooling
To create or interact with BRC-20 inscriptions:
* **Inscription platforms**: UniSat, Ordinals Wallet, LooksOrdinal
* **Indexers / explorers**: Ordiscan, BRC-20.io
***
## Limitations
The Bitcoin blockchain does not enforce BRC-20 rules. All validation — determining the canonical deploy, mint, and transfer history — is performed by off-chain indexers. Token state is only as reliable as the indexers interpreting the inscriptions.
Transfers require Taproot-compatible addresses (`bc1p...`). Sending to non-Taproot addresses is not supported by the protocol.
# BRC2.0 module
Source: https://docs.brc20.build/protocol/brc20-programmable-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:
Extract BRC2.0 JSON from the Ordinals envelope.
Check signature, nonce, and gas limits.
Run the transaction in the local EVM instance.
Commit storage changes, logs, and balance updates.
All indexers must produce identical state transitions.
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..."
}
```
Protocol identifier. Must equal `"brc20-prog"`.
Operation type. `"deploy"` or shorthand `"d"`.
Compiled Solidity deployment bytecode as a hex string. Generate with Hardhat, Foundry, or Remix.
***
### 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": "",
"b": ""
}
```
Operation type. `"call"` or shorthand `"c"`.
Address of the deployed contract to call.
ABI-encoded calldata for the function invocation.
***
### 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": ""
}
```
Operation type. `"transact"` or shorthand `"t"`.
ABI-encoded calldata including deposit parameters and function arguments.
***
## Deposit and withdraw mechanics
BRC2.0 includes a **built-in bridge** for moving BRC-20 tokens into smart contracts.
### Deposit flow
Inscribe a deposit operation specifying the ticker and amount.
Send the inscription to `OP_RETURN "BRC20PROG"` to route it into the BRC2.0 module.
Tokens move from BRC-20 state to "deposited" state.
The contract receives an equivalent ERC-20-compatible balance.
```json theme={null}
{
"p": "brc-20",
"op": "deposit",
"tick": "ordi",
"amt": "1000"
}
```
Must equal `"deposit"`.
Ticker of the BRC-20 token to deposit.
Amount to deposit as a stringified integer.
### 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"
}
```
Must equal `"brc20-module"`.
Must equal `"withdraw"`.
Ticker of the token to withdraw.
Amount to withdraw as a stringified integer.
Module identifier. Must equal `"BRC20PROG"`.
This creates a trustless bridge — no multisig or validator set is required. Indexers enforce the rules deterministically based on inscriptions and EVM execution.
***
## EVM compatibility
BRC2.0 aims for Solidity compatibility but has key differences from Ethereum.
* Solidity syntax and features
* Standard library contracts (OpenZeppelin, etc.)
* Events and logs
* Storage operations (`SSTORE`, `SLOAD`)
* Standard opcodes (`ADD`, `MUL`, `CALL`, etc.)
| 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 |
* Native ETH (`msg.value`) — use BRC-20 token deposits
* Ethereum-style key-based message signing from contract-generated addresses
***
## 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
Contract bytecode inscribed on Bitcoin cannot be changed. All operations are permanently recorded.
All indexers must produce identical state given the same inscriptions. The protocol is a deterministic state machine.
If indexers diverge, the community must choose the canonical implementation. Reference implementations and test suites are essential.
Use proxy patterns (similar to Ethereum) for upgradeable contracts.
Bitcoin verification precompiles rely on correct implementation in indexer code.
BRC2.0 security depends on indexer correctness. If the EVM implementation has bugs or deviates from specification, contract execution may diverge across indexers.
***
## Development workflow
Use Hardhat, Foundry, or Remix as usual.
Deploy to a local BRC2.0 node or testnet.
Generate deployment bytecode and ABI.
Create a deploy inscription with the bytecode.
A Bitcoin block must confirm (\~10 minutes).
Call functions by inscribing call operations.
Subscribe to indexer APIs for contract logs.
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
* 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
* 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