# Is overflow possible in this smart contract?

``````function mint(address beneficiary) public payable {
uint256 MTCToken = (msg.value/10000) * (10 ** uint256(18));
uint256 teamToken = (MTCToken/100) * (5);
balances[owner] += teamToken;
balances[beneficiary] = balances[beneficiary] + (MTCToken - teamToken);
totalSupply_ = totalSupply_ + (MTCToken);
}
``````

I'm a bit confused about the exact length of the overflow limit. Is it possible to cross the limit in the above function?

It is possible to overflow, but we can't say it unless we know what is the type of balances and totalSupply_. It might uint8 and then it would be very easy to overflow balances[owner] or balances[beneficiary] or totalSupply_

If this is uint256 then it still possible, but would require to send a lot of ETH to do it. It doesn't make any sense.

I don't know your requirements so I can't say why you multiplying by 10 ** 18.

``````uint256 MTCToken = (msg.value/10000) * (10 ** uint256(18));
``````

msg.value is in Wei so I assume you have a bug here. It is also better first to make multiplication and then division.

I'm bit confused with the exact length of overflow limit.

Answer: Overflow limit depends from destination variable type. If you are storing results in uint8 type then maximum value is 255.

So in this example:

``````pragma solidity 0.4.24;

contract Overflow {
uint8 iWantToBeCrossed;

function OverflowMe() public
{
iWantToBeCrossed = 100;
iWantToBeCrossed += 200;

}

function ShowMeTheValue () public   view returns (uint8){
return iWantToBeCrossed;
}
}
``````

Function ShowMeTheValue will return 44 after you call OverflowMe function.

For uint256 you need bigger values. So theoretically it is possible to overflow, but practically it doesn't make any sense because you would need to send a lot of ETH to your contract.

Overflow is technically possible but not very likely. The highest possible number in a uint256 is (2^256)-1. If someone were to send all the existing ether to that function, MTCToken would still only be 9.7330305e+39, which is only ~133 of the 256 bits.

Note that msg.value is already in wei, so multiplying by 10**18 isn't gonna give you how much wei there is. Also, I would suggest doing multiplication before division, since division will result in dropped decimals. e.g. 12345/100*5 = 615 vs 617.