When a new NFT collection is bridged from L1 to L2, the L2 contract updates its mapping, but the L1 contract does not. This asymmetry prevents users from bridging their NFTs back to L1, as the verification process fails due to mismatched mappings.
In bridge.cairo
, when a new collection is deployed, the mappings are updated:
However, there's no corresponding update on the L1 side.
Then, when attempting to bridge back, the _verifyRequestAddresses
function in CollectionManager.sol
will fail:
Users cannot bridge back NFTs from newly deployed collections on L2 to L1, because they are locked on the L2 side, leading to loss of assets or inability to use them on the original chain.
Manual review
Implement a mechanism to update the L1 contract's mappings when a new collection is deployed on L2:
This could be done through a message from L2 to L1 after successful deployment.
Likelyhood: High, any collections bridged, without bridge owner action, will be unable to bridge back. Impact: High, L2 -> L1 tokens will be stuck in the bridge. L1 -> L2 will need to ask for a cancellation.
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.