Deploy a token

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 or Ordinals Wallet. These tools handle the Bitcoin transaction construction for you — you supply the JSON, they handle the rest.

Understand the deploy inscription

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.

{
  "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.

Choose your ticker

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:

{
  "p": "brc-20",
  "op": "predeploy",
  "hash": "<your_commitment_hash>"
}

Then, at least 3 Bitcoin blocks later, inscribe the actual deploy as a child of the pre-deploy inscription:

{
  "p": "brc-20",
  "op": "deploy",
  "tick": "ticker",
  "salt": "<your_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.

Create the deploy inscription

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:

{
  "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:

{
  "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.

{
  "p": "brc-20",
  "op": "deploy",
  "tick": "ordi",
  "max": "21000000",
  "lim": "1000"
}

Inscribe this JSON as a text/plain inscription onto a satoshi and broadcast the Bitcoin transaction.

Wait for confirmation

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.

Mint tokens

Once your deploy inscription is confirmed, anyone (or only you, for self-mint tokens) can mint tokens up to the lim amount per inscription.

{
  "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.

Transfer tokens

Transferring BRC-20 tokens is a two-step process:

Inscribe a transfer inscription to lock the specified amount against your address.
Send the satoshi containing that inscription to the recipient’s Taproot address (bc1p...).

Step 1 — inscribe the transfer:

{
  "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.

Overview

Architecture

Guides