Quantum Audit Logo
Launch App

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

Is SushiToken Safe?

SUSHIEthereum
Not verified This record has not gone through deep verification and is not being monitored. The score is a dated snapshot — the token’s risk can change at any time.Own this token? Put it under verification →
Last checked Sep 4, 2026 · 1 audit on record
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical7/10Governance4/10Upgrades4/10Checks passed4 of 7Findings1 High · 1 Medium · 1 Low · 2 Info5
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.

Read the full analysis
What raised the score
  • Ownership not renounced — owner is a contract
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30%
  • LP lock status UNKNOWN — the pool's LP could not be read
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact 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)
  • LP lock status UNKNOWN — the pool's LP could not be read
  • 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

Security Checklist

as of audit · Sep 44 of 7 checks passed
Contract verifiedVerified
OwnershipRetained
MintMintable
Liquidity lockUnknown
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
6.2%36.6%Wallets57.2%Everyone else
6.2%36.6%Wallets57.2%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
42.8%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking6.2%
  • Walletsanonymous holders, free to sell36.6%
  • Everyone elsethe rest of the supply57.2%
Effective concentrationwhat the score reads39.1%
How holder types affect the score

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

Liquidity

as of audit · Sep 4$1.41M across 27 pairs
Show 4 more pairs

The 17 remaining pairs hold $3.2K between them and are not listed. The risk score reads depth across every pair.

LP tokensUnknown

Whether the LP tokens are locked could not be determined.

Analysed pool$971.3KShare of depth68.9%

Security Findings

1 High1 Medium1 Low2 Info
High

Centralized Control via Owner Privileges

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

Issue

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

Fix

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

Status

Unresolved

Medium

Lack of Emergency Pause Mechanism

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

Issue

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

Fix

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

Status

Unresolved

Low

ERC20 approve Race Condition

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

Issue

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

Fix

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

Status

Unresolved

Info

Incomplete Contract Context

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

Issue

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

Fix

Provide the complete source code for the SushiToken contract to enable a comprehensive security audit of its specific logic, state variables, and function implementations.

Status

Unresolved

Info

Older Solidity Compiler Version

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

Issue

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

Fix

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

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

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.

Technical7/10Low risk

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.

Governance4/10Medium risk

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.

Upgrades4/10Medium risk

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.

Final RecommendationWhat to do about this score

It is recommended to implement an emergency pause mechanism to provide a safety net against unforeseen issues.

For critical owner-controlled functions, consider integrating a multi-signature wallet or a time-lock contract to decentralize control and introduce a delay for sensitive operations, enhancing security and transparency. Review the full SushiToken contract to confirm whether _mint and _burn functions are exposed to the owner and assess their implications on tokenomics.

Contract & Record

1 audit on record
TypeSushiToken
NetworkEthereum
Token age3y
Contract0x6b35…0fe2
Deployer0xf942…a6bd
Badge for your website
SushiToken security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Sep 1, 202661Medium

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

Frequently Asked Questions

What is the SUSHI contract address?

The SushiToken (SUSHI) contract on Ethereum is 0x6b3595068778dd592e39a122f4f5a5cf09c90fe2. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is SushiToken a scam?

Quantum Audit's risk score for SushiToken is 61/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: Mintable; Upgradeability: Fixed code; Honeypot: None found; Buy / sell tax: 0% / 0%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Who holds SUSHI?

As of Sep 4, 2026, the 10 largest holders own 42.8% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
HarryPotterObamaSonic10InuBITCOIN · Ethereum61MediumLego PepeLEPE · Ethereum61MediumGraph TokenGRT · Ethereum61MediumGnosis TokenGNO · Ethereum61MediumInterfoldFOLD · Ethereum61MediumTokenFiTOKEN · Ethereum61Medium

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 Is this your token? Publish your own audit on this page