A single address can occupy both slots as a soulmate and mint a SoulmateToken
for itself and also obtain LoveToken
regularly.
The current functionality allows the same address be its own soulmate (which in general is lovely) but for the purpose of this contract I consider that to be a vulnerability as the individual can mint a token for its own and then claim Love Tokens, stake them etc.
Should be limited as the address cannot enter any other soulmate-relationship, but can claim tokens that are limited
static analysis, forge testing (viz GitHub link)
Adda require statement / if statement with a custom error, that prohibits both members of the same Soulmate to be the same address.
if (idToOwners[nextID][0] == msg.sender) { revert Soulmate__CannotBondTogetherAnymore()}
- Given the native anonymous nature of blockchain in general, this issue cannot be avoided unless an explicit whitelist is implemented. Even then we can only confirm soulmates are distinct individuals via kyc. I believe finding a soulmate is intended to be permisionless. - However, even though sufficient (500_000_000e18 in each vault) tokens are minted to claim staking and airdrop rewards, it would take 500_000_000 / 2 combined weeks for airdrop vault to be drained which is not unreasonable given there are [80+ million existing wallets](https://coinweb.com/trends/how-many-crypto-wallets-are-there/). Given there is no option to mint new love tokens, this would actually ruin the functionality of the protocol of finding soulmates and shift the focus to abusing a sybil attack to farming airdrops instead. Assigning medium severity for now but am open for appeals otherwise, since most if not all issues lack indepth analysis of the issue.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.