Quantum Audit Logo

Is SushiToken Safe?

On-chain security analysis — is it a scam or legit?

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

SushiToken SUSHI
0x6b35…0fe2
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

This audit covers a partial Solidity codebase for an ERC-20 token, including standard OpenZeppelin-like implementations for Context, IERC20, SafeMath, Address, ERC20, and Ownable. The contract leverages SafeMath for arithmetic safety. Key findings include centralized control via the owner, lack of an emergency pause mechanism, and the inherent ERC20 approve race condition. The audit is limited by the absence of the full SushiToken contract, which would define specific business logic and owner-callable functions.

1 High1 Medium1 Low2 Informational
Volume 24h
$58.4K
Liquidity
$971.3K
Price
$0.1999
Token Age
3y
Top 10 Holders
42.8%

Security Findings

1 High1 Med1 Low2 Info
High

Centralized Control via Owner Privileges

H-01The `Ownable` pattern grants a single address significant control over the contract. While `_mint` and `_burn` functions are internal in the provided ERC20 base, if the full `SushiToken` contract exposes these to the owner, it would allow unilateral inflation or deflation of the token supply. Even without direct mint/burn, the owner can transfer ownership, which is a critical privilege. The current owner being an `OZ_ProxyAdmin` implies a potentially upgradeable or complex governance structure for the owner itself, which could change the entity controlling the token.
IssueThe `Ownable` pattern grants a single address significant control over the contract. While `_mint` and `_burn` functions are internal in the provided ERC20 base, if the full `SushiToken` contract exposes these to the owner, it would allow unilateral inflation or deflation of the token supply. Even without direct mint/burn, the owner can transfer ownership, which is a critical privilege. The current owner being an `OZ_ProxyAdmin` implies a potentially upgradeable or complex governance structure for the owner itself, which could change the entity controlling the token.
FixImplement a multi-signature wallet or a time-lock contract for ownership and critical administrative functions. This decentralizes control, adds a delay for sensitive operations, and reduces the risk of a single point of failure or malicious action. Clearly document the capabilities of the owner in the full `SushiToken` contract.
StatusUnresolved
Medium

Lack of Emergency Pause Mechanism

M-01The contract lacks a `Pausable` mechanism, which could be crucial for mitigating risks during emergencies such as critical vulnerabilities, market exploits, or unexpected behavior. Without the ability to pause transfers or other critical functions, the protocol would be unable to react swiftly to prevent further damage.
IssueThe contract lacks a `Pausable` mechanism, which could be crucial for mitigating risks during emergencies such as critical vulnerabilities, market exploits, or unexpected behavior. Without the ability to pause transfers or other critical functions, the protocol would be unable to react swiftly to prevent further damage.
FixIntegrate OpenZeppelin's `Pausable` contract or a similar mechanism to allow the owner (preferably a multi-sig or governance) to pause and unpause critical operations. This provides an essential emergency stop functionality.
StatusUnresolved
Low

ERC20 `approve` Race Condition

L-01The standard `approve` function is susceptible to a known race condition. If a user approves an amount, and then attempts to approve a different amount, a malicious spender could front-run the second `approve` transaction. This could result in the spender being able to spend both the original and the new approved amounts, potentially draining funds beyond the user's intent. While `increaseAllowance` and `decreaseAllowance` mitigate this, direct `approve` calls remain vulnerable.
IssueThe standard `approve` function is susceptible to a known race condition. If a user approves an amount, and then attempts to approve a different amount, a malicious spender could front-run the second `approve` transaction. This could result in the spender being able to spend both the original and the new approved amounts, potentially draining funds beyond the user's intent. While `increaseAllowance` and `decreaseAllowance` mitigate this, direct `approve` calls remain vulnerable.
FixEducate users to use `increaseAllowance` and `decreaseAllowance` instead of directly calling `approve` when modifying an existing allowance. If `approve` must be used, users should first set the allowance to zero before setting a new value.
StatusUnresolved
Info

Incomplete Contract Context

I-01The provided code snippet represents core ERC20 and utility contracts (`Context`, `IERC20`, `SafeMath`, `Address`, `ERC20`, `Ownable`). However, the specific `SushiToken` contract implementation, which would inherit and potentially extend these with unique business logic, constructor parameters, and owner-callable functions, is missing. This limits the scope of a full security assessment, as specific functionalities and their interactions are not visible.
IssueThe provided code snippet represents core ERC20 and utility contracts (`Context`, `IERC20`, `SafeMath`, `Address`, `ERC20`, `Ownable`). However, the specific `SushiToken` contract implementation, which would inherit and potentially extend these with unique business logic, constructor parameters, and owner-callable functions, is missing. This limits the scope of a full security assessment, as specific functionalities and their interactions are not visible.
FixProvide the complete source code for the `SushiToken` contract to enable a comprehensive security audit of its specific logic, state variables, and function implementations.
StatusUnresolved
Info

Older Solidity Compiler Version

I-02The contract uses Solidity `^0.6.0`. While this version is functional, newer compiler versions (e.g., 0.8.x) include additional safety checks by default (e.g., integer overflow/underflow protection without explicit SafeMath) and introduce language features that can improve code robustness, efficiency, and readability.
IssueThe contract uses Solidity `^0.6.0`. While this version is functional, newer compiler versions (e.g., 0.8.x) include additional safety checks by default (e.g., integer overflow/underflow protection without explicit SafeMath) and introduce language features that can improve code robustness, efficiency, and readability.
FixConsider upgrading the Solidity compiler version to a more recent stable release (e.g., 0.8.x) to benefit from improved security features and optimizations. Ensure thorough testing if an upgrade is performed.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The technical architecture (7.1 Architecture) is based on well-established ERC-20 standards and OpenZeppelin patterns, utilizing SafeMath for robust arithmetic operations (7.2 Code Security). This provides a solid foundation for token functionality. However, the contract lacks an emergency pause mechanism, which could be critical for mitigating unforeseen vulnerabilities or market exploits. Additionally, the standard ERC20 `approve` function remains susceptible to a known race condition (7.2 Code Security), despite the presence of `increaseAllowance` and `decreaseAllowance` functions.

GovernanceHigh3/10

The contract employs an `Ownable` pattern (7.3 Access Control), granting significant centralized control to a single address. The prefill indicates this owner is an `OZ_ProxyAdmin` (7.5 Governance), which implies a complex governance structure for the owner itself, potentially allowing its logic to be upgraded. While `_mint` and `_burn` are internal, if the full `SushiToken` contract exposes these to the owner, it introduces a high economic risk (7.4 Economic) of supply manipulation. The lack of a multi-signature wallet or time-lock for critical owner actions further centralizes risk.

UpgradesHigh3/10

Based on the provided prefill data, the contract itself is not a proxy (`is_proxy: false`), meaning it is not directly upgradeable (7.7 Upgrades). This reduces the risk associated with upgrade mechanisms. However, the owner being an `OZ_ProxyAdmin` suggests that the entity controlling the contract's ownership might be upgradeable, which is an indirect form of upgradeability for the control mechanism, impacting governance rather than the contract's code directly.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

42.8% in top 10
36.6% in wallets6.2% in contracts
Effective Concentration39.1%

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.41M across 27 pairs
Sushiswap v3WETHanalysed$971.3K68.9%SushiswapWETH$247.3K17.5%Uniswap v2WETH$131.5K9.3%SushiswapFRAX$22.6K1.6%Sushiswap v3ZIK$10.6K0.7%Uniswap v3WETH$7.5K0.5%
Show 4 more pairsShow less
ShibaswapWETH$6.1K0.4%0x2f3D…d03CWETH$4.9K0.3%Uniswap v3UNI$3.3K0.2%Sushiswap v3WETH$1.4K0.1%

The 17 remaining pairs hold $3.2K 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
0xf942…a6bd

What Raised This Score

7 factors
  • Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (42.8% total → 39.1% effective; 36.6% in EOAs, 6.2% in contracts — moderate)
  • Liquidity NOT locked (owner can withdraw — rug-pull risk)
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 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
SPACE ID (ID)High RiskUSDS Stablecoin (USDS)High RiskMarlin POND (POND)High RiskEspresso (ESP)High RiskSEIHigh RiskDolomite (DOLO)High Risk

Would You Like a More Detailed Audit of SushiToken?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit