Integrate Ordinals with Smart Contracts on Bitcoin: Part 4
In our last article, we have shown smart contracts can control transfers of BSV-20 tokens after minting. Today, we demonstrate how to control distribution/issuance of such tokens.
Tickerless mode
BSV-20 introduces a tickerless mode in V2 and takes a different approach from V1.
Deploy
To deploy and mint a token with a supply of 21000000, you inscribe the following JSON (ContentType: application/bsv-20):
Note, unlike V1, there is no designated tick field (thus tickerless).
Issue
To issue 10000 tokens above, you create a transfer inscription with the following JSON.
Instead of a ticker, a token is identified by an id field, made of the transaction ID and output index where the token was deployed, formatted as <txid>_<vout>.
Also the first issuance transaction must spend from deployment transaction since the whole supply is minted at once, while minting transaction does not spend from it and they are separate in V1. That means every transaction of a token can traceback to that token’s genesis deployment, and each is in a DAG (Directed Acyclic Graph) rooted at genesis transaction. This allows BSV-20 indexer to scale more efficiently since it does not have to scan the entire blockchain and order minting transactions, to enforce “first is first” minting.
For more details on how BSV-20 token V2 works, please read the official documentation.
Fair launch
A notable characteristic of BSV- 20 V1 tokens is fair launch, contrasting with ERC-20 tokens. Specifically, once someone deploys a transaction of the tokens on BSV-20, everyone has the same chance to claim the tokens. Issuers cannot reserve a portion for free, i.e., there is no pre-mine.
If a token’s total supply is minted at once when deployed in V2 tickerless mode, is it possible to maintain fair launch?
The answer is yes. Instead of locking the whole supply in a standard issuer address (P2PKH script) when deployed, we lock it into a smart contract. The smart contract can be called by anyone and any distribution policy can be enforced in it.
In the diagram above, each box represents a token UTXO and stacked UTXOs are in the same transaction. The second transaction spends the UTXO of the first deployment transaction, indicated by the first arrow, and creates two UTXOs:
- a spawned copy of the same contract in genesis, but with reduced remaining supply
- newly issued tokens.
The chain of transactions goes on till the whole token supply is issued. Note the contract can be called by anyone.
We list a few policies as examples.
Rate limit
Under this policy, anyone can claim tokens as long as it is more than, say, 5 minutes away from the last claim. Contract is listed below.
Line 6–12 enforce rate limiting. Line 26–30 ensure supply is not exceeded. If yes, Line 38–52 create an output containing the same contract but with updated state: remaining supply. Line 55–58 issue tokens to a destination address.
mini PoW
The policy ensures anyone can claim tokens, as long as she finds a nonce meeting some specified difficulty requirement, as in Bitcoin’s Proof of Work (PoW).
ICO
A policy can be implemented so that anyone can receive tokens by sending bitcoin to a specific address in a trustless way, similar to an initial coin offering (ICO). In the diagram above, a third output is added for bitcoin payment, which is validated in a contract.
