Open code423n4 opened 3 years ago
sponsor disputed disagree with severity 0 These locks are meant to be operated by 3rd party contract and the locks are only as meaningful as this 3rd party contract context allows them to be. The unit test is well put together but exhibits expected behavior
In context with 3rd contract this is a non-critical issue but I’ll keep low severity because this is extremely confusing and not well documented
Handle
Sherlock
Vulnerability details
Impact
Two different addresses (Alice and Bob) could get credit for locking up the same funds because a user is able to lock without depositing
Proof of Concept
https://github.com/Evert0x/2021-05 visorfinance/blob/main/contracts/test/Test.ts#L124
Tools Used
Hardhat
Recommended Mitigation Steps
Implement additional checks to force users to have deposited before they are able to lock tokens