Audit name:
[SCA] Node Meta | NTE | Feb2026
Date:
Mar 7, 2026
Table of Content
Introduction
We express our gratitude to the Node Meta team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Enterprise-grade BEP20 token with advanced DeFi features, MEV protection, and emergency controls.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Node Meta |
| Audited By | Khrystyna Tkachuk, Kerem Solmaz |
| Approved By | Ivan Bondar, Turgay Arda Usman |
| Website | https://node-meta.com/→ |
| Changelog | 11/02/2026 - Preliminary Report |
| 24/02/2026 - Interim Report | |
| 07/03/2026 - Final Report | |
| Platform | BSC |
| Language | Solidity |
| Tags | ERC20, Fee-On-Transfer, Signatures |
| Methodology | https://docs.hacken.io/methodologies/smart-contracts→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Node Meta
- Audited By
- Khrystyna Tkachuk, Kerem Solmaz
- Approved By
- Ivan Bondar, Turgay Arda Usman
- Website
- https://node-meta.com/→
- Changelog
- 11/02/2026 - Preliminary Report
- 24/02/2026 - Interim Report
- 07/03/2026 - Final Report
- Platform
- BSC
- Language
- Solidity
- Tags
- ERC20, Fee-On-Transfer, Signatures
Review Scope | |
|---|---|
| Repository | https://github.com/nodemeta/nte→ |
| Initial Commit | 04d20e37cacc93e42945ac691a297688545e9b3a |
| Final Commit | 58ae668b2b8075c0d5f6a54f87036a464e305068 |
Review Scope
- Repository
- https://github.com/nodemeta/nte→
- Initial Commit
- 04d20e37cacc93e42945ac691a297688545e9b3a
- Final Commit
- 58ae668b2b8075c0d5f6a54f87036a464e305068
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Functional requirements are partially missed.
Technical description is not provided.
Code quality
The code duplicates commonly known contracts instead of reusing them.
NatSpec is included across the contracts.
The development environment is configured.
Test coverage
Code coverage of the project is 0 %.
Tests are not provided.
System Overview
NTE is an advanced BEP20 token (BNB Chain) that extends standard ERC20 with:
Configurable taxes on buy, sell, and P2P transfers, with a dedicated treasury and optional auto-liquidity routing.
PancakeSwap V2 integration for a canonical NTE/WETH pair and DEX-aware tax (buy vs sell vs transfer).
Security and anti-abuse layers: pause, anti-bot window, blacklist/whitelist, MEV protection, velocity limits, anti-dump, price-impact cap, and wallet cooldown.
Categorized transfers with off-chain signatures (auth signers) for business/reward flows.
Staking integration via a designated staking contract that can lock/unlock user balances.
No minting after deployment; only the initial supply is minted in the constructor. Any address can burn its own tokens.
It has the following attributes:
Name: Node Meta Energy
Symbol: NTE
Decimals: 18
Total supply: defined on the contract deployment.
Privileged roles
The owner of the NTE contract has administrative control over the contract configuration, including pausing functionality, ownership management, tax updates, blacklist and whitelist management, and DeFi protection mechanisms (setAntiDumpConfig, setPriceImpactLimitConfig, setPriceImpactExempt, setWalletCooldownConfig, setMevProtectionConfig, setMevProtectionExempt, setVelocityLimitConfig, setVelocityLimitExempt). The owner can also enable or disable the DEX pair address, set the stakingContract address, manage authSigner roles, manage payment categories (addCategory, setCategoryEnabled, updateCategoryName), and perform emergency withdrawals of ERC20 tokens and BNB. Emergency ERC20 token withdrawal has no time restriction, while BNB withdrawal requires 30 days post-launch. Ownership can be transferred instantly, but renouncing ownership is locked for 30 days after deployment. The owner is exempt from taxes and is not subject to anti-bot restrictions. If pauseIncludesOwner is set to true, even the owner's transfers can be blocked when the contract is paused.
The authorized signers stored in the isAuthSigner mapping are off-chain signers whose signatures are required to authorize categorized transfers. Any caller with sufficient allowance from the from address can execute TransactionFrom(), provided they supply a valid signature from an authorized signer.
The stakingContract can lock (lockFromStaking()) or unlock (unlockFromStaking()) tokens on behalf of users. The locked balance is enforced within _transfer(): a user cannot transfer tokens if doing so would reduce their balance below lockedForStaking[user
Potential Risks
Fixed Total Supply Post-Deployment: The token’s total supply is determined at deployment and cannot be verified beforehand, potentially limiting the project’s adaptability and economic model flexibility.
Centralized Minting to a Single Address: The project concentrates minting tokens in a single address, raising the risk of fund mismanagement or theft, especially if key storage security is compromised.
Owner's Unrestricted State Modification: The absence of restrictions on state variable modifications by the owner leads to arbitrary changes, affecting contract integrity and user trust, especially during critical operations like minting phases.
Single Points of Failure and Control: The project is fully or partially centralized, introducing single points of failure and control. This centralization can lead to vulnerabilities in decision-making and operational processes, making the system more susceptible to targeted attacks or manipulation.
Dependency on External Logic for Implemented Logic: The implemented NTE logic depends on stakingContract implementation not covered by the audit that calls lockFromStaking and unlockFromStaking fucntions. This reliance introduces risks if these external contracts are compromised or contain vulnerabilities, affecting the audited project's integrity.
Interactions with External DeFi Protocols: The NTE contract depends on PancakeSwap (Uniswap V2) for price impact calculations, pair detection, and tax routing. If the PancakeSwap router or pair contracts are compromised or behave unexpectedly, it could affect tax calculations, MEV protection logic, and anti-dump enforcement. This is distinct from your existing staking dependency risk.
Absence of Time-lock Mechanisms for Critical Operations: The owner can instantly change critical parameters like blacklisting/unblacklisting addresses, toggling pause, changing treasury address, modifying MEV/anti-dump/cooldown settings, and setting DEX pair status - all without any timelock or delay. The only rate-limited operation is tax rate changes (24h cooldown, max 2.5% delta). Users have no advance notice of other impactful changes.
Blacklist Capability as Address Freezing Risk: The owner can permanently blacklist any address (except themselves and the contract), effectively freezing user funds with no recourse. While this can serve compliance purposes, it introduces censorship risk and potential for fund lockup if the owner key is compromised or misused.
Owner Tax Exemption and Transfer Privilege: The owner address is hardcoded as exempt from all taxes, pause restrictions (when pauseIncludesOwner is false), anti-bot checks, whitelist requirements, and anti-dump enforcement. This creates a trust requirement where the owner can trade freely under conditions where all other users are restricted.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2026-1501 | Double Taxation on Liquidity ETH Removal via Router | fixed | High | |
| F-2026-1502 | Owner Rights Can Be Renounced While Contract Is Paused Permanently Locking Transfer | fixed | Medium | |
| F-2026-1501 | Buy and Sell Fees Unexpectedly Applied During Liquidity Provision Operations | mitigated | Medium | |
| F-2026-1500 | Hardcoded Primary Pair In _calculatePriceImpact() Leads To Price Impact Limit Bypass On Secondary DEX Pairs | fixed | Medium | |
| F-2026-1498 | pancakeRouter and pancakePair Initialization Can Be Skipped in Constructor With No Recovery Mechanism | fixed | Medium | |
| F-2026-1494 | Incorrect maxSellAmount Calculation Allows Selling Up to Total Supply Amount | fixed | Medium | |
| F-2026-1495 | Missing Expiration Deadline In TransactionFrom Signature Leads To Indefinitely Valid Signed Authorizations | fixed | Low | |
| F-2026-1504 | Missing msg.sender Validation in _transferWithTax | fixed | Observation | |
| F-2026-1502 | Redundant receive Function | accepted | Observation | |
| F-2026-1502 | Lack of Two Step Ownership Transfer Mechanism | fixed | Observation |
Appendix 1. Definitions
Severities
When auditing smart contracts, Hacken is using a risk-based approach that considers Likelihood, Impact, Exploitability and Complexity metrics to evaluate findings and score severities.
Reference on how risk scoring is done is available through the repository in our Github organization:
Severity | Description |
|---|---|
Critical | Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation. |
High | High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation. |
Medium | Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category. |
Low | Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution. |
Severity
- Critical
Description
- Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation.
Severity
- High
Description
- High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation.
Severity
- Medium
Description
- Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category.
Severity
- Low
Description
- Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution.
Potential Risks
The "Potential Risks" section identifies issues that are not direct security vulnerabilities but could still affect the project’s performance, reliability, or user trust. These risks arise from design choices, architectural decisions, or operational practices that, while not immediately exploitable, may lead to problems under certain conditions. Additionally, potential risks can impact the quality of the audit itself, as they may involve external factors or components beyond the scope of the audit, leading to incomplete assessments or oversight of key areas. This section aims to provide a broader perspective on factors that could affect the project's long-term security, functionality, and the comprehensiveness of the audit findings.
Appendix 2. Scope
The scope of the project includes the following smart contracts from the provided repository:
Scope Details | |
|---|---|
| Repository | https://github.com/nodemeta/nte→ |
| Initial Commit | 04d20e37cacc93e42945ac691a297688545e9b3a |
| Final Commit | 58ae668b2b8075c0d5f6a54f87036a464e305068 |
| Whitepaper | N/A |
| Requirements | README.md |
| Technical Requirements | README.md |
Scope Details
- Repository
- https://github.com/nodemeta/nte→
- Initial Commit
- 04d20e37cacc93e42945ac691a297688545e9b3a
- Final Commit
- 58ae668b2b8075c0d5f6a54f87036a464e305068
- Whitepaper
- N/A
- Requirements
- README.md
- Technical Requirements
- README.md
Assets in Scope
Appendix 3. Additional Valuables
Additional Recommendations
The smart contracts in the scope of this audit could benefit from the introduction of automatic emergency actions for critical activities, such as unauthorized operations like ownership changes or proxy upgrades, as well as unexpected fund manipulations, including large withdrawals or minting events. Adding such mechanisms would enable the protocol to react automatically to unusual activity, ensuring that the contract remains secure and functions as intended.
To improve functionality, these emergency actions could be designed to trigger under specific conditions, such as:
Detecting changes to ownership or critical permissions.
Monitoring large or unexpected transactions and minting events.
Pausing operations when irregularities are identified.
These enhancements would provide an added layer of security, making the contract more robust and better equipped to handle unexpected situations while maintaining smooth operations.
Frameworks and Methodologies
This security assessment was conducted in alignment with recognised penetration testing standards, methodologies and guidelines, including the NIST SP 800-115 – Technical Guide to Information Security Testing and Assessment →, and the Penetration Testing Execution Standard (PTES) →, These assets provide a structured foundation for planning, executing, and documenting technical evaluations such as vulnerability assessments, exploitation activities, and security code reviews. Hacken’s internal penetration testing methodology extends these principles to Web2 and Web3 environments to ensure consistency, repeatability, and verifiable outcomes.