XEN Crypto security record

We noticed the following mismatches between the code and the published documentation of XEN crypto. 1. Regarding reward amplifier calculation, the [tokenomics page](https://www.xencrypto.io/what-is-xen-tokenomics/) indicates that "... the reward amplifier (AMP) is a constant amplifying rewards by 3,000 and decreasing by 30 every 30 days until it reaches the plateau of 1."; while the code does not decrease the value at a 30-day interval. In fact, since the `REWARD_AMPLIFIER_STEP` happens to be 30, the reward amplifier should decrease by 1 every day. To bump decrease 30 (approximately) every month, the calculation would need to divide by `SECONDS_IN_MONTH` before multiplying by `REWARD_AMPLIFIER_STEP`. ```solidity = 159 function _calculateRewardAmplifier() private view returns (uint256) { uint256 amplifierDecrease = (REWARD_AMPLIFIER_STEP * (block.timestamp - genesisTs)) / SECONDS_IN_MONTH; if (amplifierDecrease < REWARD_AMPLIFIER_START) { return Math.max(REWARD_AMPLIFIER_START - amplifierDecrease, REWARD_AMPLIFIER_END); } else { return REWARD_AMPLIFIER_END; } } ``` 2. Minor issue with penalty percentage. On the [tokenomics page](https://www.xencrypto.io/what-is-xen-tokenomics/), "Penalties" section, the penalty percentage for 2 days and 5 days seem to be off by 1%. Penalty for minting 2 days late should be 3%, and for 5 days it should be 35%

The code takes penalty when the user is late for the designated minting time. The bit-wise shift on line 110 would fail if the late days exceeds 252. As a result, any user that's late for more than 252 days won't be able to remove their records in `userMints` or update the `activeMinters` count. ```solidity=107 function _penalty(uint256 secsLate) private pure returns (uint256) { // =MIN(2^(daysLate+3)/window-1,100) uint256 daysLate = secsLate / SECONDS_IN_DAY; uint256 penalty = (uint256(1) << (daysLate + 3)) / WITHDRAWAL_WINDOW_DAYS - 1; return Math.min(penalty, 100); } ```

We'd like to know more about the purpose of contract `Migrations` to better understand the significance of the owner-controlled `setCompleted()` function.

Variable `genesisTs` assigned in the constructor can be declared as `immutable`. Immutable state variables can be assigned during contract creation but will remain constant throughout the lifetime of a deployed contract. A big advantage of immutable variables is that reading them is significantly cheaper than reading from regular state variables since they will not be stored in storage.