Decreasing maxGauges does not account for users' previous gauge list size.
`ERC20Gauges` contract has a `maxGauges` state variable meant to represent the maximum amount of gauges a user can allocate to. As per the natspec, it is meant to protect against gas DOS attacks upon token transfer to allow complicated transactions to fit in a block. There is also a function `setMaxGauges` for authorised users to decrease or increase this state variable.\\n```\\nfunction setMaxGauges(uint256 newMax) external requiresAuth {\\n    uint256 oldMax = maxGauges;\\n    maxGauges = newMax;\\n\\n    emit MaxGaugesUpdate(oldMax, newMax);\\n}\\n```\\n\\nHowever, if it is decreased and there are users that have already reached the previous maximum that was larger, there may be unexpected behavior. All of these users' gauges will remain active and manageable, such as have user gauge weights incremented or decremented. So it could be possible that for such a user address `user_address`, numUserGauges(user_address) > `maxGauges`. While in the current contract logic this does not cause issues, `maxGauges` is a public variable that may be used by other systems. If unaccounted for, this discrepancy between the contract's `maxGauges` and the users' actual number of gauges given by `numUserGauges()` could, for example, cause gauges to be skipped or fail loops bounded by `maxGauges` in other systems' logic that try and go through all user gauges.
Either document the potential discrepancy between the user gauges size and the `maxGauges` state variable, or limit `maxGauges` to be only called within the contract thereby forcing other contracts to retrieve user gauge list size through `numUserGauges()`.
```\\nfunction setMaxGauges(uint256 newMax) external requiresAuth {\\n    uint256 oldMax = maxGauges;\\n    maxGauges = newMax;\\n\\n    emit MaxGaugesUpdate(oldMax, newMax);\\n}\\n```\\n