Quantum Audit Logo
Launch App

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

Is LienFi Safe?

LFIBase
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 →
Last checked Sep 4, 2026 · 1 audit on record
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical8/10Governance7/10Upgrades2/10Checks passed2 of 5Findings3 Medium · 1 Low · 1 Info5
SummaryAI Copilot

The CloneDERC20VotesV2 contract implements an ERC20 token with voting capabilities, a vesting mechanism, and an inflation model.

Read the full analysis
What raised the score
  • Ownership not renounced — owner is a contract
  • Proxy contract
  • Non-standard proxy storage
  • Top-10 concentration > 20%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • 3 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
  • Proxy contract (upgradeable — admin can replace logic)
  • Non-standard proxy storage (Etherscan-confirmed)
  • Top-10 concentration > 20% (50.2% total → 23.0% effective; 4.9% in EOAs, 45.3% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • 3 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

Security Checklist

as of audit · Sep 42 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
45.3%Contracts4.9%Wallets49.8%Everyone else
45.3%Contracts4.9%49.8%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
50.2%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking45.3%
  • Walletsanonymous holders, free to sell4.9%
  • Everyone elsethe rest of the supply49.8%
Effective concentrationwhat the score reads23.0%
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 4$671.1K across 15 pairs
Show 4 more pairs

The 5 remaining pairs hold $12 between them and are not listed. The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$463.0KShare of depth69.0%
Top-1 Unlocked Holder28.8%
Top-3 Unlocked59.8%
Unlocked LP held by
0xac5f…69050xe5c6…fe1c0x63ee…036b0xb8c6…10ae0x79d2…7c850x091c…62dd0x830d…ac1f0x1948…14c20x8c39…e01b0x73e3…93d5

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

Security Findings

3 Medium1 Low1 Info
Medium

Unused pool and isPoolLocked Variables

The pool address and isPoolLocked boolean state variables are declared and can be set by the onlyOwner functions lockPool and unlockPool. However, these variables are never read or used anywhere else in the contract to restrict or enable any functionality. This indicates either incomplete features, dead code, or a misunderstanding of their intended purpose, which can be misleading and potentially lead to future vulnerabilities if these variables are later integrated without proper security review.M-01

Issue

The pool address and isPoolLocked boolean state variables are declared and can be set by the onlyOwner functions lockPool and unlockPool. However, these variables are never read or used anywhere else in the contract to restrict or enable any functionality. This indicates either incomplete features, dead code, or a misunderstanding of their intended purpose, which can be misleading and potentially lead to future vulnerabilities if these variables are later integrated without proper security review.

Fix

Either implement the intended logic that utilizes the pool address and isPoolLocked flag, or remove these variables and their associated functions if they are not part of the current design. If they are placeholders for future functionality, clearly document their purpose and ensure a thorough security review is conducted before activating any logic dependent on them.

Status

Unresolved

Medium

Potential Gas Limit Issues in mintInflation Loop

The mintInflation function contains a while loop that iterates for each full year that has passed since currentYearStart. While currentYearStart is updated to block.timestamp upon unlockPool and within mintInflation itself, if the contract is left un-minted for an extremely long period (e.g., many centuries), this loop could iterate a significant number of times. This could potentially exceed the block gas limit, preventing the inflation mechanism from being triggered and leading to a denial of service for token minting.M-02

Issue

The mintInflation function contains a while loop that iterates for each full year that has passed since currentYearStart. While currentYearStart is updated to block.timestamp upon unlockPool and within mintInflation itself, if the contract is left un-minted for an extremely long period (e.g., many centuries), this loop could iterate a significant number of times. This could potentially exceed the block gas limit, preventing the inflation mechanism from being triggered and leading to a denial of service for token minting.

Fix

Consider an alternative approach for calculating inflation over multiple years that avoids a while loop, such as a formula-based calculation or a mechanism that caps the number of iterations. Alternatively, ensure that mintInflation is called regularly (e.g., via a keeper bot) to prevent currentYearStart from becoming excessively old.

Status

Unresolved

Medium

Potential Gas Limit Issues in release() for Many Schedules

The release() function (without a scheduleId parameter) and computeAvailableVestedAmount(address beneficiary) iterate over the _scheduleIdsOf[beneficiary] array to process all vesting schedules for a given beneficiary. While the initialize function includes checks like MAX_PRE_MINT_PER_ADDRESS_WAD and MAX_TOTAL_PRE_MINT_WAD, these primarily limit the total *amount* allocated, not the *number* of individual vesting schedules. If a single beneficiary is allocated an extremely large number of distinct vesting schedules during initialization, iterating through this array could become gas-intensive, potentially leading to a denial of service for that beneficiary's ability to claim…M-03

Issue

The release() function (without a scheduleId parameter) and computeAvailableVestedAmount(address beneficiary) iterate over the _scheduleIdsOf[beneficiary] array to process all vesting schedules for a given beneficiary. While the initialize function includes checks like MAX_PRE_MINT_PER_ADDRESS_WAD and MAX_TOTAL_PRE_MINT_WAD, these primarily limit the total *amount* allocated, not the *number* of individual vesting schedules. If a single beneficiary is allocated an extremely large number of distinct vesting schedules during initialization, iterating through this array could become gas-intensive, potentially leading to a denial of service for that beneficiary's ability to claim…

Fix

During the contract deployment and initialization phase, ensure that the number of vesting schedules allocated to any single beneficiary remains within reasonable limits to prevent excessive gas consumption. If a very large number of schedules per beneficiary is a design requirement, consider implementing a paginated claim mechanism or a way to claim a subset of schedules to avoid hitting gas limits.

Status

Unresolved

Low

Owner Receives All Inflation Tokens

The mintInflation function mints all newly generated inflation tokens directly to the owner(). While the owner is a multisig (0x660e…8d12, 3/6 threshold), this design centralizes the control of all newly minted supply. Depending on the project's economic model and governance structure, this could be perceived as a centralization risk, as the owner has sole discretion over the distribution or use of these tokens, potentially impacting market dynamics.L-01

Issue

The mintInflation function mints all newly generated inflation tokens directly to the owner(). While the owner is a multisig (, 3/6 threshold), this design centralizes the control of all newly minted supply. Depending on the project's economic model and governance structure, this could be perceived as a centralization risk, as the owner has sole discretion over the distribution or use of these tokens, potentially impacting market dynamics.

Fix

Clearly document the intended use and distribution strategy for the inflation tokens received by the owner. If a more decentralized distribution is desired in the future, consider implementing a governance-controlled treasury or a mechanism to distribute inflation directly to stakers or other protocol participants.

Status

Unresolved

Info

Truncated Vesting Logic in _available Function

The provided source code for the _available function is truncated at the point where the linear vesting calculation (else { ves...) would typically be implemented. Without the full code, a complete security analysis of the linear vesting logic, including potential edge cases like division by zero or incorrect calculation, cannot be performed.I-01

Issue

The provided source code for the _available function is truncated at the point where the linear vesting calculation (else { ves...) would typically be implemented. Without the full code, a complete security analysis of the linear vesting logic, including potential edge cases like division by zero or incorrect calculation, cannot be performed.

Fix

Provide the complete and untruncated source code for a comprehensive audit. Assuming a standard linear vesting implementation, ensure it correctly handles edge cases such as s.duration == s.cliff (which should be covered by the if (t >= start + s.duration) condition if s.cliff == s.duration) and avoids any potential for division by zero.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

The CloneDERC20VotesV2 contract implements an ERC20 token with voting capabilities, a vesting mechanism, and an inflation model. It leverages well-audited Solady libraries for core functionalities and uses an Ownable pattern for administrative control. The owner is a multisig, enhancing operational security. Key findings include unused state variables, potential gas limit issues in the inflation and vesting release functions under extreme conditions, and a design choice regarding inflation token distribution. The contract is designed with Initializable but is reported as not being a proxy.

Technical8/10Low risk

The contract's architecture (7.1) is clear, utilizing Solady libraries for robust ERC20, ERC20Votes, and Ownable implementations. Code security (7.2) is generally strong, with no apparent reentrancy or integer overflow vulnerabilities in critical paths. However, the mintInflation function's while loop and the release() function's iteration over vesting schedules could lead to gas limit issues under extreme, long-term scenarios. Access control (7.3) is appropriately implemented using the onlyOwner modifier for sensitive administrative functions, and mintInflation is public, allowing anyone to trigger inflation, which is a reasonable design choice.

Governance7/10Low risk

The economic model (7.4) includes a capped yearly inflation rate and a vesting mechanism. Inflation tokens are minted directly to the owner(), which is a multisig, mitigating the risk of a single point of failure. The contract implements ERC20Votes, indicating an intention for decentralized governance (7.5) through an external system, although direct governance mechanisms are not present within this contract. The owner's ability to control the mint rate and receive inflation tokens grants significant economic influence.

Upgrades2/10High risk

The contract includes the Initializable base contract (7.7), suggesting it was designed with upgradeability in mind, typically for deployment behind a proxy. However, the provided information states is_proxy: false, meaning it is deployed directly and is not upgradeable. The initialize function can only be called once, ensuring proper setup. The owner being an OZ_ProxyAdmin further hints at potential future proxy integration or its use as a secure owner for a non-proxy contract.

Final RecommendationWhat to do about this score

It is recommended to address the identified medium-severity issues to enhance the contract's robustness and long-term operational stability.

Specifically, consider alternative patterns for the mintInflation loop and release function's iteration to prevent potential gas limit issues. Clarify or remove the unused pool and isPoolLocked variables to avoid confusion and potential future integration risks. Ensure the economic implications of the owner receiving all inflation tokens align with the project's long-term vision and communicate this clearly to stakeholders.

Contract & Record

1 audit on record
TypeToken
NetworkBase
Token age3mo
Contract0x3722…aba3
Deployer0xa96a…dea2
Proxy Upgrade Controls
Proxy TypeEtherscan Detected Custom
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
LienFi security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Sep 4, 202642Medium
  2. Aug 12, 202663Medium

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Related Audits

6 more on the recordAll audits
B3Base42MediumMey NetworkMEY · Base42MediumBrain ArmstrongBRAINARM · Base42MediumMamoBase42MediumDeriveDRV · Base41MediumVenice DeityVVVEITY · Base41Medium

Would You Like a More Detailed Audit of LienFi?

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