RustFund
First Flight #36
Beginner FriendlyRust
100 EXP
View results
Previous Next
Submission Details
Severity: low
Invalid

Usage of `unwrap()` in Time Retrieval Risks Panics

druzh

Summary

The contract uses Clock::get().unwrap() and try_into().unwrap() calls directly, which can panic if the clock data is inaccessible or invalid. This triggers a chain halt (panic) instead of a graceful error.

Vulnerability Details

Snippets like:

let now_ts = Clock::get().unwrap().unix_timestamp.try_into().unwrap();

  • If Clock::get() fails (or try_into() fails on negative or out-of-range timestamps), the entire transaction panics rather than returning an error code.

Impact

  • Denial of Service: Attackers might cause ephemeral environment conditions that break Clock usage, halting the program’s function for all users.

  • Loss of Control Flow: Safe pattern in Rust is to return a Result instead of an unrecoverable panic.

Tools Used

  • Manual call analysis .unwrap() in time acquisition chains.

  • Comparison with recommendations for safe error handling in on-chain Rust code.

Recommendations

  • Replace all unwrap() calls with error handling using the operator ? or explicitly matching with Result to correctly return an error instead of panicking.

  • Define your own ErrorCode for situations when Clock is unavailable or conversion is not working.

Updates

Appeal created

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

[Invalid] Incorrect error handling for timestamp

It is very unlikely `Clock::get` to fail, therefore I think it is safe to use `unwrap` here. Consider this issue as informational.

Support

FAQs

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