PUMPD Info
$PUMPD isn’t just another meme coin — it’s Pump.fun 2.0 built to pump daily. With an 80-day presale where the price rises every 24h, early or late you still win. Add staking rewards, AI-powered tools, and a launchpad for the next meme kings, and $PUMPD becomes the future of meme coins you can’t afford to miss.
TrustNet Score
The TrustNet Score evaluates crypto projects based on audit results, security, KYC verification, and social media presence. This score offers a quick, transparent view of a project's credibility, helping users make informed decisions in the Web3 space.
Real-Time Threat Detection
Real-time threat detection, powered by Cyvers.io,
is currently not
activated
for this project.
This advanced feature provides continuous monitoring and instant alerts to safeguard your assets from potential security threats. Real-time detection enhances your project's security by proactively identifying and mitigating risks.
For more information, click here.
Summary and Final Words
No crucial issues found
The contract does not contain issues of high or medium criticality. This means that no known vulnerabilities were found in the source code.
Contract owner cannot mint
It is not possible to mint new tokens.
Contract owner cannot blacklist addresses.
It is not possible to lock user funds by blacklisting addresses.
Contract owner cannot set high fees
The fees, if applicable, can be a maximum of 25% or lower. The contract can therefore not be locked. Please take a look in the comment section for more details.
Token transfer can be locked
Owner can lock user funds with owner functions.
Token cannot be burned
There is no burning within the contract without any allowances
Ownership is not renounced
The owner retains significant control, which could potentially be used to modify key contract parameters.
Contract is not upgradeable
The contract does not use proxy patterns or other mechanisms to allow future upgrades. Its behavior is locked in its current state.
Scope of Work
This audit encompasses the evaluation of the files listed below, each verified with a SHA-1 Hash. The team referenced above has provided the necessary files for assessment.
The auditing process consists of the following systematic steps:
- Specification Review: Analyze the provided specifications, source code, and instructions to fully understand the smart contract's size, scope, and functionality.
- Manual Code Examination: Conduct a thorough line-by-line review of the source code to identify potential vulnerabilities and areas for improvement.
- Specification Alignment: Ensure that the code accurately implements the provided specifications and intended functionalities.
- Test Coverage Assessment: Evaluate the extent and effectiveness of test cases in covering the codebase, identifying any gaps in testing.
- Symbolic Execution: Analyze the smart contract to determine how various inputs affect execution paths, identifying potential edge cases and vulnerabilities.
- Best Practices Evaluation: Assess the smart contracts against established industry and academic best practices to enhance efficiency, maintainability, and security.
- Actionable Recommendations: Provide detailed, specific, and actionable steps to secure and optimize the smart contracts.
A file with a different Hash has been intentionally or otherwise modified after the security review. A different Hash may indicate a changed condition or potential vulnerability that was not within the scope of this review.
Final Words
The following provides a concise summary of the audit report, accompanied by insightful comments from the auditor. This overview captures the key findings and observations, offering valuable context and clarity.
Ownership Privileges
- The owner can set the private sale allocations.
- The owner can set the pre-sale allocations.
- The owner can revoke the allocation.
- The owner can set the sale as active.
- The owner can pause the contract.
- The owner can unpause the contract.
- The owner can set the price for the private sale.
- The owner can set the price for pre-sale.
- The owner can invest tokens for any user in the private sale.
- The owner can invest the tokens for any user in the pre-sale.
- The owner can withdraw unsold tokens for a sale.
Note - This Audit report consists of a security analysis of the PUMPD smart contract. This analysis did not include functional testing (or unit testing) of the contract’s logic. Moreover, we only audited the mentioned contract for the PUMPD team. Other contracts associated with the project were not audited by our team. We recommend investors do their own research before investing.
Files and details
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Findings and Audit result
medium Issues | 3 findings
Pending
#1 medium Issue
Owner Can Indefinitely Lock User Token Claims
The contract grants the owner the ability to pause and unpause its core functionalities through the pause() function. The user-facing claim functions, pvtSaleClaim() and claimPreSale(), are both implemented with the whenNotPaused modifier. This creates a significant centralization risk, as it allows the owner to unilaterally and indefinitely block all investors from claiming their vested tokens. An investor's ability to access their purchased assets is therefore not guaranteed by the code's vesting logic alone but is subject to the owner's discretion. A malicious owner could abuse this power to hold user funds hostage, or a compromised owner key could lead to all claims being permanently frozen.
Pending
#2 medium Issue
Owner Can Force-Claim Vested Tokens on Behalf of Users
The setUserDirectForPreSale function contains a design flaw that allows the owner to trigger a token claim on behalf of an investor without their consent. When the owner uses this function to add more tokens to a user who already has an existing vesting schedule, the function's logic first checks for and calculates any amount that has already vested. If there is a claimable amount, the function immediately transfers those tokens to the user's wallet. This action is not initiated by the user and removes their agency to decide when to claim their assets. This forced withdrawal could have undesirable consequences for the investor, such as creating an unexpected taxable event or interfering with their personal asset management strategy. The function's behavior violates the principle of least surprise, as its name implies it only adds tokens, not that it also performs a withdrawal.
Pending
#3 medium Issue
Function Performs an Unstated Forced Token Claim
The investInPvtSale function contains hidden functionality that poses a significant risk. While its name implies its sole purpose is to add a new investment to a user's balance, its actual behavior for existing investors is to first force-claim any vested tokens on their behalf and only then add the new investment amount. Even if this "claim-then-add" behavior is intended, it is not stated in the function's name or documentation, violating the principle of least surprise. This creates a high risk of operator error, where the contract owner could inadvertently trigger a large, unwanted token withdrawal for a user when their only intention was to add a bonus or new allocation. This could lead to negative consequences for both the project's tokenomics and the investor's personal financial planning.
low Issues | 4 findings
Pending
#1 low Issue
Unchecked Return Values on ERC20 Calls; Use safeTransfer and safeTransferFrom
The PUMPDSale contract performs multiple ERC20 token transfers using the standard transfer and transferFrom functions. A critical vulnerability exists in this implementation because the boolean value returned by these calls is not checked. According to the ERC20 standard, these functions return true on success and false on failure. By not validating this return value, the contract will continue its execution path even if a token transfer fails (e.g., due to the owner not having approved the contract to spend the required amount). This can lead to a severe state inconsistency where the contract's internal logic believes it holds tokens that were never actually transferred, which would cause subsequent investor claims to fail and could lead to a loss of confidence or funds. Additionally, this direct-call approach is not compatible with certain non-standard ERC20 tokens that do not return a boolean value, which can cause otherwise valid transactions to revert.
Pending
#2 low Issue
Internal Function Can Be Optimized to view
The internal function _checkDailyAllocation is currently defined without a state mutability specifier, which defaults to non-payable and allows for state changes. However, a review of the function's logic shows that it only reads from the contract's state variables (such as allocations and dailyAllocationUsed) and the global block.timestamp to perform its validation checks. It does not perform any write operations or modify the contract's state in any way. Leaving out the view specifier is inefficient and does not accurately represent the function's read-only purpose, potentially leading to higher gas costs when it's called internally.
Pending
#3 low Issue
Duplicated Logic for Vesting Creates Significant Maintenance Risk
The contract's design suffers from a significant structural flaw due to widespread code duplication in its core vesting logic. The complex if/else block responsible for creating a new vesting schedule or updating an existing one is copied and pasted across four separate functions: investInPvtSale, setUserDirectForPrivateSale, investInPreSale, and setUserDirectForPreSale. This violation of the "Don't Repeat Yourself" (DRY) principle introduces a serious maintenance and security risk. If a bug, logic flaw, or security vulnerability were ever discovered in this critical vesting logic, a developer would be required to locate and patch the issue in all four locations. The high probability of missing one of these instances would leave the contract partially vulnerable, making it fragile and difficult to audit and maintain securely over its lifecycle.
Pending
#4 low Issue
Daily Allocation Calculation Leads to Unsellable Tokens
The contract contains a flaw in its economic design that can render a portion of the sale allocation unsellable. This issue originates in the setPrivateSaleAllocation and setPreSaleAllocation functions. Within these functions, the perDayAllocation is calculated using integer division (saleAllocation / noOfDays). Because integer division in Solidity truncates any remainder, if the total saleAllocation is not perfectly divisible by the noOfDays, the sum of all daily allocations will be less than the total tokens allocated for the sale. These leftover tokens—the remainder from the division—are not added to the daily sale pools or the buffer allocation. As a result, they become "stuck" in the contract, impossible for investors to purchase during the sale period, which contradicts the stated purpose of the saleAllocation amount.
informational Issues | 3 findings
Pending
#1 informational Issue
Function that are not used (Dead code).
It is recommended to remove the unused code from the contract.
Pending
#2 informational Issue
Remove safemath library
The compiler version above 0.8.0 has the ability to control arithmetic overflow/underflow. It is recommended to remove the unwanted code in order to avoid high gas fees.
Pending
#3 informational Issue
Floating pragma solidity version.
Adding the constant version of solidity is recommended, as this prevents the unintentional deployment of a contract with an outdated compiler that contains unresolved bugs.