Pool Party

Smart Contract Audit Report

Executive Summary

This report presents the outcomes of our collaborative engagement with the Maximus team, focusing on the comprehensive evaluation of the PoolPartyV2 and PerpetualExchange contracts. However, large portions of the contracts analyzed rely on contracts that are outside the scope of this audit.

Our team conducted an initial security assessment from February 8th to February 12th, 2024.

Maximus DAO is releasing Pool Party which allows users to earn tPARTY tokens by providing ETH. This audit is a expansion of the previously reviewed PerpetualPool. That report can be found here.

Audit Scope

Audit Findings

An informational finding was identified and the team may want to review it.

require(current_day>LATEST_SNAPSHOT_DAY + 6 , "Snapshot can only be taken once every 2 weeks.");

PoolParty System Overview

While the mint phase is active, users may supply ETH to the PoolParty contract to allocate themselves tPARTY tokens that can later be minted. The mint phase duration is 18 days from the contract's deployment. The amount of tokens users are allocated is based on the "mint scalar". This value is set by the team on deployment and cannot be changed.

The contract contains two additional methods for minting. Users may specify a referral address when minting. Both the minting user and the referral address will receive a bonus of 2% of the minted amount. Users may supply their own address or an address they also control to receive the referral bonus when minting with this method. The contract also allows for a "team" minting method. Rather than supplying ETH users must have a sufficient "team contract" token balance. The specified amount of tokens are burned from the user and they are allocated tPARTY tokens based on the "team mint scalar". This is also set by the team on deployment and cannot be changed.

Once the mint phase has passed the owner may "seed" the liquidity fund. This will send all of the acquired ETH to the liquidity fund address and mint the liquidity fund its share of tPARTY tokens.

Users may claim their allocated tokens once the Lifeguard address "releases the supply". If 10 days have passed from the end of the mint phase any address may release the supply.

Users may also claim tokens based on their "initial supply points". When minting using this method the sender's address and amount of tokens is verified using a Merkle Tree.

Users may claim airdrop tokens allocated to them after the supply is released. The sender's address and amount allocated to them is verified using a Merkle Tree. The total amount of tokens that can be minted by airdrop is 1/10th of the total amount allocated to be minted in the minting phase. The number of tokens minted to the user is based on the amount of "airdrop points" allocated to them. Users receive the amount of tokens equal to the proportion of airdrop points allocated to them relative to the total airdrop points.

Users may stake their tPARTY tokens at any time. All staked tokens are burned from the sender. The staking duration and "merkle amount" is verified using a Merkle Tree. The amount of tokens that will be earned is calculated in advance based on the amount staked and the merkle amount.

Users may claim their staked tokens once the staking duration has passed. Users will be minted the initial staked amount and the earned yield that was calculated when staking.

Users may mint a NameTag NFT if they are the owner of the "ticker" associated with the NFT in the NameClaim contract. The NameClaim contract was out of scope for this audit so we cannot give an assessment in regard to security.

Users may start an auction on any NameTag NFT that does not have an owner in the NameClaim contract. Users bid on the NFT using tPARTY tokens. The starting bid must be at least the minimum bid specified by the owner. The owner may lower the minimum bid but cannot raise it.

Any subsequent bid must be at least 5% higher than the current bid. The new highest bidder will have their tPARTY tokens burned and the previous highest bidder will be minted back their bid amount. Each auction lasts 24 hours. If a bid is placed in the last 6 minutes the auction will last an additional 6 minutes.

Once an auction's duration has passed any user may end the auction. This will mint the current highest bidder the NameTag NFT.

Any user may "process" an asset. Processing an asset will send the contract's balance of a specified token to the Reward Distribution contract. This is intended to process the "thank you" fee sent to the contract via a PerpetualPool instance. Users may then claim these tokens through the RewardDistribution contract. After the "reward expiration" period has passed the LifeGuard address may claim tokens on users behalf.

PerpetualPool System Overview

Any user with a NameTag NFT may deploy a PerpetualPool via the PartyPoolDeployer contract. The supplied NameTag NFT is transferred to the deployed PerpetualPool instance.

Users may "pledge" hex tokens in order to be minted Pool tokens. The hex token contract is outside the scope of this audit so we are unable to give an assessment in regard to security. The pledging user is minted Pool tokens based on the amount of hex transferred and the current hex redemption rate. Pledging may only occur when staking is active and the reload phase has not ended.

Users may redeem their Pool tokens for the underlying hex tokens. They will receive hex tokens based on the amount being redeemed and the current hex redemption rate. Redemption may only occur when staking is not active.

Any user can trigger the staking period if it has not already started and the reload phase has ended. The contract's token balance is staked in the hex token contract. The hex token is outside the scope of this audit so we are unable to give an assessment in regard to security.

A "thank you" fee is taken for the Organizer and Party addresses. The Party address is transferred 0.5% of the contract's hex balance whereas the Organizer address is transferred the "organizer share" of the contract's balance. The organizer share is set by the owner on deployment.

Any user can end the staking once the stake duration has passed and the "bonus sequence" has been run. This will recalculate the hex redemption rate based on the amount of hex earned during staking and the total supply of Pool tokens. Additionally, this will trigger the next "reload phase" so users are able pledge hex tokens again.

Any user may start the bonus sequence for the current snapshot once the staking duration has passed. After 6 hours any user may complete the bonus sequence. This allows the users to claim bonus COM and HEDRON tokens based on their Pool token balance. The COM and HEDRON tokens must be supplied to the contract in order for rewards to be claimed. Both the COM and HEDRON contracts are outside the scope of this audit so we are unable to give an assessment in regard to security.

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