Representative Tokens (i.e. Colored coins) on Bitcoin Cash have generated a lot of excitement within the community, and seems to be the raison d’etre for Ethereum. There is even a significant bounty placed on this functionality. The aim of this article is to be a brief introduction to Bitcoin tokens systems, and requirements of such systems.

Currently, there are a number of mechanisms put forth for Bitcoin Representative Tokens, with a spectrum of dependence on the Bitcoin base protocol. There are Omni and Counterparty which use Bitcoin Cash primarily as a data storage mechanism for second layer smart contracts. Andrew Stone has proposed OP_GROUP which makes a small change to the UTXO format and transaction validation rules. Coins can also be colored via a 2 of 3 multisig wallet where a third party enforces rules on transaction outputs. Finally, covenants allow for script to enforce rules on transaction outputs such that the outputs do not lose their coloring.

Each of these solutions have different trade-offs, and in order to evaluate them we should compare them against the requirements for an ideal solution. To determine those requirements, we need to first revisit one of the key properties of Bitcoin to understand how representative tokens differ from normal coins. This property is that Bitcoins are both a unit of account, and a medium of exchange. Knowledge of private keys proves ownership of the associated BCH. This means that blockchain data regarding BCH is always fully congruent with what is actual.

On the other hand, representative tokens represent something else which exists outside of the blockchain. Possession of a private key which controls representative tokens does not guarantee that an individual is physically in possession of the subject of a token, that there is such an object, or that the token may be redeemed. Due to the nature of these tokens, there is always a trusted third party which must issue them and reconcile state when the blockchain and the rest of the world disagree.

An example of such reconciliation was November 20th of 2017. Tether was hacked and erroneously issued 30 million USDT. In order to reclaim those funds, Omni had to perform a hardfork to lock up those tokens. It is likely that private key material was compromised in this hack, thus enabling the attacker to continue to issue USDT at whim had no hardfork occured. If this functionality were within the base-layer of the Bitcoin protocol, Bitcoin itself would have had to perform a hardfork or let USDT become worthless.

Having such trusted third parties is antithetical to the purpose of the Bitcoin ledger. However, it should be acknowledged that having an open standard for transferring assets is valuable, and Bitcoin can perform that function. Yet, it should not be forgotten that such a trusted third party exists simply because a token exists on the Bitcoin blockchain.

As such, any representative token system which is implemented in the base layer of the Bitcoin Cash protocol requires functionality to enable the trusted third party to manage tokens which are, in practice, only on loan to Bitcoin users. Additionally, as the point of including these tokens on a blockchain is to have an open standard for asset transfer, this specifies other requirements.

These requirements are as follows:

1. Ability to issue tokens and destroy tokens by only the administrator of the token

2. Usable in SPV wallets without relying on a proprietary 2nd layer protocol

3. Ability to rotate token issuing key material.

4. Ability to accommodate revocation, and backup, keys.

5. Ability to recall tokens.

Additionally, there may be other functionality that is required to make tokens useful for their intended purpose to users. Taking the example of the ERC20 specification, the following functionality should be supported, or supportable through future Bitcoin Cash protocol upgrades:

6. Verifiable Supply limits

7. Allowances

8. Escrow

9. Transferable only under rules specified by a smart contract.

Finally, the purpose of Bitcoin Cash is to scale to support billions of transactions per day. Any auxiliary use cases are surely welcome additions, but should not hinder that vision. Representative tokens can have an effect on UTXO set management, and the implications that has on future scalability should be carefully evaluated.