Is Book of Ethereum (BOOE) Safe? Smart Contract Security Analysis

Security Findings

1 Crit1 High1 Med1 Info

Critical

Unchecked Arithmetic in Token Transfers and Minting

C-01The `_transfer` function uses `unchecked` blocks for `_balances[to] += amount;` and the `_mint` function uses `unchecked` for `_balances[account] += amount;`. This means that if `_balances[to]` or `_balances[account]` plus `amount` exceeds `type(uint256).max`, the value will wrap around to a small number instead of reverting. This can lead to incorrect user balances, token supply manipulation, and potential loss of funds for users or arbitrary token creation by an attacker if they can control the `amount` or `to` address in specific scenarios. This directly violates the integrity of the token's accounting.

IssueThe `_transfer` function uses `unchecked` blocks for `_balances[to] += amount;` and the `_mint` function uses `unchecked` for `_balances[account] += amount;`. This means that if `_balances[to]` or `_balances[account]` plus `amount` exceeds `type(uint256).max`, the value will wrap around to a small number instead of reverting. This can lead to incorrect user balances, token supply manipulation, and potential loss of funds for users or arbitrary token creation by an attacker if they can control the `amount` or `to` address in specific scenarios. This directly violates the integrity of the token's accounting.

FixRemove the `unchecked` blocks from addition operations in `_transfer` and `_mint` functions. Solidity 0.8+ by default checks for overflow/underflow, so removing `unchecked` will ensure these operations revert on overflow, maintaining token integrity. Alternatively, implement explicit overflow checks before the addition if `unchecked` is desired for gas optimization in other contexts.

StatusUnresolved

High

Inconsistent Unchecked Arithmetic for Total Supply

H-01In the `_mint` function, `_totalSupply += amount;` is *not* within an `unchecked` block, meaning it will revert on overflow. However, `_balances[account] += amount;` *is* within an `unchecked` block, meaning it will wrap around on overflow. This inconsistency can lead to a state where `_totalSupply` does not accurately reflect the sum of all token balances, breaking a fundamental invariant of ERC20 tokens. If `_balances[account]` overflows and wraps around while `_totalSupply` reverts, the token's accounting becomes corrupted, potentially leading to denial of service for minting or incorrect total supply reporting.

IssueIn the `_mint` function, `_totalSupply += amount;` is *not* within an `unchecked` block, meaning it will revert on overflow. However, `_balances[account] += amount;` *is* within an `unchecked` block, meaning it will wrap around on overflow. This inconsistency can lead to a state where `_totalSupply` does not accurately reflect the sum of all token balances, breaking a fundamental invariant of ERC20 tokens. If `_balances[account]` overflows and wraps around while `_totalSupply` reverts, the token's accounting becomes corrupted, potentially leading to denial of service for minting or incorrect total supply reporting.

FixEnsure consistent arithmetic handling for `_totalSupply` and individual `_balances`. If `unchecked` is used for `_balances` additions, it should also be used for `_totalSupply` additions, or vice-versa. The safest approach is to remove `unchecked` for all additions, allowing Solidity's default overflow checks to protect both `_totalSupply` and `_balances`.

StatusUnresolved

Medium

Redundant SafeMath Library

M-01The `SafeMath` library is included in the contract, but the `ERC20` implementation directly uses native arithmetic operators, often within `unchecked` blocks, rather than calling `SafeMath` functions. In Solidity 0.8+, arithmetic operations automatically revert on overflow/underflow unless explicitly placed in an `unchecked` block. The presence of `SafeMath` without its use suggests a potential misunderstanding of Solidity's arithmetic safety features or an incomplete refactor, leading to unnecessary bytecode and potential confusion for future developers.

IssueThe `SafeMath` library is included in the contract, but the `ERC20` implementation directly uses native arithmetic operators, often within `unchecked` blocks, rather than calling `SafeMath` functions. In Solidity 0.8+, arithmetic operations automatically revert on overflow/underflow unless explicitly placed in an `unchecked` block. The presence of `SafeMath` without its use suggests a potential misunderstanding of Solidity's arithmetic safety features or an incomplete refactor, leading to unnecessary bytecode and potential confusion for future developers.

FixEither fully integrate `SafeMath` for all arithmetic operations (if targeting older Solidity versions or specific `unchecked` behavior is not desired) or remove the `SafeMath` library entirely if relying on Solidity 0.8+'s default overflow checks and `unchecked` blocks where appropriate. For Solidity 0.8+, it's generally recommended to rely on the default checks and only use `unchecked` for specific, proven-safe operations.

StatusUnresolved

Info

Missing Context Contract Definition

I-01The `ERC20` contract inherits from `Context`, which provides the `_msgSender()` function. However, the source code for the `Context` contract was not provided in the audit scope. While it is highly probable that this refers to the standard OpenZeppelin `Context` contract, its absence means a full verification of its implementation and security cannot be performed.

IssueThe `ERC20` contract inherits from `Context`, which provides the `_msgSender()` function. However, the source code for the `Context` contract was not provided in the audit scope. While it is highly probable that this refers to the standard OpenZeppelin `Context` contract, its absence means a full verification of its implementation and security cannot be performed.

FixFor a complete audit, ensure all dependent contract source codes are provided. If using OpenZeppelin contracts, explicitly state the version used.

StatusUnresolved

Category Ratings

TechnicalLow7/10

The technical architecture is a custom ERC20 implementation, which deviates from battle-tested OpenZeppelin standards, introducing significant risk (7.1 Architecture). Critical code security flaws exist, specifically unchecked arithmetic in `_mint` and `_transfer` functions, allowing for balance overflows and underflows (7.2 Code Security). The contract also exhibits inconsistent use of `unchecked` blocks, leading to potential discrepancies between `_totalSupply` and individual balances. While `Ownable` is imported, the direct access control for `_mint` and `_burn` relies on the calling contract, which is not fully provided (7.3 Access Control).

GovernanceLow8/10

The economic model of the token is a standard ERC20 with minting and burning capabilities. The primary economic risk stems from the critical technical vulnerabilities that could lead to arbitrary token creation or destruction, directly impacting the token's supply and value (7.4 Economic). While `Ownable` is imported, the specific access control mechanisms for `_mint` and `_burn` within the `BookOfEth` contract (not fully provided) are crucial for mitigating these economic risks (7.5 Governance). Without strong governance over minting/burning, the economic stability is severely compromised.

UpgradesLow9/10

The provided contract is a standard, non-upgradeable ERC20 token implementation. There are no proxy patterns or upgrade mechanisms implemented, which simplifies the upgrade safety analysis (7.7 Upgrades). Therefore, the risk associated with upgrades is considered low, as no upgrade path exists for this specific contract.

Security Checklist

5/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

35.4% in top 10

17.6% in wallets17.8% in contracts

Effective Concentration24.8%

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

$565.4K across 4 pairs

Uniswap v2WETHanalysed$553.7K Uniswap v3WETH$11.0K Uniswap v2MOTO$693

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 Locked99.7% · Null Address, TeamFinance

Top-1 Unlocked Holder0.3%

Key Addresses

6 addresses

Deployer

0xc632…1ffb

Unlocked LP Held By

0x51e6…aca40xf385…5f850x825b…19d30x225f…b3740x1f2f…f387

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

What Raised This Score

4 factors

Top-10 concentration > 20% (35.4% total → 24.8% effective; 17.6% in EOAs, 17.8% in contracts — mild)
1 Critical finding(s) from audit
1 High finding(s) from audit
1 Medium 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

Not Signed In

Is Book of Ethereum Safe?

Security Findings

Unchecked Arithmetic in Token Transfers and Minting

Inconsistent Unchecked Arithmetic for Total Supply

Redundant SafeMath Library

Missing Context Contract Definition

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 Book of Ethereum?