Quantum Audit Logo
Launch App

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

Is CF Large Cap Index Safe?

LCAPBase
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 Oct 19, 2026 · 1 audit on record
Chart
High RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical6/10Governance1/10Upgrades1/10Checks passed3 of 7Findings1 High · 4 Medium · 2 Low · 5 Info12
SummaryAI Copilot

The audit of the Folio contract (implementation for FolioProxy) revealed a well-structured system utilizing OpenZeppelin's upgradeable contracts and access control.

Read the full analysis
What raised the score
  • Mintable supply — no cap found, dilution unbounded
  • Upgradeable proxy — the admin can replace the logic; admin: ProxyAdmin -> Timelock
  • Ownership status UNKNOWN
  • Liquidity not locked
  • Top-10 concentration > 70%
Exact factors
  • Mintable supply — no cap found, dilution unbounded
  • Upgradeable proxy — the admin can replace the logic; admin: ProxyAdmin -> Timelock
  • Ownership status UNKNOWN (owner could not be resolved)
  • Liquidity NOT locked (100% of the pool; this pool is 39% of DEX liquidity) — held by independent providers — market-depth risk
  • Top-10 concentration > 70% (94.4% total → 85.2% effective; 79.1% in EOAs, 15.3% in contracts)

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 · Oct 193 of 7 checks passed
Contract verifiedVerified
OwnershipUnknown
MintMintable
Liquidity lockNot locked
UpgradeabilityUpgradeable
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Oct 19, 202619,596 holders
15.3%Contracts79.1%Wallets5.6%
15.3%Contracts79.1%Wallets5.6%
ContractsWalletsEveryone elseBubble area = share of supply
94.4%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking15.3%
  • Walletsanonymous holders, free to sell79.1%
  • Everyone else19,586 holders5.6%
Effective concentrationwhat the score reads85.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 Oct 19, 2026

Liquidity

as of audit · Oct 19$1.24M across 6 pairs

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$480.2KShare of depth38.7%
Top-1 Unlocked Holder98.6%
Top-3 Unlocked100.0%
Unlocked LP held by
0x8d38…a01d0x57d5…eb050xf867…b511

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

Security Findings

1 High4 Medium2 Low5 Info
High

Centralized Control over Critical Functions

The DEFAULT_ADMIN_ROLE in the Folio contract possesses extensive privileges, including the ability to set TVL and mint fees, modify the asset basket (add/remove tokens), set auction length, change the mandate, and deprecate the entire Folio. While REBALANCE_MANAGER and AUCTION_LAUNCHER roles also control significant aspects of rebalancing and auctions, the DEFAULT_ADMIN_ROLE's broad authority centralizes control. This poses a significant single point of failure and a high risk of malicious actions or accidental errors if the admin key is compromised. Unlike the proxy admin, there is no apparent Timelock protecting the actions of the DEFAULT_ADMIN_ROLE within the contract itself (7…H-01

Issue

The DEFAULT_ADMIN_ROLE in the Folio contract possesses extensive privileges, including the ability to set TVL and mint fees, modify the asset basket (add/remove tokens), set auction length, change the mandate, and deprecate the entire Folio. While REBALANCE_MANAGER and AUCTION_LAUNCHER roles also control significant aspects of rebalancing and auctions, the DEFAULT_ADMIN_ROLE's broad authority centralizes control. This poses a significant single point of failure and a high risk of malicious actions or accidental errors if the admin key is compromised. Unlike the proxy admin, there is no apparent Timelock protecting the actions of the DEFAULT_ADMIN_ROLE within the contract itself (7…

Fix

Implement a Timelock mechanism for the DEFAULT_ADMIN_ROLE to introduce a mandatory delay for critical administrative actions. This would allow time for review and potential intervention, significantly reducing the risk associated with centralized control. Consider further decentralizing roles where appropriate.

Status

Unresolved

Medium

_setName Uses Assembly for Direct Storage Slot Manipulation

The _setName function directly manipulates a storage slot using inline assembly (assembly { $.slot := ERC20_STORAGE_LOCATION } $._name = _newName;) to update the ERC-20 token's name. While ERC20_STORAGE_LOCATION is a constant, relying on fixed storage slots in an upgradeable contract is a fragile pattern. If the ERC20Upgradeable contract's storage layout changes in a future OpenZeppelin upgrade, or if ERC20_STORAGE_LOCATION is miscalculated or misconfigured, it could lead to storage collisions, corrupting the contract's state and potentially leading to critical vulnerabilities (7.7 Upgrades, 7.2 Code Security).M-01

Issue

The _setName function directly manipulates a storage slot using inline assembly (assembly { $.slot := ERC20_STORAGE_LOCATION } $._name = _newName;) to update the ERC-20 token's name. While ERC20_STORAGE_LOCATION is a constant, relying on fixed storage slots in an upgradeable contract is a fragile pattern. If the ERC20Upgradeable contract's storage layout changes in a future OpenZeppelin upgrade, or if ERC20_STORAGE_LOCATION is miscalculated or misconfigured, it could lead to storage collisions, corrupting the contract's state and potentially leading to critical vulnerabilities (7.7 Upgrades, 7.2 Code Security).

Fix

Refactor the _setName function to avoid direct assembly-based storage manipulation. Instead, consider using a standard upgradeable pattern for modifying ERC-20 metadata, or ensure that ERC20_STORAGE_LOCATION is robustly verified against all potential OpenZeppelin upgrades and contract inheritance structures. If _name is intended to be immutable after initialization, remove the setter entirely.

Status

Unresolved

Medium

Operational Burden and Potential Griefing in Fee Recipient Management

The _setFeeRecipients function requires fee recipients to be provided in strictly ascending order by address (require(_feeRecipients[i].recipient > previousRecipient)). While this helps prevent duplicate entries and ensures deterministic storage, it creates an operational burden for the DEFAULT_ADMIN_ROLE. If a new fee recipient needs to be inserted with an address that falls between two existing recipients, all subsequent recipients must be removed and then re-added in the correct sorted order. This process is gas-intensive and could be exploited as a griefing vector if an attacker gains admin access, making it costly and cumbersome to manage fee distributions (7.4 Economic, 7.8 Oper…M-02

Issue

The _setFeeRecipients function requires fee recipients to be provided in strictly ascending order by address (require(_feeRecipients[i].recipient > previousRecipient)). While this helps prevent duplicate entries and ensures deterministic storage, it creates an operational burden for the DEFAULT_ADMIN_ROLE. If a new fee recipient needs to be inserted with an address that falls between two existing recipients, all subsequent recipients must be removed and then re-added in the correct sorted order. This process is gas-intensive and could be exploited as a griefing vector if an attacker gains admin access, making it costly and cumbersome to manage fee distributions (7.4 Economic, 7.8 Oper…

Fix

Consider alternative methods for managing fee recipients that do not impose strict sorting requirements, such as using a mapping for individual recipient portions or allowing for unsorted additions/removals with internal sorting logic if necessary. If sorting is deemed essential, provide helper functions to simplify the process of adding, removing, or updating recipients without requiring a full re-submission of the entire list.

Status

Unresolved

Medium

Liquidity not locked

0.0% of the pool's LP is burned or time-locked. 100.0% is held, unlocked, by 3 address(es) other than the owner/deployer. One of them — a wallet, 0x8d38…a01d — holds 98.6% and can remove that share at once; who controls it is not visible on-chain, so it is not treated as an independent provider. Some pools are concentrated-liquidity (V3/V4) positions; shares above are by position as GoPlus reports them. This assessment covers the main pool, which holds 39% of the token's DEX liquidity; the other pools were not assessed.QA-LIQUIDITY

Issue

0.0% of the pool's LP is burned or time-locked. 100.0% is held, unlocked, by 3 address(es) other than the owner/deployer. One of them — a wallet, 0x8d38…a01d — holds 98.6% and can remove that share at once; who controls it is not visible on-chain, so it is not treated as an independent provider. Some pools are concentrated-liquidity (V3/V4) positions; shares above are by position as GoPlus reports them. This assessment covers the main pool, which holds 39% of the token's DEX liquidity; the other pools were not assessed.

Fix

Check the lock's end date and beneficiary on the locker's own page before relying on it.

Status

Acknowledged

Medium

What the token's controller can do

The contract lets its controller — an owner that could not be resolved — mint new supply. Nothing independent vouches for whoever holds them, so each is a live risk to holders.QA-POWERS

Issue

The contract lets its controller — an owner that could not be resolved — mint new supply. Nothing independent vouches for whoever holds them, so each is a live risk to holders.

Fix

Check who holds these powers and whether a timelock or multisig stands between them and holders.

Status

Acknowledged

Low

Lack of Timelock for DEFAULT_ADMIN_ROLE Actions

While the proxy's administrative functions are protected by a Timelock, the DEFAULT_ADMIN_ROLE within the Folio contract itself can execute critical operations (e.g., setTVLFee, setMintFee, addToBasket, deprecateFolio) immediately. The absence of a Timelock for these internal administrative actions means there is no delay period for community review or emergency intervention, increasing the risk of immediate damage from a compromised or malicious admin key (7.3 Access Control, 7.5 Governance).L-01

Issue

While the proxy's administrative functions are protected by a Timelock, the DEFAULT_ADMIN_ROLE within the Folio contract itself can execute critical operations (e.g., setTVLFee, setMintFee, addToBasket, deprecateFolio) immediately. The absence of a Timelock for these internal administrative actions means there is no delay period for community review or emergency intervention, increasing the risk of immediate damage from a compromised or malicious admin key (7.3 Access Control, 7.5 Governance).

Fix

Integrate a Timelock mechanism for the DEFAULT_ADMIN_ROLE to introduce a delay for all critical administrative functions. This would provide a window for monitoring and potential mitigation, enhancing the overall security and governance posture of the protocol.

Status

Unresolved

Low

Presence of Deprecated Variables and Code

The contract contains several _DEPRECATED variables and mappings (e.g., auctions_DEPRECATED, sellEnds_DEPRECATED, buyEnds_DEPRECATED, auctionDelay_DEPRECATED, auctionDetails_DEPRECATED, dustAmount_DEPRECATED). While these are explicitly marked as deprecated, their continued presence in the codebase adds to its complexity, increases the contract's deployed size, and could potentially lead to confusion for developers or auditors. It also suggests that the contract might have undergone significant architectural changes without full cleanup (7.2 Code Security).L-02

Issue

The contract contains several _DEPRECATED variables and mappings (e.g., auctions_DEPRECATED, sellEnds_DEPRECATED, buyEnds_DEPRECATED, auctionDelay_DEPRECATED, auctionDetails_DEPRECATED, dustAmount_DEPRECATED). While these are explicitly marked as deprecated, their continued presence in the codebase adds to its complexity, increases the contract's deployed size, and could potentially lead to confusion for developers or auditors. It also suggests that the contract might have undergone significant architectural changes without full cleanup (7.2 Code Security).

Fix

Remove all deprecated variables and associated code paths from the contract. If historical data or functionality is still required, consider migrating it to a separate, immutable data contract or ensuring that the deprecated code is entirely unreachable and does not consume unnecessary gas or storage.

Status

Unresolved

Info

Reliance on block.timestamp for Time-Sensitive Operations

The contract extensively uses block.timestamp for various time-sensitive operations, including fee accounting (lastPoke, _getPendingFeeShares), auction timing (auctionLength, auctions[auctionId].endTime), and rebalance availability (rebalance.startedAt, rebalance.restrictedUntil, rebalance.availableUntil). While block.timestamp is commonly used, it can be manipulated by miners within a certain range (up to 900 seconds on Ethereum mainnet). For critical operations, this manipulation could potentially lead to minor timing discrepancies or, in specific scenarios, be exploited by a malicious miner to gain a slight advantage (7.2 Code Security).I-01

Issue

The contract extensively uses block.timestamp for various time-sensitive operations, including fee accounting (lastPoke, _getPendingFeeShares), auction timing (auctionLength, auctions[auctionId].endTime), and rebalance availability (rebalance.startedAt, rebalance.restrictedUntil, rebalance.availableUntil). While block.timestamp is commonly used, it can be manipulated by miners within a certain range (up to 900 seconds on Ethereum mainnet). For critical operations, this manipulation could potentially lead to minor timing discrepancies or, in specific scenarios, be exploited by a malicious miner to gain a slight advantage (7.2 Code Security).

Fix

For highly critical time-sensitive operations where miner manipulation of block.timestamp could have significant adverse effects, consider using a more robust and decentralized time oracle (e.g., Chainlink Keepers or a custom oracle solution). For less critical operations, block.timestamp is generally acceptable, but be aware of its limitations.

Status

Unresolved

Info

Who holds the supply

The ten largest holders own 94.4% of supply. What remains: 79.1% in wallets, 15.3% in other contracts. 19,596 holders in total.QA-HOLDERS

Issue

The ten largest holders own 94.4% of supply. What remains: 79.1% in wallets, 15.3% in other contracts. 19,596 holders in total.

Fix

Watch the largest wallets that are not exchanges, pools or locks — those are the ones that can move the price.

Status

Acknowledged

Info

Listed, but not independently verified

Listed on CoinGecko as CF Large Cap Index (LCAP), market cap $5M, rank #1671. 19,596 holders.QA-IDENTITY

Issue

Listed on CoinGecko as CF Large Cap Index (LCAP), market cap $5M, rank #1671. 19,596 holders.

Fix

Match the contract address against the project's official channels before trading.

Status

Acknowledged

Info

The market for this token

Liquidity $1.2M (DexScreener, all pools). 24h trading volume $993K (CoinGecko, all markets, daily snapshot). 24h trading volume $1.3M (DexScreener, all pools).QA-MARKET

Issue

Liquidity $1.2M (DexScreener, all pools). 24h trading volume $993K (CoinGecko, all markets, daily snapshot). 24h trading volume $1.3M (DexScreener, all pools).

Fix

Size any position to the liquidity and daily volume shown — they set how much you can sell and at what price.

Status

Acknowledged

Info

Asset class: Project token

A token issued by a project for use, governance or fundraising. Scored on its contract and market facts. The class itself adds no points; the contract and market facts decide the score. Basis: no class-specific evidence. Tokenomics — Supply: mintable with no on-chain cap found. Control: an owner that could not be resolved. Code: upgradeable proxy. Fees: no buy or sell tax. Market: $1.2M of DEX liquidity across 6 pools. Launch: 423 days of market history.QA-PROFILE

Issue

A token issued by a project for use, governance or fundraising. Scored on its contract and market facts. The class itself adds no points; the contract and market facts decide the score. Basis: no class-specific evidence. Tokenomics — Supply: mintable with no on-chain cap found. Control: an owner that could not be resolved. Code: upgradeable proxy. Fees: no buy or sell tax. Market: $1.2M of DEX liquidity across 6 pools. Launch: 423 days of market history.

Fix

Check the project's own documentation for what the token is used for; this report covers what the contract allows.

Status

Acknowledged

Analysis

AI Copilotas of audit · Oct 19
Executive SummaryWhat the contract is and what the review found

The audit of the Folio contract (implementation for FolioProxy) revealed a well-structured system utilizing OpenZeppelin's upgradeable contracts and access control. Key strengths include reentrancy protection and modular design. However, the audit identified a high centralization risk due to extensive DEFAULT_ADMIN_ROLE privileges, a critical upgrade safety concern with direct storage manipulation via assembly, and operational complexities in fee recipient management.

Technical6/10Medium risk

The Folio contract demonstrates strong technical foundations, leveraging OpenZeppelin's ERC20Upgradeable, AccessControlEnumerableUpgradeable, and ReentrancyGuardUpgradeable for robust security primitives (7.2 Code Security). The use of SafeERC20 for token interactions and custom error messages enhances code safety and clarity. However, a significant technical risk lies in the _setName function's direct manipulation of storage slots via assembly, which is fragile in upgradeable contexts and could lead to storage collisions (7.7 Upgrades). Additionally, the presence of deprecated variables adds unnecessary complexity to the codebase (7.2 Code Security).

Governance1/10High risk

The contract implements a comprehensive role-based access control system, including DEFAULT_ADMIN_ROLE, REBALANCE_MANAGER, and AUCTION_LAUNCHER, which is a strength for managing protocol operations (7.3 Access Control). The fee distribution mechanism, involving tvlFee, mintFee, and daoFeeRegistry, is designed to incentivize participation and support the DAO (7.4 Economic). However, the DEFAULT_ADMIN_ROLE holds extensive power over critical functions, such as setting fees, modifying the asset basket, and deprecating the Folio, without an apparent Timelock for these specific actions, posing a significant centralization risk (7.5 Governance). The fee recipient management also presents an operational burden due to sorting requirements and potential for griefing (7.4 Economic).

Upgrades1/10High risk

The Folio contract is designed as an upgradeable proxy, utilizing OpenZeppelin's Initializable pattern and AccessControlEnumerableUpgradeable, which provides a clear path for future enhancements and bug fixes (7.1 Architecture). The proxy admin is protected by a Timelock, adding a layer of security to the upgrade process. However, the _setName function directly writes to a storage slot using assembly, which is a highly risky practice in upgradeable contracts. This method bypasses standard upgradeable storage patterns and could lead to critical storage collisions if the underlying ERC20Upgradeable storage layout changes or if the ERC20_STORAGE_LOCATION constant is misconfigured (7.7 Upgrades).

Final RecommendationWhat to do about this score

It is strongly recommended to implement a Timelock for the DEFAULT_ADMIN_ROLE to introduce a delay for critical administrative actions, enhancing security and governance transparency.

The use of assembly for direct storage slot manipulation in _setName should be refactored to use standard OpenZeppelin upgradeable storage patterns to prevent potential storage collisions during future upgrades. Additionally, consider refining the _setFeeRecipients function to reduce operational complexity and potential griefing vectors.

Contract & Record

1 audit on record
TypeFolioProxy
NetworkBase
Token age1y
Contract0x4da9…e6e8
Deployer0x5e6e…32d2
Proxy Upgrade Controls
Proxy TypeEip1967 Transparent
AdminOZ ProxyAdmin → Timelock
ImplementationVerified source
Upgrades (30d)0 · stable
Audit History
  1. Oct 19, 202668High

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

Related Audits

6 more on the recordAll audits
Metronome Synth USDMSUSD · Base68HighCoW Protocol TokenCOW · Base68HighSETZBase68HighBaseBase68HighPaperBase68HighPapertradePAPER · Base68High

Would You Like a More Detailed Audit of CF Large Cap Index?

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