Usage of mint
instead of safeMint
in both Bridge
and bridge.cairo
can lock the tokens in the recipient if he doesn’t expect to receive ERC721
tokens.
Important note: nothing related to safeMint instead of mint was observed in the known issues.
We can see that both bridge contracts will mint the NFTs to the recipient in case it is not escrowed, i.e. this is the first time this collection is being bridged to the chain.
The _safeMint()
includes a necessary safety check that validates a recipient contract’s ability to receive and handle ERC-721 tokens. Without this safeguard, tokens can inadvertently be sent to an incompatible contract, causing them, and any assets they hold, to become irretrievable. If the safe operation is used transactions will fail in the bridge operation and that will give the ability originator chain senders to cancel the transaction and retrieve their assets, while now this is not possible since transaction will be completed successfully and prover will update the state so no cross chain transaction cancellation is possible.
Irrevocable NFTs due to usage of mint
instead of safeMint
which will cause loss of all the NFTs in case receiver chain recipient is not able to handle ERC721
tokens.
Manual Review
Replace mint
with safeMint
, no reentrancy can be caused in any part of the codebase.
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.
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.