Assimilators do not conform to the ERC20 specification
The assimilators in the codebase make heavy usage of both the `transfer` and `transferFrom` methods in the ERC20 standard.\\nQuoting the relevant parts of the specification of the standard:\\nTransfers _value amount of tokens to address _to, and MUST fire the Transfer event. The function SHOULD throw if the message caller's account balance does not have enough tokens to spend.\\nThe transferFrom method is used for a withdraw workflow, allowing contracts to transfer tokens on your behalf. This can be used for example to allow a contract to transfer tokens on your behalf and/or to charge fees in sub-currencies. The function SHOULD throw unless the _from account has deliberately authorized the sender of the message via some mechanism.\\nWe can see that, even though it is suggested that ERC20-compliant tokens do `throw` on the lack of authorization from the sender or lack of funds to complete the transfer, the standard does not enforce it.\\nThis means that, in order to make the system both more resilient and future-proof, code in each implementation of current and future assimilators should check for the return value of both `transfer` and `transferFrom` call instead of just relying on the external contract to revert execution.\\nThe extent of this issue is only mitigated by the fact that new assets are only added by the shell administrator and could, therefore, be audited prior to their addition.\\nNon-exhaustive Examples\\n```\\ndai.transferFrom(msg.sender, address(this), \\_amount);\\n```\\n\\n```\\ndai.transfer(\\_dst, \\_amount);\\n```\\n
Add a check for the return boolean of the function.\\nExample:\\n`require(dai.transferFrom(msg.sender, address(this), _amount) == true);`
```\\ndai.transferFrom(msg.sender, address(this), \\_amount);\\n```\\n