Quantum Audit Logo

Is Peppin Safe?

On-chain security analysis — is it a scam or legit?

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

Peppin PEPPIN
0xa816…7777
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 today 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The FlapTaxTokenV3 contract implements an upgradeable ERC20 token with a dynamic tax mechanism and a multi-state pool system. It leverages OpenZeppelin's upgradeable contracts and gas-efficient storage. Key findings include a high-severity reentrancy vulnerability in the tax liquidation logic and a denial-of-service risk due to unhandled external call reverts. Centralized control by the owner over critical state transitions and potential storage collision risks during upgrades are also noted. The provided code for `_liquidateTax` was truncated, limiting full analysis of its conditions.

2 High2 Medium1 Low1 Informational
Volume 24h
$87.7K
Liquidity
$49.1K
Price
$0.0002128
Token Age
19d
Top 10 Holders
33.6%

Security Findings

2 High2 Med1 Low1 Info
High

Reentrancy Vulnerability in `_liquidateTax`

H-01The `_liquidateTax` function, called during every `_transfer`, modifies the `notLiquidating` state variable to `false` *before* making external calls to `ITaxProcessor(taxProcessor).processTax` and `IDividend(dividendContract).distributeDividends`. It resets `notLiquidating` to `true` *after* these calls. A malicious `taxProcessor` or `dividendContract` could re-enter the `_transfer` function (and thus `_liquidateTax`) while `notLiquidating` is `false`. This could lead to unexpected behavior, such as multiple liquidations within a single transaction, or other state manipulation if the re-entered logic relies on `notLiquidating` to prevent concurrent execution.
IssueThe `_liquidateTax` function, called during every `_transfer`, modifies the `notLiquidating` state variable to `false` *before* making external calls to `ITaxProcessor(taxProcessor).processTax` and `IDividend(dividendContract).distributeDividends`. It resets `notLiquidating` to `true` *after* these calls. A malicious `taxProcessor` or `dividendContract` could re-enter the `_transfer` function (and thus `_liquidateTax`) while `notLiquidating` is `false`. This could lead to unexpected behavior, such as multiple liquidations within a single transaction, or other state manipulation if the re-entered logic relies on `notLiquidating` to prevent concurrent execution.
FixImplement a Checks-Effects-Interactions pattern. Move the external calls to `taxProcessor` and `dividendContract` *after* all state changes, including resetting `notLiquidating` to `true`. Consider using a reentrancy guard if complex interactions are unavoidable.
StatusUnresolved
High

Denial of Service via External Call Reverts

H-02The `_liquidateTax` function, which is called on every token transfer, makes external calls to `ITaxProcessor(taxProcessor).processTax` and `IDividend(dividendContract).distributeDividends`. If either of these external contracts reverts for any reason (e.g., misconfiguration, intentional attack, or unexpected state), the entire `_transfer` transaction will revert. This could lead to a denial of service, preventing all token transfers and potentially locking funds within the contract.
IssueThe `_liquidateTax` function, which is called on every token transfer, makes external calls to `ITaxProcessor(taxProcessor).processTax` and `IDividend(dividendContract).distributeDividends`. If either of these external contracts reverts for any reason (e.g., misconfiguration, intentional attack, or unexpected state), the entire `_transfer` transaction will revert. This could lead to a denial of service, preventing all token transfers and potentially locking funds within the contract.
FixImplement robust error handling for external calls. Consider using `try/catch` blocks to gracefully handle reverts from `taxProcessor` and `dividendContract`, allowing transfers to proceed even if tax processing or dividend distribution fails. Alternatively, ensure these external contracts are highly reliable and audited, or design the system to allow the owner to disable/change them in case of issues.
StatusUnresolved
Medium

Centralized Control over Critical State Transitions

M-01The `startMigration` and `finalizeMigration` functions, which control the `PoolState` transitions from `BondingCurve` to `Migrating` and then to `TaxEnforcedAntiFarmer`, are protected by the `onlyOwner` modifier. This grants significant centralized control to the contract owner over the token's operational state, including when taxes are enforced and anti-farmer mechanisms are activated. While common for initial phases, this centralization could pose a risk if the owner's key is compromised or acts maliciously.
IssueThe `startMigration` and `finalizeMigration` functions, which control the `PoolState` transitions from `BondingCurve` to `Migrating` and then to `TaxEnforcedAntiFarmer`, are protected by the `onlyOwner` modifier. This grants significant centralized control to the contract owner over the token's operational state, including when taxes are enforced and anti-farmer mechanisms are activated. While common for initial phases, this centralization could pose a risk if the owner's key is compromised or acts maliciously.
FixFor long-term decentralization and security, consider transitioning critical administrative functions to a multi-signature wallet or a decentralized autonomous organization (DAO) governance mechanism. Clearly document the owner's responsibilities and the implications of their control.
StatusUnresolved
Medium

Potential for Storage Collisions in Future Upgrades

M-02The contract uses a `PackedPoolState` struct to optimize gas usage by packing multiple state variables into a single storage slot. While efficient, modifying the `PackedPoolState` struct (e.g., changing the order, type, or adding new fields) in a future upgrade could lead to storage collisions if not handled with extreme care. This could corrupt existing state variables, leading to unexpected behavior or loss of funds.
IssueThe contract uses a `PackedPoolState` struct to optimize gas usage by packing multiple state variables into a single storage slot. While efficient, modifying the `PackedPoolState` struct (e.g., changing the order, type, or adding new fields) in a future upgrade could lead to storage collisions if not handled with extreme care. This could corrupt existing state variables, leading to unexpected behavior or loss of funds.
FixWhen performing upgrades, strictly adhere to the OpenZeppelin UUPS storage layout guidelines. New state variables should only be appended to the end of the contract's storage. If changes to `PackedPoolState` are necessary, consider a migration strategy or ensure that the new struct layout is fully compatible with the old one, which is often difficult to guarantee without careful planning and testing.
StatusUnresolved
Low

Lack of Pause Mechanism

L-01The contract implements complex tax and state transition logic, and relies on external contracts for tax processing and dividend distribution. In the event of an emergency, such as a critical bug, an exploit in an external dependency, or a market manipulation attempt, there is no mechanism for the owner to temporarily pause transfers or critical operations. This could exacerbate losses or allow an attack to continue unchecked.
IssueThe contract implements complex tax and state transition logic, and relies on external contracts for tax processing and dividend distribution. In the event of an emergency, such as a critical bug, an exploit in an external dependency, or a market manipulation attempt, there is no mechanism for the owner to temporarily pause transfers or critical operations. This could exacerbate losses or allow an attack to continue unchecked.
FixConsider implementing a `PausableUpgradeable` mechanism (e.g., from OpenZeppelin) to allow the owner (or a designated emergency multisig) to pause critical functions like `_transfer` in an emergency. This provides a crucial safety net, though it introduces another point of centralization.
StatusUnresolved
Info

Truncated Code for `_liquidateTax` Function

I-01The provided source code for the `_liquidateTax` function is truncated, specifically the condition `taxAmount >= currentPoolState.liqu...`. This prevents a full security analysis of the complete liquidation logic, including the exact conditions under which `ITaxProcessor` and `IDividend` calls are made.
IssueThe provided source code for the `_liquidateTax` function is truncated, specifically the condition `taxAmount >= currentPoolState.liqu...`. This prevents a full security analysis of the complete liquidation logic, including the exact conditions under which `ITaxProcessor` and `IDividend` calls are made.
FixProvide the complete and untruncated source code for a comprehensive audit.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract demonstrates good use of OpenZeppelin upgradeable standards and gas optimization with `PackedPoolState`. However, a significant reentrancy vulnerability exists in the `_liquidateTax` function, where external calls are made before state updates are finalized, potentially allowing malicious re-entry (7.2 Code Security). Additionally, the reliance on external contracts for tax processing and dividend distribution introduces a denial-of-service risk if these dependencies revert, impacting all token transfers (7.2 Code Security).

GovernanceMedium4/10

The economic model incorporates dynamic tax rates and state-based transitions, managed by an `OwnableUpgradeable` contract. The owner has centralized control over critical state changes like migration phases, which could pose a risk if the owner's key is compromised (7.3 Access Control, 7.5 Governance). The initial token distribution mints all `maxSupply` to the deployer, which is a common but centralized starting point (7.4 Economic).

UpgradesLow8/10

The contract correctly utilizes OpenZeppelin's UUPS proxy pattern, including `Initializable` and `_disableInitializers` in the constructor, ensuring proper upgradeability (7.1 Architecture, 7.7 Upgrades). The `OwnableUpgradeable` pattern restricts upgrade authorization to the owner. However, the use of a `PackedPoolState` struct requires extreme caution during future upgrades to prevent storage collisions and data corruption (7.7 Upgrades).

Security Checklist

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

Holder Composition

33.6% in top 10
21.6% in wallets12.0% in contracts
Effective Concentration26.4%

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

$49.1K

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

Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

2 addresses
Deployer
0x855d…82f1
Unlocked LP Held By
0x14e5…be4a

No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.

What Raised This Score

9 factors
  • Top-10 concentration > 20% (33.6% total → 26.4% effective; 21.6% in EOAs, 12.0% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $50k ($49,068 across 1 pairs — thin market)
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • Token age < 30 days (still settling)
  • 2 High finding(s) from audit
  • 2 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
CookieHigh RiskCrossHigh Risk永生果蝇High RiskChainOpera AI (COAI)High RiskYooldo Games (ESPORTS)High RiskAKEHigh Risk

Would You Like a More Detailed Audit of Peppin?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit