Quantum Audit Logo
Launch App

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

Is Interfold Safe?

FOLDEthereum
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
Technical5/10Governance2/10Upgrades3/10Checks passed4 of 7Findings1 Critical · 1 High · 2 Medium · 2 Info6
SummaryAI Copilot

The InterfoldToken contract implements an ERC20 token with advanced features including vesting locks, role-based access control, and a multi-phase lifecycle.

Read the full analysis
What raised the score
  • Ownership not renounced — strong Multisig
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
Exact factors
  • Ownership NOT renounced — strong Multisig (3-of-5)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (73.8% total → 34.8% effective; 8.9% in EOAs, 64.9% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 66% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 66% of DEX liquidity)
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 2 Medium 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 44 of 7 checks passed
Contract verifiedVerified
OwnershipRetained
MintMintable
Liquidity lockNot locked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
64.9%Contracts8.9%Wallets26.2%Everyone else
64.9%Contracts8.9%26.2%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
73.8%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking64.9%
  • Walletsanonymous holders, free to sell8.9%
  • Everyone elsethe rest of the supply26.2%
Effective concentrationwhat the score reads34.8%
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$2.53M across 9 pairs
Show 2 more 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$1.68MShare of depth66.4%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0xe491…ea1f

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

Security Findings

1 Critical1 High2 Medium2 Info
Critical

Critical Business Logic Not Provided for Review

A significant portion of the contract's core business logic, including functions responsible for token minting (_mintTokens), lock policy validation (_validateCurve, _validatePolicyMaturity), claim linking (_linkClaim), lock relinking (_relinkActiveLock, _relinkQueuedLock), spendable balance calculation (_calculateSpendable), and the critical _beforeTokenTransfer hook, were not included in the provided source code. These internal functions are fundamental to the token's economic model, vesting schedules, and transfer restrictions. Without reviewing these implementations, it is impossible to fully assess the contract's security, potential for economic manipulation, or correct…C-01

Issue

A significant portion of the contract's core business logic, including functions responsible for token minting (_mintTokens), lock policy validation (_validateCurve, _validatePolicyMaturity), claim linking (_linkClaim), lock relinking (_relinkActiveLock, _relinkQueuedLock), spendable balance calculation (_calculateSpendable), and the critical _beforeTokenTransfer hook, were not included in the provided source code. These internal functions are fundamental to the token's economic model, vesting schedules, and transfer restrictions. Without reviewing these implementations, it is impossible to fully assess the contract's security, potential for economic manipulation, or correct…

Fix

Provide the complete source code for all internal functions and dependencies that constitute the core business logic of the InterfoldToken contract. A full audit of these components is essential to ensure their security, prevent potential exploits, and verify the integrity of the token's economic model.

Status

Unresolved

High

High Centralization Risk via Privileged Roles

The contract relies heavily on privileged roles (DEFAULT_ADMIN_ROLE, MINTER_ROLE, WHITELIST_ROLE, LOCK_MANAGER_ROLE) for critical operations such as minting new tokens, managing transfer whitelists, and defining/linking lock policies. The DEFAULT_ADMIN_ROLE has the power to grant and revoke all other roles. If the private keys controlling these roles, especially the DEFAULT_ADMIN_ROLE, are compromised, an attacker could mint arbitrary tokens (up to MAX_SUPPLY), freeze transfers, or manipulate vesting schedules, leading to severe economic damage and loss of user funds. While the owner is a multisig, the AccessControl roles are distinct.H-01

Issue

The contract relies heavily on privileged roles (DEFAULT_ADMIN_ROLE, MINTER_ROLE, WHITELIST_ROLE, LOCK_MANAGER_ROLE) for critical operations such as minting new tokens, managing transfer whitelists, and defining/linking lock policies. The DEFAULT_ADMIN_ROLE has the power to grant and revoke all other roles. If the private keys controlling these roles, especially the DEFAULT_ADMIN_ROLE, are compromised, an attacker could mint arbitrary tokens (up to MAX_SUPPLY), freeze transfers, or manipulate vesting schedules, leading to severe economic damage and loss of user funds. While the owner is a multisig, the AccessControl roles are distinct.

Fix

Ensure that all privileged roles, particularly the DEFAULT_ADMIN_ROLE, are controlled by robust multi-signature wallets with a high threshold (e.g., 3-of-5 or higher) to distribute control and reduce the risk of a single point of failure. Implement strict operational procedures for managing these keys and executing privileged transactions. Regularly review and audit the addresses holding these roles.

Status

Unresolved

Medium

Lack of Emergency Pause Mechanism

The contract does not include a general emergency pause mechanism that could halt critical operations or all token transfers in response to a discovered vulnerability, a major exploit, or unforeseen market conditions. While transferWhitelist allows for restricting transfers to specific accounts, it is not a comprehensive solution for a system-wide emergency. Without a pause, the project team's ability to react quickly and mitigate damage during a crisis is limited.M-01

Issue

The contract does not include a general emergency pause mechanism that could halt critical operations or all token transfers in response to a discovered vulnerability, a major exploit, or unforeseen market conditions. While transferWhitelist allows for restricting transfers to specific accounts, it is not a comprehensive solution for a system-wide emergency. Without a pause, the project team's ability to react quickly and mitigate damage during a crisis is limited.

Fix

Consider implementing an emergency pause mechanism (e.g., using OpenZeppelin's Pausable module) that can be triggered by a trusted role (e.g., the DEFAULT_ADMIN_ROLE or a dedicated 'Pauser' role). This would allow for a rapid response to critical situations, preventing further damage while a permanent solution is developed and deployed.

Status

Unresolved

Medium

Dependency on External Bonding Registry

The InterfoldToken contract has an immutable dependency on an external IBondingRegistry contract, set during construction. While the constructor performs a basic check for a non-zero address and non-empty code, it does not guarantee the security, immutability, or continued functionality of the BONDING_REGISTRY itself. If the IBondingRegistry contract were to be compromised, upgraded maliciously (if it's a proxy), or experience a critical bug, it could indirectly impact the InterfoldToken's functionality, especially if the token's internal logic relies on the registry's state or functions in critical paths (e.g., _beforeTokenTransfer or _claimLock).M-02

Issue

The InterfoldToken contract has an immutable dependency on an external IBondingRegistry contract, set during construction. While the constructor performs a basic check for a non-zero address and non-empty code, it does not guarantee the security, immutability, or continued functionality of the BONDING_REGISTRY itself. If the IBondingRegistry contract were to be compromised, upgraded maliciously (if it's a proxy), or experience a critical bug, it could indirectly impact the InterfoldToken's functionality, especially if the token's internal logic relies on the registry's state or functions in critical paths (e.g., _beforeTokenTransfer or _claimLock).

Fix

Thoroughly audit the IBondingRegistry contract for vulnerabilities. Ensure that the BONDING_REGISTRY is also immutable or, if upgradeable, that its upgrade mechanism is robust and controlled by a secure governance process. Clearly document the expected behavior and security assumptions related to the BONDING_REGISTRY and its interaction with the InterfoldToken.

Status

Unresolved

Info

NO_MORE_LOCKS Constant Interpretation

The NO_MORE_LOCKS constant is initialized in the constructor with a check noMoreLocks_ <= earliestTge, requiring it to be strictly after earliestTge. The name 'NO_MORE_LOCKS' suggests a specific point in time after which no new locks can be created. However, the provided snippet does not show where or how this constant is enforced within the contract's logic (e.g., in createLockPolicy or linkClaim). Without this enforcement, the constant's purpose is unclear and it may not effectively prevent new locks.I-01

Issue

The NO_MORE_LOCKS constant is initialized in the constructor with a check noMoreLocks_ <= earliestTge, requiring it to be strictly after earliestTge. The name 'NO_MORE_LOCKS' suggests a specific point in time after which no new locks can be created. However, the provided snippet does not show where or how this constant is enforced within the contract's logic (e.g., in createLockPolicy or linkClaim). Without this enforcement, the constant's purpose is unclear and it may not effectively prevent new locks.

Fix

Ensure that the NO_MORE_LOCKS constant is actively enforced in all relevant functions (e.g., createLockPolicy, linkClaim, _mintAllocation) to prevent the creation of new locks after the specified timestamp. Add clear comments to the code explaining the intended behavior and enforcement mechanism of this constant.

Status

Unresolved

Info

Renounce Ownership/Roles Disabled by Design

The contract includes custom errors RenounceOwnershipDisabled() and RenounceRoleDisabledForOwner(), indicating an intentional design choice to prevent the owner from renouncing their ownership or the DEFAULT_ADMIN_ROLE. This is a security-conscious decision to prevent accidental loss of administrative control, which can be catastrophic for a protocol.I-02

Issue

The contract includes custom errors RenounceOwnershipDisabled() and RenounceRoleDisabledForOwner(), indicating an intentional design choice to prevent the owner from renouncing their ownership or the DEFAULT_ADMIN_ROLE. This is a security-conscious decision to prevent accidental loss of administrative control, which can be catastrophic for a protocol.

Fix

This is an intentional design choice and generally considered a good security practice. Ensure that this design decision is clearly documented within the project's specifications and understood by all stakeholders. The project team should have robust procedures for transferring ownership and managing role assignments.

Status

Unresolved

Analysis

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

The InterfoldToken contract implements an ERC20 token with advanced features including vesting locks, role-based access control, and a multi-phase lifecycle. While it leverages battle-tested OpenZeppelin libraries and includes robust checks in its constructor and public functions, a significant portion of the critical business logic resides in internal functions not provided for review. This limitation prevents a comprehensive security assessment of the core token mechanics and vesting logic, leading to a higher overall risk rating.

Technical5/10Medium risk

The contract utilizes OpenZeppelin's ERC20, ERC20Permit, ERC20Votes, Ownable2Step, and AccessControl, providing a solid foundation for token functionality and access management (7.2 Code Security). The constructor includes thorough validation for initial parameters like CCA windows and the Bonding Registry address, demonstrating good architectural practices (7.1 Architecture). However, the core logic for vesting, lock management, and transfer restrictions is implemented in internal functions (_mintTokens, _validateCurve, _beforeTokenTransfer, etc.) which were not available for review, posing a critical technical risk (7.2 Code Security).

Governance2/10High risk

The contract implements a robust role-based access control system using OpenZeppelin's AccessControl, defining specific roles like MINTER_ROLE, WHITELIST_ROLE, and LOCK_MANAGER_ROLE, which enhances operational security by segregating duties (7.3 Access Control). The Ownable2Step pattern for ownership transfer adds an extra layer of security (7.3 Access Control). However, the system relies heavily on the security of the addresses holding these privileged roles, particularly the DEFAULT_ADMIN_ROLE which can grant other roles, introducing a high centralization risk (7.5 Governance). The MAX_SUPPLY constant and phase-based minting restrictions (MintingClosed) are positive economic controls (7.4 Economic).

Upgrades3/10High risk

The contract is not designed as an upgradeable proxy, meaning its core logic cannot be changed post-deployment (7.7 Upgrades). This provides immutability and reduces the attack surface associated with upgrade mechanisms. However, administrative parameters and roles can be updated by the owner or authorized roles, allowing for operational flexibility (7.8 Operations). The Ownable2Step pattern ensures a secure transfer of ownership, mitigating risks during administrative changes.

Final RecommendationWhat to do about this score

It is imperative to conduct a comprehensive audit of all internal functions related to token minting, locking, vesting, and transfer restrictions to verify their correctness, security, and adherence to the intended economic model.

Ensure all privileged roles, especially the DEFAULT_ADMIN_ROLE, are controlled by robust multi-signature wallets with a high threshold to mitigate centralization risks. Consider implementing an emergency pause mechanism to provide a rapid response capability in case of unforeseen vulnerabilities or exploits.

Contract & Record

1 audit on record
TypeInterfoldToken
NetworkEthereum
Token age1mo
Contract0xe172…f904
Deployer0x0b84…c8cb
Badge for your website
Interfold 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, 202661Medium
  2. Aug 30, 202666High

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

Frequently Asked Questions

What is the FOLD contract address?

The Interfold (FOLD) contract on Ethereum is 0xe172e9b6cfbeeb5593bdce3f077356fdb33af904. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Interfold a scam?

Quantum Audit's risk score for Interfold is 61/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: Mintable; Liquidity lock: Not locked; Upgradeability: Fixed code; Honeypot: None found; Buy / sell tax: 0% / 0%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is FOLD liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $2.53M.

Who holds FOLD?

As of Sep 4, 2026, the 10 largest holders own 73.8% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
HarryPotterObamaSonic10InuBITCOIN · Ethereum61MediumLego PepeLEPE · Ethereum61MediumGraph TokenGRT · Ethereum61MediumGnosis TokenGNO · Ethereum61MediumTokenFiTOKEN · Ethereum61MediumANyONe ProtocolANYONE · Ethereum61Medium

Would You Like a More Detailed Audit of Interfold?

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