Comment on page
The purpose of this proposal is to provide a standard that offers the same functionality that BRC20-BTC offers that works on BSV instead of BTC. A guiding motivation behind this standard proposal is to try and keep the standard as simple as possible.
This specification is meant be as similar to the BTC BRC20 standard so it also follows the
first is firstapproach. In order to deploy or mint a token, the process is almost identical to the protocol on BTC: you would create a transaction output with the data fields below and tranasction are indexed on a 'first is first' approach with duplicates or overflows being invalid and ignored. The main difference between bsv-20 (this protocol) and bsv-20 protocol (on BTC) is:
- A content type of
application/bsv-20is used in place of
text/plain. This change means a bsv-20 indexer does not need to parse every text inscription to test for embedded JSON content (and failing most of the time) in order to determine if an inscription is BSV-20 related.
First is fistdeployment and minting allows for a single use-case where a token is publicly mintable, by anyone, outside of the control of any token issuer. V2 of the BSV-20 protocol introduces a new
Tickerlessmode forgoes the
first is firstnature of BRC20-BTC, and allows the capibilities to have a smart contract, or an adminstrator, control distribution. Additionally, every transaction of a
tickerlessmode token, forms part of a single on-chain DAG (Directed Acyclic Graph), such that the transaction can easily be tracked back to that token's genesis
first is firstmode, tokens are deployed and minted in separate transactions, with the only correlation between them being the token's ticker. Additionally, the ticker may be deployed multiple times, and may have more tokens minted than are defined in the token deployment. The only way to determine if any token UTXO is valid is to scan the entire blockchain and and perform complex analysis.
Tickerlessmode takes a different approach, where a token is deployed, and it's entire supply is minted in a single transaction output. This output can be locked with any logic which can be implemented in Bitcoin script. It can be as simple as a standard adminstrator address (P2PKH script), Proof-of-Work distribution, or even an entire Proof-of-Stake blockchain running on top of Bitcoin SV.
In order to deploy/mint a token, you create a JSON ordinal inscription output with the data fields below and content type of
Example: To deploy and mint a token, you would create an inscription with the following json (ContentType: application/bsv-20):
first is firstmode of v1, no
tickfield is defined. A token is identified by an
idfield, which is the transaction id and output index where the token was minted, in the form of
- 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)
- 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)
- Number of decimals cannot exceed 18 (default)
- Maximum supply cannot exceed uint64_max
In order to deploy an BSV-20
first is firsttoken, you must make sure that that token ticker has not already been deployed and then create a TXO with the following data present in the script. It does not matter whether this UTXO is spendable or not.
To deploy the
orditoken, you would create an inscription with the following json (with
In order to mint tokens of a specific BSV-20 token, you must make sure that that token ticker has already been deployed and then create a UTXO with 1 satoshi value as well as with the following data present in the script. This UTXO should be spendable in order for you to be able to transfer these minted tokens.
orditokens, you would create an inscription with the following json (with
Tokens in BSV-20 are held in UTXOs, similar to native bitcoins. This is different from BRC20, which holds balance in an account model. In order to transfer tokens, you spend that specific UTXO and create new outputs the same way you spend regular Satoshis, but the output(s) must contain
If more tokens are transferred in the output(s) than are available in the input(s) then the transaction is considered invalid and the tokens are burned. If less tokens are created in the outputs than are available in the intput(s), the unallocated tokens are burned.
Using the same procedure as regular Satoshi transfers allows us to benefit from the parallelisation Bitcoin benefits from, where you can split a specific UTXO with a large amount into smaller UTXOs and spend those in parallel (the same way you could exchange a $100 bill into $1 bills and spend those in parallel) with no sequential bottlenecks that something like ERC20 (Ethereum) sufffers from.
- 1.previous transfer output holding 500 tokens
- 2.previous transfer output holding 500 tokens
To transfer the
orditokens that you minted as shown above, you would create a transaction spending the minting UTXO (providing the signature and public key normally to spend the P2PKH script) with an output (or many) with similar scripts with the following json (with
ContentType: application/bsv-20), as shown below:
orditokens, you would create an inscription with the following json:
There are several inscriptions on the blockchain prior to the release of this spec that use
text/plainas the content type instead of
application/bsv-20. We will continue to index these up to block height
793000. Starting with this block, BSV-20 inscriptions must have a content type of
application/bsv-20to be considered valid by indexers.
V1 of this spec, supported functionality of
impliedtransfer was achieved by transferring a
transferinscription without the creation of a new
transferinscription. This functionality was put in place to support users who transferred their inscriptions before there were any publicly accessible tools to create
transferinscriptions, and was always a temporary solution. This functionality will be discontinued at block height 807000.