When Bridging NFTs between L1<->L2
, we are whitelisting the NFT collection in the destination chain if it is not whitelisted, and since we are checking that depositing NFTs from the source chain should be from a whitelisted NFT, it is important to integrability between L1 and L2.
The problem is that we are only whitelisting the collection on the destination chain if it doesn't have an attachment to it on L1, whereas after deploying it we are whitelisting it. But if the collection already existed we are not whitelisting it if needed.
As we can see, whitelisting occurs only if the NFT collection does not exist on L1
, so whitelisting the collection will not occur if the collection already exists.
We will discuss the scenario where this can occur and introduce problems in the Proof of Concept
section.
whitelisting is disabled, and any NFT can be Bridged.
NFTs are Bridged from L1, To L2.
NFT collections on L1 are not whitelisted collections now (whitelisting is disabled).
On L2 we are deploying addresses that maps to Collections on L1 and whitelist them.
the protocol enables whiteListing.
NFTs collections that were created on L2 are now whitelisted and can be Bridged to L1, but still, these Collection L1 addresses are not whitelisted.
We can Bridge from L2 to L1 easily as these collections are whitelisted.
We can withdraw the NFT from L1 easily (there is no check for whitelisting when withdrawing).
since L1<->L2
mapping is already set. NFTs Collections are still not-whitelisted
on L1.
The process will end up with the ability to Bridge NFTs from L2 to L1
as they are whitelisted on L2, but the inability to Bridge them from L1 to L2
as they are not whitelisted on L1
.
Manual Review
Whitelist the collection if it is newly deployed or if it already exists and is not whitelisted.
This issue explains the flow from Ethereum to Starknet. the problem also existed in L2 side, where we are only whitelisting if there is no address for that collection on L2
. If the collection_l2 == 0
, we are deploying the collection on L2 and whitelist it. But if it is already existed we are just returning the address without whitelisting it if existed, same as that in L1.
So if we changed the order, the Collections can be whitelisted on L1
, but not on L2
(if the Proof of Concept was in the reverse order), Bridging these NFTs collections from L1 to L2 will be allowed, but we will not be able to Bridge them from L2
to L1
, as they are not whitelisted on L2
.
Recommendations: the same as that in L1
, we need to whitelist collections if they already exist.
NOTE: if the issue will be judged as two separate issues. Please, consider making this report as duplicate of both of them.
Impact: If the whitelist option is disable and a collection has only bridged NFTs from one side before enabling the whitelist option again, one side won’t be able to bridge a whitelisted token. Likelyhood: Low, Will be rare and unexpected but can happen.
Impact: If the whitelist option is disable and a collection has only bridged NFTs from one side before enabling the whitelist option again, one side won’t be able to bridge a whitelisted token. Likelyhood: Low, Will be rare and unexpected but can happen.
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.