The LQTYToken contract implements an ERC-20 token with EIP-2612 (Permit) functionality. It features a fixed supply, specific initial token allocations, and time-locked restrictions on the Liquity multisig's operations for the first year post-deployment. The contract utilizes OpenZeppelin's SafeMath for arithmetic safety and includes custom checks for valid recipients and core contract callers. Overall, the contract demonstrates robust design and implementation practices, with identified risks being primarily informational or low-severity, related to inherent design choices or standard EIP behaviors.

On-chain security analysis — is it a scam or legit?
Is LQTY Safe?
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 →The LQTYToken contract implements an ERC-20 token with EIP-2612 (Permit) functionality.
Read the full analysis- Ownership not renounced
- Top-10 concentration > 30%
- LP top1 unlocked holder = 54.2%
- LP top3 unlocked holders = 94.3%
- LP claimed locked but only 0.0% actually locked
- 2 Low finding(s) from audit
Exact factors
- Ownership NOT renounced (admin/mint authority retained)
- Top-10 concentration > 30% (84.8% total → 46.6% effective; 21.1% in EOAs, 63.7% in contracts — moderate)
- LP top1 unlocked holder = 54.2% (independent LP — depth risk, pool = 99% of DEX liquidity)
- LP top3 unlocked holders = 94.3% (independent LP — depth risk, pool = 99% of DEX liquidity)
- LP claimed locked but only 0.0% actually locked
- 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
Security Checklist
as of audit · Sep 4Holders
as of audit · Sep 4, 2026- Contractstreasury, vesting, bridge, staking63.7%
- Walletsanonymous holders, free to sell21.1%
- Everyone elsethe rest of the supply15.2%
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 4The risk score reads depth across every pair.
The LP tokens of the analysed pool are locked or burned.
0xa67b…c8120x7cc7…68ff0x61b9…b8ff0x7163…e53c0x7bb8…9a6b0xc185…983b0x4b39…563b0xdc6b…03630x5e6a…f79bNo privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
Security Findings
LowCentralized Control via Multisig
The multisigAddress receives a significant portion of the initial LQTY token supply (64.66 million tokens) and, after the initial one-year restriction period, will have unrestricted control over these tokens. While the initial time-locked restrictions mitigate immediate risks, the multisig remains a central point of control. A compromise of the multisig's private keys or its governance process could lead to unauthorized token movements.L-01
Issue
The multisigAddress receives a significant portion of the initial LQTY token supply (64.66 million tokens) and, after the initial one-year restriction period, will have unrestricted control over these tokens. While the initial time-locked restrictions mitigate immediate risks, the multisig remains a central point of control. A compromise of the multisig's private keys or its governance process could lead to unauthorized token movements.
Fix
Implement robust security measures for the multisigAddress, including strong key management practices, multi-factor authentication, and strict operational procedures. Consider transitioning to more decentralized governance mechanisms over time if feasible.
Status
Unresolved
LowDependency on LockupContractFactory
For the first year after deployment, the multisigAddress is restricted to only transferring LQTY tokens to LockupContracts that have been deployed via and registered in the LockupContractFactory. This introduces a dependency on the correct functioning and security of the LockupContractFactory contract. If the LockupContractFactory were compromised or malfunctioned, it could hinder the multisig's ability to distribute tokens as intended during the restricted period.L-02
Issue
For the first year after deployment, the multisigAddress is restricted to only transferring LQTY tokens to LockupContracts that have been deployed via and registered in the LockupContractFactory. This introduces a dependency on the correct functioning and security of the LockupContractFactory contract. If the LockupContractFactory were compromised or malfunctioned, it could hinder the multisig's ability to distribute tokens as intended during the restricted period.
Fix
Ensure the LockupContractFactory contract is thoroughly audited and maintained with the highest security standards. Implement monitoring for the LockupContractFactory to detect any unusual activity or potential compromises that could impact the LQTY token distribution.
Status
Unresolved
InfoNon-Upgradeability of Contract
The LQTYToken contract is implemented as a standard, non-upgradeable contract. This design choice means that once deployed, the contract's logic cannot be modified. Consequently, any bugs discovered post-deployment cannot be patched, and new features cannot be introduced without deploying an entirely new contract and migrating assets.I-01
Issue
The LQTYToken contract is implemented as a standard, non-upgradeable contract. This design choice means that once deployed, the contract's logic cannot be modified. Consequently, any bugs discovered post-deployment cannot be patched, and new features cannot be introduced without deploying an entirely new contract and migrating assets.
Fix
Acknowledge this design choice. Ensure thorough testing and auditing pre-deployment, as the contract's immutability makes post-deployment fixes impossible. Communicate this characteristic clearly to users and stakeholders.
Status
Unresolved
InfoEIP-2612 Permit Front-Running Risk
The contract implements EIP-2612's permit function, which allows users to approve token transfers via a signed message instead of an on-chain transaction. While standard, this mechanism can be susceptible to front-running. A malicious actor could observe a valid permit signature in the mempool and submit their own transaction with a higher gas price to execute the permit before the legitimate user, potentially gaining the approved allowance.I-02
Issue
The contract implements EIP-2612's permit function, which allows users to approve token transfers via a signed message instead of an on-chain transaction. While standard, this mechanism can be susceptible to front-running. A malicious actor could observe a valid permit signature in the mempool and submit their own transaction with a higher gas price to execute the permit before the legitimate user, potentially gaining the approved allowance.
Fix
Educate users about the potential for front-running with permit and advise them to set a strict deadline parameter to limit the time window for exploitation. Off-chain relayers should also implement measures to prevent front-running.
Status
Unresolved
InfoFixed Token Supply and Initial Distribution
The LQTY token has a hard-capped total supply of 100 million tokens, all of which are minted during the contract's deployment. The initial distribution to specific addresses (bounty, community issuance, LP rewards, and multisig) is hardcoded in the constructor. This design ensures transparency and predictability of the token supply, as no further tokens can be minted or burned, and the initial distribution cannot be altered.I-03
Issue
The LQTY token has a hard-capped total supply of 100 million tokens, all of which are minted during the contract's deployment. The initial distribution to specific addresses (bounty, community issuance, LP rewards, and multisig) is hardcoded in the constructor. This design ensures transparency and predictability of the token supply, as no further tokens can be minted or burned, and the initial distribution cannot be altered.
Fix
This is a design choice that enhances transparency and predictability. No specific recommendation is needed beyond ensuring that the initial allocation addresses are correct and secure.
Status
Unresolved
Analysis
AI Copilotas of audit · Sep 4The LQTYToken contract exhibits strong technical security. It leverages OpenZeppelin's battle-tested ERC-20 and EIP-2612 implementations, including SafeMath for robust integer arithmetic (7.2 Code Security). Custom access control mechanisms are well-defined, such as time-locked restrictions on the multisig's transfer and approval functions, and recipient validation to prevent accidental token loss (7.3 Access Control). The CheckContract dependency ensures proper contract interactions. A minor technical observation is the inherent front-running risk associated with EIP-2612's permit function, which is a standard consideration for this EIP.
The economic model of LQTYToken is transparent, featuring a hard-capped supply of 100 million tokens, all minted at deployment (7.4 Economic). The initial distribution to various stakeholders (bounty, community issuance, LP rewards, multisig) is clearly defined in the constructor. Governance risk is mitigated by time-locked restrictions on the multisig address for the first year, preventing immediate large-scale transfers or staking (7.5 Governance). While the multisig holds a significant portion and acts as a central control point, these initial restrictions reduce immediate centralization risks.
The LQTYToken contract is not designed as an upgradeable proxy (7.7 Upgrades). This means that its logic cannot be altered post-deployment. While this design choice eliminates upgrade-related risks such as proxy misconfigurations or implementation bugs, it also implies that any discovered vulnerabilities or desired feature enhancements cannot be addressed without a new deployment and migration.
The LQTYToken contract is well-designed and implemented, adhering to established security practices.
Users interacting with the EIP-2612 permit function should be aware of potential front-running risks and utilize appropriate deadline values. The multisig responsible for initial token distribution should maintain robust security practices, especially given its significant role and the lifting of restrictions after the first year. Regular security reviews of all interacting Liquity core contracts, particularly the LockupContractFactory, are recommended to ensure the overall ecosystem's integrity.
Contract & Record
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
- Sep 4, 202647Medium
- Jul 27, 202649Medium
- Jul 27, 202661Medium
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
Frequently Asked Questions
Is LQTY a scam?
Based on automated analysis, LQTY scores 61/100 (High Risk) on our risk scale. No honeypot was detected, but always verify independently before investing.
Is LQTY safe to buy?
Our scanner flagged a risk score of 61/100. Ownership has not been renounced, which is a risk factor. DYOR before purchasing any token.
Has LQTY been audited?
The contract has not been verified on-chain. Verification is not the same as a full security audit. Use Quantum Audit's free tool to run a deeper analysis of the contract code.
Would You Like a More Detailed Audit of LQTY?
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