While the rescue functionality is intended as a safeguard for emergencies, it inherently provides significant control over the contract’s funds. This design choice centralizes risk in the hands of the owner.
Location: rescue_tokens
function
Issue: No additional safeguards (such as multi-signature approval or time delays) are implemented for the owner’s ability to withdraw tokens.
Risk: A compromised or malicious owner could misuse this function to withdraw tokens prematurely or against the interests of the vesting schedule.
Loss of trust among users and potential misallocation of tokens.
Increased risk of funds being drained from the contract if owner credentials are exposed.
Code review
Manual static analysis
Consider implementing multi-signature controls or time-lock mechanisms to add an extra layer of security for emergency functions.
Clearly document the rescue function’s intended use and associated risks so that users are aware of the centralized control aspect.
The `owner` is trusted and the function `rescue_tokens` can be called only by the owner and only in case of emergency. This means the owner will not act maliciously and will not call the function without need. Also, issues realated to the malicious admin actions are invalid according to the CodeHawks documentation: https://support.cyfrin.io/en/articles/10059196-findings-validity
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.