# How Æ stops hackers' favourite Token Contract exploit right on protocol level

The most unseeming things may sometimes lead to disastrous consequences. In the design of smart contracts, it didn't always take [confusing code structure](https://blog.zeppelin.solutions/on-the-parity-wallet-multisig-hack-405a8c12e8f7) or [sloppy logic](https://medium.com/chain-cloud-company-blog/parity-multisig-hack-again-b46771eaa838) to cause major havoc. Sometimes it took only something as simple as arithmetic operators from elementary school: Addition, Subtraction and Multiplication.

Taking as examples

0

and

2^256 - 1

, which are the smallest and largest numbers (unsigned integers) representable in the Ethereum Virtual Machine (EVM).

Although they seem to be far away from each other from a numeric point of view, they are actually way closer than any developer of smart contracts might like: Subtracting ```1 ``` from the former number or adding ```1``` to the latter results to

0 - 1 == 2^256 - 1

and

2^256 - 1 + 1 == 0

. An integer overflow occurs, the numbers *wrap around*. This has been the default behaviour in Ethereum ever since due to limitations of the EVM. Developers had to put extra checks in place to prevent this from becoming a problem - which didn#t always go well as you will see.

## Why is this so important? ##
In 2018 and subsequent years, the so called [batchOverflow bug](https://medium.com/@peckshield/alert-new-batchoverflow-bug-in-multiple-erc20-smart-contracts-cve-2018-10299-511067db6536) in many of Ethereum Token Contracts allowed malicious actors to create tokens from thin air, thereby causing major damage to exchanges and token owners.

What happens is that the hacker **transfers way more tokens** to multiple recipients **than he actually owns**, by calling the token contract's transfer function in a seemingly unproblematic way.

To explain how that common exploit is abused and what Aeternity has in place to prevent this by design, let's reimplement the same exploitable problematic contract logic in Sophia, Aeternity's Smart Contract Language. The critical line of code will be line ```13```.

**If you are not a programmer and/or just want to know how the exploit works, skip to after the code.**

include "List.aes"

contract SomeBasicToken =
  record state = {   
   balances: map(address, int)} // define map for balances
   
  stateful entrypoint init() : state = {
    balances = {[Call.caller] = 1337}} // give the deployer some tokens

  
  stateful entrypoint batch_transfer(receivers : list(address), value : int) =
   let count = List.length(receivers)
   let amount = count * value // potential overflow here
   let balance = state.balances[Call.caller]
   require(count > 0 && count =< 20, "incorrect count")
   // bypassable security check in next line:
   require(value > 0 && balance >= amount, "incorrect value or balance")

   // subtract tokens from sender
   let substracted_balance = state.balances{ [Call.caller] = balance - amount}
   put(state{ balances = substracted_balance })
   
   // helpfer function to add tokens to recipients' balance
   let add_balance_function =
    (receiver) =>
      let receiver_balance = state.balances[receiver]
      let added_balance = state.balances{ [receiver] = receiver_balance + value}
      put(state{ balances = added_balance })
   
   // add tokens to recipients' balance
   List.map(add_balance_function, receivers)

## So what happens ?
To make sure the sender does not transfer more tokens than he owns, the number of ```receivers``` is multiplied with the ```value``` of tokens to be transfered to each of them.

By passing a **large** number into `value`, this multiplication can lead to the described integer overflow, returning a **very small** number. Now to the security check in line `17`, it appears as if one was trying to transfer only very few tokens, e.g. an amount the transaction sender could actually afford.

After this check is bypassed, the `value` is added to every `receiver`'s balance.

**Et voilà - profit ! 💸**

## Why is this not a thing on Aeternity ?

The Fast Æternity Transaction Engine (FATE) VM is not only type-safe and disallows unsigned integers to wrap around below 0 (read: subtracting 1 from your token balance of 0 does not make you a gazillionaire).

It also has **no fixed upper bounds** for numbers: `2^256 - 1`is not the larges number possible, the only limits to arithmetics are transaction costs and eventually storage.

So in the case of our example, the hacker (and anyone else) is free to try sending `2^256 - 1` or more tokens to X people in one transaction, the token contract will not be fooled and will execute itself (only) if he owns the necessary amount.

No luck for hackers, less worries to keep an eye out for developers.