2
If daiToken were a malicious contract once you have invoked transferFrom then it can call your deposit function before it has finished executing the first time so potentially amount is credited multiple times.
But to be honest ERC20 doesn't guarantee even if you call transferFrom successfully that the transfer of tokens will be OK. You have to trust that it ...
2
Yes, you can simply add that restriction in functions transfer and transferFrom.
For example, suppose you want to restrict it to multiples of 100:
contract MyERC20Token {
...
function transfer(address to, uint256 value) public returns (bool) {
require(value % 100 == 0);
...
}
function transferFrom(address from, address to, ...
1
There is reentrancy example code you can try out here: https://github.com/KevinSmall/SolidityContractVulnerabilities#reentrancy
1
Everything (no exceptions) starts with a transaction signed by an externally owned account (EOA).
Signed transactions are sent to the network and included in a block. Blocks establish the canonical transaction order. (Peer discovery, gossip and mining.)
Ordered transactions are processed by nodes as the blocks arrive. To deploy that contract, first, it is ...
1
Your understanding is intuitive but the actual situation calls for inverting the conceptualization of tokens.
First, ETH is a special case since it's the native currency OF the network. Tokens are contracts that run ON the network. They have commonality because they, generally, adhere to the ERC20 standard.
Your contract will know when it has received ...
1
As you have not made the contracts upgradable at deployment, you can't upgrade it. I would forget about this and deploy a new one. Hopefully you haven't deployed tokens to it.
Only top voted, non community-wiki answers of a minimum length are eligible
