Fee Calculators
TrustedSignerFeeCalculator.sol
[MEDIUM] Insufficient Message Hash Entropy
Depending on the duration of the signature generated, a malicious user could pre-generate a range of signatures against any pool, and then use them to bot against a pool that has just launched. This could be accomplished by manually generating n signatures and then storing them into a bot to make requests against when a new token launches. This would render the calculator logic nullified.
Recommended solution:
To remediate this, we would recomment adding the PoolId or token address to the signature that is generated and passed to the user.
// Create the message hash from the `origin`
bytes32 messageHash = keccak256(abi.encodePacked(origin, poolId, signedMessage.deadline));
[INFO] Optimisation of determine origin
The current function to determine the origin of the sender could be optimised to additionally check if the caller is themselves an EOA, or a contract address. If the caller is an EOA, then return the msg.sender; however, if the caller is a contract without the msgSender() function, then return the tx.origin as currently doing.
function _determineOrigin(address _sender) internal returns (address origin_) {
// Set our default origin to the `tx.origin`
origin_ = tx.origin;
// If the sender has a `msgSender` function, then we use that to determine the origin
(bool success, bytes memory data) = _sender.call(abi.encodeWithSignature('msgSender()'));
if (success && data.length >= 32) {
origin_ = abi.decode(data, (address));
}
}
[INFO] Low wallet cap or transaction cap would prevent swaps
If a user flaunched a token with a wallet cap or transaction cap of a low, non-zero value, then it would effectively prevent any swaps from taking place during fair launch.
For example, if a transaction cap of 1 was set, then no swaps could effectively be made.
This is at the users discretion, but it could be beneficial to either enforce a minimum at a protocol level in the setFlaunchParams function, or display a warning in the application.