Asset contract (voting pools)
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 use a colored coin definition 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 colored coin with a IFOC kernel. This indivisible colored output is known as the
charter output. The colored coin definition 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 charter output definition in its header. Each future instance must contain the same definition.
To activate the pool contract, the charter output must be moved to the 0th change address defined for the first series, and the corresponding transaction must include an OP_RETURN output containing the instance identifier.
Modifying the contract
Clients validate the asset contract using the blockchain. The current location of the charter output is identified, and the transaction which contain it is checked for a valid instance identifier that matches the supplied instance of the 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.