The current setup in the ArkProject bridge allows the bridge admin to independently whitelist or disable NFT collections on either L1 or L2 chains. This asymmetric management of whitelisting can lead to scenarios where users may unknowingly bridge valuable NFTs into a situation where they become trapped, particularly if a collection is disabled on L2 but remains active on L1.
Risk of Asset Lock-In: If a collection is disabled on L2 after an NFT has been bridged, the owner may not be able to bridge it back to L1, effectively trapping the asset in escrow.
User Trust Issues: Users, unaware of the disabling, could bridge high-value NFTs to L2 only to find themselves unable to return the NFTs to L1, causing significant financial and emotional distress.
Operational Bottleneck: The centralization of whitelisting power in the hands of the bridge admin without automatic synchronization between L1 and L2 whitelisting status increases the risk of operational errors and misuse of authority.
Bob owns two valuable Bored Ape NFTs (#1 and #2) on the ETH (L1), each worth over 30 ETH.
The bridge admin disables the Bored Ape collection on the L2 network, but Bob is unaware of this action.
Motivated by an airdrop or other benefits on L2, Bob decides to bridge his Bored Ape NFT #1 from L1 to L2.
The bridging process locks the NFT in Escrow on L1, and a corresponding token is minted for Bob on L2.
After receiving the perks on L2, Bob tries to bridge his NFT back to L1 to withdraw it from escrow.
Bob discovers that he cannot complete the bridging back process because the collection is disabled on L2.
As a result, Bob's Bored Ape NFT #1 remains stuck in escrow, leaving him dependent on the bridge admin to re-enable the collection to retrieve his valuable asset.
Synchronized Whitelisting: Implement a policy where disabling a collection on one chain (L1 or L2) automatically triggers the disabling of the same collection on the other chain. This would prevent users from inadvertently bridging assets into a disabled state.
Pre-Bridge Whitelisting Check: Introduce a verification step during the bridging process that checks the whitelisting status on both L1 and L2 before allowing the bridge transaction to proceed. If the collection is disabled on either chain, the user should be alerted and the transaction should be blocked.
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.
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.