Quantum Audit Logo

Is Subsquid Safe?

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

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

Subsquid SQD
0xe50e…cc13
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The PeerToken contract is an ERC-20 token with minting and burning capabilities, leveraging OpenZeppelin's audited libraries. The primary risks identified stem from the highly centralized control over token supply and administrative functions, particularly the unlimited minting power held by a single `minter` address, which is itself controlled by a single `owner` address. While the code quality is high due to OpenZeppelin's robust implementations, the economic model introduces significant centralization risks.

1 Critical1 High1 Low1 Informational
Volume 24h
$192.3K
Liquidity
$416.0K
Price
$0.0343
Token Age
1y
Top 10 Holders
94.5%

Security Findings

1 Crit1 High1 Low1 Info
Critical

Centralized Minting Authority and Unlimited Supply

C-01The `minter` role, which is controlled by the `owner`, has the ability to mint an arbitrary amount of tokens without any on-chain supply cap. This poses a critical economic risk (7.4 Economic), as a compromised `minter` or `owner` key could lead to hyperinflation and severe devaluation of the token. The contract does not enforce any maximum total supply.
IssueThe `minter` role, which is controlled by the `owner`, has the ability to mint an arbitrary amount of tokens without any on-chain supply cap. This poses a critical economic risk (7.4 Economic), as a compromised `minter` or `owner` key could lead to hyperinflation and severe devaluation of the token. The contract does not enforce any maximum total supply.
FixImplement a multi-signature wallet for the `minter` role. Consider adding a hard cap on the total supply of tokens or implementing a controlled minting schedule to limit the potential for inflation. If unlimited minting is a core design choice, ensure robust operational security for the `minter` and `owner` keys.
StatusUnresolved
High

High Centralization of Administrative Control

H-01The `Ownable` pattern grants significant administrative power to a single `owner` address, specifically the ability to `setMinter` and `transferOwnership` (7.3 Access Control). This central point of failure increases operational risk (7.8 Operations), as a compromised `owner` key could lead to unauthorized changes in the `minter` role, loss of administrative control, or other malicious actions.
IssueThe `Ownable` pattern grants significant administrative power to a single `owner` address, specifically the ability to `setMinter` and `transferOwnership` (7.3 Access Control). This central point of failure increases operational risk (7.8 Operations), as a compromised `owner` key could lead to unauthorized changes in the `minter` role, loss of administrative control, or other malicious actions.
FixImplement a multi-signature wallet for the `owner` address to distribute control and reduce the risk associated with a single point of failure. This would require multiple approvals for critical administrative actions, enhancing security.
StatusUnresolved
Low

Immutability of Contract Logic

L-01The `PeerToken` contract is not upgradeable (7.7 Upgrades). While this eliminates risks associated with upgrade mechanisms, it means that any discovered vulnerabilities or desired feature changes would necessitate a new contract deployment and a potentially complex and costly migration of assets and user base. This lack of flexibility can be a long-term operational challenge.
IssueThe `PeerToken` contract is not upgradeable (7.7 Upgrades). While this eliminates risks associated with upgrade mechanisms, it means that any discovered vulnerabilities or desired feature changes would necessitate a new contract deployment and a potentially complex and costly migration of assets and user base. This lack of flexibility can be a long-term operational challenge.
FixAcknowledge the implications of immutability. For future projects, if flexibility for bug fixes or feature enhancements is critical, consider implementing an upgradeable proxy pattern (e.g., UUPS) to allow for future contract logic updates without redeployment.
StatusUnresolved
Info

Single Address for Minter Role

I-01The `minter` role is assigned to a single external address. While this is functional, for systems requiring higher security or distributed control, relying on a single address for such a powerful role can be a point of concern (7.3 Access Control, 7.8 Operations).
IssueThe `minter` role is assigned to a single external address. While this is functional, for systems requiring higher security or distributed control, relying on a single address for such a powerful role can be a point of concern (7.3 Access Control, 7.8 Operations).
FixConsider using a multi-signature wallet or a more robust role-based access control (RBAC) system (e.g., OpenZeppelin's `AccessControl` contract) for the `minter` role to enhance security and decentralize control, if appropriate for the project's long-term vision.
StatusUnresolved

Category Ratings

TechnicalMedium5/10

The contract is well-structured, inheriting from standard OpenZeppelin ERC20, ERC20Burnable, and Ownable contracts (7.1 Architecture). It correctly implements access control modifiers (`onlyMinter`, `onlyOwner`) and includes zero-address checks for critical roles (e.g., `setMinter`) (7.3 Access Control). The use of `unchecked` blocks in `_update` is standard for OpenZeppelin's ERC20 and is protected by prior checks, preventing integer overflows/underflows (7.2 Code Security).

GovernanceHigh1/10

The economic model presents a critical risk due to the centralized minting authority. A single `minter` address, controlled by the `owner`, can mint an unlimited supply of tokens, posing a significant inflation risk (7.4 Economic). Furthermore, the `owner` holds substantial administrative power, including the ability to change the `minter` and transfer ownership, creating a single point of failure (7.3 Access Control, 7.8 Operations). There is no on-chain governance mechanism (7.5 Governance).

UpgradesHigh2/10

The PeerToken contract is implemented as a standard, non-upgradeable contract. This design choice eliminates risks associated with proxy patterns or upgrade mechanisms, such as storage collisions or faulty upgrade logic. However, it also means that any future bug fixes or feature enhancements would require a complete redeployment and migration of assets, which can be a complex and costly process (7.7 Upgrades).

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass

Holder Composition

94.5% in top 10
52.0% in wallets42.5% in contracts
Effective Concentration69.0%

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

$419.3K across 5 pairs
Pancakeswap v3USDCanalysed$416.0K99.2%Pancakeswap v3USDC$3.3K0.8%UniswapUSDT$130.0%Pancakeswap v3USDT$110.0%Pancakeswap v3WBNB$70.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 Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

2 addresses
Deployer
0x479b…d3c6
Unlocked LP Held By
0x80db…09e3

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

What Raised This Score

9 factors
  • Ownership NOT renounced — owner is an EOA (single private key)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 50% (94.5% total → 69.0% effective; 52.0% in EOAs, 42.5% in contracts — heavy)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 99% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 99% of DEX liquidity)
  • 1 Critical finding(s) from audit
  • 1 High 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
PancakeSwap Token (CAKE)Critical RiskBOBCritical RiskAnoma (XAN)Critical RiskelizaOSCritical RiskPlasma (XPL)Critical RiskMirex (MRX)Critical Risk

Would You Like a More Detailed Audit of Subsquid?

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

Get Detailed Audit