Vyper Vested Claims
First Flight #34
Beginner FriendlyDeFi
100 EXP
View results
Previous Next
Submission Details
Severity: low
Invalid

No Time-Based Access Control on rescue_tokens Functions

edoscoba

Summary

The token vesting contract contains a critical centralization risk due to the absence of time-based access controls on privileged owner functions. Specifically, the rescue_tokens function can be called by the owner at any point in time, including during the active vesting period. This functionality enables the contract owner to withdraw tokens that are intended for distribution to users according to the vesting schedule, potentially undermining the entire purpose of the vesting contract.

Vulnerability Details

In the current implementation:

@external
def rescue_tokens(to: address, amount: uint256):
"""
@notice This function is used to rescue tokens from the contract
@param to address, the address to send the tokens to
@param amount uint256, the amount of tokens to send
@dev this is a "better safe then sorry" function, use it only in case of emergency
@dev This function can only be called by the owner
"""
self.onlyOwner()
log TokensRescued(to, amount)
_success: bool = extcall IERC20(self.token).transfer(to, amount)
assert _success, "Transfer failed"

While the function includes a comment indicating it should only be used in emergencies, there are no programmatic safeguards preventing its use under normal circumstances. The function is only protected by the onlyOwner modifier but lacks any time-based restrictions that would prevent the owner from accessing funds during the vesting period.

Impact

This vulnerability creates several significant risks:

  1. Trust Violation: Users who expect their tokens to vest according to the predefined schedule have no on-chain guarantee that the owner won't withdraw these tokens prematurely.

  2. Undermining of Vesting Purpose: The entire purpose of a vesting contract is to provide assurance that tokens will be distributed according to a specific schedule. This vulnerability fundamentally compromises that assurance.

  3. Centralization Risk: The contract becomes highly dependent on the trustworthiness of the owner, contradicting the principles of decentralization and trustlessness.

  4. Potential Loss of Funds: In the worst-case scenario, users could lose all their vested and unvested tokens if the owner decides to withdraw all funds from the contract.

Tools Used

Manual Review

Recommendations

Implement time-based restrictions on the rescue_tokens function to ensure it can only be used in legitimate emergency situations:

@external
def rescue_tokens(to: address, amount: uint256):
"""
@notice This function is used to rescue tokens from the contract
@param to address, the address to send the tokens to
@param amount uint256, the amount of tokens to send
@dev Can only be called after the vesting period has ended
@dev This function can only be called by the owner
"""
self.onlyOwner()
# Ensure the vesting period has ended
assert block.timestamp > self.vesting_end_time, "Cannot rescue tokens during vesting period"
# Additional safeguard: Ensure all claimed amounts are respected
# This would require tracking total allocated tokens separately
# assert amount <= available_unallocated_tokens, "Cannot rescue allocated tokens"
log TokensRescued(to, amount)
_success: bool = extcall IERC20(self.token).transfer(to, amount)
assert _success, "Transfer failed"
Updates

Appeal created

bube Lead Judge 6 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity
Assigned finding tags:

[Invalid] Owner can call rescue_tokens and withdraw users tokens

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

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.