PerlinXerc20emission

There is no check on the input value given to `changeEraDuration`, which allows setting the era duration to zero. ** 2020-08-18 update **: Perlin team states that the design permits 0x0 as a valid input parameter.

The `changeIncentiveAddress` function does not check if `newIncentiveAddress` is different from `0x0`. ** 2020-08-18 update **: Perlin team states that the design permits 0x0 as a valid input parameter.

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. An example of an exploit goes as follows: 1. Alice allows Bob to transfer `N` amount of Alice's tokens (`N>0`) by calling the `approve()` method on `Token` smart contract (passing Bob's address and `N` as method arguments) 2. After some time, Alice decides to change from `N` to `M` (`M>0`) the number of Alice's tokens Bob is allowed to transfer, so she calls the `approve()` method again, this time passing Bob's address and `M` as method arguments 3. Bob notices Alice's second transaction before it was mined and quickly sends another transaction that calls the `transferFrom()` method to transfer `N` Alice's tokens somewhere 4. If Bob's transaction will be executed before Alice's transaction, then Bob will successfully transfer `N` Alice's tokens and will gain an ability to transfer another `M` tokens 5. Before Alice notices any irregularities, Bob calls `transferFrom()` method again, this time to transfer `M` Alice's tokens. The exploit (as described above) is mitigated through use of functions that increase/decrease the allowance relative to its current value, such as `increaseAllowance` and `decreaseAllowance`. Pending community agreement on an ERC standard that would protect against this exploit, we recommend that developers of applications dependent on `approve()` / `transferFrom()` should keep in mind that they have to set allowance to 0 first and verify if it was used before setting the new value. Teams who decide to wait for such a standard should make these recommendations to app developers who work with their token contract.

The `SafeMath` library is cloned in the file. A subset of the ERC20 has been cloned, with some modifications. 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.

The constructor does not check if `_perlin1` is different from `0x0`, nor if it refers to a contract. If the given address is `0x0` or refers to an externally owned account (EOA), the `Perlin2 ` contract will not work as expected. ** 2020-08-19 update **: Perlin team states that it is for testing only and will be removed before the deployment of the contract.

Smart contracts will often have `owner` variables to designate the person with special privileges to make modifications to the smart contract. However, this centralization of power needs to be made clear to the users, especially depending on the level of privilege the contract allows to the owner. Specifically, `Perlinx2` gives the `DAO` address a privileged role, as only the `DAO` address can call functions marked as `onlyDAO ` (e.g., `changeEmissionCurve`, `changeEraDuration `, etc). ** 2020-08-18 update **: Perlin team has added related explanation to the README file.