The token timelock example is important because it's a well understood simple concept that touches on how to work with tokens. I propose implementing a few simplifications/clarifications in order to enhance it's readability and usability as learning material:
- Consistent naming: the folder is named
timelock but the contract is called CalimbaleBalance. I suggest standardizing on token-timelock and TokenTimelockContract
- Remove
Timebound and only support "valid after" semantics
- Support a single claimant instead of a vector of claimants
- Migrate from
deposit() to a p22 constructor
The token timelock example is important because it's a well understood simple concept that touches on how to work with tokens. I propose implementing a few simplifications/clarifications in order to enhance it's readability and usability as learning material:
timelockbut the contract is calledCalimbaleBalance. I suggest standardizing ontoken-timelockandTokenTimelockContractTimeboundand only support "valid after" semanticsdeposit()to a p22 constructor