Is Shiba Inu (SHIB) a Scam? Security Analysis

Security Findings

1 Med3 Info

Medium

ERC20 `approve` Race Condition Vulnerability

M-01The ERC20 standard's `approve` function is susceptible to a known front-running attack. If a user calls `approve(spender, newAmount)` while the `spender` is concurrently attempting to `transferFrom` an `oldAmount`, a malicious actor could front-run the `newAmount` transaction. This could allow the `spender` to spend both the `oldAmount` and the `newAmount`, effectively doubling their allowance for a brief period. While this is an inherent design flaw in the ERC20 standard, it can lead to unexpected token transfers.

IssueThe ERC20 standard's `approve` function is susceptible to a known front-running attack. If a user calls `approve(spender, newAmount)` while the `spender` is concurrently attempting to `transferFrom` an `oldAmount`, a malicious actor could front-run the `newAmount` transaction. This could allow the `spender` to spend both the `oldAmount` and the `newAmount`, effectively doubling their allowance for a brief period. While this is an inherent design flaw in the ERC20 standard, it can lead to unexpected token transfers.

FixImplement and encourage the use of `increaseAllowance` and `decreaseAllowance` functions, which are designed to safely modify allowances by adding or subtracting from the current value. These functions prevent the race condition by ensuring that allowance changes are atomic relative to the current allowance. The provided OpenZeppelin `ERC20` contract description mentions these functions as mitigations, but they are not present in the provided snippet.

StatusUnresolved

Info

Base ERC20 Implementation

I-01The provided contract code represents a base implementation of the ERC20 standard. It includes core functionalities like `transfer`, `transferFrom`, `approve`, `balanceOf`, and `totalSupply`. However, it does not include mechanisms for token minting, burning, or any specific business logic. Its full functionality and security profile will depend on how it is extended by a derived contract.

IssueThe provided contract code represents a base implementation of the ERC20 standard. It includes core functionalities like `transfer`, `transferFrom`, `approve`, `balanceOf`, and `totalSupply`. However, it does not include mechanisms for token minting, burning, or any specific business logic. Its full functionality and security profile will depend on how it is extended by a derived contract.

FixEnsure that any derived contracts that extend this base ERC20 implementation are thoroughly audited. Pay close attention to the implementation of minting, burning, or any custom logic, as these are common sources of vulnerabilities if not handled correctly.

StatusUnresolved

Info

Older OpenZeppelin Contracts Version

I-02The contract uses `pragma solidity ^0.5.0` and appears to be based on an older version of OpenZeppelin Contracts (likely v2.x). While these versions are generally robust, newer versions (e.g., v4.x, v5.x) offer updated patterns, gas optimizations, and potentially new features or security enhancements that have been developed since this version was released.

IssueThe contract uses `pragma solidity ^0.5.0` and appears to be based on an older version of OpenZeppelin Contracts (likely v2.x). While these versions are generally robust, newer versions (e.g., v4.x, v5.x) offer updated patterns, gas optimizations, and potentially new features or security enhancements that have been developed since this version was released.

FixConsider migrating to a more recent version of OpenZeppelin Contracts if possible. This would allow the project to benefit from the latest security best practices, gas efficiencies, and features. A migration would require careful testing and potentially adjustments to the codebase.

StatusUnresolved

Info

Missing `increaseAllowance`/`decreaseAllowance` Functions

I-03The `ERC20` contract description within the OpenZeppelin code explicitly mentions `decreaseAllowance` and `increaseAllowance` as functions added to mitigate the well-known issues around setting allowances (the `approve` race condition). However, these functions are not present in the provided `ERC20` contract snippet. This means users are exposed to the `approve` race condition without the standard OpenZeppelin-provided safe allowance modification methods.

IssueThe `ERC20` contract description within the OpenZeppelin code explicitly mentions `decreaseAllowance` and `increaseAllowance` as functions added to mitigate the well-known issues around setting allowances (the `approve` race condition). However, these functions are not present in the provided `ERC20` contract snippet. This means users are exposed to the `approve` race condition without the standard OpenZeppelin-provided safe allowance modification methods.

FixImplement the `increaseAllowance` and `decreaseAllowance` functions as provided in standard OpenZeppelin ERC20 implementations. This will provide users with safer methods to adjust allowances, reducing the risk associated with the `approve` function.

StatusUnresolved

Category Ratings

TechnicalLow10/10

The technical architecture (7.1) is a standard ERC20 token, utilizing battle-tested OpenZeppelin libraries like SafeMath, which effectively prevents common integer overflow/underflow vulnerabilities (7.2 Code Security). The implementation adheres to the ERC20 standard, ensuring broad compatibility. However, the `approve` function, a part of the ERC20 standard, is susceptible to a known front-running race condition (7.2 Code Security). The provided code is a base ERC20, meaning its full security relies on how it is extended by derived contracts.

GovernanceHigh3/10

The provided contract code is a base ERC20 token and does not include any specific governance mechanisms (7.5 Governance) or complex economic models (7.4 Economic). Therefore, there are no inherent governance or economic risks within this specific codebase. Any economic or governance considerations would arise from how this base token is integrated into a broader protocol.

UpgradesMedium6/10

The contract is a standard, non-upgradeable ERC20 implementation (7.7 Upgrades). It does not utilize any proxy patterns or other upgradeability mechanisms. Consequently, there are no upgrade-specific risks associated with this contract. Any future changes would require a new deployment and migration of assets.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

Holder Composition

64.2% in top 10

64.2% in wallets0.0% in contracts

Effective Concentration64.2%

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

$4.17M across 18 pairs

ShibaswapWETHanalysed$2.88M Uniswap v2WETH$585.5K Uniswap v3WETH$285.2K Uniswap v3WETH$263.9K Uniswap v4ETH$39.2K ShibaswapUSDT$37.8K

Show 4 more pairsShow less

0xD9CE…2509WETH$30.7K ShibaswapUSDC$27.5K Uniswap v2USDT$7.1K Uniswap v3USDC$3.5K

The 8 remaining pairs hold $11.5K between them and are not listed.

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 Holder25.2%

Top-3 Unlocked44.8%

Key Addresses

11 addresses

Deployer

0xb8f2…fa08

Unlocked LP Held By

0xe151…1a310x805e…96650xc78b…70100xe70f…1d7b0x9f06…afed0x5bbc…d3b80x06e7…5c730x3c08…ccb70xdb6a…68940x93a0…2569

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

What Raised This Score

4 factors

Ownership status UNKNOWN (owner could not be resolved)
Top-10 concentration > 50% (64.2% total → 64.2% effective; 64.2% in EOAs, 0.0% in contracts — heavy)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
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

Is Shiba Inu a Scam?

Security Findings

ERC20 `approve` Race Condition Vulnerability

Base ERC20 Implementation

Older OpenZeppelin Contracts Version

Missing `increaseAllowance`/`decreaseAllowance` Functions

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Frequently Asked Questions

Related Audits

Would You Like a More Detailed Audit of Shiba Inu?