# ElasticReceiptToken audit: preliminary findings

**a. Possible vulnerabilities:**

1. Insufficient checks in `validAmount` modifier - it only checks if the amount is zero but does not check if the amount exceeds the account balance or total supply. This can lead to issues such as negative balances or supply overflow if not handled properly in the derived contract.
2. Rounding Errors: The contract mentions that non-zero rounding errors can occur in conversion functions. However, it does not provide any specific mechanisms to handle or mitigate these rounding errors. Depending on the usage and implementation of the derived contract, these rounding errors could lead to inaccuracies in token balances or supply calculations.
3. Lack of Access Control: The contract does not include any access control mechanisms for critical functions. This means that any address that meets the validation requirements can execute functions such as minting, burning, or adjusting allowances, which may pose security risks if not properly controlled.
4. In the `setInterestRate()` function, there are no input validations for the rate parameter. This means that any value can be passed as the interest rate without any restrictions or checks. It is important to validate that the interest rate is within a reasonable range and complies with the intended behavior of the contract.

**b. Informal:**

1. move `DOMAIN_SEPARATOR()` into variable `bytes32 public DOMAIN_SEPARATOR`.
1. `bytes32 public immutable EIP712_DOMAIN`; immutable variables should be mixedCase, not upper case.
1. variables `name`, `symbol` and `decimals` should be immutable.
1. `MAX_UINT` wastes storage space.
1. It would make more sense to `emit Rebase` event directly in `_rebase()` instead of in `_burn` or `_mint`. If any, those functions should emit corresponding burn/emit events
1. _`supplyTarget()` function should be implemented in the derived contract. The absence of this implementation makes it impossible to determine the intended behavior and potential vulnerabilities associated with the supply adjustment mechanism.
2. There is a lack of unit/integration tests for the inverter project scope.

**c. Discussion points:**

1. `_mint()` doesen't call _`rebase()`, while `_burn()` does. Is this expected behavior, shouldn't `mint()` update supply as well?
2. Does separate `rebase()` function make sense? Are there any instances when this method needs to be called manually ?
3. ***l. 278*** why set allowance to 1 if `tokens == 0`, and does it make sense to transfer 0 tokens?
4. ***l. 420*** Does `_activeBits()` always return the same value ?
5. ***l.570*** Does `_transfer()` take tokens argument only for event emission?