|Type of change request|
This feature attempts to democratise the asset type creation aspects of the Iroha distributed ledger to enable every user to create any arbitrary tokens of their own choosing. Initially, this was motivated by the idea of recording personal IOUs on the ledger and making such informal ‘debts’ tradable in the system. However, considerations of how to do the implementation led to a more generallzed set of enhancements that can accomplish the same end.
This proposal extends the existing behaviour of Iroha in two ways:
Personal domains extend the domain concept to add a domain that is associated with every user account. The user is then given all of the domain and asset administrator permissions normally associated with the domain (except perhaps for adding other users into their personal domain). Ideally, it would be possible for users to create additional personal domains to seperate assets, but at this stage I cannot think of any motivating use cases for this. All personal domain assets are tradable just like normal domain assets.
Derivative assets are a type of asset that has a relationship with another pre-existing asset in the ledger. For example, an IOU dollar would be a token that derives from the underlying asset type of dollar, but maintains its separate identity as an IOU. Derivative assets need not be created in the same domain as the underlying linked asset. Most types of derivative assets will need additional properties attached to them. To continue with the IOU dollar example, it would need fields for specifying an owed by relationship to the user responsible for repayment.
In a more serious application, a bank might record actual loan information as a debt asset with other metadata such as the loan repayment terms or an options asset might record the maturity date and the strike price.
To obtain maximum flexibility, derivative assets may require an additional change to the asset metadata model to allow any arbitrary additional fields to be added to it at creation time, with restrictions allowed on how/when these metadata fields are updated (if ever).
|#||Change description||Affected component||Change motivation||Dependency (optional)|
|1||What is changed||Where it is changed|
Why it is done
|#||Research activity||Details||Acceptance criteria||Responsible (accepter)|
|#||Target reader||Documentation description|
|#||Validation activity||Intention||Actions||Expected result|
|1||Testing||Test component X and check if …|
Change request type