Introduction

A token is defined, in this context, as a digital record of ownership that is managed by a smart contract. The term 'token' implies a sense of physicality in that it can only be in one place at one time. However, at a technical level, it is simply a digital ledger entry that records the ownership rights of a certain entity for a given asset, and the subsequent changes of ownership over time to the Bitcoin (BSV) ledger. The protocol doesn't recognize two owners of a token at the same point in time, and the smart contract governs this rule.

With Tokenized tokens, the owner of the asset is the entity that possesses the associated token by controlling the private keys to the Bitcoin public address that the token is held at. For the ownership of the asset to change, the token must be transferred to the new owners.

A token is created by a smart contract at the request of the administration of a contract issuer by way of the Asset Definition action. The administration specifies what rules/terms the smart contract uses to control the token(s) and the smart contract will adhere to these terms, but only if they are in accordance with the rules of the protocol. Tokens can only be transferred from one address to another by way of a Settlement or Confiscation action published to the blockchain by the smart contract in response to a valid request action.

It is up to the administration to ensure that the rules under which tokens are managed and exchanged are in-line with the legal and regulatory requirements of the jurisdiction that they are subject to. The protocol provides enough expressiveness and functionality to cover all the administration's compliance requirements.

Token Types

A token is a concept, and as a concept the definition does not vary. A token is a token. However, the asset that the token represents varies significantly with respect to the metadata that defines it. Asset types are broadly defined by a 3-letter code called the Asset Type, which is used by the wallet, smart contract and the rest of the ecosystem to inform them how the metadata is to be parsed and presented.

The metadata is defined by the user and confirmed by the smart contract at the creation stage. The user can specify any metadata as long as it adheres to the protocol rules.

Token Identification

The identity of a token is centred around its Asset ID (Asset ID = Asset Type + base58(Asset Code + checksum)) which should be unique on the Bitcoin network. However, the Asset ID is always associated with a particular contract address and the real identity of a token should always be referenced by the Contract Address + Asset ID. Asset ID's are generated by creating a Sha256 hash of the Contract's PKH and the index of the asset. This is to ensure they are created by an administration in a random way such that there cannot exist multiple copies of the same Asset ID except through extreme incidents of chance. The potential for fraud is minimised by ensuring users cannot be misled into buying the wrong asset with a copied Asset ID.

The Asset ID is generated by the issuer's wallet when the tokens are created and is used by the token until they are destroyed. The Asset ID can never be changed and attempts to do so will be rejected by the smart contract.

Token Fungibility

Fungibility is the property of a good or a commodity whose individual units are essentially interchangeable, where each unit is indistinguishable from any other unit. Tokens that are created with the same asset ID are considered fungible tokens. These tokens can be exchanged and will carry the same value as any other token created in the same asset ID.

It is possible to create non-fungible tokens by creating tokens that have unique asset IDs. These tokens can represent unique qualities such as seat numbers or other details for things such as in-game collectibles or other such items.

Modifying Tokens

Depending on the rules of the asset and smart contract, most tokens can have their metadata modified using on-chain messages to the smart contract.

Modifications can be made to any individual field (within rules) but modifications to the payload require the full data encapsulated within the payload to be overwritten.