Is Shiro Neko (SHIRO) Safe? Smart Contract Security Analysis

Security Findings

1 Crit2 High2 Med

Critical

Critical External Dependency on IVerifier

C-01The `_transfer` function critically relies on an external `IVerifier` contract for authorization during transfers (`verifier.verify(from, to)`). If the `IVerifier` contract is compromised, malicious, or malfunctions, it could arbitrarily block legitimate transfers or allow unauthorized ones, leading to a complete breakdown of the token's transfer mechanism. This represents a single point of failure for the entire token system (7.6).

IssueThe `_transfer` function critically relies on an external `IVerifier` contract for authorization during transfers (`verifier.verify(from, to)`). If the `IVerifier` contract is compromised, malicious, or malfunctions, it could arbitrarily block legitimate transfers or allow unauthorized ones, leading to a complete breakdown of the token's transfer mechanism. This represents a single point of failure for the entire token system (7.6).

FixThoroughly audit the `IVerifier` contract for vulnerabilities. Implement robust monitoring for the `IVerifier` contract's behavior. Consider adding a mechanism for the owner to pause transfers or replace the `IVerifier` contract in an emergency, or to disable the verification requirement if the verifier becomes unresponsive or malicious. Ensure the `IVerifier` contract's access control and upgradeability are secure.

StatusUnresolved

High

High Centralization of Control by Owner

H-01The `owner` role, protected by OpenZeppelin's `Ownable` contract, possesses extensive control over critical contract parameters and functionalities. This includes enabling/disabling transfer limits and cooldowns, excluding addresses from limits, setting AMM pairs and routers, and marking addresses as bots. This high degree of centralization introduces significant trust assumptions and potential for abuse or single point of failure if the owner's private key is compromised (7.5, 7.8).

IssueThe `owner` role, protected by OpenZeppelin's `Ownable` contract, possesses extensive control over critical contract parameters and functionalities. This includes enabling/disabling transfer limits and cooldowns, excluding addresses from limits, setting AMM pairs and routers, and marking addresses as bots. This high degree of centralization introduces significant trust assumptions and potential for abuse or single point of failure if the owner's private key is compromised (7.5, 7.8).

FixConsider migrating ownership to a multi-signature wallet (e.g., Gnosis Safe) to distribute control and require multiple approvals for critical operations. Implement a timelock for sensitive owner actions to provide a window for community review or emergency intervention. Clearly communicate the extent of owner privileges to token holders.

StatusUnresolved

High

Irreversible AMM Pair and Router Configuration

H-02The `setAutomatedMarketMakerPair` and `setRouter` functions include a `require` statement (`require(!automatedMarketMakerPairs[account], AMMAlreadySet());` and `require(!routers[account], RouterAlreadySet());`) that prevents an address from being set as an AMM pair or router if it has already been configured. This means once an address is marked as an AMM pair or router (by setting `value` to `true`), it cannot be unset or changed. This design limits flexibility and could lead to issues if a configured AMM or router becomes deprecated, compromised, or needs to be updated (7.4).

IssueThe `setAutomatedMarketMakerPair` and `setRouter` functions include a `require` statement (`require(!automatedMarketMakerPairs[account], AMMAlreadySet());` and `require(!routers[account], RouterAlreadySet());`) that prevents an address from being set as an AMM pair or router if it has already been configured. This means once an address is marked as an AMM pair or router (by setting `value` to `true`), it cannot be unset or changed. This design limits flexibility and could lead to issues if a configured AMM or router becomes deprecated, compromised, or needs to be updated (7.4).

FixRemove the `require` statements that prevent re-setting AMM pairs or routers. This would allow the owner to update or remove configurations as needed, providing greater flexibility and adaptability to future changes in the DeFi ecosystem. Alternatively, implement a separate function to remove or replace existing configurations.

StatusUnresolved

Medium

Potential Reentrancy in `withdrawStuckTokens` (Owner Risk)

M-01The `withdrawStuckTokens` function, when withdrawing ETH (`tkn == ZERO_ADDRESS`), uses a low-level `call{value: amount}("")` to send ETH to `msg.sender`. If `msg.sender` (the owner) is a malicious contract, it could potentially reenter this function before the contract's balance is updated, leading to a reentrancy attack against the owner's funds. While this primarily affects the owner, it's a common vulnerability pattern (7.2).

IssueThe `withdrawStuckTokens` function, when withdrawing ETH (`tkn == ZERO_ADDRESS`), uses a low-level `call{value: amount}("")` to send ETH to `msg.sender`. If `msg.sender` (the owner) is a malicious contract, it could potentially reenter this function before the contract's balance is updated, leading to a reentrancy attack against the owner's funds. While this primarily affects the owner, it's a common vulnerability pattern (7.2).

FixImplement the Checks-Effects-Interactions pattern by setting `amount = 0` or updating the contract's state *before* the external call. Alternatively, use OpenZeppelin's `ReentrancyGuard` or a pull-over-push pattern for withdrawals to prevent reentrant calls.

StatusUnresolved

Medium

`tx.origin` Usage for Exclusion and Cooldown

M-02The contract uses `tx.origin` in the constructor for `_excludeFromLimits` and within the `_transfer` function for `_holderLastTransferBlock` and `isBot` checks. While `tx.origin` is not used for direct authorization in a way that would enable a critical phishing attack (e.g., `require(tx.origin == owner)`), its general use can be a vector for phishing attacks where a user is tricked into interacting with a malicious contract that then calls the legitimate contract. In such a scenario, `tx.origin` would still refer to the user's EOA, potentially bypassing some intended restrictions if the malicious contract is not itself excluded (7.2).

IssueThe contract uses `tx.origin` in the constructor for `_excludeFromLimits` and within the `_transfer` function for `_holderLastTransferBlock` and `isBot` checks. While `tx.origin` is not used for direct authorization in a way that would enable a critical phishing attack (e.g., `require(tx.origin == owner)`), its general use can be a vector for phishing attacks where a user is tricked into interacting with a malicious contract that then calls the legitimate contract. In such a scenario, `tx.origin` would still refer to the user's EOA, potentially bypassing some intended restrictions if the malicious contract is not itself excluded (7.2).

FixWhile the current usage is less critical, it's generally recommended to avoid `tx.origin` where possible. For `_holderLastTransferBlock` and `isBot` checks, consider using `msg.sender` instead of `tx.origin` if the intent is to track the direct caller. For exclusions, ensure that any contract interacting with the token is also properly excluded if needed.

StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract utilizes Solidity 0.8.28, benefiting from built-in overflow/underflow checks. Standard OpenZeppelin libraries are used for ERC20 and Ownable functionalities, enhancing code security (7.2). However, a critical external dependency on the `IVerifier` contract introduces a single point of failure, as its compromise or malfunction directly impacts all token transfers (7.6). Additionally, the `withdrawStuckTokens` function, while useful for recovery, uses a low-level call for ETH transfers without reentrancy guards, posing a risk if the owner's address is a malicious contract (7.2). The use of `tx.origin` in some checks, while not directly exploitable for authorization, can be a vector for phishing attacks (7.2).

GovernanceMedium6/10

The ShiroToken contract exhibits significant centralization, with the `owner` having extensive control over critical parameters such as `limitsEnabled`, `cooldownEnabled`, `isExcludedFromLimits`, `automatedMarketMakerPairs`, `routers`, and `isBot` (7.5). This centralized control allows the owner to significantly influence token transfer behavior and potentially manipulate market dynamics. A notable design flaw is the irreversible nature of setting `automatedMarketMakerPairs` and `routers` to `true`, preventing future adjustments or corrections (7.4). The anti-bot and cooldown mechanisms are in place to manage early trading, but their effectiveness is highly dependent on the owner's operational decisions (7.8).

UpgradesLow9/10

The ShiroToken contract is not designed to be upgradeable. It does not implement any proxy patterns (e.g., UUPS, Transparent, Beacon). Therefore, there are no upgrade-specific risks (7.7). Any changes to the contract logic would require a new deployment and migration of assets.

Security Checklist

5/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

55.9% in top 10

43.6% in wallets12.3% in contracts

Effective Concentration48.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

$124.9K

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

LP Burned99.9% · ≈ permanent lock

LP Locked99.9% · Null Address

Key Addresses

5 addresses

Deployer

0x786f…e71e

Unlocked LP Held By

0x61ff…4b060x9d24…123b0xa5d9…8aa20x861b…10c2

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

What Raised This Score

4 factors

Top-10 concentration > 30% (55.9% total → 48.5% effective; 43.6% in EOAs, 12.3% in contracts — moderate)
1 Critical finding(s) from audit
2 High finding(s) from audit
2 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

Final Recommendation

AI Copilot

It is highly recommended to review the `IVerifier` contract's security and ensure its integrity, as it is a critical external dependency.…

Read the verdictHide

Consider implementing a multi-signature wallet for the `owner` role to mitigate centralization risks and enhance security for critical operations. For the `withdrawStuckTokens` function, implement a reentrancy guard or use a pull-over-push pattern for ETH withdrawals to protect against potential reentrancy. Evaluate the necessity of irreversible AMM/router configurations and consider adding functionality for the owner to update or remove these if needed for future flexibility.

Contract

TypeShiroToken

Audit History

1 audit on record

Sep 1328

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Not Signed In

Is Shiro Neko Safe?

Security Findings

Critical External Dependency on IVerifier

High Centralization of Control by Owner

Irreversible AMM Pair and Router Configuration

Potential Reentrancy in `withdrawStuckTokens` (Owner Risk)

`tx.origin` Usage for Exclusion and Cooldown

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of Shiro Neko?