Not being an ERC721
doesn't mean being an ERC1155
for sure. There is a lot of other standards and an attacker could just create its own with malicious code, it won't be an ERC721
. The contract will consider it as an ERC1155
and execute the malicious code.
==> A possible malicious code set appart, treating all non ERC721
like if they were ERC1155
will lead to problems for the user, and the protocol may not function as intended.
In depositTokens()::Bridge.sol
we can see that all non ERC721
are treated like if they were ERC1155
:
The protocol won't work as intended if the non ERC721
is not an ERC1155
.
An other possibility is that an attacker could create an non ERC721 contract
with (potential) malicious code.
Github, VisualCode, Foundry.
Check if it's an ERC721
, then an ERC1155
, if not revert :
No impact on the bridge or the users. If any NFT protocol use another standard with that bridge, they have to know how the bridge works and also that it doesn’t work with other standards at the moment.
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.