Quantum Audit Logo

Is Toshi a Scam?

Honeypot, rug-pull and ownership checks

Toshi TOSHI
0xac1b…b2b4
Base Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Low Risk
Executive SummaryAI Copilot

The ToshiToken contract is an ERC20 token implementation based on OpenZeppelin Contracts v4.x. The provided code snippet indicates a standard, well-tested foundation. No critical or high-severity vulnerabilities were identified. Minor informational findings relate to standard ERC20 characteristics and a non-critical pragma usage.

1 Low3 Informational
i Our automated scanner reviewed Toshi (TOSHI) on Base. 4 of 5 security checks passed — see the full breakdown below.
Volume 24h
$99.8K
Liquidity
$1.13M
Price
$0.0001197
Age
2y
Top 10 Holders
38.5%

Security Findings

1 Low3 Info
Low

Potential for Token Lock if Custom Logic Were Present

L-01While the provided code is a standard ERC20 implementation, any contract that holds tokens and does not include a mechanism for withdrawing arbitrary ERC20 tokens (e.g., a `recoverERC20` function) risks locking tokens sent to it mistakenly or from unsupported protocols. This is a general consideration for contracts holding assets.
IssueWhile the provided code is a standard ERC20 implementation, any contract that holds tokens and does not include a mechanism for withdrawing arbitrary ERC20 tokens (e.g., a `recoverERC20` function) risks locking tokens sent to it mistakenly or from unsupported protocols. This is a general consideration for contracts holding assets.
FixFor contracts intended to hold tokens, consider implementing a `recoverERC20` function, callable only by the owner, to retrieve accidentally sent or stuck tokens. This enhances operational flexibility (7.8 Operations) without compromising core functionality.
StatusUnresolved
Info

Use of `pragma experimental ABIEncoderV2`

I-01The contract includes `pragma experimental ABIEncoderV2;`. While not a vulnerability, `ABIEncoderV2` has been standard since Solidity 0.8.0 and is typically not required to be explicitly enabled in 0.8.17. Its presence might indicate legacy code patterns or specific complex data structures not fully visible in the provided snippet.
IssueThe contract includes `pragma experimental ABIEncoderV2;`. While not a vulnerability, `ABIEncoderV2` has been standard since Solidity 0.8.0 and is typically not required to be explicitly enabled in 0.8.17. Its presence might indicate legacy code patterns or specific complex data structures not fully visible in the provided snippet.
FixReview if `ABIEncoderV2` is strictly necessary for the contract's functionality. If not, it can be removed to simplify the pragma declarations. This is a minor code quality point.
StatusUnresolved
Info

Centralized Ownership

I-02The contract utilizes OpenZeppelin's `Ownable` pattern, which grants a single address (the owner) exclusive control over certain administrative functions (7.3 Access Control). This design introduces a single point of failure, as a compromise of the owner's private key could lead to unauthorized actions.
IssueThe contract utilizes OpenZeppelin's `Ownable` pattern, which grants a single address (the owner) exclusive control over certain administrative functions (7.3 Access Control). This design introduces a single point of failure, as a compromise of the owner's private key could lead to unauthorized actions.
FixFor enhanced security and decentralization, consider transitioning ownership to a multi-signature wallet (e.g., Gnosis Safe) or a robust governance mechanism. This mitigates the risk associated with a single point of failure.
StatusUnresolved
Info

ERC20 `approve` Race Condition

I-03The ERC20 `approve` function is susceptible to a known race condition. If a user increases their allowance for a spender, a malicious actor could front-run this transaction, spend the original allowance, and then spend the newly increased allowance before the user's second transaction confirms. This is a characteristic of the ERC20 standard itself, as noted in the OpenZeppelin `IERC20` interface comments.
IssueThe ERC20 `approve` function is susceptible to a known race condition. If a user increases their allowance for a spender, a malicious actor could front-run this transaction, spend the original allowance, and then spend the newly increased allowance before the user's second transaction confirms. This is a characteristic of the ERC20 standard itself, as noted in the OpenZeppelin `IERC20` interface comments.
FixEducate users about this inherent ERC20 limitation. Recommend using `increaseAllowance` and `decreaseAllowance` functions (if implemented in the full ERC20 contract) or setting the allowance to zero before setting a new value to mitigate this risk. This is a user-side operational concern (7.8 Operations).
StatusUnresolved

Category Ratings

TechnicalLow10/10

The ToshiToken contract is built upon battle-tested OpenZeppelin ERC20 and Ownable implementations, which significantly reduces the likelihood of common technical vulnerabilities (7.2 Code Security). The contract uses Solidity 0.8.17, benefiting from default checked arithmetic. The architecture (7.1 Architecture) is a standard token, minimizing complexity. A minor point is the use of `pragma experimental ABIEncoderV2`, which is often unnecessary in Solidity 0.8.x.

GovernanceMedium6/10

The contract implements a standard ERC20 token with no complex economic models or governance mechanisms (7.5 Governance). Ownership is centralized via OpenZeppelin's Ownable pattern (7.3 Access Control), meaning a single address controls administrative functions (if any were added). This introduces a single point of failure, but is common for simple tokens. There are no external dependencies that introduce oracle manipulation risks (7.6 External).

UpgradesLow8/10

The provided contract is not designed as an upgradeable proxy (7.7 Upgrades). It is a standard, non-upgradeable implementation. Therefore, upgrade safety concerns are not applicable to this specific contract, but any system integrating it should consider its own upgradeability strategy.

Security Checklist

4/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass

Holder Composition

38.5% in top 10
38.5% in wallets0.0% in contracts
Effective Concentration38.5%

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

$1.45M across 30 pairs
Uniswap v3WETHanalysed$1.13M78.1%Uniswap v4ETH$95.5K6.6%Uniswap v2VIRTUAL$63.6K4.4%AerodromeWETH$46.7K3.2%Uniswap v3WETH$42.5K2.9%Uniswap v3USDC$36.0K2.5%
Show 4 more pairsShow less
AerodromeAERO$13.6K0.9%Uniswap v4ETH$6.7K0.5%BaseswapWETH$6.5K0.4%SushiswapWETH$1.6K0.1%

The 20 remaining pairs hold $4.3K 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.

Key Addresses

1 addresses
Deployer
0xbd11…856c

What Raised This Score

3 factors
  • Top-10 concentration > 30% (38.5% total → 38.5% effective; 38.5% in EOAs, 0.0% in contracts — moderate)
  • Liquidity NOT locked (owner can withdraw — rug-pull risk)
  • 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

Related Audits

6 more on the record
mfercoin ($MFER)Low RiskVEIL Token (VEIL)Low RiskdoginmeLow RiskBriun Armstrung (BRIUN)Low RiskKeyboard Cat (KEYCAT)Low RiskCoinye West (COINYE)Low Risk

Would You Like a More Detailed Audit of Toshi?

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

Get Detailed Audit