Is LienFi (LFI) Safe? Smart Contract Security Analysis

Security Findings

3 Med1 Low1 Info

Medium

Unused `pool` and `isPoolLocked` Variables

M-01The `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.

IssueThe `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.

FixEither 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.

StatusUnresolved

Medium

Potential Gas Limit Issues in `mintInflation` Loop

M-02The `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.

IssueThe `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.

FixConsider 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.

StatusUnresolved

Medium

Potential Gas Limit Issues in `release()` for Many Schedules

M-03The `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…

IssueThe `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…

FixDuring 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.

StatusUnresolved

Low

Owner Receives All Inflation Tokens

L-01The `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.

IssueThe `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.

FixClearly 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.

StatusUnresolved

Info

Truncated Vesting Logic in `_available` Function

I-01The 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.

IssueThe 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.

FixProvide 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.

StatusUnresolved

Category Ratings

TechnicalLow8/10

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.

GovernanceLow7/10

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.

UpgradesHigh2/10

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.

Security Checklist

2/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEtherscan Detected Custom

ImplementationVerified source

Upgrades (30d)0 · stable

Holder Composition

50.2% in top 10

4.9% in wallets45.3% in contracts

Effective Concentration23.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

$671.1K across 15 pairs

Uniswap v4WETHanalysed$463.0K AerodromeUSDC$88.1K Uniswap v3WETH$83.1K Hydrex CLAMMUSDC$35.6K Uniswap v4USDC$1.1K Uniswap v4USDC$104

Show 4 more pairsShow less

PancakeswapWETH$63 PancakeswapUSDC$19 Uniswap v4USDC$10 Uniswap v4USDC$7

The 5 remaining pairs hold $12 between them and are not listed.

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 Holder28.8%

Top-3 Unlocked59.8%

Key Addresses

11 addresses

Deployer

0xa96a…dea2

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.

What Raised This Score

7 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

Final Recommendation

AI Copilot

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

Read the verdictHide

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

TypeToken

Audit History

1 audit on record

Aug 1263Sep 442

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

Is LienFi Safe?

Security Findings

Unused `pool` and `isPoolLocked` Variables

Potential Gas Limit Issues in `mintInflation` Loop

Potential Gas Limit Issues in `release()` for Many Schedules

Owner Receives All Inflation Tokens

Truncated Vesting Logic in `_available` Function

Category Ratings

Security Checklist

Proxy Upgrade Controls

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of LienFi?