Problem description
Current retirement implementation allows for 'pairing' and further retirement of tokens issued by the same Standard Registry (SR). This is limiting as the architecture was designed for supporting retirement of any token pairs even issues by different registries (with prior approval of such operations by each side of the retirement 'pair'). Furthermore with the recent security changes in the Hedera contract operations detailed here and here the existing implementation would not work for newly deployed contracts.
Requirements
Implement an enhancement for the token creation and retirement operation essentially creating contract-managed ACL list of delegate (contract) accounts which can retire tokens. The idea is as follows:
- An SR deploys a smart contract which will be the creator/destroyer of tokens of a particular type. This means that the 'burn' and/or 'wipe' key for the token would belong to this smart contract. The SR adds this key as the wipe key to the token 'definition'.
- This smart contract contains a provision for keeping a map of (contract) account addresses to tokens it controls.
- Each of the 3rd party 'exchange' contract, for each pair, requests an authorisation from the 'Manager' smart contracts for performing retirement operations.
- When/if the SR approves such request the 'exchange' smart contract's address gets added tot he 'authorised' map of address-token pairs.
- From this point this 'exchange' smart contract can call 'retire' method on the 'Manager' smart contract, the latter checks if the caller's address is in the 'authorised' list and then performs the requested action.
Definition of done
- Retirement functionality is implemented in high-level architecture described above
- Documentation is updated accordingly
- An example retirement contract is built into the Guardian distro, as well as production 'Manager' contract
Acceptance criteria
Retirement operations are aligned with the original vision described in #55, supporting the ability to:
- define 'pairs' (for retirement) of tokens issued by different SRs
- incomplete 'pairs' where only one side of the pair is tokenised, the other side is handled manually by a user who is able to associate manually issued VC documents with the retirement operation
- operations can be configured to require manual approval (for each retirement transaction) from the SR, and also pre-approved for automatic execution
- the implementation needs to enable the trustchain to display retirement as well as the general events
Problem description
Current retirement implementation allows for 'pairing' and further retirement of tokens issued by the same Standard Registry (SR). This is limiting as the architecture was designed for supporting retirement of any token pairs even issues by different registries (with prior approval of such operations by each side of the retirement 'pair'). Furthermore with the recent security changes in the Hedera contract operations detailed here and here the existing implementation would not work for newly deployed contracts.
Requirements
Implement an enhancement for the token creation and retirement operation essentially creating contract-managed ACL list of delegate (contract) accounts which can retire tokens. The idea is as follows:
Definition of done
Acceptance criteria
Retirement operations are aligned with the original vision described in #55, supporting the ability to: