GenZ Info
GENZVerse represents a new paradigm in Web3 platforms, combining cutting-edge blockchain technology with user-centric design to create an ecosystem that is both powerful and accessible. Our mission is to bridge the gap between complex blockchain technology and mainstream adoption, making Web3 accessible to everyone while maintaining the core principles of decentralization, security, and transparency.
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 owner can set or replace the GNZ token address at any time with no timelock and no one-time lock.
- The owner can set or replace the DEX pair address at any time with no timelock and no one-time lock.
- The owner can propose a new business contract address.
- The owner can execute a pending business contract change after the 2-day timelock has elapsed.
- The owner can cancel a pending business contract proposal before execution.
- The owner can set the swap slippage tolerance to any value between 90 and 100 basis points (i.e., between 0% and 10% maximum slippage).
Note - This Audit report consists of a security analysis of the GenZLPController 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 GenZ 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
Resolved
#1 high Issue
buyFromLP() Permanently Destroys User USDT During 365-Day Lock Period
During the 365-day lock period, buyFromLP() at line 222 accepts usdtAmount via usdt.transferFrom() (minimum $10, maximum $100,000 enforced at lines 215–216), at lines 230–236 swaps the full amount for GNZ tokens via the DEX router, then at line 242 sends all received tokens to businessContract via token.transfer(businessContract, tokensReceived). IGenZBusiness(businessContract).receiveCommunityTokens() — called in processLP() at line 208 — is never called from buyFromLP(). GenZVerse receives tokens with no accounting update, no credit entry for the caller, and no on-chain link between the incoming tokens and the paying user. The emitted DirectPurchase event at line 247 records the call but has zero economic effect. Every user who calls this function during the first year loses their full USDT payment unconditionally with no recourse.
medium Issues | 1 findings
Resolved
#1 medium Issue
setToken() and setPair() Have No Address Lock
Unlike GenZVerse which enforces one-time tokenLocked/lpLocked flags, and GenZReservePool which uses require(address(token) == address(0), "TOKEN_ALREADY_SET"), GenZLPController allows the owner to replace the GNZ token and DEX pair addresses at any time with no timelock and no one-time lock. Since 30% of every purchase routes through this controller via lp.processLP() at GenZVerse line 410, the owner can substitute a malicious token that returns true on burn() without burning (allowing unlimited fake burn events while retaining tokens), or substitute a fake pair returning manipulated reserve ratios to control all price oracle readings used for token allocation in _getValidatedPrice().
informational Issues | 4 findings
Resolved
#1 informational Issue
Permanently Frozen Ownership — pendingOwner Declared, Zero Transfer Functions Exist
address public pendingOwner is declared at line 54 and event OwnershipTransferInitiated(address indexed currentOwner, address indexed pendingOwner) is declared at line 75. No transferOwnership() or acceptOwnership() function exists anywhere in GenZLPController. The two-step ownership pattern was scaffolded (variable declared, event declared) but never implemented. If the deployer wallet is compromised, the attacker permanently controls: setToken() and setPair() (rug vector HIGH-01), setSlippage() (allowing up to 10% MEV extraction), and proposeBusinessContract()/executeBusinessContractChange() (business contract redirection). No on-chain recovery path exists.
Resolved
#2 informational Issue
No Independent Pause Mechanism — buyFromLP() Cannot Be Stopped Without Protocol-Wide Collateral Damage
GenZVerse has pause()/unpause(). GenZToken has pause()/unpause(). GenZLPController has no pause mechanism. buyFromLP() — which destroys user USDT during the lock period (CRIT-03) — is publicly callable regardless of GenZVerse's pause state. When CRIT-03 is discovered, the only mitigation options are: pause GenZVerse (does not affect direct buyFromLP() calls), or pause GenZToken (bricks all token operations protocol-wide per HIGH-05 in GenZToken). No surgical pause for LP-specific operations exists.
Resolved
#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.
Resolved
#4 informational Issue
OwnershipTransferInitiated Event Declared but Can Never Be Emitted
pendingOwner at line 54 and OwnershipTransferInitiated at line 75 were declared for an ownership transfer pattern that was never implemented. The event cannot be emitted from any code path. The declared pendingOwner variable wastes a storage slot that is always zero.