Quantum Audit Logo

Is Squid Safe?

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

Squid QUID
0x1a44…cb53
Base Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The SquidToken contract implements a standard ERC-20 token with Permit functionality, leveraging battle-tested OpenZeppelin libraries. The codebase is minimal and straightforward, contributing to a low-risk profile. No critical or high-severity vulnerabilities were identified.

2 Low1 Informational
Volume 24h
$151.4K
Liquidity
$858.2K
Price
$0.06697
Token Age
7d
Top 10 Holders
97.8%

Security Findings

2 Low1 Info
Low

Immutability of Token Contract

L-01The `SquidToken` contract is not designed to be upgradeable (7.7). While this simplifies the architecture (7.1) and removes upgrade-related risks, it implies that any discovered vulnerabilities or desired feature enhancements would necessitate a new contract deployment and a potentially complex migration process for token holders. This is a design choice rather than a direct vulnerability.
IssueThe `SquidToken` contract is not designed to be upgradeable (7.7). While this simplifies the architecture (7.1) and removes upgrade-related risks, it implies that any discovered vulnerabilities or desired feature enhancements would necessitate a new contract deployment and a potentially complex migration process for token holders. This is a design choice rather than a direct vulnerability.
FixAcknowledge the implications of immutability. For future projects requiring flexibility, consider implementing an upgradeable proxy pattern. For this specific contract, ensure that the initial design is thoroughly reviewed to minimize the need for future changes.
StatusUnresolved
Low

Permit Function Front-Running Risk

L-02The `permit` function, while a standard feature of ERC-20 Permit, can be susceptible to front-running attacks (7.2, 7.4). A malicious actor could observe a signed `permit` transaction waiting in the mempool and submit their own transaction with a higher gas price to execute the `permit` before the legitimate user. This could allow the attacker to manipulate the allowance set by the `owner` for the `spender`, potentially leading to unexpected behavior or loss of funds if not handled carefully off-chain. This is an inherent characteristic of the ERC-20 Permit standard and not a flaw in the implementation itself.
IssueThe `permit` function, while a standard feature of ERC-20 Permit, can be susceptible to front-running attacks (7.2, 7.4). A malicious actor could observe a signed `permit` transaction waiting in the mempool and submit their own transaction with a higher gas price to execute the `permit` before the legitimate user. This could allow the attacker to manipulate the allowance set by the `owner` for the `spender`, potentially leading to unexpected behavior or loss of funds if not handled carefully off-chain. This is an inherent characteristic of the ERC-20 Permit standard and not a flaw in the implementation itself.
FixEducate users about the potential for front-running when using the `permit` function. Recommend using private transaction relays or services that offer front-running protection where available. Implement off-chain mechanisms to mitigate this risk if the application relies heavily on `permit` functionality.
StatusUnresolved
Info

Standard OpenZeppelin Implementation

I-01The SquidToken contract leverages battle-tested and widely audited OpenZeppelin libraries for its core ERC-20 and ERC-20 Permit functionality. This significantly reduces the likelihood of common vulnerabilities associated with custom implementations of these standards, contributing to a high level of code security (7.2).
IssueThe SquidToken contract leverages battle-tested and widely audited OpenZeppelin libraries for its core ERC-20 and ERC-20 Permit functionality. This significantly reduces the likelihood of common vulnerabilities associated with custom implementations of these standards, contributing to a high level of code security (7.2).
FixContinue to rely on well-vetted libraries for core functionalities. Regularly monitor OpenZeppelin's security advisories and updates.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The technical architecture (7.1) is robust, relying on well-audited OpenZeppelin ERC-20 and ERC-20 Permit implementations. Code security (7.2) is high due to minimal custom logic and adherence to established patterns, with proper checks in the constructor for `recipient` and `initialSupply`. Access control (7.3) is standard for an ERC-20 token, with no additional privileged roles beyond the initial deployer for minting. No reentrancy or integer overflow/underflow vulnerabilities were found.

GovernanceHigh2/10

The economic model (7.4) is that of a simple ERC-20 token, without complex mechanisms or external dependencies that could introduce economic exploits. There is no explicit governance (7.5) mechanism implemented within the contract. The primary economic risk identified is the inherent front-running potential of the `permit` function, which is a known characteristic of the standard.

UpgradesMedium6/10

The contract is not designed to be upgradeable (7.7), which simplifies its architecture and eliminates upgrade-related risks such as proxy misconfigurations or storage collisions. This design choice means that any future changes or bug fixes would require a new deployment and token migration, which is a common approach for simple token contracts. Operations (7.8) are straightforward, as the contract has no complex operational dependencies.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass

Holder Composition

97.8% in top 10
8.8% in wallets88.9% in contracts
Effective Concentration44.4%

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

$866.7K across 8 pairs
PancakeswapUSDCanalysed$858.2K99.0%AerodromeUSDC$8.5K1.0%Uniswap v4ETH$400.0%Uniswap v3USDC$320.0%Uniswap v3USDC$210.0%Uniswap v4USDC$10.0%
Show 2 more pairsShow less
Uniswap v4USDC$00.0%Uniswap v4USDC$00.0%

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

Top-1 Unlocked Holder96.5%
Top-3 Unlocked100.0%

Key Addresses

4 addresses
Deployer
0x2d43…59e9
Unlocked LP Held By
0xfa2b…52bb0x85f9…ea620xfa8b…bca7

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

What Raised This Score

7 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Top-10 concentration > 30% (97.8% total → 44.4% effective; 8.8% in EOAs, 88.9% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 96.5% (independent LP — depth risk, pool = 99% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 99% of DEX liquidity)
  • Token age < 30 days (still settling)
  • 2 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
Horizen (ZEN)Medium RiskAave Token (AAVE)Medium RiskHandlPay (HANDL)Medium RiskBaseUncMedium RiskRollMedium RiskOpenGradient (OPG)Medium Risk

Would You Like a More Detailed Audit of Squid?

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

Get Detailed Audit