PROOF Standard Stealth Token

Smart Contract Audit Report

PROOF Standard Stealth Token Audit Report

Executive Summary

This report presents the outcomes of our collaborative engagement with the PROOF team, focusing on the comprehensive evaluation of the ProofStandardStealth contract.

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 ProofStandardStealth token represents a framework for users to deploy their own tokens, which function as automatic liquidity-providing protocols.


Audit Scope

Name

Source Code

Visualized

ProofStandardStealth

Inheritance Chart.  Function Graph.

Name/Source Code

Visualized

ProofStandardStealth

Inheritance Chart.  Function Graph.


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 deployer upon deployment. A percentage of the total supply (specified by the deployer) is minted to the contract. The remaining tokens are minted to the deployer's address. The deployer must specify an LP token lock duration of at least 30 days, a maximum wallet percentage that is no less than 0.1% of the total supply, and the initial ETH contribution to the contract must be a minimum of 1 ETH. No mint or burn functions are publicly accessible in the platform.

FUND LIQUIDITY

The owner can trigger a fund-liquidity transaction, which adds liquidity to the Pair using the contract’s current token and ETH balances. The LP tokens generated through this process are sent to the contract.

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.
  • 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.
  • Set the anti-sniper end block to 10 blocks in the future.

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. The contract enforces an anti-sniper mechanism for the first 10 blocks after trading is enabled, which prevents users from initiating more than one transfer per block.

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 reached their resting values. The total fee percentages combined for both fee structures cannot exceed 7%. 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 set the maximum transaction amount and maximum wallet amount to any values between 0.5% of the total supply and 3% of the total supply after 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.


Vulnerability Analysis

Vulnerability Category Notes Result
Arbitrary Jump/Storage Write N/A PASS
Centralization of Control The owner can set total fees on buys and sells up to 7% at any time. PASS
Compiler Issues N/A PASS
Delegate Call to Untrusted Contract N/A PASS
Dependence on Predictable Variables N/A PASS
Ether/Token Theft N/A PASS
Flash Loans N/A PASS
Front Running N/A PASS
Improper Events N/A PASS
Improper Authorization Scheme N/A PASS
Integer Over/Underflow N/A PASS
Logical Issues N/A PASS
Oracle Issues N/A PASS
Outdated Compiler Version N/A PASS
Race Conditions N/A PASS
Reentrancy N/A PASS
Signature Issues N/A PASS
Sybil Attack N/A PASS
Unbounded Loops N/A PASS
Unused Code N/A PASS
Overall Contract Safety   PASS

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.