HOAMI

Smart Contract Audit Report

Executive Summary

This report presents the outcomes of our collaborative engagement with the HOAMI team, focusing on the comprehensive evaluation of the HOAMI, PIIP, and RoyaltyPool contracts.

Our team conducted an initial security assessment from July 23rd to July 30th, 2024. On August 2nd, our team amended this report to reflect updates made to the PIIP and RoyaltyPool contracts that resolve all Findings. On September 18th, our team amended this report to reflect updates made to the HOAMI contract. On October 29th, our team amended this report to reflect the contracts' mainnet addresses.

HOAMI is developing an ERC-20 token, alongside a new HOAMI NFT series. Users can purchase these NFTs using HOA tokens. Additionally, HOAMI NFT holders can claim rewards based on their holdings.

Audit Scope

Audit Findings

All findings have been resolved. In addition, minimal centralized aspects are present.

for (uint256 tokenIndex = 0; tokenIndex < length; ) {
	uint256 tokenId = _tokenIds[tokenIndex];
	uint64 unclaimedDays = currentDay - lastClaimDay[tokenId];
	if (unclaimedDays > 0) {
		address hoamiTokenOwner = hoamiContract.ownerOf(tokenId);
		if (lastOwnerAddress != hoamiTokenOwner) {
			if (unclaimedDaysSum > 0) {
				uint256 mintAmount = unclaimedDaysSum * rewardAmountPerDay;
				_mint(lastOwnerAddress, mintAmount);
				unclaimedDaysSum = 0; // Reset unclaimedDaysSum
				amountClaimed += mintAmount;
			}
			lastOwnerAddress = hoamiTokenOwner;
		}
		unclaimedDaysSum += unclaimedDays;
		lastClaimDay[tokenId] = currentDay;
	}
	unchecked {
		++tokenIndex;
	}
}

System Overview

HOAMI NFT

Any user can mint a specified number of NFTs during the active minting period. The Default Admin can update the minting period end time at any time before the current end time has been reached. Upon deployment, the team will set the address for the HOA ERC-20 token referenced in the contract. The calculated number of HOA tokens (based on the minting fee) will be transferred from the user to the contract and will remain locked until the corresponding NFT is burned. The user must grant the contract a sufficient token allowance for the transfer to occur successfully.

The total supply of HOAMI NFTs is limited to 10,000. Additionally, the Default Admin can impose a per-user mint limit on any address at any time. If set, the user's total mint amount cannot exceed one less than their designated limit. If the collection is minted out or the minting period has expired, no further NFTs can be minted.

Any user can specify any of their owned NFT IDs to burn after the minting period has ended. For each NFT burned, the user will receive 1 HOA token from the contract, which was originally supplied during the minting process.

The contract implements ERC-2981 functionality that supports the use of Royalties that can be used with NFT marketplaces. The Default Admin can update the Royalty recipient to any address at any time and the Royalty percentage to any value up to 50% at any time.

PIIP TOKEN

The total supply of the token is set to zero upon deployment. No public mint functions are accessible. No burn functions are accessible though the circulating supply could be reduced by sending tokens to the 0x..dead address.

Any user can set the HOAMI address referenced in the contract one time. The contract's start time is automatically set to the minting end time of the HOAMI contract.

Any user can initiate a rewards claim at any time by specifying a list of NFT IDs. The contract calculates the unclaimed rewards for each specified token ID based on the number of unclaimed days and the contract's reward per day value of 2 tokens. The calculated amount of PIIP token rewards is minted to the respective NFT owners.

ROYALTY POOL

The deployer will add the WPLS token address to the list of reward tokens upon deployment. Any user can set the HOAMI address referenced in the contract one time. The deployer is automatically granted the Default Admin role. The Default Admin can add or remove addresses from the reward token list at any time. Any user can initiate the update of reward balances for all reward tokens or any individual reward token at any time. Any PLS sent directly to the contract is automatically exchanged for WPLS and used for rewards.

Any user can claim all accumulated rewards for a specified HOAMI NFT across all reward tokens available on the platform. Rewards are distributed based on the proportional accumulated balance of reward tokens in relation to the total supply of HOAMI NFTs. The claimed rewards are transferred from the contract directly to the NFT owner.

Any user can initiate a claim for one of the platform's reward tokens by specifying a list of HOAMI NFT IDs and a reward token that has been approved by the team. Rewards are calculated based on the proportional balance of accumulated reward tokens relative to the total supply of HOAMI NFTs. The claimed rewards are transferred from the contract directly to the NFT owner.

Vulnerability Analysis

About SourceHat

SourceHat has quickly grown to have one of the most experienced and well-equipped smart contract auditing teams in the industry. Our team has conducted 1800+ solidity smart contract audits covering all major project types and protocols, securing a total of over $50 billion U.S. dollars in on-chain value!
Our firm is well-reputed in the community and is trusted as a top smart contract auditing company for the review of solidity code, no matter how complex. Our team of experienced solidity smart contract auditors performs audits for tokens, NFTs, crowdsales, marketplaces, gambling games, financial protocols, and more!

Contact us today to get a free quote for a smart contract audit of your project!

What is a SourceHat Audit?

Typically, a smart contract audit is a comprehensive review process designed to discover logical errors, security vulnerabilities, and optimization opportunities within code. A SourceHat Audit takes this a step further by verifying economic logic to ensure the stability of smart contracts and highlighting privileged functionality to create a report that is easy to understand for developers and community members alike.

How Do I Interpret the Findings?

Each of our Findings will be labeled with a Severity level. We always recommend the team resolve High, Medium, and Low severity findings prior to deploying the code to the mainnet. Here is a breakdown on what each Severity level means for the project:

• High severity indicates that the issue puts a large number of users' funds at risk and has a high probability of exploitation, or the smart contract contains serious logical issues which can prevent the code from operating as intended.
• Medium severity issues are those which place at least some users' funds at risk and has a medium to high probability of exploitation.
• Low severity issues have a relatively minor risk association; these issues have a low probability of occurring or may have a minimal impact.
• Informational issues pose no immediate risk, but inform the project team of opportunities for gas optimizations and following smart contract security best practices.

• Go Home