Documentation

Latest brc-20 documentation

Concept

Experiment to see if ordinal theory can facilitate fungibility on bitcoin

• Create a brc-20 with the deploy function

• Mint an amount of brc-20's with the mint function

• Transfer an amount of brc-20's with the transfer function.

brc-20 balance state can be found by aggregating all of these function's activity together.

• Deployments initialize the brc-20. Do not affect state

• Mints provide a balance to only the first owner of the mint function inscription

• Transfers deduct from the senders balance and add to the receivers balance, only upon the first transfer of the transfer function. (1. Inscribe transfer function to senders address 2. sender transfer's transfer function)

Usage

*Careful if using inscription service. Some tools inscribe to themselves first then forward it to the customer (thus the intermediate inscription service owned address keeps the balance)

**At block height 816000, the valid inscription definition was paused to ord 0.90

**At the Jubilee, the valid inscription definition was updated to 0.14 with vindications and encoding/delegation features ignored.

***At block height 837090 self mint and 5 digit tickers were enabled.

Getting a balance

You can either deploy your own or 'first is first' mint from existing deployments

1. (Optional: Only do if you want to create your own brc-20. If not go to step 2) Inscribe the deploy function to you ordinal compatible wallet with the desired brc-20 parameters set.

2. Inscribe the mint function to your ordinal compatible wallet. Make sure the ticker matches a brc-20 that has yet to reach its fully diluted supply. Also, if the brc-20 has a mint limit, make sure not to surpass this.

Transferring a balance

1. Inscribe the transfer function to your ordinal compatible wallet. Make sure the transfer function inscription information is valid before inscribing.

2. Once inscribed, (and if valid) send the inscription to the desired destination to transfer the balance.

What is valid?

A valid transfer function is required to transfer a balance. Validity can be determined by the following:

• Valid transfer functions are ones where the amount stated in the inscription does not exceed Available balance when inscribed.

• Available balance defined as: [Overall balance] - [valid/active transfer function inscriptions in wallet (Transferable balance)]. If there are no valid/active transfer functions held by an address Available balance and Overall balance are equivalent.

• Example: A wallet holds an Overall balance of 1000 "ordi", and . The holder then inscribes a transfer function of 700 "ordi". Once the inscription is confirmed, the following is true: Overall balance = 1000, Available balance = 300, Transferable balance = 700. If in the next block, the user tried to inscribe a transfer function of 500 "ordi", this would not be valid as the maximum amount that can be inscribed is 300 (Available balance).

Balance Control

• If a user changes their mind and no longer wishes to transfer their transfer function, and wants to restore their Available balance to the Overall balance (invalidate Transferable balance), the user must simply transfer the transfer function inscription to themselves.

• Proposal 2: Core Function Cleanup v1 seeks to enhance user control over their balances.

(LEFT) The transfer of 700 "ordi" from sender to receiver (RIGHT) The restoration of overall balance via a self transfer of 700 "ordi". Only the balances marked in red are represented by inscriptions.

Notes

• Do not send inscriptions to non ordinal compatible wallet taproot addresses

• Under no circumstances does the transfer of a mint function result in a balance change.

• Each transfer inscription can only be used once

• The first deployment of a ticker is the only one that has claim to the ticker. Tickers are not case sensitive (DOGE = doge).

• If two events occur in the same block, prioritization is assigned via order they were confirmed in the block. (first to last).

• For public brc-20 mints the bitcoin punks / .sats names 'first is first' approach is adopted. This means that the first x inscriptions that meet the deploy function parameters are granted a balance.

• The mint function and the second step of the transfer function are the only events that cause changes in balances

• The first mint to exceed the maximum supply will receive the fraction that is valid. (ex. 21,000,000 maximum supply, 20,999,242 circulating supply, and 1000 mint inscription = 758 balance state applied)

• No valid action can occur via the spending of an ordinal via transaction fee. If it occurs during the inscription process then the resulting inscription is ignored. If it occurs during the second phase of the transfer process, the balance is returned to the senders available balance.

• Number of decimals cannot exceed 18 (default)

• Standard limited to uint128

• Maximum supply cannot exceed uint64_max

• For tickers with: self_mint = true, when issuing the mint inscription, the deploy inscription must be used as the parent of the mint inscription; otherwise, the mint is invalid.

• 5 digit ticker deployments are initially limited to self mints. Self mints are not initially available to 4 digit ticker deployments.

• When max=0, there is an unlimited maximum issuance for self_mint deployments. For BRC-20, the meaning of max is the total upper limit of all mints (max_uint64 (2 ** 64-1) * (10 ** decimals))

• To burn a BRC-20 asset send the transfer inscription to an OP_RETURN script that contains no data.

• BRC-20 assets do not “disappear” when sent to a burn address; the available space for additional minting does not reopen.

Operations

Deploy brc-20

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

Key	Required?	Description
p	Yes	Protocol: Helps other systems identify and process brc-20 events
op	Yes	Operation: Type of event (Deploy, Mint, Transfer)
tick	Yes	Ticker: 4 or 5 letter identifier of the brc-20
max	Yes	Max supply: set max supply of the brc-20
lim	No	Mint limit: If letting users mint to themsleves, limit per ordinal
dec	No	Decimals: set decimal precision, default to 18
self_mint	No	Self mint: Set the ticker to be mintable only by the deployment holder

Mint brc-20

{ 
  "p": "brc-20",
  "op": "mint",
  "tick": "ordi",
  "amt": "1000"
}

Key	Required?	Description
p	Yes	Protocol: Helps other systems identify and process brc-20 events
op	Yes	Operation: Type of event (Deploy, Mint, Transfer)
tick	Yes	Ticker: 4 or 5 letter identifier of the brc-20
amt	Yes	Amount to mint: States the amount of the brc-20 to mint. Has to be less than "lim" above if stated

Transfer brc-20

{ 
  "p": "brc-20",
  "op": "transfer",
  "tick": "ordi",
  "amt": "100"
}

Key	Required?	Description
p	Yes	Protocol: Helps other systems identify and process brc-20 events
op	Yes	Operation: Type of event (Deploy, Mint, Transfer)
tick	Yes	Ticker: 4 or 5 letter identifier of the brc-20
amt	Yes	Amount to transfer: States the amount of the brc-20 to transfer.