The deposit_tokens function in the bridge.cairo contract lacks a crucial validation check for the existence of a valid L1 address mapping when processing L2 to L1 token transfers. This oversight can lead to transactions with invalid L1 collection addresses, potentially causing tokens to become locked on the Starknet L2 network.
The deposit_tokens function bridge.cairo processes L2 to L1 transactions using the provided L2 collection address. However, it does not verify whether a valid L1 address mapping exists:
The function retrieves the L1 address mapped to the provided L2 address using the l2_to_l1_addresses mapping and proceeds directly to add it to the request struct for processing on L1.
If this mapping does not exist or the user calls deposit_tokens prior to setting up of l2_to_l1_addresses mapping by the owner, the collection_l1 address will default to a zero address (0x0) or an invalid address.
In the absence of validation, the invalid collection_l1 address may lead to failed transactions on the Ethereum side, causing tokens to remain locked on L2, as they cannot be correctly bridged to L1.
Locked tokens on Starknet L2.
VSCode
Introduce a validation check in the deposit_tokens() function to ensure that a valid mapping exists for the provided collection_l2 address before proceeding with any operations.
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.