In the Manager, while the loops themselves are not capped, we are in control of how many items we include to be looped over. This gives us the same control.
In the Staking contract, the loop in question is in a view function so should not have an effect on gas paid by users. We also have a very low number of schedules planned which will keep the loop in check. Should this change in the future, we can re-visit.
Different Solidity Versions
Individual contracts have been set to a single version. Multiple versions overall are still required due to targeted integrations.
ERC20 Allowance Double Spend Exploit
This is an exploit inherent to the ERC20 spec and all tokens are subject to it. Integrations have used the safe() methods as suggested.
Unsafe Cycle Durations
Cycle durations are undergoing an overall change that will capture this item.
Using Minimum Output Checks for Liquidity AMM Add/Removal
Where the exchange doesn’t automatically revert when the minimum output is not met, checks will be added to ensure the expected output it met.
Controllers Able to be Called by Anyone / Funds in Controllers
While this didn’t have a direct impact on Tokemak's usage of the contracts, should anyone fork them in the future they could have unknowingly opened themselves up to an exploit. We are adding a check to ensure only the Manager is able to use the controllers.
Schedule.setup Check in the Staking Contract Always Passes
This is expected behavior to ensure we don’t send in a invalid schedule id given that valid values for all other schedule properties include their defaults.