Quantum Audit Logo

Is BUDDY - First Crypto Dog a Scam?

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

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

BUDDY - First Crypto Dog BUDDY
0x4e00…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 10d ago 1 audit on record New Launch · 9h old
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The FlapTaxTokenV3 contract is an upgradeable ERC20 token incorporating a dynamic tax mechanism and a multi-stage migration process. It leverages OpenZeppelin's upgradeable contracts for core functionalities and access control. The audit identified a potential reentrancy vulnerability in the tax liquidation logic, centralized control by the owner over critical state transitions, and susceptibility to MEV for time-dependent state changes. The contract demonstrates good code quality and adherence to upgradeability patterns, but requires careful review of external interactions and owner privileges.

1 High2 Medium1 Low1 Informational
! Early-stage analysis. This token has limited on-chain history (9h old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$381.4K
Liquidity
$57.0K
Price
$0.0003088
Token Age
9h
Top 10 Holders
31.4%

Security Findings

1 High2 Med1 Low1 Info
High

Potential Reentrancy in `_liquidateTax` Function

H-01The `_liquidateTax` function is called on every `_transfer` and is likely to perform external calls (e.g., to `ITaxProcessor`, `IDividend`, or a DEX via `v2Router`) to process collected taxes. The provided snippet shows a check for `currentPoolState.notLiquidating`, but it does not show how this flag is set to `false` at the beginning of the liquidation process and `true` at the end. If external calls are made before state updates or without a proper reentrancy guard, a malicious external contract could re-enter the `_transfer` or `_liquidateTax` function, potentially draining funds or manipulating contract state.
IssueThe `_liquidateTax` function is called on every `_transfer` and is likely to perform external calls (e.g., to `ITaxProcessor`, `IDividend`, or a DEX via `v2Router`) to process collected taxes. The provided snippet shows a check for `currentPoolState.notLiquidating`, but it does not show how this flag is set to `false` at the beginning of the liquidation process and `true` at the end. If external calls are made before state updates or without a proper reentrancy guard, a malicious external contract could re-enter the `_transfer` or `_liquidateTax` function, potentially draining funds or manipulating contract state.
FixImplement a robust reentrancy guard (e.g., OpenZeppelin's `ReentrancyGuard` or a custom mutex flag) around the `_liquidateTax` function, specifically covering any external calls. Ensure the `notLiquidating` flag is correctly managed: set to `false` at the very beginning of the liquidation logic and reset to `true` only after all external calls and state updates are complete.
StatusUnresolved
Medium

Centralized Control by Owner

M-01The contract inherits `OwnableUpgradeable`, granting a single owner address exclusive control over critical functions such as `startMigration` and `finalizeMigration`. These functions significantly alter the token's tax and transfer mechanics, moving it through different `PoolState`s. This centralization introduces a single point of failure, where a compromised owner key or a malicious owner could unilaterally change the token's behavior, potentially leading to economic instability or loss of user trust.
IssueThe contract inherits `OwnableUpgradeable`, granting a single owner address exclusive control over critical functions such as `startMigration` and `finalizeMigration`. These functions significantly alter the token's tax and transfer mechanics, moving it through different `PoolState`s. This centralization introduces a single point of failure, where a compromised owner key or a malicious owner could unilaterally change the token's behavior, potentially leading to economic instability or loss of user trust.
FixConsider implementing a multi-signature wallet (e.g., Gnosis Safe) for the owner address to distribute control and reduce the risk of a single point of failure. For highly sensitive operations like state migrations, introduce a time-lock mechanism to allow users sufficient time to react to impending changes.
StatusUnresolved
Medium

Time-Dependent State Changes Susceptible to MEV

M-02The `_liquidateTax` function modifies the `poolState` (e.g., from `TaxEnforcedAntiFarmer` to `TaxEnforced` or `TaxFree`) based on `block.timestamp` exceeding `taxExpirationTime` or `antiFarmerExpirationTime`. These time-based state transitions can have significant economic implications for users, as they directly affect tax rates. Malicious miners or sophisticated actors could exploit this by manipulating block timestamps within a small window or front-running transactions to trigger state changes at an opportune moment, potentially gaining an unfair advantage or causing adverse effects for other users.
IssueThe `_liquidateTax` function modifies the `poolState` (e.g., from `TaxEnforcedAntiFarmer` to `TaxEnforced` or `TaxFree`) based on `block.timestamp` exceeding `taxExpirationTime` or `antiFarmerExpirationTime`. These time-based state transitions can have significant economic implications for users, as they directly affect tax rates. Malicious miners or sophisticated actors could exploit this by manipulating block timestamps within a small window or front-running transactions to trigger state changes at an opportune moment, potentially gaining an unfair advantage or causing adverse effects for other users.
FixWhile `block.timestamp` is commonly used, be aware of its manipulability. If precise timing is critical and economic incentives for manipulation are high, consider alternative time sources (e.g., Chainlink Keepers or Oracles for time-based events) or implement a grace period after a state change is triggered to allow users to react, reducing the immediate impact of MEV.
StatusUnresolved
Low

Lack of Setter Functions for Critical External Contracts

L-01Several critical external contract addresses, including `taxProcessor`, `dividendContract`, `v2Router`, `quoteToken`, `mainPool`, and the `pools` mapping, are set only during the `initialize` function. While this ensures immutability after deployment, it also means that if any of these external dependencies need to be updated (e.g., due to a bug, a migration, or a strategic change), the entire `FlapTaxTokenV3` contract would require an upgrade. This reduces operational flexibility and increases the overhead for necessary updates.
IssueSeveral critical external contract addresses, including `taxProcessor`, `dividendContract`, `v2Router`, `quoteToken`, `mainPool`, and the `pools` mapping, are set only during the `initialize` function. While this ensures immutability after deployment, it also means that if any of these external dependencies need to be updated (e.g., due to a bug, a migration, or a strategic change), the entire `FlapTaxTokenV3` contract would require an upgrade. This reduces operational flexibility and increases the overhead for necessary updates.
FixFor external contract addresses that may require updates over the contract's lifetime, consider implementing owner-only setter functions. These setters should include appropriate access control, zero-address checks, and potentially a time-lock mechanism to provide transparency and a grace period before changes take effect.
StatusUnresolved
Info

Missing `_authorizeUpgrade` for UUPS Proxy Pattern

I-01The contract is an implementation behind a proxy and utilizes OpenZeppelin's `Upgradeable` contracts. If the proxy follows the UUPS (Universal Upgradeable Proxy Standard) pattern, the implementation contract is responsible for authorizing upgrades via an `_authorizeUpgrade` function. This function is not present in the provided snippet. Without it, the upgradeability mechanism might either be insecure (if the proxy allows anyone to upgrade) or not fully compliant with the UUPS standard, potentially leading to unexpected upgrade behavior or security risks.
IssueThe contract is an implementation behind a proxy and utilizes OpenZeppelin's `Upgradeable` contracts. If the proxy follows the UUPS (Universal Upgradeable Proxy Standard) pattern, the implementation contract is responsible for authorizing upgrades via an `_authorizeUpgrade` function. This function is not present in the provided snippet. Without it, the upgradeability mechanism might either be insecure (if the proxy allows anyone to upgrade) or not fully compliant with the UUPS standard, potentially leading to unexpected upgrade behavior or security risks.
FixVerify the exact proxy pattern used. If it is UUPS, ensure that the full implementation contract includes a properly secured `_authorizeUpgrade` function, typically restricting upgrade calls to the contract owner or a designated governance mechanism. If a different proxy pattern (e.g., Transparent Proxy) is used, confirm that the proxy admin's upgrade authority is adequately secured.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract utilizes OpenZeppelin's upgradeable ERC20, Ownable, and Permit modules, demonstrating a robust architectural foundation (7.1). Code quality is generally high, with proper use of `SafeERC20` and gas-efficient `PackedPoolState` struct (7.2). However, the `_liquidateTax` function, called on every transfer, presents a potential reentrancy vulnerability if it makes external calls before updating its `notLiquidating` state (7.2). Additionally, state changes based on `block.timestamp` in `_liquidateTax` are susceptible to miner extractable value (MEV) (7.2). Access control (7.3) is managed by `OwnableUpgradeable`, centralizing significant power.

GovernanceMedium4/10

The economic model revolves around a dynamic tax mechanism that changes based on the `poolState` (7.4). The owner has significant centralized control (7.5) over the contract's lifecycle, including initiating and finalizing migration phases that alter tax enforcement. While the tax calculation logic appears sound, the owner's ability to transition states without a multi-signature or time-lock mechanism introduces a single point of failure. External interactions (7.6) with `ITaxProcessor`, `IDividend`, and `v2Router` are critical dependencies.

UpgradesLow8/10

The contract is designed as an upgradeable implementation using OpenZeppelin's `Initializable` and `Upgradeable` patterns (7.7). The constructor correctly calls `_disableInitializers()`, and the `initialize` function uses the `initializer` modifier. However, if the proxy uses the UUPS pattern, the implementation contract would typically require an `_authorizeUpgrade` function, which is not present in the provided snippet, potentially leaving the upgrade mechanism insecure or non-compliant (7.7). State variables are defined appropriately for upgradeability.

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

31.4% in top 10
17.9% in wallets13.5% in contracts
Effective Concentration23.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

$57.0K 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

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

Key Addresses

2 addresses
Deployer
0xa44c…a844
Unlocked LP Held By
0x4589…e108

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

What Raised This Score

8 factors
  • Top-10 concentration > 20% (31.4% total → 23.3% effective; 17.9% in EOAs, 13.5% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • Token age < 24h (brand new — bot activity, unproven)
  • 1 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
APRO oracle Token (AT)Medium Riskutility token (UTILITY)Medium RiskArk Of Panda (AOP)Medium RiskHOMER CZ (HOMER)Medium RiskBaby Doge Coin (BABYDOGE)Medium RiskBitway Token (BTW)Medium Risk

Would You Like a More Detailed Audit of BUDDY - First Crypto Dog?

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

Get Detailed Audit