Quantum Audit Logo

Is LinqAI Safe?

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

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

LinqAI LNQ
0xd4f4…bd04
Ethereum
Not verifiedThis 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 2d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

This audit covers a Taxable ERC20 token contract. The contract implements a transfer tax mechanism with owner-controlled parameters and utilizes standard OpenZeppelin libraries for its core ERC20 functionality and ownership. A critical economic vulnerability exists due to the expired liquidity pool lock, posing a significant rug pull risk. Additionally, while ownership is renounced, this makes the tax parameters immutable, which could be problematic for future adjustments.

1 Critical1 High1 Medium1 Low
Volume 24h
$112.3K
Liquidity
$463.8K
Price
$0.008146
Token Age
2y
Top 10 Holders
78.1%

Security Findings

1 Crit1 High1 Med1 Low
Critical

Expired Liquidity Pool Lock Poses Rug Pull Risk

C-01The provided prefill data indicates that the liquidity pool (LP) lock for this token has expired (`lp_lock_status: lock_expired`, `lp_unlock_days_remaining: -569`). This means that the entities holding the LP tokens (e.g., the project team or initial liquidity providers) are now able to withdraw the underlying assets (e.g., ETH/WETH and the project token) from the liquidity pool at any time. This capability creates a direct and immediate 'rug pull' vulnerability, where the value of the token could be severely impacted or rendered worthless if liquidity is removed.
IssueThe provided prefill data indicates that the liquidity pool (LP) lock for this token has expired (`lp_lock_status: lock_expired`, `lp_unlock_days_remaining: -569`). This means that the entities holding the LP tokens (e.g., the project team or initial liquidity providers) are now able to withdraw the underlying assets (e.g., ETH/WETH and the project token) from the liquidity pool at any time. This capability creates a direct and immediate 'rug pull' vulnerability, where the value of the token could be severely impacted or rendered worthless if liquidity is removed.
FixImmediately re-lock the liquidity pool tokens for a significant duration (e.g., 1-5 years) using a reputable locking service. This action is crucial to restore investor confidence and prevent a potential rug pull. If ownership has been renounced and no mechanism exists to re-lock, this risk is unmitigable for the current contract.
StatusUnresolved
High

Immutable Tax Mechanism Post-Ownership Renunciation

H-01The contract's ownership has been renounced (`ownership_renounced: true`). While renouncing ownership can be a positive step towards decentralization, in this context, it renders the `setTaxRate`, `setTaxAddress`, and `setExcludeFromTax` functions permanently inaccessible. This means the token's tax rate, the address receiving the tax, and the list of tax-excluded addresses cannot be modified. This inflexibility could be problematic if the initial tax configuration is found to be suboptimal, if the tax address needs to be updated, or if market conditions necessitate adjustments. Combined with the expired LP lock, this lack of control exacerbates the economic risk.
IssueThe contract's ownership has been renounced (`ownership_renounced: true`). While renouncing ownership can be a positive step towards decentralization, in this context, it renders the `setTaxRate`, `setTaxAddress`, and `setExcludeFromTax` functions permanently inaccessible. This means the token's tax rate, the address receiving the tax, and the list of tax-excluded addresses cannot be modified. This inflexibility could be problematic if the initial tax configuration is found to be suboptimal, if the tax address needs to be updated, or if market conditions necessitate adjustments. Combined with the expired LP lock, this lack of control exacerbates the economic risk.
FixFor future projects, carefully consider the long-term implications of renouncing ownership, especially for contracts with configurable parameters. If flexibility is desired, consider a multi-signature wallet or a time-locked governance mechanism to manage critical parameters instead of outright renunciation. For this specific contract, this issue is a consequence of renunciation and is now immutable.
StatusUnresolved
Medium

Centralized Control of Tax Parameters (Pre-Renunciation Risk)

M-01Prior to the ownership renunciation, the deployer (owner) had complete control over the token's tax mechanism. This included the ability to set the `_taxRate` (within `_minTaxRate` and `_maxTaxRate` bounds), designate the `_taxAddress`, and add/remove addresses from the `_isExclude` list. This centralized control, even if temporary, presented a risk where a malicious owner could have configured the tax to create a 'honeypot' (e.g., very high tax for non-excluded users, while excluding themselves), effectively draining value from other users. Although this risk is mitigated post-renunciation, the initial period of full control is a concern.
IssuePrior to the ownership renunciation, the deployer (owner) had complete control over the token's tax mechanism. This included the ability to set the `_taxRate` (within `_minTaxRate` and `_maxTaxRate` bounds), designate the `_taxAddress`, and add/remove addresses from the `_isExclude` list. This centralized control, even if temporary, presented a risk where a malicious owner could have configured the tax to create a 'honeypot' (e.g., very high tax for non-excluded users, while excluding themselves), effectively draining value from other users. Although this risk is mitigated post-renunciation, the initial period of full control is a concern.
FixFor future token deployments with configurable parameters, consider implementing a timelock for critical parameter changes or a multi-signature wallet for ownership to reduce the risk of malicious actions during the initial deployment phase. Clearly communicate the initial parameter settings and the plan for ownership transfer/renunciation to the community.
StatusUnresolved
Low

Standard ERC20 `approve` Race Condition

L-01The contract inherits the standard OpenZeppelin ERC20 `approve` function. This function is susceptible to a well-known front-running vulnerability. If a user approves an allowance for a spender, and then attempts to change that allowance to a different value, a malicious actor could front-run the second `approve` transaction. This could result in the spender spending the original allowance, and then also being able to spend the new allowance, effectively doubling the approved amount or leading to unintended transfers.
IssueThe contract inherits the standard OpenZeppelin ERC20 `approve` function. This function is susceptible to a well-known front-running vulnerability. If a user approves an allowance for a spender, and then attempts to change that allowance to a different value, a malicious actor could front-run the second `approve` transaction. This could result in the spender spending the original allowance, and then also being able to spend the new allowance, effectively doubling the approved amount or leading to unintended transfers.
FixUsers should be advised to use the `increaseAllowance` and `decreaseAllowance` functions (if available in a newer OpenZeppelin version or custom implementation) instead of directly calling `approve` to change an existing allowance. Alternatively, users should set the allowance to zero before setting a new non-zero allowance. While this is a common ERC20 pattern, it's important for users to be aware of the risk.
StatusUnresolved

Category Ratings

TechnicalLow7/10

7.1 Architecture and 7.2 Code Security are generally robust, leveraging well-tested OpenZeppelin contracts for ERC20 and Ownable functionalities. The contract uses Solidity 0.8.x, benefiting from built-in overflow/underflow checks, with `unchecked` blocks appropriately used for gas optimization where safety is guaranteed. Custom error messages enhance clarity and gas efficiency. However, the design introduces a tax mechanism that, while technically sound, has significant implications for 7.3 Access Control and 7.8 Operations, particularly after ownership renunciation.

GovernanceLow7/10

The contract exhibits critical risks concerning 7.4 Economic and 7.5 Governance aspects. The most severe issue is the expired liquidity pool lock, which allows liquidity providers to withdraw funds at any time, creating a direct rug pull vulnerability. While ownership has been renounced, making the tax rate, tax address, and exclusion list immutable, this inflexibility prevents necessary adjustments or emergency fixes. Prior to renunciation, the owner had full control over these parameters, posing a 'honeypot' risk. The combination of an expired LP lock and immutable tax parameters presents a high economic risk to token holders.

UpgradesLow9/10

The contract is not designed as an upgradeable proxy (7.7 Upgrades). It is a standard, non-upgradeable implementation. Therefore, there are no upgrade-specific risks or considerations.

Security Checklist

5/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

78.1% in top 10
17.7% in wallets60.4% in contracts
Effective Concentration41.9%

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

$463.8K

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

LP Locked100.0% · Null Address, TeamFinance
Lock ExpiryExpired 569d ago

Key Addresses

1 addresses
Deployer
0x705d…a06c

What Raised This Score

5 factors
  • Top-10 concentration > 30% (78.1% total → 41.9% effective; 17.7% in EOAs, 60.4% in contracts — moderate)
  • 1 Critical finding(s) from audit
  • 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
wojakMedium RiskBalancer (BAL)Medium RiskCateMedium RiskApeCoin (APE)Medium Risk01Medium RiskI love puppies (PUPPIES)Medium Risk

Would You Like a More Detailed Audit of LinqAI?

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

Get Detailed Audit