DECA DEcentralized CArbon tokens - ITDE

The owner can mint an arbitrary amount of tokens for themselves by simply calling the payable function repeatedly (which sends the ETH right back to the owner). Since this is an uncapped token, users cannot know in advance what percentage of the total supply they will have at the end of the token sale.

The lines 112-116 contain testing code as opposed to production code. Specifically, time-dependent bonuses are given according to intervals determined by hours instead of weeks.

The ERC20 function `approve()` is supposed to set an allowance. In the current implementation it only emits an event and returns a boolean value. Furthermore, it cannot be called if there is any existing allowance, which does not conform to the ERC20 standard.

According to the comment in line 232, the owner is entitled to 2% of the tokens. In the implementation, however, (in lines 243 and 247: `safeDiv(tokens, percentage)`), the owner will actually get 50% of the tokens.

Integer overflow/underflow occur when an integer hits its bit-size limit. Every integer has a set range; when that range is passed, the value loops back around. A clock is a good analogy: at 11:59, the minute hand goes to 0, not 60, because 59 is the largest possible minute. Integer overflow and underflow may cause many unexpected kinds of behavior and was the core reason for the `batchOverflow` attack. Here's an example with `uint8` variables, meaning unsigned integers with a range of `0..255`. ``` function under_over_flow() public { uint8 num_players = 0; num_players = num_players - 1; // 0 - 1 now equals 255! if (num_players == 255) { emit LogUnderflow(); // underflow occurred } uint8 jackpot = 255; jackpot = jackpot + 1; // 255 + 1 now equals 0! if (jackpot == 0) { emit LogOverflow(); // overflow occurred } } ``` In the function `appendWeeks()`, if the argument `appendWeeks` is too large, the `endDate` computation on L160 may overflow and cause the sale to immediately end.

As it presently is constructed, the contract is vulnerable to the [allowance double-spend exploit](https://github.com/OpenZeppelin/openzeppelin-solidity/blob/b4f87bb8fc25fb07f73099701e39e167a3d36465/contracts/token/ERC20/ERC20.sol#L71-L78), as with other ERC20 tokens.

The clone-and-own approach involves copying and adjusting open source code at one's own discretion. From the development perspective, it is initially beneficial as it reduces the amount of effort. However, from the security perspective, it involves some risks as the code may not follow the best practices, may contain a security vulnerability, or may include intentionally or unintentionally modified upstream libraries. Specifically, we noticed code cloned from OpenZeppelin libraries.

As security standards develop, so does the Solidity language. In order to stay up to date with current practices, it's important to use a recent version of Solidity and recent conventions. For example, the attribute `constant` on functions is deprecated.

Every Solidity file specifies in the header a version number of the format `pragma solidity (^)0.4.*`. The caret (`^`) before the version number implies an unlocked pragma, meaning that the compiler will use the specified version _and above_, hence the term "unlocked".