CoinSpark allows any web-backed asset to be issued and transacted over the bitcoin network.

CoinSpark assets can be considered as a member of the Colored Coins family, although in CoinSpark units of bitcoin are not colored directly. Instead, each output of a bitcoin transaction can contain quantities of one or more CoinSpark assets, alongside regular bitcoin. When a transaction output is ‘spent’ by the input of another transaction, all units of the CoinSpark assets flow into the new transaction together with the bitcoin, and are distributed between the new transaction’s outputs in accordance with any transfer metadata attached.

The CoinSpark protocol is designed specifically for scalability and usability. One of the key design principles is asset independence, meaning that the movement of any particular CoinSpark asset can be tracked across bitcoin transactions while ignoring the movement of other assets. Another key principle is asset discoverability, meaning that the user of a CoinSpark wallet can receive any type of asset using a single address, and their wallet will automatically load and recognize new asset types as they come in. For more background, please see the Bitcoin Colors white paper.

A new CoinSpark asset is created by a bitcoin transaction which includes genesis metadata in its OP_RETURN output. This metadata encodes a number of key parameters, including the number of units issued, transaction charges, the URL of the asset’s web page, and an asset hash as a proof-of-contract. If the genesis is valid, units of the asset are ‘deposited’ in all non-OP_RETURN outputs except the last, to create the desired total. Once the genesis transaction is confirmed on the blockchain, the asset which it created can be referred to concisely using an asset reference.

By default, any CoinSpark assets in the inputs of a transaction flow to the last non-OP_RETURN output of that transaction. However if a transaction contains transfer metadata in its OP_RETURN, and the transfer is valid, this default behavior can be changed, with some units of some assets being sent from specific inputs to specific outputs. The CoinSpark protocol uses a highly efficient encoding scheme to allow many such transfers to be represented within the 40 byte limit for OP_RETURNs.

Every CoinSpark asset has a web page, whose URL is given by the genesis metadata of the transaction which created the asset. The web page can be viewed in regular web browsers, but also contains machine-readable information about the asset in JSON format. The JSON includes a link to the contract defining the legal relationship between the asset issuer and its holders. Some of the JSON fields, together with the contract’s content, are used to calculate the asset hash. This hash is embedded within the genesis metadata and serves to ensure that issuers cannot change important legal aspects of their asset after it is created.

In order to know the quantity of a particular CoinSpark asset in a particular bitcoin transaction output, the history of that asset since its genesis needs to be tracked across all transactions that took place between. This is because regular bitcoin nodes are unaware of the CoinSpark protocol, so they cannot be trusted to verify and track these quantities directly. If a bitcoin wallet downloads the entire blockchain, it has all the information it needs to perform this calculation, though the process can be very time-consuming. Therefore CoinSpark requires every asset issuer to provide the address of one or more tracking servers in the asset web page JSON. Tracking servers calculate the balance of the asset in the outputs of transactions issued into the network and respond to requests from wallets regarding that balance. Issuers are free to use our free tracking server at assets[1|2|3] We also provide an open source asset tracking server for issuers who prefer to run their own.