Tensorplex Labs

If `lastBatchNonce` is accidentally or maliciously set to the max `uint256` value, `submitBatch()` cannot be called anymore for the respective `_tokenWrapperAddress`. Such a sanity check is performed in `updateValset()` for the `valsetNonce`, but is missing for `lastBatchNonce`.

`RaterLimiter.refill()` contains the condition `if (timeElapsed > 60 seconds)` to ensure that tokens will be refilled to the RateLimit only if at least one period worth of time has passed. However, if `60 seconds` have passed, there will be no refilling that takes place, as the `timeElapsed` has to be strictly greater than `60 seconds`.

A revert condition in `submitBatch()` is concatenated with `&&` instead of `||`. As a result, there are edge cases where the function will not revert or revert without the correct error message. Two examples: 1. `_amounts.length > _destinations.length` but `_destinations.length == _transactionIds.length`: The function will not revert at all and the elements in the `_amounts` array after `_destinations.length - 1` index will not be considered. 2. `_amounts.length < _destinations.length` but `_destinations.length == _transactionIds.length`: The function will revert at a later point because of an array out of bounds error, but not at the intended sanity checkpoint.

When an unsupported chain ID is provided when calling `sendToChain()`, the burnt tokens will be lost. While a UI can protect from such a mistake, some users prefer to directly interact with smart contracts.

It is crucial to validate inputs, even if the inputs come from trusted addresses, to avoid human error. A lack of robust input validation can only increase the likelihood and impact in the event of mistakes. Following is the list of places that can potentially benefit from stricter input validation: <br> - `BridgeWrapper.constructor()`: - qs-badge-acknowledged Validate that `maxBurnCapacity`, `burnRefillRate`, `maxMintCapacity`, and `mintRefillRate` are within some reasonable bound defined in the contract. - qs-badge-fixed Validate that `_maximumAmount` is larger or equal to `_minimumAmount` and `_baseFee`. - qs-badge-mitigated Validate that when assigning `baseFee`, `serviceFee`, `minimumAmount`, and `maximumAmount` in the ensure that they are within some appropriate bounds defined for this contract. - qs-badge-fixed Validate that `_minimumAmount` is greater than zero. - `BridgeWrapper.setMinimumAmount()` - qs-badge-fixed Validate that `_minimumAmount` is less or equal to `maximumAmount`. - qs-badge-fixed Validate that `_minimumAmount` is larger or equal to `baseFee`. - qs-badge-fixed Validate that `_minimumAmount` is greater than zero. - `BridgeWrapper.setMaximumAmount()` - qs-badge-fixed Validate that `_maximumAmount` is larger or equal to `minimumAmount`. - `BridgeWrapper.sendToChain()` - qs-badge-fixed Validate that `_dstChainId` is a known chain ID. This can prevent users from sending tokens to an unsupported chain and, therefore, possibly losing their funds. - qs-badge-acknowledged `_dstTokenAddress` can also be validated if the supported tokens are known. - `BridgeWrapper.receiveFromChain()` - qs-badge-fixed Validate that `_srcChainId` is a known chain ID.

The `submitBatch()` function of `ConsensusBridge` takes a parameter, `_sourceChainId`, the ID of the source chain from which tokens are bridged. According to the code comments, the Tensorplex relayers use this value for record keeping. Note that `_sourceChainId` is not included in the signed data. Therefore, anyone may front-run a `submitBatch()` transaction and modify the `_sourceChainId` to an arbitrary value, while the signature validation would still succeed. This may cause inconsistent record-keeping results, especially if multiple source chains are used.