brc-223
Advanced Fungible Token Standard
Last updated
Advanced Fungible Token Standard
Last updated
BRC-223 is a more advanced version of BRC-20, which simplifies the interaction between smart contracts and tokens. BRC-223 aims to address the limitations of BRC-20.
The BRC-223 standard is backwards compatible with BRC-20, meaning you can interact with these tokens as if they were BRC-20, using the standard functions. Any platform working with BRC-20 will also work with BRC-223.
An important aspect of deploying, minting, and sending tokens is the data
and operatorData
parameters, which is an enhancement over BRC-20 where only the recipient and amounts of tokens can be specified as part of a transfer. This allows new and exciting use cases such as accepting transfers only if a signed message is provided or specify a purpose for a transfer such that a recipient contract can take appropriate actions.
The data
parameter is intended to be similar to the data
parameter of a regular Ethereum transaction, and the standard intentionally does not enforce a specific format for this data only that the recipient defines what data it expects.
The operatorData
is the second free bytes parameter associated with a token transaction. It is similar to the data
parameter, except that it is explicitly intended for the operator to provide any information or reason for the transaction. In contrast, the data
parameter may be provided by either the token holder, the operator, or both.
Ultimately the recipient is free to define which data
and operatorData
it expects and reject any transaction which does not match its expectations. In practice, we expect the recipient to mainly focus on the data
parameter, with the operatorData
only providing optional and additional information regarding the transfer.
One key aspect for the BRC-223 standard is to maintain backward compatibility with the older BRC-20 standard. The BRC-223 standard also allows some forward-compatibility. Namely, the format of the data
and operatorData
have been left free for future standard to define specific formats they need.
BRC-223 - Advanced Fungible Token Standard Experiment
Create a brc-223 with the deploy function
Mint an amount of brc-223's with the mint function
Transfer an amount of brc-223's with the transfer function.
brc-223 balance state can be found by aggregating all of these function's activity together.
Deployments initialize the brc-223. 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)
How to
Getting a balance
You can either deploy your own or mint from existing deployments bitcoin punks style
(Optional: Only do if you want to create your own brc-223. If not go to step 2) Inscribe the deploy function to your ordinal compatible wallet with the desired brc-223 parameters set.
Inscribe the mint function to your ordinal compatible wallet. Make sure the ticker matches either a) the brc-223 you deployed in step 1, or b) any brc-223 that has yet to reach its fully diluted supply. Also if the brc-223 has a mint limit, make sure not to surpass this. 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)
Transferring a balance
Inscribe the transfer function to your ordinal compatible wallet. Make sure the transfer function inscription information is valid before inscribing. Careful if using inscription service. Some tools inscribe to themselves first then forward it to the customer (thus because the intermediate inscription service owned address has no balance and the transfer function is wasted). Some ordinal wallets generate a different address each time, make sure to send to the address that holds the balance.
Once received, (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).
If multiple transfer functions are inscribed in the same block, validity is determined by the order the were confirmed in the block.
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.
(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
It is unlikely that balances will be safely tradable using existing marketplace infrastructure. 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).
Minting transfer inscription to yourself first is necessary to avoid others spending your balance
For public brc-223 mints the bitcoin punks / .sats names 'first is first' approach is adopted
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)
Mint function inscriptions do not have a padding requirement
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
Operations
Deploy brc-223
ordi used for demo purposes in the docs. It has already reached its max supply.
{ "p": "brc-223", "op": "deploy", "tick": "ordi", "max": "21000000", "lim": "1000", "data":"123456789", "operatorData":"123456789" }
Mint brc-223
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)
{ "p": "brc-223", "op": "mint", "tick": "ordi", "amt": "1000", "data":"123456789", "operatorData":"123456789" }
Transfer brc-223
Careful if using inscription service. Some tools inscribe to themselves first then forward it to the customer (thus because the intermediate inscription service owned address has no balance and the transfer function is wasted). Some ordinal wallets generate a different address each time, make sure to send to the address that holds the balance.
{ "p": "brc-223", "op": "transfer", "tick": "ordi", "amt": "100", "data":"123456789", "operatorData":"123456789" }
*BRC-223 is similar to ERC-223
**BRC-223 will support Ethereum-style smart contract technologies on the Bitcoin network such as BitVM: https://www.coindesk.com/tech/2023/10/11/bitcoin-might-get-ethereum-style-smart-contracts-under-bitvm-plan
Key
Required?
Description
p
Yes
Protocol: Helps other systems identify and process brc-223 events
op
Yes
Operation: Type of event (Deploy, Mint, Transfer)
tick
Yes
Ticker: 4 letter identifier of the brc-223
max
Yes
Max supply: set max supply of the brc-223
lim
No
Mint limit: If letting users mint to themsleves, limit per ordinal
dec
No
Decimals: set decimal precision, default to 18
data
No
Free bytes parameter associated with a token transaction. The data parameter may be provided by either the token holder, the operator, or both. (Supports the Unicode Standard - supports all Unicode characters, symbols, signs, and codes)
operatorData
No
Free bytes parameter associated with a token transaction explicitly intended for the operator to provide any information or reason for the transaction. (Supports the Unicode Standard - supports all Unicode characters, symbols, signs, and codes)
Key
Required?
Description
p
Yes
Protocol: Helps other systems identify and process brc-223 events
op
Yes
Operation: Type of event (Deploy, Mint, Transfer)
tick
Yes
Ticker: 4 letter identifier of the brc-223
amt
Yes
Amount to mint: States the amount of the brc-223 to mint. Has to be less than "lim" above if stated
data
No
Free bytes parameter associated with a token transaction. The data parameter may be provided by either the token holder, the operator, or both. (Supports the Unicode Standard - supports all Unicode characters, symbols, signs, and codes)
operatorData
No
Free bytes parameter associated with a token transaction explicitly intended for the operator to provide any information or reason for the transaction. (Supports the Unicode Standard - supports all Unicode characters, symbols, signs, and codes)
Key
Required?
Description
p
Yes
Protocol: Helps other systems identify and process brc-223 events
op
Yes
Operation: Type of event (Deploy, Mint, Transfer)
tick
Yes
Ticker: 4 letter identifier of the brc-223
amt
Yes
Amount to transfer: States the amount of the brc-223 to transfer.
to
No
Address to send to: States the receiving address. If left blank logic will presume that the receiver of the transfer is correct.
fee
No
Transfer fee: For tracking without taproot data purposes only
data
No
Free bytes parameter associated with a token transaction. The data parameter may be provided by either the token holder, the operator, or both. (Supports the Unicode Standard - supports all Unicode characters, symbols, signs, and codes)
operatorData
No
Free bytes parameter associated with a token transaction explicitly intended for the operator to provide any information or reason for the transaction. (Supports the Unicode Standard - supports all Unicode characters, symbols, signs, and codes)