Staked service will be irrecoverable by owner if not an ERC721 receiver about 2024-05-olas-findings

[kupermind]

msg.sender is the owner that stakes the service, and it's exactly the same owner that is able to unstake it. What is the scenario that msg.sender was able to be the owner of the service before staking it, but is no longer able to receive ERC721 token when unstaking?

Our protocol assumes a valid ERC721 standard used in all the possible service registry contracts. If someone decides to use a custom broken ERC721 contract that is able to mint tokens to the contract, but cannot receive one by the transfer, this is out of scope of our protocol.

[c4-sponsor]

kupermind (sponsor) disputed

[kupermind]

After several communication rounds we can accept the issue, however the declared severity completely does not match the issue. There is zero risk factor for the protocol, only the user stupidity that have not checked the staking contract requirements.

None of well-known contract wallets reject the contract ERC721 support. This must be an artificially created scenario when the user deliberately uses the contract without such a support. If one is talking about outdated Safe, for example, there is a way to upgrade the Safe version, and then provide the correct fallbackHandler contract address to deal with ERC721 contracts.

[c4-judge]

0xA5DF changed the severity to 2 (Med Risk)

[c4-judge]

0xA5DF marked the issue as satisfactory

[c4-judge]

0xA5DF marked the issue as selected for report

[0xA5DF]

I agree that this is less likely to happen and somewhat on the user to ensure that their contract can receive ERC721
However, I think that the likelihood is sufficient to consider this as med, given the high impact.

[thebrittfactor]

For transparency, per discord discussion with the Olas sponsor (kupermind) the labeling has been updated to sponsor acknowledged.

[vsharma4394]

Fixed