Quantum Audit Logo

Is Interfold Safe?

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

Is this your token? Publish your own audit on this page →

Interfold FOLD
0xe172…f904
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

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.

1 Critical1 High2 Medium2 Informational
Volume 24h
$1.16M
Liquidity
$1.68M
Price
$0.05735
Token Age
1mo
Top 10 Holders
73.8%

Security Findings

1 Crit1 High2 Med2 Info
Critical

Critical Business Logic Not Provided for Review

C-01A 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…
IssueA 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…
FixProvide 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.
StatusUnresolved
High

High Centralization Risk via Privileged Roles

H-01The 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.
IssueThe 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.
FixEnsure 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.
StatusUnresolved
Medium

Lack of Emergency Pause Mechanism

M-01The 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.
IssueThe 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.
FixConsider 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.
StatusUnresolved
Medium

Dependency on External Bonding Registry

M-02The `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`).
IssueThe `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`).
FixThoroughly 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`.
StatusUnresolved
Info

`NO_MORE_LOCKS` Constant Interpretation

I-01The `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.
IssueThe `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.
FixEnsure 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.
StatusUnresolved
Info

Renounce Ownership/Roles Disabled by Design

I-02The 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.
IssueThe 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.
FixThis 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.
StatusUnresolved

Category Ratings

TechnicalMedium5/10

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

GovernanceHigh2/10

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

UpgradesHigh3/10

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.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

73.8% in top 10
8.9% in wallets64.9% in contracts
Effective Concentration34.8%

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

$2.53M across 9 pairs
Uniswap v4ETHanalysed$1.68M66.4%Uniswap v4USDC$794.9K31.4%Uniswap v4USDC$31.8K1.3%Uniswap v4ETH$7.2K0.3%Uniswap v4USDC$6.3K0.3%Uniswap v4USDC$5.3K0.2%
Show 2 more pairsShow less
Uniswap v4USDC$3.4K0.1%Uniswap v4USDC$380.0%

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 Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

2 addresses
Deployer
0x0b84…c8cb
Unlocked LP Held By
0xe491…ea1f

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

What Raised This Score

9 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

Related Audits

6 more on the record
HarryPotterObamaSonic10Inu (BITCOIN)High RiskLego Pepe (LEPE)High RiskGraph Token (GRT)High RiskGnosis Token (GNO)High RiskTokenFi (TOKEN)High RiskANyONe Protocol (ANYONE)High Risk

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