The contract’s method of blocking a user (via blockProfile
) is limited to burning the user’s NFT. It does not prevent the same address from re-minting another profile afterward.
Ineffective Blocking
blockProfile
only deletes the user’s current NFT. There is no “blocked” record in storage.
A blocked user can simply call mintProfile
again and create a fresh identity.
Lack of Persistent Tracking
There is no data structure (like a mapping) that permanently marks an address as blocked.
Burning an NFT leaves no persistent restriction on the address itself.
Circumvention of Owner’s Authority: The contract owner’s attempt to remove undesirable users is undercut, as the user can rejoin with the same address.
No Deterrence: Malicious or abusive participants can continue to re-mint profiles indefinitely, negating the concept of effective moderation.
Manual Review: Observed that blockProfile
and burnProfile
do not set any status that would prevent new mintProfile
calls.
Static Analysis: Automated tools can highlight the absence of a persistent block or ban list.
Implement a Ban Mapping
Introduce mapping(address => bool) blocked;
.
Upon blocking, set blocked[user] = true;
and require a require(!blocked[msg.sender], "Blocked")
check in mintProfile
.
Optional Unblock Functionality
If desired, add a way for the contract owner to revert a block by setting blocked[user] = false;
.
Emit events to maintain an auditable history of blocking and unblocking actions.
In the SoulboundProfileNFT.sol:
In the LikeRegistry.sol:
Likelihood: Low, any blocked users. Impact: High, not really blocked.
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.