Quantum Audit Logo

Is Subsquid Safe?

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

Subsquid SQD
0x1337…8ab1
Arbitrum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The SQD token contract is an ERC20 implementation based on OpenZeppelin's battle-tested library, deployed on Arbitrum. It includes specific functions for bridging (`bridgeMint`, `bridgeBurn`) controlled by an immutable `l2Gateway` address. While the contract's technical implementation is robust and follows best practices, the centralized control over token supply by the `l2Gateway` introduces a significant external dependency risk, elevating the overall risk profile.

1 High1 Low1 Informational
Volume 24h
$18.4K
Liquidity
$351.6K
Price
$0.03427
Token Age
2y
Top 10 Holders
53.1%

Security Findings

1 High1 Low1 Info
High

Centralized Control of Token Supply via L2 Gateway (External Dependency Risk)

H-01The `l2Gateway` address has exclusive control over the `bridgeMint` and `bridgeBurn` functions, allowing it to arbitrarily increase or decrease the token supply. While this is a necessary design for a bridged token, it introduces a single, highly privileged point of control. The security of the entire SQD token's economic integrity on Arbitrum is directly dependent on the security and integrity of the `l2Gateway` contract. A compromise of the `l2Gateway` would lead to a critical economic impact, such as hyperinflation or complete draining of the token supply.
IssueThe `l2Gateway` address has exclusive control over the `bridgeMint` and `bridgeBurn` functions, allowing it to arbitrarily increase or decrease the token supply. While this is a necessary design for a bridged token, it introduces a single, highly privileged point of control. The security of the entire SQD token's economic integrity on Arbitrum is directly dependent on the security and integrity of the `l2Gateway` contract. A compromise of the `l2Gateway` would lead to a critical economic impact, such as hyperinflation or complete draining of the token supply.
FixImplement the highest security standards for the `l2Gateway` contract, including robust access control (e.g., multi-signature wallet), thorough auditing, and continuous monitoring. Establish a clear and secure operational procedure for managing the `l2Gateway` to minimize the risk of compromise. Consider decentralizing control over time if feasible for the bridge architecture.
StatusUnresolved
Low

ERC20 `approve` Race Condition

L-01The standard ERC20 `approve` function is susceptible to a known race condition. If a user approves an amount, and then approves a different amount before the first transaction is mined, an attacker could front-run the second approval to spend the original approved amount, and then the second approval would overwrite the allowance, potentially allowing the attacker to spend more than intended. This is an inherent characteristic of the ERC20 standard and not a flaw in the OpenZeppelin implementation.
IssueThe standard ERC20 `approve` function is susceptible to a known race condition. If a user approves an amount, and then approves a different amount before the first transaction is mined, an attacker could front-run the second approval to spend the original approved amount, and then the second approval would overwrite the allowance, potentially allowing the attacker to spend more than intended. This is an inherent characteristic of the ERC20 standard and not a flaw in the OpenZeppelin implementation.
FixInform users about this potential race condition. Recommend a 'set-to-zero then approve' pattern for changing allowances, where users first approve 0 and then the new amount. Alternatively, consider using ERC20 permit or a custom `increaseAllowance`/`decreaseAllowance` pattern if the token design allows for it, although OpenZeppelin's `_spendAllowance` mitigates some risks.
StatusUnresolved
Info

Use of `unchecked` Blocks for Addition

I-01The `_update` function, specifically for `_totalSupply += value` and `_balances[to] += value`, utilizes `unchecked` blocks. In Solidity 0.8.0 and later, arithmetic operations revert on overflow/underflow by default. `unchecked` blocks disable this check. While this is a standard optimization in OpenZeppelin contracts, and `uint256` provides a vast range, a theoretical overflow could occur if `value` is extremely large and the target variable is near `type(uint256).max`, leading to a wrap-around instead of a revert.
IssueThe `_update` function, specifically for `_totalSupply += value` and `_balances[to] += value`, utilizes `unchecked` blocks. In Solidity 0.8.0 and later, arithmetic operations revert on overflow/underflow by default. `unchecked` blocks disable this check. While this is a standard optimization in OpenZeppelin contracts, and `uint256` provides a vast range, a theoretical overflow could occur if `value` is extremely large and the target variable is near `type(uint256).max`, leading to a wrap-around instead of a revert.
FixNo direct action is required as this is a standard and generally safe optimization in modern Solidity for operations where overflow is highly improbable. However, it's important to be aware of this design choice and ensure that the context of `value` in `_mint` and `_burn` operations does not introduce an unexpected overflow scenario.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The SQD token contract leverages the OpenZeppelin ERC20 standard, providing a robust and well-audited foundation (7.2 Code Security). Access control for bridge-specific minting and burning functions is correctly implemented using an `onlyL2Gateway` modifier, ensuring only the designated L2 gateway can modify the token supply (7.3 Access Control). The `l2Gateway` and `l1Address` are immutable, preventing unauthorized changes post-deployment (7.1 Architecture). A minor observation is the use of `unchecked` blocks for addition in `_update`, which is standard OpenZeppelin practice but theoretically could lead to overflow if `uint256` limits are reached.

GovernanceHigh1/10

The economic security of the SQD token is heavily reliant on the `l2Gateway` contract, which possesses the exclusive ability to mint and burn tokens (7.4 Economic). This centralized control, while necessary for a bridged asset, represents a significant external dependency risk (7.6 External). A compromise of the `l2Gateway` would directly impact the token's supply integrity and value, leading to a critical economic impact on the entire protocol.

UpgradesMedium6/10

The SQD contract is not designed with an upgrade mechanism (e.g., proxy pattern), meaning its code is immutable after deployment (7.7 Upgrades). This eliminates risks associated with upgradeability, such as proxy misconfigurations or malicious upgrade paths. Any future changes or bug fixes would require a new deployment and a token migration process.

Security Checklist

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

Holder Composition

53.1% in top 10
23.3% in wallets29.8% in contracts
Effective Concentration35.2%

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

$351.8K across 2 pairs
PancakeswapWETHanalysed$351.6K99.9%UniswapWETH$2500.1%

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

4 addresses
Deployer
0x1de8…4add
Unlocked LP Held By
0xf161…e9e10x6b9f…e9800xd883…b378

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 NOT renounced (admin/mint authority retained)
  • Top-10 concentration > 30% (53.1% total → 35.2% effective; 23.3% in EOAs, 29.8% in contracts — moderate)
  • 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)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • 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
Arbitrum Dog (MILES)High RiskCoW Protocol Token (COW)High RiskAutonomi (ANT)High RiskEquilibria Token (EQB)High RiskWrapped BTC (WBTC)High RiskNOXCAT (NOX)High 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