Quantum Audit Logo

Is osbook a Scam?

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

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

osbook OSBOOK
0x355c…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 New Launch · 1d old
DexScreener ↗
How is this score calculated? → Low Risk
Executive SummaryAI Copilot

The FlapTaxTokenV3 contract is an upgradeable ERC20 token implementation featuring a dynamic tax mechanism and a multi-state pool system. It leverages OpenZeppelin's upgradeable contracts for robustness. The audit identified a high centralization risk due to extensive owner control over critical economic parameters and state transitions. Medium risks include potential denial of service from external contract interactions within the transfer path and reliance on truncated external contract logic. Low risks involve `block.timestamp` reliance and potential gas issues during initialization with large arrays. The contract's upgradeability is well-implemented but also owner-controlled.

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

Security Findings

1 High2 Med2 Low1 Info
High

Centralized Control over Critical Token Parameters and State Transitions

H-01The `OwnableUpgradeable` contract grants the owner significant control over the token's core functionality. The owner can initiate `startMigration()` and `finalizeMigration()`, which directly change the `poolState` (e.g., from `BondingCurve` to `Migrating` to `TaxEnforcedAntiFarmer`). These state changes dictate whether transfers are taxed, at what rates, and if they are restricted. For example, the owner can enable or disable taxes, and change tax rates by transitioning states. This level of control allows the owner to unilaterally alter the token's economic model and transfer behavior without community consensus.
IssueThe `OwnableUpgradeable` contract grants the owner significant control over the token's core functionality. The owner can initiate `startMigration()` and `finalizeMigration()`, which directly change the `poolState` (e.g., from `BondingCurve` to `Migrating` to `TaxEnforcedAntiFarmer`). These state changes dictate whether transfers are taxed, at what rates, and if they are restricted. For example, the owner can enable or disable taxes, and change tax rates by transitioning states. This level of control allows the owner to unilaterally alter the token's economic model and transfer behavior without community consensus.
FixImplement a multi-signature wallet for ownership or transition to a decentralized governance model (e.g., DAO) for critical parameter changes and state transitions. If a multi-sig is not feasible, ensure robust operational security for the owner key.
StatusUnresolved
Medium

Reliance on External Contracts with Truncated Logic

M-01The contract relies on external contracts `ITaxProcessor` and `IDividend` for critical functions like `processTax` and `distributeDividends` within `_liquidateTax`. The full implementation of `_liquidateTax` and the interfaces for these external contracts are truncated in the provided source. If these external contracts contain vulnerabilities (e.g., reentrancy, denial of service, or incorrect logic), they could directly impact the security and functionality of `FlapTaxTokenV3`, potentially leading to frozen funds or unexpected behavior during tax liquidation.
IssueThe contract relies on external contracts `ITaxProcessor` and `IDividend` for critical functions like `processTax` and `distributeDividends` within `_liquidateTax`. The full implementation of `_liquidateTax` and the interfaces for these external contracts are truncated in the provided source. If these external contracts contain vulnerabilities (e.g., reentrancy, denial of service, or incorrect logic), they could directly impact the security and functionality of `FlapTaxTokenV3`, potentially leading to frozen funds or unexpected behavior during tax liquidation.
FixConduct a thorough audit of the `ITaxProcessor` and `IDividend` contracts, including their full source code, to ensure they are secure and function as intended. Implement robust error handling and reentrancy guards in `ITaxProcessor` and `IDividend` if they perform external calls.
StatusUnresolved
Medium

Potential for Denial of Service in `_liquidateTax`

M-02The `_liquidateTax` function is called on every `_transfer`. This function performs state transitions and potentially calls external contracts (`ITaxProcessor.processTax` and `IDividend.distributeDividends` based on the truncated code). If any of these external calls or internal logic within `_liquidateTax` (e.g., due to an unexpected state or insufficient funds for a required operation) were to revert, it would cause the entire `_transfer` operation to revert, effectively halting all token transfers. This creates a denial-of-service vector for token holders.
IssueThe `_liquidateTax` function is called on every `_transfer`. This function performs state transitions and potentially calls external contracts (`ITaxProcessor.processTax` and `IDividend.distributeDividends` based on the truncated code). If any of these external calls or internal logic within `_liquidateTax` (e.g., due to an unexpected state or insufficient funds for a required operation) were to revert, it would cause the entire `_transfer` operation to revert, effectively halting all token transfers. This creates a denial-of-service vector for token holders.
FixIsolate complex or external interactions from the core `_transfer` path. Consider implementing a separate, owner-triggered function for tax liquidation and dividend distribution, or ensure that `_liquidateTax` handles all potential failure scenarios gracefully without reverting the `_transfer` function.
StatusUnresolved
Low

`block.timestamp` Reliance for Critical State Transitions

L-01The `_liquidateTax` function uses `block.timestamp` to determine state transitions, specifically for `taxExpirationTime` and `antiFarmerExpirationTime`. While `block.timestamp` is generally suitable for time-based logic, it is susceptible to miner manipulation within a small window (typically a few seconds). A malicious miner could slightly adjust the timestamp to trigger a state change (e.g., from `TaxEnforcedAntiFarmer` to `TaxEnforced` or `TaxFree`) earlier or later, potentially benefiting from changes in tax rates or transfer restrictions.
IssueThe `_liquidateTax` function uses `block.timestamp` to determine state transitions, specifically for `taxExpirationTime` and `antiFarmerExpirationTime`. While `block.timestamp` is generally suitable for time-based logic, it is susceptible to miner manipulation within a small window (typically a few seconds). A malicious miner could slightly adjust the timestamp to trigger a state change (e.g., from `TaxEnforcedAntiFarmer` to `TaxEnforced` or `TaxFree`) earlier or later, potentially benefiting from changes in tax rates or transfer restrictions.
FixFor critical time-sensitive operations where miner manipulation could have significant financial implications, consider using `block.number` and calculating time based on average block times, or use a decentralized oracle for time if higher precision and tamper-resistance are required. For this specific use case, the risk is low given the typical duration of tax periods.
StatusUnresolved
Low

Gas Limit Risk in `initialize` for `pools` Array

L-02The `initialize` function iterates through the `params.pools` array to set `pools[address] = true`. If `params.pools.length` is excessively large, this loop could potentially consume a significant amount of gas, potentially exceeding the block gas limit during deployment. While `initialize` is called only once, a very large array could lead to deployment failure.
IssueThe `initialize` function iterates through the `params.pools` array to set `pools[address] = true`. If `params.pools.length` is excessively large, this loop could potentially consume a significant amount of gas, potentially exceeding the block gas limit during deployment. While `initialize` is called only once, a very large array could lead to deployment failure.
FixWhile unlikely to be an issue for typical deployments, consider imposing a reasonable maximum length for the `pools` array in `initialize` to prevent potential gas limit issues. For example, `require(params.pools.length <= MAX_POOLS_COUNT, "Too many pools");`.
StatusUnresolved
Info

Unused `initialLiquidationThreshold` Variable

I-01The `initialLiquidationThreshold` state variable is set in the `initialize` function to `START_LIQ_THRESHOLD`. However, in the provided code snippet, this variable is not subsequently read or used anywhere else. This suggests it might be redundant or part of an incomplete feature.
IssueThe `initialLiquidationThreshold` state variable is set in the `initialize` function to `START_LIQ_THRESHOLD`. However, in the provided code snippet, this variable is not subsequently read or used anywhere else. This suggests it might be redundant or part of an incomplete feature.
FixReview the purpose of `initialLiquidationThreshold`. If it's not intended for future use, consider removing it to reduce contract complexity and storage costs. If it is intended for future use, ensure its purpose is clearly documented and that it is integrated into the contract's logic.
StatusUnresolved

Category Ratings

TechnicalLow9/10

The contract leverages OpenZeppelin's upgradeable ERC20 standard, providing a solid foundation for token functionality and upgradeability (7.1 Architecture, 7.2 Code Security). It implements a complex state machine (`PackedPoolState`) to manage various tax and transfer behaviors, including anti-farmer mechanisms. However, the reliance on external contracts (`ITaxProcessor`, `IDividend`) for critical tax liquidation logic, which is truncated, introduces potential reentrancy or denial-of-service risks if not properly secured (7.6 External, 7.2 Code Security). The `_liquidateTax` function, called on every transfer, could also lead to denial of service if external calls revert (7.8 Operations).

GovernanceLow8/10

The contract employs an `OwnableUpgradeable` pattern, granting the owner significant control over critical economic parameters and state transitions (7.3 Access Control, 7.5 Governance). The owner can unilaterally change the `poolState` via `startMigration` and `finalizeMigration`, directly impacting tax rates and transfer restrictions, which poses a high centralization risk (7.4 Economic). While this allows for flexible adaptation, it concentrates power and introduces a single point of failure.

UpgradesLow10/10

The contract is designed as an upgradeable proxy implementation using OpenZeppelin's `Initializable` and `Upgradeable` patterns, which is a robust approach for future enhancements (7.7 Upgrades). The `_disableInitializers` in the constructor and `initializer` modifier are correctly implemented. However, the upgrade mechanism is solely controlled by the owner, meaning a single entity has the power to deploy new logic, which is a significant centralization aspect of the upgrade process.

Security Checklist

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

Holder Composition

26.2% in top 10
13.5% in wallets12.7% in contracts
Effective Concentration18.6%

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

$96.6K

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 Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address

Key Addresses

2 addresses
Deployer
0x99ef…106d
Unlocked LP Held By
0x1947…61f2

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

What Raised This Score

4 factors
  • Token age < 7 days (early, volatile)
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 2 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
Marscoin (MARS)Low RiskTagger (TAG)Low RiskSmart Solve Token (SST)Low RiskPaluLow Risk哈基米Low Risk黑马Low Risk

Would You Like a More Detailed Audit of osbook?

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

Get Detailed Audit