Cloud Hosting

This post was first published on Medium. Read Part 1 here, Part 2 here, and Part 3 here.

Control Distribution of BSV-20 Tokens

In our last article, we have shown smart contracts can control transfers ofBSV-20tokens after minting. Today, we demonstrate how to control distribution/issuance of such tokens.

Tickerless mode

BSV-20 introduces atickerlessmode in V2 and takes a different approach from V1.

DeployTo deployand minta token with a supply of 21000000, you inscribe the following JSON (ContentType: application/bsv-20):

Note, unlike V1, there is no designatedtickfield (thustickerless).

Issue

To issue 10000 tokens above, you create a transfer inscription with the following JSON.

Instead of a ticker, a token is identified by anidfield, made of the transaction ID and output index where the token was deployed, formatted as_.

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 tokens 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 firstminting.

For more details on how BSV-20 token V2 works, please read theofficial 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 tokens 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:

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.

Contract

Line 612 enforce rate limiting. Line 2630 ensure supply is not exceeded. If yes, Line 3852 create an output containing the same contract but with updated state: remaining supply. Line 5558 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 Bitcoins Proof of Work (PoW).

Credit: David Case

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.

Watch The Bitcoin Masterclasses #3 Day 2 Afternoon Session: Accounting and mapping transaction on-chain

New to blockchain? Check out CoinGeeks Blockchain for Beginners section, the ultimate resource guide to learn more about blockchain technology.

Read the original here:

Integrate Ordinals with smart contracts on Bitcoin: Part 4 - CoinGeek