Quantum Audit Logo

Is BigShortBets Safe?

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

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

BigShortBets BIGSB
0x1311…b6f6
Ethereum Not verifiedLast checked 2d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The BigSB token contract implements a deflationary ERC-20 token with reflection mechanics, automated liquidity provision, and anti-whale/anti-bot features. The contract exhibits a high degree of centralized control by the owner, who can modify critical economic parameters, pause transfers, and exclude addresses from fees and rewards. While the code is generally well-structured and uses Solidity 0.8.7 for overflow protection, the extensive owner privileges introduce significant trust assumptions and potential for malicious manipulation or operational risks.

1 Critical2 High1 Medium1 Low1 Informational
Volume 24h
$23.3K
Liquidity
$218.2K
Price
$0.1866
Token Age
4y
Top 10 Holders
87.3%

Security Findings

1 Crit2 High1 Med1 Low1 Info
Critical

Centralized Control Over Critical Parameters and Transfers

C-01The `owner` of the contract possesses extensive control over critical functions and parameters. This includes the ability to set all transaction fees (reflection, burn, liquidity, wallet) to arbitrary values, enable/disable the `swapAndLiquify` mechanism, set `_maxTxAmount` and `_maxWalletAmount` to zero (effectively halting all transfers or making tokens untradable), pause all transfers via `_isPaused`, and recover any ERC20 tokens or ETH accidentally sent to the contract. This level of centralization creates a single point of failure and a significant rug-pull risk, as a malicious or compromised owner could severely impact token holders.
IssueThe `owner` of the contract possesses extensive control over critical functions and parameters. This includes the ability to set all transaction fees (reflection, burn, liquidity, wallet) to arbitrary values, enable/disable the `swapAndLiquify` mechanism, set `_maxTxAmount` and `_maxWalletAmount` to zero (effectively halting all transfers or making tokens untradable), pause all transfers via `_isPaused`, and recover any ERC20 tokens or ETH accidentally sent to the contract. This level of centralization creates a single point of failure and a significant rug-pull risk, as a malicious or compromised owner could severely impact token holders.
FixImplement a multi-signature wallet for ownership or transition to a decentralized governance model. For highly sensitive functions like pausing transfers or setting critical limits, consider adding a time-lock mechanism or requiring community consensus through a DAO vote. Clearly communicate the extent of owner privileges to the community.
StatusUnresolved
High

Potential for Manipulation of Anti-Whale/Anti-Bot Limits

H-01The `_maxTxAmount` and `_maxWalletAmount` variables, intended to prevent large transactions or holdings, can be modified by the owner at any time. While these features aim to protect against market manipulation, an malicious owner could set these limits to extremely low values. This could effectively prevent users from selling their tokens (if `_maxTxAmount` is too low) or holding their desired amount (if `_maxWalletAmount` is too low), leading to a denial of service for token holders or forced sell-offs at disadvantageous prices.
IssueThe `_maxTxAmount` and `_maxWalletAmount` variables, intended to prevent large transactions or holdings, can be modified by the owner at any time. While these features aim to protect against market manipulation, an malicious owner could set these limits to extremely low values. This could effectively prevent users from selling their tokens (if `_maxTxAmount` is too low) or holding their desired amount (if `_maxWalletAmount` is too low), leading to a denial of service for token holders or forced sell-offs at disadvantageous prices.
FixIf these limits are deemed necessary, consider making them immutable after deployment or subject to a time-locked, multi-signature, or governance-controlled update process. Provide clear documentation on the purpose and potential impact of these limits.
StatusUnresolved
High

High and Arbitrarily Modifiable Transaction Fees

H-02The contract implements multiple transaction fees (reflection, burn, liquidity, wallet) which can sum up to a significant percentage of each transfer. The owner has the ability to modify these fees at any time through functions like `setReflectionFee`, `setBurnFee`, `setLiquidityFee`, and `setWalletFee`. This arbitrary control over fees introduces economic uncertainty for users and could be exploited by a malicious owner to extract excessive value from transactions, negatively impacting token liquidity and user trust.
IssueThe contract implements multiple transaction fees (reflection, burn, liquidity, wallet) which can sum up to a significant percentage of each transfer. The owner has the ability to modify these fees at any time through functions like `setReflectionFee`, `setBurnFee`, `setLiquidityFee`, and `setWalletFee`. This arbitrary control over fees introduces economic uncertainty for users and could be exploited by a malicious owner to extract excessive value from transactions, negatively impacting token liquidity and user trust.
FixConsider capping the maximum allowable fees or implementing a time-lock for fee changes to provide transparency and predictability for users. Alternatively, decentralize fee management through a governance mechanism.
StatusUnresolved
Medium

Gas Inefficiency in `_excluded` Array Management

M-01The `includeInReward` and `excludeFromReward` functions iterate through the `_excluded` array to add or remove addresses. If the number of excluded addresses grows significantly, these operations will become increasingly gas-intensive. This could lead to high transaction costs, potentially making these functions prohibitively expensive to call, effectively causing a denial of service for managing excluded addresses.
IssueThe `includeInReward` and `excludeFromReward` functions iterate through the `_excluded` array to add or remove addresses. If the number of excluded addresses grows significantly, these operations will become increasingly gas-intensive. This could lead to high transaction costs, potentially making these functions prohibitively expensive to call, effectively causing a denial of service for managing excluded addresses.
FixFor large numbers of excluded addresses, consider alternative data structures (e.g., a mapping `isExcluded[address] => bool` without an array for iteration) or implement a mechanism to process exclusions in batches. If the array is necessary, enforce a reasonable maximum size for `_excluded` to prevent excessive gas consumption.
StatusUnresolved
Low

Use of `UNLICENSE` License

L-01The contract uses the `UNLICENSE` identifier. While legally permissible, `UNLICENSE` is less common and explicit than other open-source licenses like MIT, Apache 2.0, or GPL. Using a more widely recognized license can provide clearer terms regarding intellectual property rights, permissions, and limitations for users and developers interacting with the code.
IssueThe contract uses the `UNLICENSE` identifier. While legally permissible, `UNLICENSE` is less common and explicit than other open-source licenses like MIT, Apache 2.0, or GPL. Using a more widely recognized license can provide clearer terms regarding intellectual property rights, permissions, and limitations for users and developers interacting with the code.
FixConsider adopting a more standard and explicit open-source license (e.g., MIT License) to provide greater clarity on the terms of use and distribution of the contract code.
StatusUnresolved
Info

Extensive In-Code Project Description

I-01The contract includes a very long, philosophical project description and marketing text as a multi-line comment at the top of the `bigsb-token.sol` file. While informative for understanding the project's vision, this extensive text adds unnecessary bytes to the deployed bytecode (if not optimized away by the compiler) and can make the source code harder to navigate and review for security-critical logic.
IssueThe contract includes a very long, philosophical project description and marketing text as a multi-line comment at the top of the `bigsb-token.sol` file. While informative for understanding the project's vision, this extensive text adds unnecessary bytes to the deployed bytecode (if not optimized away by the compiler) and can make the source code harder to navigate and review for security-critical logic.
FixRelocate extensive project descriptions and marketing content to external documentation (e.g., project website, whitepaper, GitHub README). Keep in-code comments concise and focused on explaining the logic, purpose, and invariants of the code itself.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract's architecture (7.1) is a standard ERC-20 with added deflationary and reflection mechanisms. Code security (7.2) benefits from Solidity 0.8.7, mitigating common integer issues. However, operational risks (7.8) are high due to the owner's ability to pause transfers via `_isPaused` and recover arbitrary ERC20 tokens or ETH, which could be misused. Gas inefficiency (7.2) in `_excluded` array management could lead to high transaction costs for certain owner functions.

GovernanceHigh1/10

Access control (7.3) is heavily centralized, with an `Owned` contract granting the owner extensive privileges over critical economic parameters (7.4). The owner can arbitrarily set all transaction fees (reflection, burn, liquidity, wallet), modify anti-whale/anti-bot limits (`_maxTxAmount`, `_maxWalletAmount`), and exclude addresses from fees and rewards. This level of control presents a significant single point of failure and potential for economic manipulation, including rug-pull scenarios or denial of service for token holders.

UpgradesMedium6/10

The BigSB contract is not designed with upgradeability in mind (7.7). It is a standard contract deployment without a proxy pattern, meaning its logic cannot be changed after deployment. This eliminates upgrade-related risks but also removes flexibility for future enhancements or bug fixes.

Security Checklist

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

Holder Composition

87.3% in top 10
45.6% in wallets41.7% in contracts
Effective Concentration62.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

$220.5K across 2 pairs
Uniswap v2USDCanalysed$218.2K99.0%Uniswap v2WETH$2.3K1.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 Burned28.8%
LP Locked28.8% · Null Address
Top-1 Unlocked Holder42.1%
Top-3 Unlocked71.2%

Key Addresses

4 addresses
Deployer
0x3cee…6935
Unlocked LP Held By
0x3efd…881a0x37f1…b2ee0x055b…37aa

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

What Raised This Score

6 factors
  • Ownership NOT renounced — owner is an EOA (single private key)
  • Top-10 concentration > 50% (87.3% total → 62.3% effective; 45.6% in EOAs, 41.7% in contracts — heavy)
  • 1 Critical finding(s) from audit
  • 2 High finding(s) from audit
  • 1 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
Global Dollar (USDG)Critical RiskFrankencoin (ZCHF)Critical RiskRe Protocol reUSD (REUSD)Critical RiskRallyCritical RiskTurtleCritical RiskSyrup Token (SYRUP)Critical Risk

Would You Like a More Detailed Audit of BigShortBets?

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

Get Detailed Audit