An interchain token's `flowLimit` set in `TokenManager` can be used to DoS interchain transfers and potentially prevent an express executor from being reimbursed their tokens
Audit: 2024-08-axelar-network-findings
Severity: MEDIUM

# Lines of code

https://github.com/code-423n4/2024-08-axelar-network/blob/main/interchain-token-service/contracts/token-manager/TokenManager.sol#L117
https://github.com/code-423n4/2024-08-axelar-network/blob/main/interchain-token-service/contracts/utils/FlowLimit.sol#L18


# Vulnerability details

**Impact**
Interchain tokens in the protocol have a `flowLimit` minimising the amount of tokens that can be added/removed from a particular chain over a set period of time (referred to as an `EPOCH`, each of which is 6 hours long). This is however exploitable as a user with enough tokens could transfer the maximum repeatedly causing interchain transfers to a particular chain to be DoSed.

This behaviour is damaging regardless, however one way it could be particularly harmful to users is when considering a user triggering an `expressExecute` of an interchain transfer. When performing an `expressExecute` the caller on the destination chain will first transfer their own tokens (ones already on the chain) to the recipient with the expectation that they will be reimbursed shortly afterwards once the transaction has been finalised on the source chain. However in the DoS scenario outlined above this denial of service would delay the express executor getting their tokens reimbursed. This is particularly problematic when considering the differences in block finality wait periods across chain as shown in the Axelar docs [here](https://github.com/axelarnetwork/axelar-docs/blob/main/src/pages/learn/txduration.mdx), as attackers can use chains with fast block finality to DoS interchain transfers from chains with slower block finality.

**Proof Of Concept**
Consider the following steps:
1. User A triggers an interchain token transfer moving tokens from Chain A to Chain B (where Chain A is a chain with slower block finality).
2. User B (potentially a protocol willing to put up the tokens) triggers the `InterchainTokenService::expressExecute` transferring the tokens to the recipient on the destination chain.
3. Malicious User C forces the token to hit the `flowLimit` by transferring in via a blockchain with a faster block finality wait period meaning the interchain transfer can be validated and executed faster than User A's original transaction.
4. Now when later calling `InterchainTokenService::execute` to reimburse User B, it will revert as the tokens flow limit has been hit for this epoch.
5. User B has to wait until `EPOCH` (6 hours) passes (after which User C could attempt to do it again), or the token manager raises the flow limit for the token in question.

**Recommended Mitigation**
It is difficult to suggest a mitigation that does not require removing the `flowLimit` entirely however one option to stop this particular attack scenario would be to ignore the `flowLimit` when reimbursing a user that has performed and express execution. However there is potential that this could then be abused by users wishing to bypass the `flowLimit`, so the team would have to