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

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

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

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

    ```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.
  </Step>

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

    <Warning>
      **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": "<your_commitment_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": "<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.
    </Warning>
  </Step>

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

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

    <CodeGroup>
      ```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"
      }
      ```
    </CodeGroup>

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

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

    <Note>
      One confirmation is sufficient for the token to appear in indexers. You do not need to wait for multiple confirmations before proceeding to mint.
    </Note>
  </Step>

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

    ```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.
  </Step>

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

    <Warning>
      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.
    </Warning>
  </Step>
</Steps>