Summary

In the bridge::deposit_tokens function, the ctype is automatically assumed to be CollectionType::ERC721 without any validation of the token’s interface. This implies that any token passed in could mistakenly be treated as an ERC721. Later in the escrow_deposit_tokens function, the erc721.transfer_from(from, to, token_id) method is invoked to ensure that NFTs are deposited. However, both ERC20 and ERC721 tokens have a transfer_from function. As a result, if a user passes in an ERC20 address, the deposit_tokens function would still succeed, leading to the creation of an ERC721 token on the Ethereum mainnet. This inconsistency could undermine the intended functionality.

Vulnerability Details

In bridge::deposit_tokens, the ctype is automatically set to CollectionType::ERC721 without any validation to ensure that the contract is indeed an ERC721 token.

Subsequently, in the escrow_deposit_tokens function, the erc721.transfer_from(from, to, token_id) method is called to facilitate the NFT deposit. Typically, addresses that do not implement transfer_from would fail at this stage.

However, both ERC20 and ERC721 tokens implement the transfer_from(ContractAddress,ContractAddress,u256) function. This means an ERC20 token could still be deposited successfully, resulting in the creation of an ERC721 token on the Ethereum mainnet. This discrepancy compromises the intended behavior of the cross-chain bridge.

Impact

An ERC20 token could be erroneously used to bridge from Starknet to Ethereum as an ERC721 token, compromising the intended functionality and potentially leading to unintended consequences.

Tools Used

Manual

Recommendations

It is recommended to implement interface checks on the collection to ensure that the correct token type is being processed.