Quantum Audit Logo
Launch App

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

Is BigShortBets Safe?

BIGSBEthereum
Not verified This 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 Sep 4, 2026 · 1 audit on record
Chart
High RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical6/10Governance1/10Upgrades6/10Checks passed5 of 7Findings1 Critical · 2 High · 1 Medium · 1 Low · 1 Info6
SummaryAI Copilot

The BigSB token contract implements a deflationary ERC-20 token with reflection mechanics, automated liquidity provision, and anti-whale/anti-bot features.

Read the full analysis
What raised the score
  • Ownership not renounced — owner is an EOA
  • Top-10 concentration > 50%
  • 1 Critical finding(s) from audit
  • 2 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 45 of 7 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax1.5% / 1.5%

Holders

as of audit · Sep 4, 2026
41.7%Contracts45.6%Wallets12.7%Everyone else
41.7%Contracts45.6%Wallets12.7%
ContractsWalletsEveryone elseBubble area = share of supply
87.3%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking41.7%
  • Walletsanonymous holders, free to sell45.6%
  • Everyone elsethe rest of the supply12.7%
Effective concentrationwhat the score reads62.3%
How holder types affect the score

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.

Holder balances as recorded by the audit of Sep 4, 2026

Liquidity

as of audit · Sep 4$220.5K across 2 pairs

The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$218.2KShare of depth99.0%
LP Burned28.8%
LP Locked28.8% · Null Address
Top-1 Unlocked Holder42.1%
Top-3 Unlocked71.2%
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.

Security Findings

1 Critical2 High1 Medium1 Low1 Info
Critical

Centralized Control Over Critical Parameters and Transfers

The 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.C-01

Issue

The 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.

Fix

Implement 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.

Status

Unresolved

High

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

The _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.H-01

Issue

The _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.

Fix

If 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.

Status

Unresolved

High

High and Arbitrarily Modifiable Transaction Fees

The 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.H-02

Issue

The 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.

Fix

Consider 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.

Status

Unresolved

Medium

Gas Inefficiency in _excluded Array Management

The 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.M-01

Issue

The 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.

Fix

For 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.

Status

Unresolved

Low

Use of UNLICENSE License

The 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.L-01

Issue

The 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.

Fix

Consider 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.

Status

Unresolved

Info

Extensive In-Code Project Description

The 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.I-01

Issue

The 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.

Fix

Relocate 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.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

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.

Technical6/10Medium risk

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.

Governance1/10High risk

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.

Upgrades6/10Medium risk

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.

Final RecommendationWhat to do about this score

To mitigate the identified risks, consider decentralizing critical control functions by implementing a multi-signature wallet or a time-locked governance mechanism for sensitive parameter changes (e.g., fees, anti-whale limits, pause functionality).

Clearly document the intended use and limitations of owner-controlled functions to manage community expectations. For gas efficiency, explore alternative data structures or limits for the _excluded array if it is expected to grow large.

Contract & Record

1 audit on record
TypeToken
NetworkEthereum
Token age4y
Contract0x1311…b6f6
Deployer0x3cee…6935
Badge for your website
BigShortBets security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Sep 3, 202681High

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Frequently Asked Questions

What is the BIGSB contract address?

The BigShortBets (BIGSB) contract on Ethereum is 0x131157c6760f78f7ddf877c0019eba175ba4b6f6. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is BigShortBets a scam?

Quantum Audit's risk score for BigShortBets is 81/100 (High risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: No mint; Liquidity lock: Locked; Upgradeability: Fixed code; Honeypot: None found; Buy / sell tax: 1.5% / 1.5%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is BIGSB liquidity locked?

Liquidity lock: Locked (as of Sep 4, 2026). Total DEX liquidity: $220.5K.

Who holds BIGSB?

As of Sep 4, 2026, the 10 largest holders own 87.3% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
Global DollarUSDG · Ethereum81HighFrankencoinZCHF · Ethereum81HighHeyAnonANON · Ethereum81HighKyber Network Crystal v2KNC · Ethereum81HighRe Protocol reUSDREUSD · Ethereum82HighRallyEthereum80High

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 Is this your token? Publish your own audit on this page