Quantum Audit Logo

Is 4Stock a Scam?

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

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

4Stock 4STOCK
0xd270…ffff
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 · 4d old
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

This audit covers the Stock4TaxToken contract, an ERC-20 token implementation behind a proxy on the BSC network. The contract features a complex fee mechanism for buy/sell operations, distributing fees to founders, holders, burn addresses, and liquidity pools. It utilizes OpenZeppelin libraries for secure ERC-20 operations and includes reentrancy guards for fee dispatching. Key findings highlight centralized control over critical parameters and external dependencies, potential for fee accumulation, and reliance on an external `ITokenHelper` for core operations. The upgradeability pattern appears standard and secure.

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

Security Findings

1 High2 Med2 Low2 Info
High

Centralized Control over Critical Parameters and External Contracts

H-01The `tokenModule` (likely an admin role) possesses significant control over the contract's operation. It can configure critical external dependencies such as `wrappedNative`, `quote`, `shareHolderManager`, `tokenHelper`, and `lpV2Manager` via the `postInitialize` function. Additionally, the `shareHolderManager` contract, once set, has the power to blacklist users, preventing them from transferring tokens. This level of centralized control introduces a single point of failure and a high trust assumption on the `tokenModule` and `shareHolderManager` addresses (7.3 Access Control, 7.6 External).
IssueThe `tokenModule` (likely an admin role) possesses significant control over the contract's operation. It can configure critical external dependencies such as `wrappedNative`, `quote`, `shareHolderManager`, `tokenHelper`, and `lpV2Manager` via the `postInitialize` function. Additionally, the `shareHolderManager` contract, once set, has the power to blacklist users, preventing them from transferring tokens. This level of centralized control introduces a single point of failure and a high trust assumption on the `tokenModule` and `shareHolderManager` addresses (7.3 Access Control, 7.6 External).
FixImplement a multi-signature wallet for the `tokenModule` address and any other privileged roles. Consider time-locks for critical parameter changes to allow users to react to impending modifications. Clearly document the roles and responsibilities of each privileged address.
StatusUnresolved
Medium

Potential for Fee Accumulation and Stagnation

M-01The `dispatchTax` function is responsible for distributing accumulated fees to various destinations (founder, holders, burn, liquidity). However, its execution is gated by several conditions, including `tokenAccumulated > minDispatch`, `feeAccumulated > minDispatchQuote`, and the availability of `tokenHelper`. If `minDispatch` or `minDispatchQuote` are set too high, or if `tokenHelper` is not properly configured or becomes unavailable, fees could accumulate indefinitely without being distributed. This could lead to a lack of rewards for holders and an inability to fund other protocol functions (7.4 Economic).
IssueThe `dispatchTax` function is responsible for distributing accumulated fees to various destinations (founder, holders, burn, liquidity). However, its execution is gated by several conditions, including `tokenAccumulated > minDispatch`, `feeAccumulated > minDispatchQuote`, and the availability of `tokenHelper`. If `minDispatch` or `minDispatchQuote` are set too high, or if `tokenHelper` is not properly configured or becomes unavailable, fees could accumulate indefinitely without being distributed. This could lead to a lack of rewards for holders and an inability to fund other protocol functions (7.4 Economic).
FixReview and carefully set `minDispatch` and `minDispatchQuote` to ensure they are economically viable for frequent dispatching. Implement a mechanism for the `tokenModule` to manually trigger dispatching or adjust these minimums if automatic dispatching stalls. Consider adding a fallback mechanism for fee distribution if `tokenHelper` becomes unresponsive.
StatusUnresolved
Medium

Heavy Reliance on External `ITokenHelper` for Core Operations

M-02The `Stock4TaxToken` contract delegates crucial functionalities related to liquidity management and token swaps (e.g., `addLiquidity`, `swapForQuote`, `swapForToken`, `swapForETH`) to an external `ITokenHelper` contract. The address of this `tokenHelper` is configurable by the `tokenModule`. A compromise or malicious behavior of the `ITokenHelper` contract could directly impact the token's economic stability, potentially leading to fund loss, price manipulation, or disruption of the fee distribution mechanism. The security of `Stock4TaxToken` is thus highly dependent on the security and trustworthiness of `ITokenHelper` (7.6 External, 7.2 Code Security).
IssueThe `Stock4TaxToken` contract delegates crucial functionalities related to liquidity management and token swaps (e.g., `addLiquidity`, `swapForQuote`, `swapForToken`, `swapForETH`) to an external `ITokenHelper` contract. The address of this `tokenHelper` is configurable by the `tokenModule`. A compromise or malicious behavior of the `ITokenHelper` contract could directly impact the token's economic stability, potentially leading to fund loss, price manipulation, or disruption of the fee distribution mechanism. The security of `Stock4TaxToken` is thus highly dependent on the security and trustworthiness of `ITokenHelper` (7.6 External, 7.2 Code Security).
FixConduct a thorough audit of the `ITokenHelper` contract. Ensure that the `tokenHelper` address is set to a verified, immutable, and audited contract. Implement robust monitoring for the `tokenHelper` contract's behavior. Consider adding circuit breakers or emergency pause mechanisms if the `tokenHelper` exhibits suspicious activity.
StatusUnresolved
Low

Incomplete Event Emission for Critical Parameter Changes

L-01The `initialize` function sets several critical economic parameters such as `buyFeeRate`, `sellFeeRate`, `rateFounder`, `rateHolder`, `rateBurn`, `rateLiquidity`, `minDispatch`, `minDispatchQuote`, and `minShare`. While `LPV2ManagerConfigured` is emitted in `postInitialize`, there are no corresponding events emitted when these core economic parameters are initially set or if they were to be changed in a future upgrade. This lack of event emission hinders off-chain monitoring, transparency, and the ability for users and external systems to track the token's economic model effectively (7.8 Operations).
IssueThe `initialize` function sets several critical economic parameters such as `buyFeeRate`, `sellFeeRate`, `rateFounder`, `rateHolder`, `rateBurn`, `rateLiquidity`, `minDispatch`, `minDispatchQuote`, and `minShare`. While `LPV2ManagerConfigured` is emitted in `postInitialize`, there are no corresponding events emitted when these core economic parameters are initially set or if they were to be changed in a future upgrade. This lack of event emission hinders off-chain monitoring, transparency, and the ability for users and external systems to track the token's economic model effectively (7.8 Operations).
FixEmit explicit events for all critical parameters set during `initialize` and `postInitialize`. If any of these parameters are made mutable in future upgrades, ensure that corresponding events are emitted upon each modification.
StatusUnresolved
Low

Default `founder` to `creator` in `_decodeOrDefault`

L-02The `_decodeOrDefault` function, used during initialization, sets the `founder` address to the `creator` (which is `msg.sender` of the `initialize` call, typically the `tokenModule` or deployer) if `p.founder` is `address(0)` in the provided `TaxTokenParams`. While this might be intended, it means the `tokenModule` automatically becomes a recipient of a portion of the fees if a specific founder is not explicitly set. This could lead to an unintended distribution of funds if the `tokenModule` is not the intended long-term founder or if the `creator` address is a temporary deployment wallet (7.2 Code Security).
IssueThe `_decodeOrDefault` function, used during initialization, sets the `founder` address to the `creator` (which is `msg.sender` of the `initialize` call, typically the `tokenModule` or deployer) if `p.founder` is `address(0)` in the provided `TaxTokenParams`. While this might be intended, it means the `tokenModule` automatically becomes a recipient of a portion of the fees if a specific founder is not explicitly set. This could lead to an unintended distribution of funds if the `tokenModule` is not the intended long-term founder or if the `creator` address is a temporary deployment wallet (7.2 Code Security).
FixExplicitly require `p.founder` to be a non-zero address in `TaxTokenParams` to prevent accidental assignment to the `creator`. Alternatively, clearly document this default behavior and ensure the `creator` address is appropriately managed if it's intended to receive founder fees.
StatusUnresolved
Info

Redundant `quote` parameter in `postInitialize`

I-01The `quote` state variable is initialized in the `initialize` function using `c.quoteAsset`. Subsequently, the `postInitialize` function also takes an `address quote_` parameter and assigns it to the `quote` state variable, effectively overwriting the value set during the main initialization. While this might be intentional to allow for a two-step configuration, it introduces redundancy and could be a source of confusion or potential misconfiguration if the two values are intended to be different or if the `quote_` parameter in `postInitialize` is accidentally set incorrectly (7.2 Code Security).
IssueThe `quote` state variable is initialized in the `initialize` function using `c.quoteAsset`. Subsequently, the `postInitialize` function also takes an `address quote_` parameter and assigns it to the `quote` state variable, effectively overwriting the value set during the main initialization. While this might be intentional to allow for a two-step configuration, it introduces redundancy and could be a source of confusion or potential misconfiguration if the two values are intended to be different or if the `quote_` parameter in `postInitialize` is accidentally set incorrectly (7.2 Code Security).
FixClarify the intended purpose of setting `quote` in both `initialize` and `postInitialize`. If `postInitialize` is meant to finalize this value, ensure clear documentation. If it's truly redundant, remove the `quote_` parameter from `postInitialize` and rely solely on the value set in `initialize`.
StatusUnresolved
Info

Potential Reentrancy in `_transfer` (Truncated Code)

I-02The provided `_transfer` function snippet is truncated, preventing a full security analysis. However, in fee-on-transfer tokens, `_transfer` often involves complex logic, including calculating and distributing fees, which may entail external calls (e.g., to swap fees, add liquidity). If these external calls are made before critical state updates or without robust reentrancy guards, the contract could be vulnerable to reentrancy attacks. While `swapping` and `dispatchingFee` flags are present elsewhere, their application and effectiveness within the full `_transfer` logic cannot be confirmed (7.2 Code Security).
IssueThe provided `_transfer` function snippet is truncated, preventing a full security analysis. However, in fee-on-transfer tokens, `_transfer` often involves complex logic, including calculating and distributing fees, which may entail external calls (e.g., to swap fees, add liquidity). If these external calls are made before critical state updates or without robust reentrancy guards, the contract could be vulnerable to reentrancy attacks. While `swapping` and `dispatchingFee` flags are present elsewhere, their application and effectiveness within the full `_transfer` logic cannot be confirmed (7.2 Code Security).
FixA complete review of the `_transfer` function and any related fee-handling logic is crucial. Ensure strict adherence to the Checks-Effects-Interactions pattern. All state changes must be finalized before any external calls are made. Confirm that all functions involving external calls or sensitive state modifications are protected by appropriate reentrancy guards, such as `swapping` or `dispatchingFee`, and that these guards are correctly implemented and scoped.
StatusUnresolved

Category Ratings

TechnicalLow9/10

The contract demonstrates good technical practices, including the use of OpenZeppelin's SafeERC20 for secure token transfers and explicit reentrancy guards (`swapping`, `dispatchingFee`) for sensitive operations (7.2 Code Security). However, the contract's heavy reliance on external interfaces like `ITokenHelper` for liquidity and swap operations introduces significant external dependency risk (7.6 External). The truncated `_transfer` function also raises concerns about potential reentrancy if not fully protected (7.2 Code Security).

GovernanceLow7/10

The token's economic model involves a detailed fee distribution mechanism, including founder, holder, burn, and liquidity rates, which are set during initialization (7.4 Economic). However, the `tokenModule` (likely an admin) holds significant centralized control over critical parameters and external contract addresses, posing a high trust assumption (7.3 Access Control). There is also a potential for fees to accumulate and stagnate if dispatching conditions are not met, impacting holder rewards (7.4 Economic). The `shareHolderManager` can blacklist users, introducing a censorship risk (7.5 Governance).

UpgradesLow9/10

The contract is designed as an upgradeable proxy implementation, using the `initializer` modifier for one-time setup, which is a standard and secure pattern for UUPS proxies (7.7 Upgrades). The `__OpenFourToken_init` function ensures proper initialization of the base contract. This setup allows for future logic upgrades without migrating user funds, provided the upgrade process itself is managed securely.

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

47.2% in top 10
3.7% in wallets43.5% in contracts
Effective Concentration21.1%

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

$2.11M across 13 pairs
Pancakeswap v3USDTanalysed$840.8K39.8%Pancakeswap v2BNC4$673.2K31.9%Pancakeswap v3USDT$339.1K16.1%UniswapUSDT$210.9K10.0%Pancakeswap v3USDC$25.1K1.2%Pancakeswap v3WBNB$18.3K0.9%
Show 4 more pairsShow less
Pancakeswap v3USDC$3.0K0.1%Pancakeswap v2USDT$1730.0%Uniswap v2USDT$1510.0%Pancakeswap v2WBNB$260.0%

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 Holder16.1%
Top-3 Unlocked36.2%

Key Addresses

11 addresses
Deployer
0x9b47…fb3f
Unlocked LP Held By
0x79ad…24780x8d48…578b0x6229…ae0f0x214a…0b300xba44…ea330xbd7a…d8eb0xa0bf…0efb0x2175…de9c0x770c…4b970x87dc…3658

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

What Raised This Score

6 factors
  • Top-10 concentration > 20% (47.2% total → 21.1% effective; 3.7% in EOAs, 43.5% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • 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
The Final Form Bull (CZ)Medium RiskTest (TST)Medium RiskLABMedium RiskKoma Inu (KOMA)Medium RiskFLORKMedium RiskBaby Asteroid (BABYASTEROID)Medium Risk

Would You Like a More Detailed Audit of 4Stock?

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

Get Detailed Audit