RadarDrop Info
In the dynamic and ever-evolving world of cryptocurrency, airdrop farming has become a pivotal strategy for user acquisition and project promotion. However, the current process is riddled with challenges: identifying legitimate airdrop opportunities is both complex and time-consuming, the qualification steps are often intricate and daunting, and there is a constant risk of scams. These factors render airdrop farming inefficient and difficult for both seasoned and novice participants. Addressing these challenges is crucial because airdrop farming is key to the adoption and success of emerging Web3 projects. Enabling users to easily and securely participate in airdrop campaigns benefits both users and projects by fostering a more engaged and supportive community.
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 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 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.
Ownership Privileges
- The functions
set_receiver,pause, andunpausecan only be executed by the designated owner, granting them control over payment routing and system state. - The initialization function
initializeestablishes the owner and receiver accounts, ensuring proper setup of payment processing parameters. - The owner has complete control over pausing the system and updating the receiver address, providing emergency stop functionality and payment routing flexibility.
The audited smart contract is a payment processor system built using Anchor on the Solana blockchain. The code implements a basic payment processor with administrative controls and proper event emission. The use of PDAs and account validation is generally good. Notably, the critical token account ownership validation issue has been resolved in the latest version.
Throughout the review, the contract's structure and adherence to Anchor conventions have been sound. However, several potential improvements were identified:
- Token Account Validation: While the primary token account ownership check is now in place—and explicit mint validation on both payer and receiver accounts has been added—further enhancements (such as validating token decimals and enforcing amount boundaries) could improve the robustness of token transfers.
- Account Management: The contract lacks functionality for account closure and ownership transfer, which limits administrative flexibility and rent recovery options.
- PDA Architecture: The current single-seed PDA structure limits scalability by allowing only one payment processor instance per program deployment. Consider incorporating a unique element (for example, the payer's public key) in the PDA derivation if multiple instances are desired.
- Input Validation: Additional validation of payment parameters (especially regarding token amounts and decimals) would further secure the payment processing operations.
- Authority Controls: Although sensitive operations are currently restricted to the designated owner, implementing additional safety measures—such as timelock mechanisms or multi-signature controls—could enhance overall security.
This audit report focuses on a security analysis and did not include exhaustive functional or unit testing.
Note - This audit report consists of a security analysis of the RadarDrop smart contract. It did not include functional testing (or unit testing) of the contract's logic. Moreover, only one contract associated with the project was audited; other contracts associated with the project were not reviewed by our team. We recommend that investors perform their own research before investing.
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
/
Findings and Audit result
high Issues | 1 findings
Resolved
#1 high Issue
Verification of the Receiver’s Token Account
In the pay instruction the PaymentProcessor’s configuration includes a designated receiver (stored as a Pubkey) that must receive tokens. Although the payment_processor account is constrained (via has_one = receiver) to match a provided receiver account, the CPI transfer call uses a separate account—receiver_token_account—as the destination for tokens. There is no check that the owner of receiver_token_account matches the configured receiver. This gap means that a payer could supply any token account as the destination—even one not controlled by the intended recipient—thus diverting funds away from the proper beneficiary.
low Issues | 2 findings
Resolved
#1 low Issue
Lack of Explicit Mint Consistency Check for the Receiver’s Token Account
The program checks that the mint of the payer’s token account matches the PaymentProcessor’s configured mint. However, there is no explicit check that the receiver_token_account holds tokens of the same mint. Although the underlying SPL Token program will reject a transfer between accounts with mismatched mints, adding an explicit check in your program logic would improve clarity and could provide earlier failure with a clearer error message.
Resolved
#2 low Issue
Documentation Mismatch: Incorrect Account Size Comment
The comment in the PaymentProcessor account definition indicates that the total account size is “73 bytes”. However, the actual size computed from the fields is 8 (discriminator) + 32 (owner) + 32 (receiver) + 32 (mint) + 1 (paused) = 105 bytes. Although the code correctly uses the PaymentProcessor::SIZE constant (which equals 105 bytes), the incorrect comment may lead to confusion or miscalculations during maintenance or future modifications.
informational Issues | 2 findings
Acknowledged
#1 informational Issue
PDA Derivation Limitation for PaymentProcessor Accounts
The PaymentProcessor account is initialized using a fixed seed ([b"payment_processor"]). This design forces all instances of the PaymentProcessor to use the same PDA. If the intent is to support only one payment processor per deployed program then this is acceptable; however, if multiple PaymentProcessor instances are desired (for example, one per owner), this design will prevent that.
Resolved
#2 informational Issue
Inadequate Decimal Handling
The pay instruction accepts amounts as raw u64 without consideration of token decimals. This could lead to precision issues or user confusion.