Quantum Audit Logo
Launch App

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

Is Boop Safe?

BOOPArbitrum
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
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical6/10Governance4/10Upgrades8/10Checks passed6 of 7Findings1 Critical · 2 High · 2 Medium · 1 Low6
SummaryAI Copilot

The Boop token contract implements standard ERC-20 functionality alongside custom features for anti-bot measures, transfer limits, and liquidity management.

Read the full analysis
What raised the score
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 93.9%
  • LP top3 unlocked holders = 99.9%
  • 1 Critical finding(s) from audit
  • 2 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 93.9% (independent LP — depth risk, pool = 85% of DEX liquidity)
  • LP top3 unlocked holders = 99.9% (independent LP — depth risk, pool = 85% of DEX liquidity)
  • 1 Critical finding(s) from audit
  • 2 High finding(s) from audit
  • 2 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 46 of 7 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
8.2%Contracts14.4%Wallets77.4%Everyone else
8.2%14.4%77.4%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
22.6%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking8.2%
  • Walletsanonymous holders, free to sell14.4%
  • Everyone elsethe rest of the supply77.4%
Effective concentrationwhat the score reads17.7%
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$177.1K across 6 pairs

The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$151.0KShare of depth85.3%
Top-1 Unlocked Holder93.9%
Top-3 Unlocked99.9%
Unlocked LP held by
0x54de…e99e0xf45f…95310x0711…3aff0x99f9…b70d0xf96b…18f70x1a83…70a60xc532…26a2

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

Security Findings

1 Critical2 High2 Medium1 Low
Critical

Truncated Code Prevents Full Audit

The provided source code for the _transfer function is incomplete. The function, which is central to all token movements and likely contains critical logic for fees, anti-bot measures, and external interactions, is truncated at _holderLastTransferTimestamp[tx.orig.... This prevents a comprehensive security assessment of the contract's core functionality, leaving significant attack vectors and vulnerabilities potentially undiscovered (7.2 Code Security, 7.6 External).C-01

Issue

The provided source code for the _transfer function is incomplete. The function, which is central to all token movements and likely contains critical logic for fees, anti-bot measures, and external interactions, is truncated at _holderLastTransferTimestamp[tx.orig.... This prevents a comprehensive security assessment of the contract's core functionality, leaving significant attack vectors and vulnerabilities potentially undiscovered (7.2 Code Security, 7.6 External).

Fix

Provide the complete and untruncated source code for all contract functions, especially the _transfer function, to allow for a thorough security audit.

Status

Unresolved

High

Centralized Control and Owner Privileges

The contract owner, utilizing the Ownable pattern, possesses extensive control over critical contract parameters and operations. This includes the ability to manage _maxTxAmount, _maxWalletSize, transferDelayEnabled, bots mapping, and tradingOpen (though specific setter functions are not fully visible in the truncated code, their existence is implied by the state variables). This high degree of centralization introduces a single point of failure and potential for malicious activity or operational errors, such as pausing trading or blocking legitimate users (7.3 Access Control, 7.5 Governance, 7.8 Operations).H-01

Issue

The contract owner, utilizing the Ownable pattern, possesses extensive control over critical contract parameters and operations. This includes the ability to manage _maxTxAmount, _maxWalletSize, transferDelayEnabled, bots mapping, and tradingOpen (though specific setter functions are not fully visible in the truncated code, their existence is implied by the state variables). This high degree of centralization introduces a single point of failure and potential for malicious activity or operational errors, such as pausing trading or blocking legitimate users (7.3 Access Control, 7.5 Governance, 7.8 Operations).

Fix

Consider decentralizing control where feasible, perhaps by implementing a multi-signature wallet for ownership or introducing time-locks for sensitive parameter changes. Clearly document all owner-controlled functions and their potential impact. Implement robust access control checks for all administrative functions.

Status

Unresolved

High

Constructor Ownership Transfer Logic

The constructor includes logic if (_lockOwner != msg.sender) transferOwnership(_lockOwner); to transfer ownership. If _lockOwner is an incorrect address, a contract that cannot accept ownership, or address(0) (which would revert), the contract's ownership could become stuck or transferred to an unintended entity. This could lead to a loss of administrative control over critical contract functions (7.3 Access Control, 7.8 Operations).H-02

Issue

The constructor includes logic if (_lockOwner != msg.sender) transferOwnership(_lockOwner); to transfer ownership. If _lockOwner is an incorrect address, a contract that cannot accept ownership, or address(0) (which would revert), the contract's ownership could become stuck or transferred to an unintended entity. This could lead to a loss of administrative control over critical contract functions (7.3 Access Control, 7.8 Operations).

Fix

Ensure that the _lockOwner address provided during deployment is correct, is an EOA or a contract capable of accepting ownership, and is the intended administrative address. Consider adding a two-step ownership transfer process for the constructor, where the _lockOwner must explicitly claim ownership.

Status

Unresolved

Medium

Redundant SafeMath Usage

The contract uses the SafeMath library for arithmetic operations. While SafeMath is crucial for preventing integer overflows/underflows in Solidity versions prior to 0.8.0, Solidity 0.8.x and later versions include native overflow and underflow checks by default. Therefore, the explicit use of SafeMath adds unnecessary code complexity and slightly increases gas costs without providing additional security benefits in this compiler version (7.2 Code Security).M-01

Issue

The contract uses the SafeMath library for arithmetic operations. While SafeMath is crucial for preventing integer overflows/underflows in Solidity versions prior to 0.8.0, Solidity 0.8.x and later versions include native overflow and underflow checks by default. Therefore, the explicit use of SafeMath adds unnecessary code complexity and slightly increases gas costs without providing additional security benefits in this compiler version (7.2 Code Security).

Fix

Remove the SafeMath library and its using directives. Rely on Solidity's native overflow/underflow checks for arithmetic operations, which are enabled by default in pragma solidity 0.8.21.

Status

Unresolved

Medium

Anti-Bot/Anti-Whale Mechanisms as DoS Vectors

The contract implements several anti-bot and anti-whale mechanisms, including _maxTxAmount, _maxWalletSize, transferDelayEnabled, and the bots mapping. While intended to prevent malicious activity, these features grant significant power to the owner and can be misused or inadvertently cause denial of service for legitimate users, especially large holders, liquidity providers, or automated systems. For example, setting _maxTxAmount too low could prevent necessary liquidity movements (7.4 Economic, 7.8 Operations).M-02

Issue

The contract implements several anti-bot and anti-whale mechanisms, including _maxTxAmount, _maxWalletSize, transferDelayEnabled, and the bots mapping. While intended to prevent malicious activity, these features grant significant power to the owner and can be misused or inadvertently cause denial of service for legitimate users, especially large holders, liquidity providers, or automated systems. For example, setting _maxTxAmount too low could prevent necessary liquidity movements (7.4 Economic, 7.8 Operations).

Fix

Carefully review the parameters and conditions for these anti-bot/anti-whale features. Ensure that they are configured to minimize impact on legitimate users and liquidity. Consider implementing a mechanism for users to appeal bot status or for the community to vote on parameter changes if decentralization is a goal.

Status

Unresolved

Low

Lack of Event Emission for Critical State Changes

The provided code snippet does not show event emissions for changes to several critical contract parameters, such as _maxWalletSize, transferDelayEnabled, or updates to the bots mapping. While MaxTxAmountUpdated is present, comprehensive event logging for all configurable parameters is crucial for transparency, allowing off-chain applications and users to monitor changes and react accordingly (7.8 Operations).L-01

Issue

The provided code snippet does not show event emissions for changes to several critical contract parameters, such as _maxWalletSize, transferDelayEnabled, or updates to the bots mapping. While MaxTxAmountUpdated is present, comprehensive event logging for all configurable parameters is crucial for transparency, allowing off-chain applications and users to monitor changes and react accordingly (7.8 Operations).

Fix

Emit events whenever critical state variables or configuration parameters are modified. This enhances transparency and allows for better off-chain monitoring and auditing of contract behavior.

Status

Unresolved

Analysis

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

The Boop token contract implements standard ERC-20 functionality alongside custom features for anti-bot measures, transfer limits, and liquidity management. A significant limitation of this audit is that the provided source code for the critical _transfer function is truncated, preventing a complete assessment of its internal logic, fee mechanisms, and interaction with external components. This truncation introduces substantial uncertainty regarding the contract's full security posture.

Technical6/10Medium risk

The contract utilizes Solidity 0.8.21 and SafeMath for arithmetic, although the latter is redundant due to native overflow checks. It incorporates anti-reentrancy measures with lockTheSwap for internal swaps. However, the core _transfer function is incomplete, hindering a full review of its security implications, including fee calculations and external calls (7.2 Code Security). The contract also implements _maxTxAmount and _maxWalletSize to control token flow (7.1 Architecture).

Governance4/10Medium risk

The Boop token's economic model includes a fixed total supply, marketing allocation, and mechanisms like _maxTxAmount and _maxWalletSize to manage token distribution and prevent large transactions. Governance is highly centralized, with the Ownable pattern granting the owner extensive control over critical parameters such as trading status, transfer delays, and bot exclusion lists (7.3 Access Control, 7.4 Economic, 7.5 Governance). This centralization introduces significant operational risk.

Upgrades8/10Low risk

The Boop contract is implemented as a standard, non-upgradeable token contract. This design choice ensures immutability, meaning the contract's logic cannot be altered post-deployment (7.7 Upgrades). While this eliminates risks associated with upgrade mechanisms, it also means that any discovered vulnerabilities or desired feature enhancements would necessitate a complete redeployment.

Final RecommendationWhat to do about this score

Address the critical issue of the truncated source code to enable a comprehensive security review, particularly for the _transfer function and any associated fee logic.

Evaluate the extent of centralized control, considering implementing multi-signature wallets for critical owner functions or introducing time-locks for sensitive parameter changes to mitigate single points of failure. Ensure all critical state changes are accompanied by explicit event emissions for transparency and off-chain monitoring.

Contract & Record

1 audit on record
TypeRouter, Token
NetworkArbitrum
Token age2y
Contract0x13a7…72b3
Deployer0xd5d1…f24c
Badge for your website
Boop 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 1, 202644Medium

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

Related Audits

6 more on the recordAll audits
ApeCoinAPE · Arbitrum44MediumCamelot tokenGRAIL · Arbitrum44MediumRAINArbitrum43MediumWrapped liquid staked Ether 2.0WSTETH · Arbitrum42MediumAave TokenAAVE · Arbitrum42MediumSperaxSPA · Arbitrum42Medium

Would You Like a More Detailed Audit of Boop?

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