Mainframe security record

The admin should vet each fy token that wraps another token to ensure the wrapped token behaves as expected.

In smart contracts, for loops are often prone to vulnerabilities given the nature of transactions and the concept of gas. The gas necessary for executing such a loop is proportional to the number of iterations. Using is safe when the number of iterations is predictable, but against the best practices if unknown. In MainframeTokenDistribution.sol, the distribute Tokens() function loops through all recipients passed to the smart contract. Because the number of recipients is unbounded, it is possible that the transaction will consume so much gas that it will not be able to fit within a block. In addition, if the transferFrom() function ever failed, it would revert all progress thus far. To mitigate both these issues, it is much safer to break that functionality into smaller, digestible pieces.

These other issues, though not immediate security vulnerabilities, were still concerns to the Quantstamp team. If possible, take some time to fix the following potential problems. • In file MainframeToken.sol in the validDestination modifier, we suggest that require(address != 0x0) be included in this modifier as well. • Both MainframeToken#47,51 and MainframeTokenDistribution#8, 19 accept uint parameters. We suggest that those be turned into uint256. • Consider making the emergencyERC20Drain() functions of MainframeToken.sol identical to that of MainframeTokenDistribution.sol to drain any and all accidental tokens, as there is likely no scenario in which it would be preferable to only drain, say, half.