Is Boop Safe? Smart Contract Security Analysis

Security Findings

1 Crit2 High2 Med1 Low

Critical

Truncated Code Prevents Full Audit

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

IssueThe 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).

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

StatusUnresolved

High

Centralized Control and Owner Privileges

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

IssueThe 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).

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

StatusUnresolved

High

Constructor Ownership Transfer Logic

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

IssueThe 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).

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

StatusUnresolved

Medium

Redundant SafeMath Usage

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

IssueThe 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).

FixRemove 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`.

StatusUnresolved

Medium

Anti-Bot/Anti-Whale Mechanisms as DoS Vectors

M-02The 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).

IssueThe 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).

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

StatusUnresolved

Low

Lack of Event Emission for Critical State Changes

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

IssueThe 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).

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

StatusUnresolved

Category Ratings

TechnicalMedium6/10

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

GovernanceMedium4/10

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.

UpgradesLow8/10

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.

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

22.6% in top 10

14.4% in wallets8.2% in contracts

Effective Concentration17.7%

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

$177.1K across 6 pairs

CamelotWETHanalysed$151.0K UniswapWETH$22.2K Camelot v3WETH$3.6K Uniswap v2WETH$302 DeltaswapWETH$45

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 Holder93.9%

Top-3 Unlocked99.9%

Key Addresses

8 addresses

Deployer

0xd5d1…f24c

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.

What Raised This Score

7 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

Is Boop Safe?

Security Findings

Truncated Code Prevents Full Audit

Centralized Control and Owner Privileges

Constructor Ownership Transfer Logic

Redundant SafeMath Usage

Anti-Bot/Anti-Whale Mechanisms as DoS Vectors

Lack of Event Emission for Critical State Changes

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of Boop?