Rules

Rules This part of the metadata is one of novel features of the new colored coins protocol which opens up the possibility of creating smart contracts with colored coins.

The current implementation of the colored coins protocol supports 4 kinds of rules:

• Fees: Pay a fee to specific address on each transfer
• Expiration: The asset expires after a while
• Minters: Recipients of the asset can issue more of it
• Holders: Only certain Bitcoin addresses can receive this asset

Each one of the above 4 rule types accepts a JSON object (or objects) with two keys

params

Specifying relevant parameters to be discussed below

Inheritance

Specifying how this rule is inherited upon transferring the asset. The inheritance flag can accept the numbers 0, 1 or 2. The inheritance rules are less strict (giving more freedom to the new recipient of the asset) as the number increases. Roughly you should think of those numbers as designating:

• 0 : Low privilege (Locked)
• 1 : Limited privilege
• 2 : Admin (Unlocked)

Fees

Specifies a list of amount and addresses to which the amounts must be payed on each transfer of the asset.

TODO are we talking about satoshis or about asset units? is the address a Bitcoin address

params

The Fees rule can accept an array of JSON objects each specifying the following parameters:

• amount: The amount of units of the relevant asset that must be payed to the address
• address: The Bitcoin address to which the amount must be transfered

Inheritance

• 0 : The new recipient of the asset cannot add fees
• 1 : The new recipient of the asset can add more fees, but only of inheritance level 0
• 2 : The new recipient of the asset can add more fees without restriction

Expiration

Setting an expiration time for the asset using blocks.

params

The Expiration rule can accept JSON object with two parameters:

• blocks: [encoded](Number Encoding) integer specifying a block-height or a range.
• range: A boolean specifying whether
• range = 0 : The block parameter is the height of a specific block that when reached the asset expires, or
• range = 1 : The block parameter designates range N. The asset will expire when N blocks were mined on top of the block of the issuance transaction.

Inheritance

• 0 : The new recipient of the asset cannot add an expiration
• 1 : The new recipient of the asset can add an expiration, but only of inheritance level 0
• 2 : The new recipient of the asset can add an expiration without restriction

TODO what does it mean to add an expiration if one exists?

Minters

Allowing issuance of more units of the asset from certain Bitcoin addresses, regardless of the asset type.

TODO can we mint more in an address only if we first have that asset in the address ?

params

The Minter rule can accept a list of JSON object with a single parameter:

• address: A Bitcoin address. Anyone with the private key to this address can issue more units of the asset, even if it is
• locked
• unlocked but the minter doesn't have the private key for the address where it was originally issued .

Inheritance

• 0 : The new recipient of the asset cannot add minters (asset is locked as far as the rules engine is concerned)
• 1 : The new recipient of the asset can add minters, but only of inheritance level 0
• 2 : The new recipient of the asset can add minters without restriction

Note that, for the sake of performance optimization, in case of reissuing an asset by a minter (regardless if the asset is locked or not) the [Asset_Genesis](Asset Metadata) pointing to the transaction and block of the first issuance, must be provided in the metadata.

Holders

Restricting the set of Bitcoin addresses that the asset can be sent to.

params

The Holders rule can accept a list of JSON object with a single parameter:

• address: A Bitcoin address. The asset can only be sent to one of those addresses, so only the limited group that controls this list of addresses can hold the asset.

Inheritance

• 0 : The new recipient of the asset cannot add holders
• 1 : The new recipient of the asset can add holders, but only of inheritance level 0
• 2 : The new recipient of the asset can add holders without restriction

Use case

One of the biggest debates for using a permissionless blockchain (like Bitcoin's) as a backbone for financial institutions is the ability to control the assets in a manner that will comply with regulations like AML and KYC. Using this rule one would be able to issue an asset that is valid only when stored in predefined confirmed addresses, thus effectively creating a permission layer inside a permissionless blockchain.

Example

A private equity market issuing an asset that only accredited investor are allowed to buy and hold a specific address after a full KYC. In that case the exchange/ crowdfunding platform will verify the identity and the address by signing a transaction and match between the person and the address. Sending or selling the asset to an unconfirmed address will end in loosing the asset (the asset will become invalid in an unregistered address). The issuer of the asset would be able to add more permissions (addresses) to the list of confirmed addresses the asset will be valid in if the flag locked is false.