Quantum Audit Logo

Is BigShort a Scam?

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

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

BigShort SHORT
0x7c46…bbbb
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 · 2d old
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The BigShortTokenV1 contract, serving as an upgradeable ERC20 token implementation, integrates a complex tax mechanism and relies heavily on an external protocol registry for configuration. While it employs OpenZeppelin's upgradeable patterns and includes specific reentrancy guards, a significant portion of the core transfer and tax processing logic within the `_update` function was truncated, preventing a full security assessment. This audit identifies several medium-level risks related to external dependencies, upgradeability, and the incomplete view of critical functionality.

3 Medium1 Low1 Informational
! Early-stage analysis. This token has limited on-chain history (2d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$451.6K
Liquidity
$175.6K
Price
$0.0002909
Token Age
2d
Top 10 Holders
69.0%

Security Findings

3 Med1 Low1 Info
Medium

Reliance on External Protocol Registry for Critical Configuration

M-01The `initialize` function and overall contract operation heavily depend on the `IProtocolRegistry` for fetching critical configuration data such as `TokenRecord`, `MarketGroup`, `EconomicConfiguration`, and `EngineReservation`. If the `IProtocolRegistry` is compromised, misconfigured, or returns malicious data, it could lead to incorrect token initialization, invalid tax parameters, or an overall broken token state. This introduces a central point of trust and a significant external dependency risk (7.6 External, 7.1 Architecture).
IssueThe `initialize` function and overall contract operation heavily depend on the `IProtocolRegistry` for fetching critical configuration data such as `TokenRecord`, `MarketGroup`, `EconomicConfiguration`, and `EngineReservation`. If the `IProtocolRegistry` is compromised, misconfigured, or returns malicious data, it could lead to incorrect token initialization, invalid tax parameters, or an overall broken token state. This introduces a central point of trust and a significant external dependency risk (7.6 External, 7.1 Architecture).
FixImplement robust security measures for the `IProtocolRegistry`, including strong access control, immutable configuration where possible, and thorough validation of data before it's consumed by dependent contracts. Consider adding additional on-chain validation checks within `BigShortTokenV1` for critical parameters fetched from the registry, if feasible, to provide a defense-in-depth approach.
StatusUnresolved
Medium

Incomplete Tax Processing Logic (Truncated Code)

M-02The provided source code for the `_update` function, which is central to token transfers and tax application, is truncated. This prevents a full security assessment of the tax mechanism, including potential reentrancy vectors beyond the explicitly mentioned guard, slippage attacks during swaps (if applicable), or incorrect tax calculations. Without the complete implementation of this critical function and the `BigShortTaxProcessorV1` contract, an unknown level of risk remains regarding the core economic and security logic (7.2 Code Security, 7.4 Economic).
IssueThe provided source code for the `_update` function, which is central to token transfers and tax application, is truncated. This prevents a full security assessment of the tax mechanism, including potential reentrancy vectors beyond the explicitly mentioned guard, slippage attacks during swaps (if applicable), or incorrect tax calculations. Without the complete implementation of this critical function and the `BigShortTaxProcessorV1` contract, an unknown level of risk remains regarding the core economic and security logic (7.2 Code Security, 7.4 Economic).
FixProvide the complete source code for the `_update` function and the `BigShortTaxProcessorV1` contract for a comprehensive security audit. A full review is necessary to identify and mitigate any vulnerabilities related to tax calculation, external calls, and reentrancy within the entire transfer process.
StatusUnresolved
Medium

Upgradeability Risks (General)

M-03As an upgradeable contract (BeaconProxy implementation), future upgrades must meticulously manage storage layout to prevent collisions or data corruption. While the current contract uses OpenZeppelin's `ERC20Upgradeable` and `Initializable` patterns, the inherent complexity of upgradeable systems introduces a persistent risk if new state variables are added or existing ones are reordered incorrectly in subsequent versions. This could lead to critical data loss or unexpected contract behavior upon upgrade (7.7 Upgrades).
IssueAs an upgradeable contract (BeaconProxy implementation), future upgrades must meticulously manage storage layout to prevent collisions or data corruption. While the current contract uses OpenZeppelin's `ERC20Upgradeable` and `Initializable` patterns, the inherent complexity of upgradeable systems introduces a persistent risk if new state variables are added or existing ones are reordered incorrectly in subsequent versions. This could lead to critical data loss or unexpected contract behavior upon upgrade (7.7 Upgrades).
FixAdhere strictly to OpenZeppelin's upgradeability guidelines for storage layout. When performing upgrades, conduct thorough testing in a staging environment, including migration simulations. Consider using tools like 'hardhat-upgrades' or 'openzeppelin-upgrades' to assist in detecting storage layout incompatibilities during development and deployment. Formal verification of storage compatibility for each upgrade is highly recommended.
StatusUnresolved
Low

Centralization Risk via `controller` Role

L-01The `controller` address holds significant power within the contract, including the ability to bind the main trading pair (`bindMainPair`) and enable external trading (`enableExternalTrading`). While this is a common design pattern for operational control, it introduces a centralization risk. A compromise of the `controller`'s private key or its controlling mechanism (e.g., a multisig with too few signers) could lead to critical operational disruptions or malicious actions affecting the token's trading capabilities (7.3 Access Control, 7.8 Operations).
IssueThe `controller` address holds significant power within the contract, including the ability to bind the main trading pair (`bindMainPair`) and enable external trading (`enableExternalTrading`). While this is a common design pattern for operational control, it introduces a centralization risk. A compromise of the `controller`'s private key or its controlling mechanism (e.g., a multisig with too few signers) could lead to critical operational disruptions or malicious actions affecting the token's trading capabilities (7.3 Access Control, 7.8 Operations).
FixEnsure the `controller` address is secured with the highest possible operational security standards, such as a robust multisignature wallet with a sufficient number of signers and strict key management practices. Consider implementing time-locks for critical administrative actions to provide a window for intervention in case of a compromise.
StatusUnresolved
Info

Specific Reentrancy Guard in `_update` for Tax Processing

I-01The `_update` function includes a reentrancy guard (`_processingExternalTax`) specifically designed to prevent re-entry during tax processing initiated by the `taxProcessor`. This is a good practice for the identified scenario, ensuring that internal state changes related to tax collection are not interrupted or manipulated by re-entrant calls from the `taxProcessor` (7.2 Code Security).
IssueThe `_update` function includes a reentrancy guard (`_processingExternalTax`) specifically designed to prevent re-entry during tax processing initiated by the `taxProcessor`. This is a good practice for the identified scenario, ensuring that internal state changes related to tax collection are not interrupted or manipulated by re-entrant calls from the `taxProcessor` (7.2 Code Security).
FixWhile this specific guard is well-placed, ensure that the `BigShortTaxProcessorV1` contract itself is also thoroughly audited for reentrancy vulnerabilities, especially if it makes external calls that could re-enter the token contract in different contexts (e.g., via `transfer` or `transferFrom` to an attacker-controlled contract). A holistic view of reentrancy across all interacting contracts is crucial.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The `BigShortTokenV1` contract demonstrates good technical practices, including the use of OpenZeppelin's upgradeable contracts and custom error handling. A specific reentrancy guard is implemented within the `_update` function to protect against re-entry during tax processing (7.2 Code Security). However, a significant portion of the `_update` function, critical for transfer and tax logic, was truncated, preventing a full security assessment of its implementation. The contract also relies heavily on external contracts like `BigShortTaxProcessorV1` and `IProtocolRegistry`, introducing dependency risks (7.6 External).

GovernanceMedium4/10

The economic model incorporates a flexible tax mechanism with configurable buy/sell taxes and a burn mode, validated extensively during initialization (7.4 Economic). The `controller` role is central to enabling external trading and binding the main pair, which is a common but centralized design choice (7.3 Access Control). The protocol's economic parameters and operational integrity are highly dependent on the `IProtocolRegistry` for initial configuration, making its security paramount (7.5 Governance).

UpgradesHigh2/10

The contract is designed as an upgradeable implementation for a BeaconProxy, leveraging OpenZeppelin's `Initializable` pattern for secure deployment (7.7 Upgrades). The `initialize` function includes robust checks to ensure proper setup within the protocol's framework. However, as with all upgradeable contracts, careful management of storage layout is crucial for future upgrades to prevent data corruption or unexpected behavior (7.7 Upgrades).

Security Checklist

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

Proxy Upgrade Controls

Proxy TypeBeacon
ImplementationVerified source

Holder Composition

69.0% in top 10
5.8% in wallets63.2% in contracts
Effective Concentration31.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

$175.6K across 4 pairs
Pancakeswap v2WBNBanalysed$175.6K100.0%Uniswap v2USDT$00.0%Uniswap v2WBNB$00.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

LP Burned99.7% · ≈ permanent lock
LP Locked99.7% · Null Address

Key Addresses

2 addresses
Deployer
0xd40b…0f5a
Unlocked LP Held By
0x66cb…bbf5

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

What Raised This Score

7 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Proxy contract (upgradeable — admin can replace logic)
  • Complex proxy pattern (BEACON)
  • Top-10 concentration > 30% (69.0% total → 31.1% effective; 5.8% in EOAs, 63.2% in contracts — moderate)
  • Token age < 7 days (early, volatile)
  • 3 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
孙小圣Medium RiskAltura (ALU)Medium Risk4catMedium RiskMame Inu (MAME)Medium RiskOLAXBT (AIO)Medium RiskNon-Playable Coin (NPC)Medium Risk

Would You Like a More Detailed Audit of BigShort?

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

Get Detailed Audit