User NFT Not Re-Minted After Migration Causing User Confusion

[code423n4]

Lines of code

https://github.com/code-423n4/2023-07-lens/blob/cdef6ebc6266c44c7068bc1c4c04e12bf0d67ead/contracts/FollowNFT.sol#L480

Vulnerability details

Impact

In the existing implementation of the system, an issue has been identified. The bug occurs during the migration process of a user's NFT. During this process, the user's NFT is burned, but a new one isn't automatically minted in its place. Although the user has the ability to manually mint the NFT later, it is suggested to incorporate this feature within the migration function. This change would help avoid confusion and concern for the user, especially if the migration process was carried out by the hub on behalf of the user.

The bug can be traced back to the tryMigrate function in the system:

  function tryMigrate(
        uint256 followerProfileId,
        address followerProfileOwner,
        uint256 idOfProfileFollowed,
        uint256 followTokenId
    ) external onlyHub returns (uint48) {
        ...

        super._burn(followTokenId);
        return mintTimestamp;
    }
}

Proof of Concept

https://github.com/code-423n4/2023-07-lens/blob/cdef6ebc6266c44c7068bc1c4c04e12bf0d67ead/contracts/FollowNFT.sol#L480

Tools Used

None

Recommended Mitigation Steps

Include wrap and mint functionality in the migrate function so the user gets a new nft copy immediately

Assessed type

ERC721

[vicnaum]

This is by-design, because many users were complaining about having thousands of FollowNFTs in their wallets and having to move them with their profile to a different wallet. The migration solves this issue by tying the FollowNFTs to the Profile, hiding them from wallets, and introducing minting on-demand.

[c4-sponsor]

vicnaum marked the issue as sponsor disputed

[c4-judge]

Picodes marked the issue as unsatisfactory: Invalid