Asset contract (voting pools)

From Open Transactions
Jump to navigation Jump to search

Introduction

Asset contract for voting pools differ from standard OT asset contracts in two ways: they contain a copy of the keyset definition, and they are not identified by their hash.

Since keyset definitions change over time, or when the pool is modified, this means voting pool asset contracts are mutable, This means the asset contracts can not be identified by their hash. Instead, voting pool contracts are linked to a smart property, and use the smart property's color descriptor as their identifier.

Identifying voting pool asset contracts

Each valid version of the contract is known as an instance of the contract, and has an instance identifier. Prior to creating a voting pool asset contract, one of the creators of the pool must create a smart property virtual token. This indivisible virtual token (smart property) is known as the charter output. The color descriptor for the charter output is the permanent identifier that will be used as the asset contract ID.

The initial pool asset contract instance is created with the smart property descriptor in its header. Each future instance must contain the same descriptor.

To activate the pool contract, the charter output must be moved to the 0th change address defined for the first series, will setting the value of the smart property to the instance identifier.

Modifying the contract

Clients validate the asset contract by looking up the value of its smart property and verifying this value matches the instance identifier of the asset contract. Additionally, the charter output must be located in the 0th change output for the current series.

This means the only way the charter output can be moved is if m-of-n members of the voting pool, therefore it is possible to prove that the current instance of the contract is part of an uninterrupted continuity from the original version if the charter output is located at the correct address.