ArkProject: NFT Bridge
ArkProject
NFTBridge
60,000 USDC
View results
Previous Next
Submission Details
Severity: low
Invalid

Cancelling of L1 to L2 bridging is not done in the most efficient way and would be broken in some instances

bauchibred

Summary

The cancellation process for L1 to L2 bridging requests is inefficient and potentially problematic as it requires admin intervention rather than allowing users to initiate the cancellation themselves. This design could lead to missed cancellation opportunities due to time constraints and administrative delays.

Vulnerability Details

Cancelling of L1 to L2 bridging is not done in the most efficient way since it requires the admin to call these functions instead of the users themselves.

Per the Starknet's docs, there is an official duration as to how long it should take before the decision of cancelling can no longer be reachable. This means that if a user decides to cancel within the valid duration, they are not assured they'd make it and cancel on time because there is a needed process of getting a hold of the admin first, and then the admin would need to externally verify all, which could end up making the users not cancel on time since the time might pass before admin verifies or before they even get a hold of the admin.

The duration for L1->L2 takes 10 confirmation blocks and the sequencer picks up the request and executes on L2, which makes it not realistically possible for a user to get in touch with the admin within this time frame and cancel their bridging.

Note that we can't claim this to be a user error since the cancellation functionality exists, but currently it doesn't work as expected.

The cancellation is restricted to admin-only calls, as seen in the following code snippets:

function startRequestCancellation(
uint256[] memory payload,
uint256 nonce
) external onlyOwner {
IStarknetMessaging(_starknetCoreAddress).startL1ToL2MessageCancellation(
snaddress.unwrap(_starklaneL2Address),
felt252.unwrap(_starklaneL2Selector),
payload,
nonce
);
Request memory req = Protocol.requestDeserialize(payload, 0);
emit CancelRequestStarted(req.hash, block.timestamp);
}
​
function cancelRequest(
uint256[] memory payload,
uint256 nonce
) external {
IStarknetMessaging(_starknetCoreAddress).cancelL1ToL2Message(
snaddress.unwrap(_starklaneL2Address),
felt252.unwrap(_starklaneL2Selector),
payload,
nonce
);
Request memory req = Protocol.requestDeserialize(payload, 0);
_cancelRequest(req);
emit CancelRequestCompleted(req.hash, block.timestamp);
}

Impact

The current design could lead to:

  1. Missed cancellation opportunities due to administrative delays.

  2. Potential loss of funds or assets if users are unable to cancel their bridging requests in time.

  3. Reduced user control over their own transactions.

  4. Increased burden on the admin team to handle cancellation requests promptly.

Tools Used

Manual review

Recommendations

Implement a two-step cancellation process:
a. Users can initiate the cancellation request.
b. Admin can finalize the cancellation after external verification.

Updates

Lead Judging Commences

n0kto Lead Judge 9 months ago
Submission Judgement Published
Invalidated
Reason: Incorrect statement
Assigned finding tags:

Informational / Gas

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.

Appeal created

bauchibred Submitter
9 months ago
n0kto Lead Judge 8 months ago
Submission Judgement Published
Invalidated
Reason: Incorrect statement
Assigned finding tags:

Informational / Gas

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.

Support

FAQs

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