Is Toshi a Scam? Security Analysis

Rug Pull Risk Checklist

4/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

Audit History

2 audits on record

Jul 235

Every audit run adds a dated snapshot — history is append-only and cannot be edited.

Audit Summary

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.

Final Recommendation: The ToshiToken contract is a robust implementation of the ERC20 standard, leveraging OpenZeppelin's audited libraries. It is recommended to ensure that the owner address is secured with multi-signature wallets or robust access controls to mitigate the single point of failure inherent in the Ownable pattern. Additionally, users interacting with the `approve` function should be educated on the known ERC20 race condition to prevent potential front-running issues.

Category Ratings

TechnicalLow

10/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

GovernanceMedium

6/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 introd

UpgradesLow

8/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.

What Raised This Score

3 factors

Top-10 concentration > 30% (38.6% total → 38.6% effective; 38.6% 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

Security Findings

4 total

1 Low 3 Info

L-01LowUnresolved

Potential for Token Lock if Custom Logic Were Present

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

Recommendation: For 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.

I-01InformationalUnresolved

Use of `pragma experimental ABIEncoderV2`

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

Recommendation: Review 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.

I-02InformationalUnresolved

Centralized Ownership

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

Recommendation: For 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.

I-03InformationalUnresolved

ERC20 `approve` Race Condition

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

Recommendation: Educate 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).

Is Toshi a Scam? TOSHI