PixelPump Info
Welcome to PixelPump, where creativity meets DeFi. PixelPump lets you create, customize, and launch unique pixel tokens on the Solana blockchain. Design your pixel on a 30x30 grid, name it, and showcase it to the world. Each pixel becomes a tradeable asset with its own token terminal, following a bonding curve that adjusts its value based on demand. When the curve is complete, creators earn a 2 SOL reward, and the pixel launches on Raydium with permanently locked liquidity. PixelPump transforms simple art into valuable digital assets, bridging the gap between imagination and decentralized finance.
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.
Security Assessments
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 can set high fees
Contract owner is able to set fees above 25%. Very high fees can also prevent token transfer.
Contract cannot be locked
Owner cannot lock any user funds.
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 upgradeable
The contract uses a proxy pattern or similar mechanism, enabling future upgrades. This can introduce risks if the upgrade mechanism is not securely managed.
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.
Contract Analysis
The audit of the PixelPump smart contract has revealed a modular design built on the Anchor framework, with well-structured modules for configuration, token creation, bonding curve operations, staking functionalities, and fund management. Most issues have been resolved; however, some medium concerns remain:
Key findings include:
- Inconsistent Configuration Update Mechanism: The
update_configfunction permits modifications to several parameters after the bonding curve has been initialized. Changing values such as reserve levels or fee parameters post-token creation can cause inconsistencies between the active bonding curve state and the updated configuration. It is recommended to either restrict updates to parameters that affect pricing after token creation or implement a mechanism to ensure that such updates do not violate existing invariants. - Potential Overflow in Reward Multiplication: The multiplication of
user_stake_amount * epoch_rewardcould overflow if the values are unexpectedly high, as there is no explicit overflow check. Although checked arithmetic methods are used, the code still unwraps their results. If an overflow occurs, the unwrap calls will trigger a panic rather than handling the error gracefully. Consider using more robust error handling or saturating arithmetic. - Unchecked UTF-8 Conversion in Token Metadata Creation: In the
CreateToken::applyfunction, the contract uses.unwrap()when converting the name, symbol, and URI from byte vectors to UTF‑8 strings. This means that if the inputs aren’t valid UTF‑8, the contract will panic. Proper error handling or input validation is needed to address this potential runtime error. - Unbounded Growth of Epoch Data in BTreeMap Structures: The use of
BTreeMapfor storing rewards and total stakes per epoch can lead to unbounded growth over time, increasing on-chain storage requirements and processing delays. It is advisable to implement a pruning or capping mechanism to limit the number of epochs stored or periodically consolidate old epoch data.
Overall, while the PixelPump smart contract has a strong modular foundation and innovative features, addressing these remaining issues will significantly improve its reliability, security, and long-term operational efficiency.
Ownership Privileges
The PixelPump smart contract grants significant privileges to the admin (owner). Key owner privileges include:
- Configuration Updates: The admin can update critical configuration parameters through the
update_configfunction. This includes the ability to change fee settings, reserve values, token total supply, and the fee recipient address, which directly affect token pricing and staking reward distribution. - Fund Withdrawal: Only the admin is authorized to execute the
withdrawandwithdraw_stake_holderfunctions, enabling the extraction of SOL and tokens from both the bonding curve vault and the staking module. This centralized control over funds requires strong governance measures. - Control Over Token Economics and Staking: With the ability to adjust configuration parameters, the admin can modify the economic model underlying the token and the staking reward mechanism, which underscores the importance of robust administrative oversight.
- Upgrade and Governance: While upgradeability is managed externally via Solana’s upgradeable loader, the admin’s role is central to contract governance. Transparent governance practices and rigorous checks on administrative actions are essential to mitigate potential misuse.
Note - This audit report presents a security analysis of the PixelPump smart contract. Functional or unit testing of the contract’s logic was not conducted, and only the audited token contract is covered. Other associated contracts were not audited. We recommend that investors perform their own research before making investment decisions.
Files and details
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Findings and Audit result
critical Issues | 1 findings
Resolved
#1 critical Issue
Incorrect Epoch Calculation Due to Operator Precedence
In functions for staking, unstaking, and claiming rewards, the epoch is calculated using an expression that subtracts a divided value rather than dividing the difference between the current time and the start time.
high Issues | 3 findings
Resolved
#1 high Issue
Potential Division by Zero in Buy Function
In the Buy::apply function, the SOL cost is calculated as sol_amount = ((min_amount * virtual_sol_reserves) / (virtual_token_reserves - min_amount)) + 1. If min_amount equals virtual_token_reserves, the denominator becomes zero, resulting in a runtime error.
Resolved
#2 high Issue
Lack of Invariants in Configuration Parameters
Neither the CreateConfig nor the UpdateConfig functions enforce that initial_virtual_token_reserves is greater than initial_real_token_reserves. An improper setting may lead to division by zero or inconsistent bonding curve behavior during token purchases.
Resolved
#3 high Issue
Insufficient User Stake Check in Unstake Operation
The unstake function only checks that the unstake amount is less than the stake holder’s total stake, without verifying that the user’s individual staked amount is sufficient.
medium Issues | 2 findings
Acknowledged
#1 medium Issue
Inconsistent Configuration Update Mechanism
The UpdateConfig function permits modifications to several parameters after the bonding curve has been initialized. Changing values such as reserve levels or fee parameters post-token creation can cause inconsistencies between the active bonding curve state and the updated config.
Acknowledged
#2 medium Issue
Potential Overflow in Reward Multiplication
The multiplication of user_stake_amount * epoch_reward could overflow if the values are unexpectedly high, as there is no explicit overflow check.
low Issues | 2 findings
Acknowledged
#1 low Issue
Unchecked UTF-8 Conversion in Token Metadata Creation
In CreateToken::apply, the contract uses .unwrap() when converting the name, symbol, and URI from a byte vector to a UTF‑8 string. This can lead to a panic if the input is not valid UTF‑8.
Resolved
#2 low Issue
Division-by-Zero and Rounding Concerns in Reward Calculation
Reward calculations involve division operations that use epoch total stakes as the denominator. Although there is a check for a nonzero denominator, careful handling is needed to avoid division-by-zero or rounding issues in edge cases.
optimization Issues | 1 findings
Acknowledged
#1 optimization Issue
Unbounded Growth of Epoch Data in BTreeMap Structures
The use of BTreeMap for storing rewards and total stakes per epoch can lead to unbounded growth over time, increasing on-chain storage requirements and potential processing delays.