Quantum Audit Logo

Is Atoshi a Scam?

Honeypot, rug-pull and ownership checks

Is this your token? Publish your own audit on this page →

Atoshi ATOS
0x4d05…4b18
Ethereum
Not verifiedThis 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 today 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The Atoshi contract is a basic ERC-20 token implementation. The audit identified a critical integer overflow vulnerability in addition operations, which can lead to incorrect balance updates and potential loss of funds. Additionally, the standard ERC-20 `approve` function is susceptible to a known front-running attack. Several minor issues related to missing zero-address and zero-value checks were also noted. The contract is not upgradeable and has a simple economic model.

1 Critical1 High2 Low
i Our automated scanner reviewed Atoshi (ATOS) on Ethereum. 3 of 5 security checks passed — see the full breakdown below.
Volume 24h
$67.5K
Liquidity
$159.9K
Price
$0.04839
Age
2y
Top 10 Holders
98.2%

Security Findings

1 Crit1 High2 Low
Critical

Integer Overflow in Addition Operations

C-01The `balances[_to] += _value` operations in both the `transfer` and `transferFrom` functions are susceptible to integer overflow. In Solidity versions prior to 0.8.0, arithmetic operations do not automatically revert on overflow. If `balances[_to]` is a large number and `_value` is also large, their sum could exceed `2**256 - 1`, causing the balance to wrap around to a smaller number. This can lead to incorrect balance tracking and potential loss of funds for users or manipulation of the total supply.
IssueThe `balances[_to] += _value` operations in both the `transfer` and `transferFrom` functions are susceptible to integer overflow. In Solidity versions prior to 0.8.0, arithmetic operations do not automatically revert on overflow. If `balances[_to]` is a large number and `_value` is also large, their sum could exceed `2**256 - 1`, causing the balance to wrap around to a smaller number. This can lead to incorrect balance tracking and potential loss of funds for users or manipulation of the total supply.
FixImplement a SafeMath library for all arithmetic operations, especially additions, to ensure that overflows are checked and revert the transaction if they occur. For example, use `add(balances[_to], _value)` from OpenZeppelin's SafeMath.
StatusUnresolved
High

ERC-20 `approve` Race Condition Vulnerability

H-01The standard ERC-20 `approve` function is vulnerable to a known front-running attack. If a user approves an amount for a spender, and then later approves a different (usually higher) amount without first setting the allowance to zero, a malicious actor can front-run the second `approve` transaction. The attacker can spend the original allowance, and then the second `approve` transaction will succeed, allowing the attacker to spend the newly approved amount as well, effectively spending more than the user intended.
IssueThe standard ERC-20 `approve` function is vulnerable to a known front-running attack. If a user approves an amount for a spender, and then later approves a different (usually higher) amount without first setting the allowance to zero, a malicious actor can front-run the second `approve` transaction. The attacker can spend the original allowance, and then the second `approve` transaction will succeed, allowing the attacker to spend the newly approved amount as well, effectively spending more than the user intended.
FixWhile this is a known ERC-20 design flaw, it can be mitigated. Advise users to always set their allowance to zero before approving a new, non-zero amount. Alternatively, consider implementing `increaseAllowance` and `decreaseAllowance` functions (as seen in later ERC-20 standards) which are not susceptible to this race condition.
StatusUnresolved
Low

Missing Zero-Address Checks

L-01The `transfer` and `transferFrom` functions do not include checks to prevent sending tokens to the zero address (`address(0)`). While sending tokens to the zero address effectively burns them, this might be an unintended action by the user and can lead to irreversible loss of tokens.
IssueThe `transfer` and `transferFrom` functions do not include checks to prevent sending tokens to the zero address (`address(0)`). While sending tokens to the zero address effectively burns them, this might be an unintended action by the user and can lead to irreversible loss of tokens.
FixAdd a `require(_to != address(0), "ERC20: transfer to the zero address")` check at the beginning of the `transfer` and `transferFrom` functions to prevent accidental burning of tokens.
StatusUnresolved
Low

Missing Zero-Value Checks

L-02The `transfer` and `transferFrom` functions do not explicitly check if the `_value` parameter is zero. While transferring zero tokens has no functional impact on balances, it still consumes gas and emits an event. This can lead to unnecessary transaction costs.
IssueThe `transfer` and `transferFrom` functions do not explicitly check if the `_value` parameter is zero. While transferring zero tokens has no functional impact on balances, it still consumes gas and emits an event. This can lead to unnecessary transaction costs.
FixConsider adding a `require(_value > 0, "ERC20: transfer amount must be greater than zero")` check to the `transfer` and `transferFrom` functions to prevent zero-value transfers and save gas.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The technical architecture (7.1) is a standard ERC-20 implementation, which is straightforward. However, the code security (7.2) is significantly compromised by a critical integer overflow vulnerability in addition operations within the `transfer` and `transferFrom` functions, a common pitfall in Solidity 0.4.x. Access control (7.3) is minimal, as expected for a simple token, with no special privileges for the deployer post-initialization. External interactions (7.6) are limited to standard ERC-20 transfers, but the `approve` function is susceptible to a known front-running attack. Operational aspects (7.8) are simple, with no complex roles or pause mechanisms.

GovernanceHigh1/10

The economic model (7.4) is very simple: a fixed supply token minted entirely to the deployer at creation, with no further minting, burning, or fee mechanisms. This simplicity reduces complexity and associated economic risks. There are no governance mechanisms (7.5) implemented, as it's a basic token contract, meaning no complex decision-making processes or associated risks. The lack of special administrative functions after deployment contributes to a low governance risk profile.

UpgradesMedium5/10

The Atoshi contract is not designed to be upgradeable (7.7). It does not implement any proxy patterns (e.g., UUPS, Transparent, Beacon) or other mechanisms for future modification. This means there are no upgrade-related risks such as proxy misconfigurations, storage collisions, or logic errors during an upgrade. Any changes would require a new deployment.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

98.2% in top 10
98.2% in wallets0.0% in contracts
Effective Concentration98.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

$249.7K across 5 pairs
Uniswap v3WETHanalysed$159.9K64.1%Uniswap v4ETH$75.9K30.4%Uniswap v3USDT$12.1K4.8%Uniswap v2USDT$1.8K0.7%Uniswap v4USDC$50.0%

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 Holder80.2%
Top-3 Unlocked100.0%

Key Addresses

4 addresses
Deployer
0x8a88…260c
Unlocked LP Held By
0x7a38…a70d0x7c20…f9850x622a…4341

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

What Raised This Score

8 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Top-10 concentration > 70% (98.2% total → 98.2% effective; 98.2% in EOAs, 0.0% in contracts — extreme)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 80.2% (independent LP — depth risk, pool = 64% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 64% of DEX liquidity)
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 2 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

Related Audits

6 more on the record
Gram (prev. Toncoin) (GRAM)High RiskAmpleforth (AMPL)High RiskStarknet (STRK)High RiskREHigh RiskZamaHigh RiskUNICURVEHigh Risk

Would You Like a More Detailed Audit of Atoshi?

Paste the contract address into our AI-powered scanner for a deeper real-time report — free, with every scoring factor shown.

Get Detailed Audit