- High: 2
- Medium: 0
- Low: 0
The claimReward function within the Staking module has a vulnerability. If a user claims a reward for the first time, the lastClaim mapping value is set to the timestamp of the soulmate matching. However, if the user has not staked any tokens before claiming rewards, there is a possibility to claim a disproportionate amount of reward.
If the idToCreationTimestamp mapping value for a couple is denoted as x, and after y days, where y is an extremely large value, the user can stake love tokens and immediately claim the reward. The lastClaim value is configured to the idToCreationTimestamp mapping value. Consequently, the amountToClaim will be extremely large, even though the user did not stake tokens for the expected duration.
This vulnerability allows users to claim a disproportionate amount of tokens, potentially exploiting the system.
Manual Review
To mitigate this risk, consider implementing a mechanism to lock the tokens during the reward period. This would prevent users from exploiting the system by claiming rewards without staking tokens for the appropriate duration.
The claimAirdrop function lacks validation to determine whether the user is reunited or not. If a user who is not reunited attempts to claim the reward, the idToCreationTimestamp mapping value remains the default, resulting in a calculation error. This miscalculation could lead to a significant value for numberOfDaysInCouple, potentially exceeding the balance of the vault contract and causing the withdrawal of all funds.
If a user is not reunited, either because they minted a soulmate NFT but did not find a match or did not mint an NFT at all, attempting to claim the reward in the Airdrop leads to an issue. The idToCreationTimestamp mapping value is not updated, remaining at the default zero value. The calculation of numberOfDaysInCouple becomes the pure result of block.timestamp / daysInSecond, representing the days since the initial block creation. Consequently, the tokenAmountToDistribute becomes excessively large, potentially causing the user to drain all funds in the Airdrop vault contract.
A test scenario exemplifies this potential issue:
function test_AllFundsDrained() public {
vm.warp(10_000 days + 1 seconds);
vm.prank(soulmate1);
airdropContract.claim();
assertEq(loveToken.balanceOf(soulmate1), 10_000 ether);
}
In this case, soulmate1, who did not mint any tokens, still receives 10,000 love tokens as a reward, deviating from the intended specification.
Manual Review
To address this vulnerability, it is recommended to add validation checks to determine whether the user is reunited or not. Additionally, consider validating whether idToCreationTimestamp is at its default value before proceeding with the reward claim.
M-01. ILoveToken does not follow ERC-20 Specification, leading to failure of operation when interacting with the protocol
While LoveToken adheres to the ERC-20 token standard, its interface, ILoveToken, is inconsistent with the ERC-20 token interface. This discrepancy may lead to user confusion during interactions with the protocol.
The LoveToken contract utilizes the solmate template for ERC-20 tokens. In a standard ERC-20 token, the transfer, transferFrom, and approve functions are expected to return a boolean to indicate the success of the operation.
function transfer(address _to, uint256 _value) public returns (bool success)
function transferFrom(address _from, address _to, uint256 _value) public returns (bool success)
function approve(address _spender, uint256 _value) public returns (bool success)
However, in ILoveToken, the interface for LoveToken, there is a slight difference:
function transfer(address to, uint256 amount) external;
function transferFrom(address from, address to, uint256 amount) external;
function approve(address to, uint256 amount) external;It does not include a return boolean value. Interacting with these functions using a contract compiled with Solidity > 0.4.22 will result in execution failure due to the missing return value.
If the protocol is deployed and users claim Love Tokens, attempting to interact with the contract using ILoveToken as a reference may prove unsuccessful.
Slither
To solve this issue, update the ILoveToken interface to align with the ERC-20 token standard by adding return values to the transfer, transferFrom, and approve functions.