V2.2 Crosschain, Part 7

In the bridgeOutFromController function for tokens and secondaryTokens the _bridgeOutParams.amount is assigned as only the params.amount in the first case, ignoring the secondaryAmount entirely.

This misses the secondary token amount that should be bridged out in the event that both output tokens are the same token.

Assign the _bridgeOutParams.amount as params.amount + params.secondaryAmount in the first case.

GMX Team: Resolved.

Depending on the token decimals and corresponding edge oracle decimals there may be some tokens which cannot be used with the edge oracle due to the token decimals multiplier calculations.

For example:

• Token has 18 decimals
• Expo is -14
• floatMultiplier = 30 - 18 - 14 = -2

A resulting negative multiplier reverts with the InvalidEdgeDataStreamExpo error.

Consider if tokens which have a net negative float multiplier due to high decimals or a high exponent should be supported by using a division of 10^(-floatMultiplier). Otherwise be aware of this incompatibility for exotic tokens.

GMX Team: Acknowledged.

With the addition of the minimum output amount configuration for the user, the maximum datalist length should be increased as necessary to be able to include a minimum amount out value for both the primary output token and secondary output token if there is one for the action.

Be sure that the largest required data list length can be supported by the validation.

GMX Team: Acknowledged.

In the transferClaim function there is no validation preventing the from and to addresses from being the same account. This may lead to unexpected issues and should be explicitly prevented to avoid mistakes.

Consider adding validation to ensure that the from and to addresses of each TransferClaimParam are unique.

GMX Team: Resolved.

In the emitClaimFundsClaimed invocation in the claimFunds function the receiver is emitted as the account, however the msg.sender is the account that claimed funds.

This may be misleading to consumers of the emitClaimFundsClaimed emission.

Consider using the msg.sender as the account field for the emitClaimFundsClaimed invocation.

GMX Team: Resolved.

The setTerms function should be called for a given distributionId that requires terms before the depositFunds function is used for that distributionId.

This is because it is possible for an actor to withdraw their distribution immediately after the depositFunds function is used, without signing any terms if they are not configured at that point.

Be sure to call the setTerms function before the depositFunds function for any distributions which require terms.

GMX Team: Acknowledged.

The validateTermsSignature validation does not include any deadline for when the signature made by the user should become invalid, or Nonce which makes signature uses unique.

This may be unexpected especially if a user makes an initial claim for a distributionId before their allocation for that distributionId is increased and they are able to claim again.

Consider adding mechanisms that more strictly define the use of a user’s signature such as a nonce and deadline.

GMX Team: Acknowledged.

There is no domain separator included in the validateTermsSignature signature validation. This means a signature of terms could be potentially used across multiple contracts or even on other chains if a ClaimHandler were to be deployed on multiple networks.

Consider adding a domain separator to make signatures specific to the context in which they are meant to be used.

GMX Team: Resolved.

In the prepareSend function the sendParam.minAmountLD is re-assigned to receipt.amountReceivedLD.

Therefore if for any reason the amount received by the user on the stargate.send invocation would be less than the receipt.amountReceivedLD but more than the sendParam.minAmountLD then the send would fail even though the minimum amount specified by the user could have been met.

This case should not be possible since the quoteOFT call should always return the exact result of the send.

However consider if the minAmountLD should be left as the user’s specified sendParam.minAmountLD so that this case cannot arise with any underlying stargate pool or OFT implementation.

GMX Team: Acknowledged.