Asset Token 1.2.6

Added

• owner() view function to retrieve contract owner address
• Deployment through KeystoreProvider

Changed

• uint8 status parameter instead of int status in the initialize function

Asset Token 1.2.2

In this release we have extended the granularity variable size from uint8 to uint256, to support a wider set of use-cases.

Asset Token 1.2.1

In this minor release we run the slither source analyzer against the project to check for vulnerabilities. Fortunately we just had few low severity flags raised, so we changed:

• external instead of public function modifier
• calldata instead of memory data location of external function parameters
• private instead of public state variables

Asset Token 1.2.0

We allowed the user specify during contract deployment the granularity of their token, as previously it was fixed at one. As reported in the EIP-777, the granularity is the smallest amount of tokens (in the internal denomination) which MAY be minted, sent or burned at any time. Given that different use-cases may need a different granularity, this solution provides a much higher flexibility. Clearly, this implies that for each send, fund and burn operations, the amount specified MUST be a multiple of the granularity in order for the transaction to go through. This release provides also that check.

Asset Token 1.1.0

We added filtering features for payment operations, namely Blacklist and Whitelist. The user deploying the contract specify in the constructor the mode to start with, but then can switch from one to another (as well to NoFiltermode).
Depending on the active mode at a given time, the contract will check for each payment operation (send, burn and fund) if the sender is allowed to do so.

Asset Token 1.0

ERC777

We migrated our token contract from ERC20/ERC223 to ERC777 standard. This improvement aim at giving more advanced features to interact with the token. The two most important are hooks and operators:

• With hooks, contracts and regular addresses can react both to incoming and outgoing tokens, by means of custom functions that may as well reject the transfer in case of unsupported tokens. This would avoid unintentional lock of tokens as with ERC20 contract. The contract makes use of the ERC1820 pseudo-introspection registry, where addresses register the interfaces that implement such hooks.
• By means of operators, contracts and regular addresses can authorize as well as revoke other addresses to move tokens on their behalf. As deeper explained in this post, this will allow to build several different payment services (i.e. bulk payments, etherless transfer) in a more modular way, subsequently to the token contract deployment.

For the sake of simplicity, we decided not to maintain backward compatibility with ERC20 tokens. This doesn't imply that such compatibility couldn't be integrated in case of need.

npm package

From this version on, we decided to publish our Asset Token as npm-package, so that it could be easily reused and extended by other projects.

Upgradable Asset Token

With this release we have given our Asset Token the power of upgradeability! This means that we can now implement new functionalities or release patches without requiring hard forks and keeping the state consistent.
This is possible thanks to the groundbreaking zeppelinOs project and the proxy pattern they have come up with to support updates. For more insights about that, including caveats and an how-to guide, please refer to our blog post.