Skip to content
Assaf Shomer edited this page Jun 15, 2015 · 30 revisions

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 1, 2 or 3. Basically, the inheritance rules are less strict (giving more freedom to the new recipient of the asset) as the number increases.

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

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

params

  • 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.

The Expiration rule can accept JSON object with the following parameters:

params

  • blocks: [encoded](Number Encoding) integer specifying a block-height or a range.
  • range: A boolean specifying whether the block parameter is the height of a specific block or designating that the asset will expire within so many blocks after the block where the issuance transaction was included.

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 ?

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

params

  • 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
Clone this wiki locally