The token deposit and withdrawal system involves transferring tokens between Layer 1 (L1) and Layer 2 (L2) using message-passing mechanisms. A critical issue has been identified with the startRequestCancellation
function, which is restricted to the contract owner only. This restriction poses a risk of token loss for users if an invalid ownerL2
address is passed in the deposit function and if the owner fails to address cancellation requests.
Invalid ownerL2
Address:
The depositTokens
function on Layer 1 (L1) accepts an ownerL2
parameter that can be an invalid address (e.g., 0 snaddress
).
An invalid ownerL2
address may cause failures or unexpected behavior in the withdrawal process on L2.
Cancellation Mechanism:
The startRequestCancellation
function is designed to reclaim tokens in case of issues but is restricted to the contract owner.
This restriction centralizes control and prevents users from reclaiming tokens if the contract owner is unresponsive.
Token Loss: Users may lose tokens if the ownerL2
address is invalid, leading to failures in the L2 withdrawal function. The restricted access to the startRequestCancellation
function means users cannot reclaim their tokens if the owner does not act promptly.
Centralization Risk: Restricting request cancellation to the contract owner centralizes control, making the system vulnerable to failures or delays due to the owner's actions or inactions.
Manual Code Review
Remove the onlyOwner
restriction to allow users involved in the transaction to initiate cancellations if needed.
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.