Quantum Audit Logo
Launch App

Early-stage security check — honeypot & rug-pull analysis

Is TermMax a Scam?

TMXBNB Chain
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 recordNew Launch · 5d old
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical8/10Governance4/10Upgrades7/10Checks passed5 of 7Findings3 Low · 3 Info6
SummaryAI Copilot

This security review was conducted on the provided Solidity interface definitions for LayerZero V2 components, including ILayerZeroEndpointV2 and related messaging interfaces.

Read the full analysis
What raised the score
  • Ownership not renounced — strong Multisig
  • LP lock status UNKNOWN — the pool's LP could not be read
  • Liquidity < $50k
  • Token age < 7 days
  • 3 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced — strong Multisig (5-of-6)
  • LP lock status UNKNOWN — the pool's LP could not be read
  • Liquidity < $50k ($13,022 across 6 pairs — thin market)
  • Token age < 7 days (early, volatile)
  • 3 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

Early-stage analysis. This token has limited on-chain history (5d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.

Security Checklist

as of audit · Sep 45 of 7 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockUnknown
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026

How the supply is spread across holders could not be read — the indexer's holder list does not add up to the supply. Check the largest holders on a block explorer, which reads current balances.

Liquidity

as of audit · Sep 4$13.0K across 6 pairs

The risk score reads depth across every pair.

LP tokensUnknown

Whether the LP tokens are locked could not be determined.

Analysed pool$7.8KShare of depth59.8%

Security Findings

3 Low3 Info
Low

Design Implies Critical Administrative Functions

The interfaces define numerous highly sensitive administrative functions, such as registerLibrary, setDefaultSendLibrary, setDefaultReceiveLibrary, setSendLibrary, setReceiveLibrary, setLzToken, and setDelegate. These functions control core aspects of the LayerZero messaging system, including library registration, default message routing, and critical token/delegate settings (7.3 Access Control, 7.8 Operations).L-01

Issue

The interfaces define numerous highly sensitive administrative functions, such as registerLibrary, setDefaultSendLibrary, setDefaultReceiveLibrary, setSendLibrary, setReceiveLibrary, setLzToken, and setDelegate. These functions control core aspects of the LayerZero messaging system, including library registration, default message routing, and critical token/delegate settings (7.3 Access Control, 7.8 Operations).

Fix

Any implementation of these interfaces *must* incorporate robust, multi-layered access control mechanisms (e.g., multi-signature wallets, role-based access control, time-locks) to prevent unauthorized modifications that could compromise the entire system's integrity or lead to fund loss.

Status

Unresolved

Low

Payable Functions Require Reentrancy Protection

Several critical functions, including send, lzCompose, and lzReceive, are declared as payable. This indicates that they are designed to handle native token transfers. In an implementation, any interaction with external contracts or token transfers within these payable functions could introduce reentrancy vulnerabilities if not properly mitigated (7.2 Code Security, 7.4 Economic).L-02

Issue

Several critical functions, including send, lzCompose, and lzReceive, are declared as payable. This indicates that they are designed to handle native token transfers. In an implementation, any interaction with external contracts or token transfers within these payable functions could introduce reentrancy vulnerabilities if not properly mitigated (7.2 Code Security, 7.4 Economic).

Fix

Implementations of these payable functions should strictly adhere to the Checks-Effects-Interactions pattern and utilize reentrancy guards (e.g., OpenZeppelin's ReentrancyGuard) to prevent malicious reentrant calls.

Status

Unresolved

Low

Extensive External Calls Increase Attack Surface

The LayerZero V2 architecture, as implied by the interfaces, involves extensive interactions between the endpoint, message libraries, and receiver contracts. Functions like send, lzReceive, and setConfig inherently involve calls to external, potentially untrusted, contracts. This high degree of inter-contract communication increases the overall attack surface and complexity, making the system more susceptible to issues arising from malicious or buggy external contracts (7.2 Code Security, 7.6 External).L-03

Issue

The LayerZero V2 architecture, as implied by the interfaces, involves extensive interactions between the endpoint, message libraries, and receiver contracts. Functions like send, lzReceive, and setConfig inherently involve calls to external, potentially untrusted, contracts. This high degree of inter-contract communication increases the overall attack surface and complexity, making the system more susceptible to issues arising from malicious or buggy external contracts (7.2 Code Security, 7.6 External).

Fix

Implementations should carefully validate all inputs and outputs from external calls. Consider using call limits, gas stipends, and robust error handling for external interactions. Thorough testing of all possible interaction paths, especially with edge cases and malicious external contracts, is crucial.

Status

Unresolved

Info

Audit Scope Limited to Interface Definitions

The provided source code consists solely of Solidity interface definitions for LayerZero V2 components (e.g., ILayerZeroEndpointV2, IMessageLibManager). No concrete contract implementations were provided for analysis. This significantly limits the scope of the audit, as common vulnerabilities such as reentrancy, integer overflows/underflows, and specific access control flaws cannot be identified without the actual contract logic (7.2 Code Security).I-01

Issue

The provided source code consists solely of Solidity interface definitions for LayerZero V2 components (e.g., ILayerZeroEndpointV2, IMessageLibManager). No concrete contract implementations were provided for analysis. This significantly limits the scope of the audit, as common vulnerabilities such as reentrancy, integer overflows/underflows, and specific access control flaws cannot be identified without the actual contract logic (7.2 Code Security).

Fix

Provide the full source code for all relevant contract implementations to enable a comprehensive security audit.

Status

Unresolved

Info

Grace Periods for Receive Library Changes

The setDefaultReceiveLibrary and setReceiveLibrary functions include a _gracePeriod parameter, allowing for a delayed activation of new receive libraries. This mechanism provides a time window for users or governance to react to potentially malicious or erroneous library changes, enhancing security and operational safety (7.8 Operations, 7.5 Governance).I-02

Issue

The setDefaultReceiveLibrary and setReceiveLibrary functions include a _gracePeriod parameter, allowing for a delayed activation of new receive libraries. This mechanism provides a time window for users or governance to react to potentially malicious or erroneous library changes, enhancing security and operational safety (7.8 Operations, 7.5 Governance).

Fix

Continue to utilize and enforce grace periods for all critical configuration changes where feasible, especially those that could impact user funds or system integrity.

Status

Unresolved

Info

Dynamic Configuration via setConfig

The IMessageLibManager and IMessageLib interfaces define setConfig and getConfig functions, allowing for dynamic configuration of message libraries. This provides significant flexibility for adapting the system to various requirements and evolving protocols. However, dynamic configuration also introduces complexity and the potential for misconfiguration if not managed with extreme care (7.1 Architecture, 7.8 Operations).I-03

Issue

The IMessageLibManager and IMessageLib interfaces define setConfig and getConfig functions, allowing for dynamic configuration of message libraries. This provides significant flexibility for adapting the system to various requirements and evolving protocols. However, dynamic configuration also introduces complexity and the potential for misconfiguration if not managed with extreme care (7.1 Architecture, 7.8 Operations).

Fix

Implementations should ensure that setConfig is protected by stringent access control. All configuration parameters should be thoroughly validated before application. Consider implementing a robust testing framework for configuration changes and potentially a multi-stage approval process for critical updates.

Status

Unresolved

Analysis

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

This security review was conducted on the provided Solidity interface definitions for LayerZero V2 components, including ILayerZeroEndpointV2 and related messaging interfaces. No concrete contract implementations were provided for analysis, which significantly limits the scope of this audit. The prefill indicated 'MyOFT' as a contract name, but no source code for 'MyOFT' was available. Therefore, the analysis focuses on the architectural implications, design patterns, and potential security considerations derived from the interface definitions. A comprehensive security assessment, including identification of implementation-specific vulnerabilities, requires the full source code of all deployed contracts.

Technical8/10Low risk

The technical architecture, as defined by the interfaces (7.1 Architecture), demonstrates a modular and extensible design for cross-chain messaging. Key strengths include explicit grace periods for critical configuration changes, such as setDefaultReceiveLibrary, which enhances operational safety. However, the design also implies a high degree of inter-contract complexity (7.2 Code Security) due to extensive external calls to message libraries and receiver contracts, increasing the attack surface. Critical administrative functions like registerLibrary and setLzToken (7.3 Access Control) are defined, necessitating robust access control in any implementation.

Governance4/10Medium risk

The interfaces define functions that directly impact economic aspects (7.4 Economic), such as quote and send for fee calculation and message transmission, and setLzToken for managing the LayerZero token. The presence of payable functions (send, lzCompose, lzReceive) indicates native token handling, which requires careful implementation to prevent economic exploits. Governance (7.5 Governance) is implied through administrative functions that control core system parameters, emphasizing the need for secure governance mechanisms to manage these critical settings.

Upgrades7/10Low risk

The modular design, with distinct interfaces for message libraries (IMessageLibManager, IMessageLib), suggests a flexible architecture that can accommodate future upgrades or changes (7.7 Upgrades) by swapping out library implementations. The use of grace periods for receive library changes further supports a safer upgrade path for critical components. However, the interfaces themselves do not explicitly define an upgrade mechanism (e.g., proxy patterns), which would be a crucial consideration for the concrete implementations.

Final RecommendationWhat to do about this score

To ensure the security and integrity of the LayerZero V2 system, it is paramount that all concrete contract implementations adhere to stringent security best practices.

Implementations of critical administrative functions must incorporate robust access control, ideally through multi-signature wallets or time-locked governance. All payable functions should be protected against reentrancy attacks using established patterns like Checks-Effects-Interactions and reentrancy guards. Furthermore, comprehensive testing, including fuzzing and formal verification, should be conducted on the full implementation to identify and mitigate vulnerabilities arising from complex inter-contract interactions and dynamic configurations.

Contract & Record

1 audit on record
TypeSolidity 0.8.22
NetworkBNB Chain
Token age5d
Contract0x3c2f…0039
Deployer0x1c59…976f
Badge for your website
TermMax 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, 202639Medium
  2. Aug 30, 202661Medium

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

Frequently Asked Questions

What is the TMX contract address?

The TermMax (TMX) contract on BNB Chain is 0x3c2f61f2e27c865981d2e7aaf6b2cdf823030039. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is TermMax a scam?

Quantum Audit's risk score for TermMax is 39/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: No mint; 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.

Related Audits

6 more on the recordAll audits
Bitway TokenBTW · BNB Chain39MediumMarsCoinBNB Chain39MediumCZ'S DOGBROCCOLI · BNB Chain39Medium永生果蝇果蝇 · BNB Chain39MediumFetchFET · BNB Chain39MediumR2BNB Chain39Medium

Would You Like a More Detailed Audit of TermMax?

This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.

Get Detailed Audit Is this your token? Publish your own audit on this page