When Deploying a new ERC721 collection on L1, we are creating a new instance of ERC721Bridgeable(), and deploy it as a Proxy to be able to upgrade it.
Since this interface ERC721Bridgeable is a constant bytecode when compiling the contract, it will make the code logic of ERC721 that will get deployed when withdrawing from L1 immutable and we can't change its logic.
If we checked L2Bridge we will find this is not how it works, where it supports changing the logic of the ERC721 collection that will get deployed on L2. There is a function called set_erc721_class_hash() which changes the class_hash of the ERC721 collection addresses (which is like changing the bytecode in EVM/solidity).
And by changing erc721_bridgeable_class the newly created NFTs collections on L2 will have the Logic that represents that class_hash.
So in L2Bridge we will be able to change the Code Logic of the ERC721 collection that will get deployed, but in L1Bridge we will not be able to do this. which means that the two Bridges are not consistent.
Manual Review
Make the bytecode a variable that can be changed, and since there is no constructor argument this will be enough.
Make the creation using create opcode, with providing that bytecode variable.
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.