MaxFund Info
MaxFund is a groundbreaking decentralized donation protocol built on the Binance Smart Chain (BSC). It introduces Perpetual Referral ID Bots (PRIB) and self-executing smart contracts to create a fully automated, transparent, and self-sustaining member-to-member exchange ecosystem where forward-looking participants give and receive donations turn by turn without failure, backed and enforced by code, not. human emotions.
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.
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 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 admin can set the batch size to any arbitrary value.
- The admin can pause/unpause the RB ID creation.
- The admin can set the cooldown period to any arbitrary value.
Note - This Audit report consists of a security analysis of the MaxFund 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 MaxFund 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
high Issues | 1 findings
Acknowledged
#1 high Issue
Denial of Service via Synchronous, Cascading Reinvestments.
The system's architecture contains a critical flaw where a single registration can trigger an unbounded chain of recursive reinvestments within the Team X6 matrix, leading to a guaranteed Denial of Service (DoS) due to exceeding the block gas limit. The registrationExt function initiates a call chain that eventually reaches updateX6ReferrerSecondLevel. This function is designed to recursively call updateX6Referrer whenever a user's matrix is filled, in order to "reinvest" them under their own upline. This synchronous, recursive pattern is fundamentally unsafe on the blockchain. For Example, When NewUser calls registrationExt to register under their referrer D, the transaction begins a catastrophic, cascading failure. The initial placement of NewUser fills the sixth and final slot in D's Level 1 matrix, which immediately triggers the updateX6ReferrerSecondLevel function to process a "reinvestment" for D. Instead of queuing this action, the function synchronously makes a recursive call to updateX6Referrer to place D into their own referrer C's matrix. Since C's matrix was also pre-filled to five of six slots, this placement of D immediately fills it, which in turn triggers another synchronous, recursive call to place C under B. This chain reaction continues up the referral leg within the single transaction, with each recursive reinvestment adding a significant gas cost for storage writes and function calls. By the time the cascade attempts to reinvest B under A, the accumulated gas from processing multiple, nested matrix reinvestments has already exceeded the block's gas limit, causing the entire transaction to fail and revert. As a result, NewUser's registration is rejected, their gas fee is consumed, and it becomes impossible for anyone to join this active part of the network.
medium Issues | 3 findings
Resolved
#1 medium Issue
Reentrancy Vulnerabilities in Core Registration and Level-Up Logic.
The contract contains a systemic and critical reentrancy vulnerability that manifests in its two most important state-changing functions: user registration and level purchasing. Both functions are fundamentally insecure because they violate the Checks-Effects-Interactions (CEI) security pattern. They first perform a check (e.g., if a user exists or a level is active), then make an external call to the USDT token contract, and only after that interaction do they apply the state-changing effect (e.g., marking the user as registered or the level as active). This flawed Check -> Interact -> Effect sequence creates a critical window where a malicious token contract can re-enter the function it was called from, bypass the initial security check, and trigger an infinite recursive loop. An attacker, using a malicious token contract, calls either registrationExt or buyNewLevel. The target function checks if the action is allowed (e.g., !users[attacker].isExist or !users[attacker].activeX6Levels[level]), which passes. The function then calls the attacker's malicious token, which immediately calls back into the original function. Because the crucial state change (isExist = true or activeX6Levels[level] = true) has not yet been executed, the security check passes a second time, triggering an infinite loop and causing the transaction to fail with an out-of-gas error, permanently bricking that feature for all users.
Resolved
#2 medium Issue
Funneling Community Funds to the Admin.
The contract contains a severe economic design flaw that violates user trust. The system-created Robot IDs are all hard-coded to have the admin as their referrer. When these bots, which are funded by a pool of community-generated revenue, earn certain matrix rewards, those rewards are paid out directly to the admin's personal wallet. This is not a decentralized system; it is a mechanism for the admin to use the system's own funds to create a fleet of agents that perpetually siphon profits back to a centralized owner. The rbIdPool (filled from other users' matrix payments) funds the creation of a Robot ID. In createRbId, its referrer is set to admin. Later, in fillGlobalX6Slot, when this bot fills its 5th slot, the payment is sent to its inviter—the admin.
Resolved
#3 medium Issue
Missing Input Validation on Admin Functions
The setRbIdBatchSize and setRbIdCooldownPeriod function, are missing input validation. This allows the admin to set parameters to dangerous or nonsensical values, which can lead to a permanent Denial of Service (DoS) or unintentionally disable core features. The setRbIdBatchSize function lacks an upper-bound check, which is the most severe issue. It permits the admin to set a batch size so large that it guarantees the gas cost of the RB ID creation loop will exceed the block limit, effectively bricking the registration function for all future users. The setRbIdCooldownPeriod function also lacks a sanity check, allowing for an absurdly long cooldown that could permanently disable the RB ID feature by mistake.
low Issues | 1 findings
Resolved
#1 low Issue
Missing events arithmetic
Emit all the critical parameter changes.