Quantum Audit Logo

Is VortexPad a Scam?

Early-stage security check — honeypot & rug-pull analysis

Is this your token? Publish your own audit on this page →

VortexPad VPAD
0x535b…529e
BNB Chain
Not verifiedThis record has not gone through deep verification and is not being monitored. The score is a dated snapshot — the token’s risk can change at any time.Own this token? Put it under verification →
Last checked 5d ago 1 audit on record New Launch · 18h old
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The VPAD token contract implements standard ERC20 functionality with custom buy/sell taxes and integration with a dividend distribution system. The audit identified several high-severity issues, primarily concerning the unhandled accumulation of tax funds within the contract, critical reliance on external, unaudited dependencies, and the absence of an emergency pause mechanism. These findings introduce significant economic and operational risks to the protocol.

4 High1 Medium1 Low
! Early-stage analysis. This token has limited on-chain history (18h old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$40.6K
Liquidity
$39.7K
Price
$0.00005566
Token Age
18h
Top 10 Holders
76.0%

Security Findings

4 High1 Med1 Low
High

Unhandled Tax Accumulation in Contract

H-01The `_update` function collects buy and sell taxes (3%) by transferring them to `address(this)` (the VPAD token contract itself). However, there is no mechanism implemented to retrieve, distribute, or burn these accumulated tokens. This means the collected taxes are effectively locked within the contract, reducing the circulating supply without a clear benefit to the ecosystem or token holders, representing a significant economic design flaw.
IssueThe `_update` function collects buy and sell taxes (3%) by transferring them to `address(this)` (the VPAD token contract itself). However, there is no mechanism implemented to retrieve, distribute, or burn these accumulated tokens. This means the collected taxes are effectively locked within the contract, reducing the circulating supply without a clear benefit to the ecosystem or token holders, representing a significant economic design flaw.
FixImplement a mechanism to manage accumulated taxes. Options include: 1) a function to burn the collected tokens, 2) a function to transfer them to a designated treasury address, or 3) a governance-controlled withdrawal mechanism. Ensure the chosen method aligns with the project's economic model.
StatusUnresolved
High

Critical External Dependency on IDeployerRegistry

H-02The contract relies on `IDeployerRegistry` to resolve critical addresses such as `mainPool`, `taxProcessor`, and `dividend` during construction. The security, immutability, and correct configuration of the `IDeployerRegistry` are paramount. If `IDeployerRegistry` is compromised or returns incorrect addresses, it could lead to funds being sent to malicious contracts, incorrect tax calculations, or a broken dividend mechanism, impacting the entire protocol.
IssueThe contract relies on `IDeployerRegistry` to resolve critical addresses such as `mainPool`, `taxProcessor`, and `dividend` during construction. The security, immutability, and correct configuration of the `IDeployerRegistry` are paramount. If `IDeployerRegistry` is compromised or returns incorrect addresses, it could lead to funds being sent to malicious contracts, incorrect tax calculations, or a broken dividend mechanism, impacting the entire protocol.
FixThoroughly audit the `IDeployerRegistry` contract and its control mechanisms. Ensure it is highly secure, immutable, or governed by a robust, decentralized process. Document the audit status and control of all registered addresses.
StatusUnresolved
High

Critical External Dependency on ICakeDividend

H-03The `_syncShare` function interacts with the `ICakeDividend` contract to update user shares. The economic model, security, and reentrancy protections of `ICakeDividend` are critical to the overall system's integrity. A vulnerability in `ICakeDividend` (e.g., reentrancy, access control flaws, or economic exploits) could directly impact `VPAD` token holders, potentially leading to incorrect dividend distributions or other exploits.
IssueThe `_syncShare` function interacts with the `ICakeDividend` contract to update user shares. The economic model, security, and reentrancy protections of `ICakeDividend` are critical to the overall system's integrity. A vulnerability in `ICakeDividend` (e.g., reentrancy, access control flaws, or economic exploits) could directly impact `VPAD` token holders, potentially leading to incorrect dividend distributions or other exploits.
FixConduct a comprehensive security audit of the `ICakeDividend` contract, focusing on reentrancy guards, access control, and its economic model. Ensure its behavior aligns with expected dividend distribution mechanics and that it is resilient to known attack vectors.
StatusUnresolved
High

Lack of Emergency Pause Mechanism

H-04The contract lacks an emergency pause mechanism. In the event of a critical vulnerability discovery within the VPAD contract itself or any of its integrated external dependencies (e.g., `IDeployerRegistry`, `ICakeDividend`), there is no way to temporarily halt transfers or tax collection to prevent further damage or mitigate ongoing exploits. This significantly limits incident response capabilities.
IssueThe contract lacks an emergency pause mechanism. In the event of a critical vulnerability discovery within the VPAD contract itself or any of its integrated external dependencies (e.g., `IDeployerRegistry`, `ICakeDividend`), there is no way to temporarily halt transfers or tax collection to prevent further damage or mitigate ongoing exploits. This significantly limits incident response capabilities.
FixImplement a robust pause mechanism, ideally controlled by a multi-signature wallet or a decentralized governance system. This mechanism should allow for temporary suspension of critical operations (e.g., transfers, tax collection) in emergencies, providing time to address severe issues.
StatusUnresolved
Medium

Centralized Control over Tax Activation

M-01The `taxActive` flag, which controls the application of buy/sell taxes and enables transfers involving the `mainPool`, can only be set by the `launcher` address via the `activate()` function. Until `activate()` is called, `mainPool` transfers are blocked. This introduces a single point of control and potential for delayed activation or censorship if the `launcher` address is compromised, becomes unresponsive, or acts maliciously.
IssueThe `taxActive` flag, which controls the application of buy/sell taxes and enables transfers involving the `mainPool`, can only be set by the `launcher` address via the `activate()` function. Until `activate()` is called, `mainPool` transfers are blocked. This introduces a single point of control and potential for delayed activation or censorship if the `launcher` address is compromised, becomes unresponsive, or acts maliciously.
FixConsider decentralizing the activation mechanism, perhaps through a multi-signature wallet, a time-locked function, or a community governance vote. Clearly communicate the operational plan for activation to the community.
StatusUnresolved
Low

Potential for Unintended Tax Exemption for `taxProcessor`

L-01The `taxProcessor` address is explicitly exempted from all buy and sell taxes (`if (from != taxProcessor)`). While this might be an intentional design choice for specific operational flows (e.g., for a liquidity provider or a specific protocol function), it means any tokens moved by or through the `taxProcessor` will bypass the tax mechanism. This could be abused if the `taxProcessor` address is compromised or if its role is not clearly defined and restricted.
IssueThe `taxProcessor` address is explicitly exempted from all buy and sell taxes (`if (from != taxProcessor)`). While this might be an intentional design choice for specific operational flows (e.g., for a liquidity provider or a specific protocol function), it means any tokens moved by or through the `taxProcessor` will bypass the tax mechanism. This could be abused if the `taxProcessor` address is compromised or if its role is not clearly defined and restricted.
FixClearly document the intended role and security measures for the `taxProcessor` address. Ensure its permissions are minimal and its operations are transparent. If its role is purely for internal protocol mechanics, consider if the exemption is strictly necessary or if a more granular control is warranted.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract demonstrates good adherence to OpenZeppelin standards for ERC20 and ERC20Permit, enhancing code reliability (7.2 Code Security). However, it exhibits significant technical risks due to its heavy reliance on external contracts, `IDeployerRegistry` and `ICakeDividend`, whose security and behavior are critical but not part of this audit scope (7.6 External). A major concern is the lack of an emergency pause mechanism, which limits the ability to respond to critical vulnerabilities or exploits in integrated systems (7.8 Operations).

GovernanceHigh1/10

The tokenomics include a fixed supply and a buy/sell tax mechanism (7.4 Economic). A critical economic flaw is that collected taxes accumulate within the token contract itself without any mechanism for retrieval, distribution, or burning, effectively locking these funds (7.4 Economic). The `launcher` address holds centralized control over the initial activation of taxes and `mainPool` transfers, posing a single point of failure for initial protocol functionality (7.3 Access Control, 7.5 Governance).

UpgradesMedium6/10

The VPAD contract is not designed as an upgradeable proxy, meaning its logic is immutable once deployed (7.7 Upgrades). This design choice inherently carries a high risk for long-term projects, as any discovered vulnerabilities or required feature enhancements would necessitate a complete redeployment and token migration, which is a complex and risky process (7.7 Upgrades).

Security Checklist

4/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

76.0% in top 10
13.2% in wallets62.9% in contracts
Effective Concentration38.3%

Share held by contracts — treasury, vesting, bridge or staking — is discounted against share held by wallets when the score is computed: a contract cannot decide to sell the way an anonymous holder can, though it can still be drained or voted to sell. Effective concentration is the figure the risk score is actually calculated from.

Liquidity Depth

$39.7K across 2 pairs

The risk score reads depth across every pair. The volume figure and the volume-to-liquidity ratio elsewhere on this page describe only the pair this audit analysed, so the two are not directly comparable.

LP Distribution

LP Locked100.0% · Null Address, PinkLock02

Key Addresses

1 addresses
Deployer
0xc129…a981

What Raised This Score

7 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Top-10 concentration > 30% (76.0% total → 38.3% effective; 13.2% in EOAs, 62.9% in contracts — moderate)
  • Liquidity < $50k ($39,725 across 2 pairs — thin market)
  • Token age < 24h (brand new — bot activity, unproven)
  • 4 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit

Each factor is an on-chain fact recorded at the time of this analysis. The score is computed from them by a deterministic function, so the same contract returns the same score for anyone who runs the audit. How scores are computed

Related Audits

6 more on the record
United Stables (U)Critical RiskCATCritical RiskAIOZ Network (AIOZ)Critical RiskNVIDIA Corp (NVDAB)Critical RiskGiggle Tom (TOM)Critical RiskDexeCritical Risk

Would You Like a More Detailed Audit of VortexPad?

This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.

Get Detailed Audit