Honeypot, rug-pull and ownership checks
The ToshiToken contract is an ERC20 token implementation based on OpenZeppelin Contracts v4.x.
Read the full analysisEach 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
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.
Holder balances as recorded by the audit of Sep 4, 2026
The 20 remaining pairs hold $4.3K between them and are not listed. The risk score reads depth across every pair.
Whether the LP tokens are locked could not be determined.
recoverERC20 function) risks locking tokens sent to it mistakenly or from unsupported protocols. This is a general consideration for contracts holding assets.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.
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.
Unresolved
pragma experimental ABIEncoderV2pragma 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.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.
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.
Unresolved
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.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.
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.
Unresolved
approve Race Conditionapprove 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.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.
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).
Unresolved
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.
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.
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).
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.
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.
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
Paste the contract address into our AI-powered scanner for a deeper real-time report — free, with every scoring factor shown.
Get Detailed Audit Is this your token? Publish your own audit on this page
