This audit report addresses a critical issue identified in the Starklane::cancelRequest
function of the Starklane contract. The function is designed to handle the cancellation of L1 → L2 messages as part of a cross-chain operation between Ethereum and Starknet. According to the Starknet documentation, the cancellation process requires a two-step procedure with a mandatory 5-day waiting period between initiating and completing the cancellation. However, the current implementation does not enforce a check for this 5-day wait which can mislead users to call the Starklane::cancelRequest
earlier than usual.
The vulnerability arises from the missing 5-day waiting period check in the Starklane::cancelRequest
function. According to Starknet's official documentation:
Step 1: The startL1ToL2MessageCancellation
function initiates the cancellation process.
Step 2: After a mandatory 5-day waiting period, the cancelL1ToL2Message
function completes the cancellation.
However, the current implementation of the Starklane::cancelRequest
function does not enforce this waiting period, allowing users to call this function which will revert due to the wait period.
Starklane::cancelRequest
will always revert when called before the end of the 5-day waiting period
Manual Review
Add the 5-day waiting period check in the Starklane::cancelRequest
function.
Please, do not suppose impacts, think about the real impact of the bug and check the CodeHawks documentation to confirm: https://docs.codehawks.com/hawks-auditors/how-to-determine-a-finding-validity A PoC always helps to understand the real impact possible.
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.