PROOF Standard Whitelist Token

Smart Contract Audit Report

Executive Summary

This report presents the outcomes of our collaborative engagement with the PROOF team, focusing on the comprehensive evaluation of the ProofStandardWhitelist and DataStore contracts.

Our team conducted an initial security assessment from September 30th to October 2nd, 2024.

The PROOF team has upgraded their existing platform, enhancing its infrastructure with a new set of modular contracts that enable users to create various types of tokens. The ProofStandardWhitelist contract is designed to be one of the token implementations within the Factory contract, providing a framework for users to deploy their own tokens that function as automatic liquidity-providing protocols.

Audit Scope

Audit Findings

No findings were identified, though some centralized aspects are present.

System Overview

DEPLOYMENT AND TOKENOMICS

The total supply of the token is set by the token creator in the Factory contract, with a portion minted to the contract and the remaining tokens minted to the owner's address. The creator will specify an initial ETH contribution that is sent to the contract. Liquidity is added to the Pair using the contract’s current token and ETH balances upon initialization. The LP tokens generated through this process are sent to the contract.

The initializer must specify an LP token lock duration, whitelist duration, a list of addresses that are added to the whitelist, and a maximum wallet percentage. No mint or burn functions are publicly accessible in the platform.

LAUNCH AND CANCELLATION

The owner can initiate the contract's launch and bundle buy process, which includes the following actions:

• Execute a purchase with the amount of ETH allocated for the bundle buy as specified by the owner.
• Enable the whitelist functionality and set the whitelist end time.
• Whitelist every address that currently owns a ProofPass NFT.
• Lock the contract's full LP token balance for the lock duration specified upon deployment in a Team Finance token-locking contract.
• Enable trading and record the timestamp in which trading is enabled.

The owner can initiate a cancellation before the token has been launched, which will remove liquidity from the Pair, transfer the tokens and ETH to the owner, and subsequently transfer 100% of the tokens and ETH held in the contract to the owner's address.

TRANSFERS

Trading must be enabled before transfers can take place on the platform. Before the whitelist end time has been reached, both the sender and the recipient must have been added to the contract's whitelist in order for a transfer to successfully occur.

The contract enforces a maximum sell amount when the restrict-whales functionality is enabled by the owner, which imposes a limit to the number of tokens that can be sold via Uniswap in a single transaction.

The contract enforces a maximum wallet amount when the restrict-whales functionality is enabled by the owner, which prevents a transfer from occurring if the recipient's token balance will exceed the limit number of tokens after the transfer occurs. The maximum wallet amount begins at an initial value and automatically increases by 0.1% of the total supply every 10 blocks. This continues until it reaches 1%, unless the owner manually updates the maximum wallet amount.

There is a Liquidity fee, Secondary fee, Main fee, and Proof fee on all buys and sells via Uniswap where neither the sender nor the recipient is excluded from fees. A separate fee structure can be set by the team to apply different fee percentages depending on whether the transaction is a buy or sell.

If more than 1 day has passed since the token launch, the Proof fee is reduced to 1%. After 31 days, the Proof fee is completely removed. Additionally, the remaining buy and sell fees decrease gradually: buy fees reduce (from 15%) by 1% every 10 blocks, and sell fees reduce (from 20%) by 1% every 10 blocks, until they reach their predefined resting values set upon deployment.

The tokens collected through fees are stored in the contract address. The tokens are swapped for ETH for the purpose of funding Uniswap liquidity and designated addresses when the following conditions are met:

• The automatic liquidity add functionality is enabled by the team.
• The threshold number of tokens in the contract address (determined by the owner) has been reached.
• The contract is not currently performing an automatic liquidity add.
• The caller is not initiating a buy transaction via Uniswap.
• At least 1 block has passed since this swapping functionality has previously occurred.

Liquidity adds are automatically performed by selling the tokens collected as fees, pairing the received ETH with the token, and adding it as liquidity to the ETH pair. The LP tokens received through this process are sent to the 0x..dead address.

The tokens collected through the Secondary Fee and Main fee are swapped for ETH and sent to the team's Secondary wallet and Main wallet respectively. The tokens collected through the Proof fee are swapped for ETH and evenly split between the Proof Staking address and Proof wallet.

OWNERSHIP CONTROLS

The owner can update the Liquidity fee, Main fee, and Secondary fee for both the buy and sell fee structures after initial taxes have settled. The total fee percentages combined for both fee structures cannot exceed the limit values set in the DataStore contract. If at least 1 day but less than 31 days has passed since launch, the Proof fee will be automatically updated from 2% to 1% on both buys and sells. After 31 days have passed, the Proof fee will be permanently removed. The owner can exclude/include accounts from fees at any time.

The owner can specify a list of addresses to add to the contract's whitelist at any time. The owner can set the maximum transaction amount and maximum wallet amount to any values within specified percentage ranges of the total supply, as defined in the DataStore contract, once trading has been enabled. The owner can exclude/include accounts from the maximum transaction and maximum wallet restrictions at any time. The owner can enable/disable the maximum transaction and maximum wallet restrictions at any time.

The owner can enable/disable automatic liquidity adds at any time. The owner can update the threshold number of tokens needed to trigger an automatic liquidity add to any value at any time.

The owner can withdraw any tokens not collected through fees from the contract at any time. The owner can set the team's Secondary wallet and Main wallet to any addresses at any time. The owner can transfer ownership to any address at any time.

DataStore Overview

DEPLOYMENT

The deployer will specify a list of address keys and their corresponding address values, as well as a list of uint keys and their corresponding uint values, to store in the contract during deployment. Each key-value pair is stored in respective mappings that support various data types, including addresses, booleans, bytes32, integers, strings, and unsigned integers, with each key being used to retrieve its associated value.

STORAGE AND RETRIEVAL

The contract utilizes multiple mappings to store different data types, allowing for efficient data management. Each type of data has its own mapping, with keys encoded to ensure consistent storage and retrieval.

UPDATE/DELETE MAPPINGS

The owner can update values in each mapping by specifying the key and the new value at any time. The owner can remove values from each mapping by specifying the key at any time.

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