Core Contracts
Regnum Aurum Acquisition Corp
HardhatReal World AssetsNFT
77,280 USDC
View results
Previous Next
Submission Details
Severity: high
Invalid

No Restriction Of Minting After a House is Bought- RAACNFT.sol

boraicho

Summary

The RAACNFT.sol contract is designed to represent multiple NFTs, each backed by a physical house. However, the current implementation does not restrict minting after a house has been "bought," allowing multiple users to mint the same token ID. This creates a critical issue where there is no restriction to stop buying a house once it has been bought . The contract inherits from ERC721Enumerable.sol but does not implement it properly to stop this from happening.

Vulnerability Details

The mint function in RAACNFT.sol does not enforce a restriction on re-minting an already purchased house. As seen in the following function (GitHub reference: RAACNFT.sol#L32-L50), users can continuously mint the same token ID if they have sufficient funds:

function mint(uint256 _tokenId, uint256 _amount) public override {
uint256 price = raac_hp.tokenToHousePrice(_tokenId);
if(price == 0) { revert RAACNFT__HousePrice(); }
if(price > _amount) { revert RAACNFT__InsufficientFundsMint(); }
​
// Transfer ERC20 from user to contract - requires pre-approval from user
token.safeTransferFrom(msg.sender, address(this), _amount);
​
// Mint tokenId to user
_safeMint(msg.sender, _tokenId);
​
// Refund excess amount if user approved more than necessary
if (_amount > price) {
uint256 refundAmount = _amount - price;
token.safeTransfer(msg.sender, refundAmount);
}
​
emit NFTMinted(msg.sender, _tokenId, price);
}

Since there is no check to prevent the same _tokenId from being minted multiple times, multiple users can own the same house-backed NFT, breaking the intended exclusivity.

Impact

This vulnerability has high impact because:

  • Users may unknowingly purchase an NFT without true asset backing.

  • The protocol could lose credibility and legal validity if asset-backed claims cannot be enforced.

Tools Used

  • Manual Review

Recommendations

To fix this issue, the protocol should implement a finite minting mechanism that prevents an already-minted _tokenId from being minted again. Possible solutions include:

  1. Checking Ownership: Before minting, check if _tokenId is already assigned to an owner (ownerOf(_tokenId)) and revert if so.

Updates

Lead Judging Commences

inallhonesty Lead Judge 4 months ago
Submission Judgement Published
Invalidated
Reason: Incorrect statement
inallhonesty Lead Judge 4 months ago
Submission Judgement Published
Invalidated
Reason: Incorrect statement

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.