Q2 2026 Security & Compliance Report67 incidents, $764M in losses, 88% from operational failures.
Get the report →
Node Meta logo

Node Meta

Audit name:

[SCA] Node Meta | NTE | Jun2026

Date:

Jun 22, 2026

Table of Content

→Introduction
→Audit Summary
→System Overview
→Potential Risks
→Findings
→Appendix 1. Definitions
→Appendix 2. Scope
→Appendix 3. Additional Valuables
→Disclaimer

Want a comprehensive audit report like this?

Introduction

We express our gratitude to the Node Meta team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.

Node Meta Energy (NTE) is a BEP20-compatible token deployed on BNB Smart Chain, built around a configurable tax-on-transfer mechanism with integrated PancakeSwap DEX liquidity management. The core user-facing actions include taxed token transfers (buy, sell, peer-to-peer), off-chain-signed categorized payments, token burning, and interaction with the built-in role-based governance and timelock system.

Document

NameSmart Contract Code Review and Security Analysis Report for Node Meta
Audited ByKhrystyna Tkachuk; Olesia Bilenka
Approved ByKornel Światłowski
Websitewww.node-meta.com
Changelog16/06/2026 - Preliminary Report
22/06/2026 - Final Report
PlatformBSC
LanguageSolidity
TagsERC20, Fee-On-Transfer, Signatures
Methodologyhttps://docs.hacken.io/methodologies/smart-contracts→

  • Document

    Name
    Smart Contract Code Review and Security Analysis Report for Node Meta
    Audited By
    Khrystyna Tkachuk; Olesia Bilenka
    Approved By
    Kornel Światłowski
    Website
    www.node-meta.com
    Changelog
    16/06/2026 - Preliminary Report
    22/06/2026 - Final Report
    Platform
    BSC
    Language
    Solidity
    Tags
    ERC20, Fee-On-Transfer, Signatures
    Methodology
    https://docs.hacken.io/methodologies/smart-contracts→

Review Scope

Repositoryhttps://github.com/nodemeta/nte→
Commitd72f563
Remediation commit1317487

Audit Summary

11Total Findings
10Resolved
0Accepted
1Mitigated

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 partially provided.

  • NatSpec comments are sufficient.

Code quality

  • The code duplicates commonly known contracts instead of reusing them.

  • The development environment is configured.

Test coverage

Code coverage of the project is 0 %.

  • Tests are not provided.

System Overview

The protocol centers on NTE, a custom ERC20/BEP20 token that implements standard transfer, transferFrom, approve, and allowance semantics, plus burn and increaseAllowance/decreaseAllowance. All token movements except direct burn are routed through an internal _transferWithTax engine that classifies each transfer as buy, sell, or wallet-to-wallet based on registered PancakeSwap pair addresses and trusted router mappings, then applies the corresponding tax rate. Collected tax is sent to a configurable treasury; an optional auto-liquidity path can split a portion of tax proceeds to a designated liquidityCollector contract. PancakeSwap V2 integration is established at deployment via embedded IPancakeRouter, IPancakeFactory, and IPancakePair interfaces: the constructor can initialize or create an NTE/WBNB pair, and trusted keepers may register additional pairs from trusted factories through registerPairFromFactory.

Trading protections are enforced on every taxed transfer path. A fixed launch-period anti-bot window, MEV shield (block- and time-based spacing, contract-sell restrictions, minimum hold-before-sell), velocity limits, wallet cooldowns, price-impact caps (AMM reserve math via PancakeSwap), and anti-dump sell-size and cooldown rules are applied in sequence. Access control uses blacklist and whitelist mappings (with optional expiry), tax-exempt and helper-bypass lists, and a circuit breaker that auto-pauses when a single transfer exceeds a supply-percentage threshold. Emergency role holders can invoke instant pause; unpausing and other sensitive operations require timelock execution.

Governance is role-based: Security and Governance roles configure protections, lists, and metadata; Governance queues and executes timelocked actions through queueAction, executeAction, and cancelAction (48-hour delay, 7-day grace period), including tax updates, treasury changes, DEX configuration, role grants, ownership transfer, and renouncement. Emergency asset recovery is timelocked: emergencyWithdrawToken and emergencyWithdrawBNB send stranded ERC20 tokens and native BNB only to an mutable emergencyRescueVault, with BNB withdrawal additionally restricted until 30 days after launch. The stored _owner address is updated only through timelocked transferOwnership and renounceOwnership and does not gate any function; operational access control is enforced entirely through role membership. Standards implemented include ERC20 token semantics, and PancakeSwap V2 router/factory/pair interfaces for DEX price quotes and pair management.

NTECategoryManager is a decoupled companion contract that manages transaction category bookkeeping, off-chain signer authorizations, signature verification, and per-category statistics. It references the main NTE token contract as an immutable dependency and derives all permission checks dynamically from NTE's role system (querying hasRole for GOVERNANCE_ROLE and SECURITY_ROLE on each call). The contract enables categorized token transfers — where a user submits a signed message from an authorized off-chain signer to classify their transfer under a named category (e.g., "Payment", "Reward", "Staking") — and tracks cumulative and per-user transaction counts and volumes for each category. It exposes 50 semantically named public entry points (e.g., Payment, Reward, Bonus, Salary, StakingReward, CoreNodePurchase) that all route through a single internal _transactionFrom execution path. The signature verification uses EIP-191 personal-sign format with sequential nonces, deadline-based expiry, chain ID binding, and ECDSA malleability protection. The contract includes its own emergency ERC-20 and BNB recovery functions (restricted to GOVERNANCE_ROLE, destination locked to NTE's emergencyRescueVault, BNB subject to the same 30-day post-launch lock), reentrancy protection, and a receive fallback for native BNB.

Files in Scope

  • NTE.sol — Monolithic BEP20/ERC20 token contract for Node Meta Energy containing embedded DEX interfaces, the full transfer and tax engine, PancakeSwap pair registration, role-based governance with native timelock, trading protection modules, and emergency rescue functions. Key responsibilities include ERC20 lifecycle (transfer, approve, burn), tax routing and auto-liquidity configuration, protection enforcement in _transferWithTax, and timelocked admin operations through queueAction/executeAction.

  • NTECategoryManager.sol — Decoupled companion contract for NTE token transaction classification via off-chain signature authorization. Implements categorized transfers with per-category bookkeeping (transaction counts and volumes per category and per user), authorized signer management, sequential nonce-based replay protection, EIP-191 signature verification with ECDSA malleability checks, 50 semantic transaction aliases (Transaction, Payment, Reward, Bonus, Payout, Deposit, Withdrawal, Purchase, Refund, Fee, Subscription, Sell, Gift, Airdrop, Mint, Royalty, Incentive, Penalty, Cashback, Swap, Bridge, Escrow, Loan, Repayment, Rent, Claim, LevelUpReward, MoveToEarnReward, TournamentPrize, GovernanceVotingFee, CardPayment, Salary, StakingReward, FarmingReward, LotteryPrize, Charity, Donation, Tip, PartnerPayment, ReferralBonusClaim, CoreNodePurchase, EliteNodePurchase, CoreNodeBonusClaim, EliteNodeBonusClaim, StakingPurchase, StakingBonusClaim, MetaPulsePurchase, MetaPulseBonusClaim, DBEPurchase, DBEBonusClaim), emergency ERC-20 and BNB recovery functions restricted to NTE's emergency rescue vault, and reentrancy protection. Permission checks are derived dynamically from the main NTE contract's role system.

Privileged roles

NTEsol

GOVERNANCE_ROLE: Primary governance authority; timelock orchestration, token metadata, and override access to all onlyRoleOrGov(SECURITY_ROLE) functions.

  • Can call queueAction to enqueue a timelocked call (48-hour delay, 7-day grace period).

  • Can call executeAction to execute a queued call after the delay; when target is address(this), msg.sender becomes the contract and unlocks onlyTimelock functions.

  • Can call cancelAction to cancel a queued timelocked call.

  • Can call setNameAndSymbol to update the token name and symbol.

  • Can call pause to halt all token transfers (via onlyEmergencyOrGov).

  • Can call all SECURITY_ROLE\-gated functions listed below via the onlyRoleOrGov(SECURITY_ROLE) modifier.

  • Can access all onlyRoleOrGov(TREASURY_ROLE) functions as a fallback (see TREASURY_ROLE below).

  • Can access all onlyEmergencyOrGov functions as a fallback (see EMERGENCY_ROLE below).

  • During _transferWithTax, governance accounts are exempt from pause when pauseIncludesOwner is false (if from, to, or msg.sender holds GOVERNANCE_ROLE), from the launch anti-bot window, from whitelist enforcement, from tax collection when from or to holds GOVERNANCE_ROLE, and from velocity limits when from holds GOVERNANCE_ROLE. MEV, wallet cooldown, price-impact, anti-dump, and circuit-breaker rules still apply unless the address is separately listed in the corresponding exemption mappings.

TREASURY_ROLE: Controls tax-related operational parameters without timelock delay.

  • Can call setTaxExempt to grant or revoke tax exemption for an address.

  • Can call setAntiDumpConfig to configure anti-dump protection parameters (enabled, max percentage, cooldown).

  • Can call setHelperBypass to enable or disable helper bypass for a contract address.

  • Can call setHelperWhitelistEnforcement to toggle whitelist enforcement for helper-bypass transfers.

SECURITY_ROLE: Operational security and compliance configuration; category management, signer administration, list controls, and trading protections.

  • Can call cancelAction to cancel a previously queued timelocked operation (guardian mechanism, also accessible by GOVERNANCE_ROLE and EMERGENCY_ROLE).

  • Can call setBlacklist to blacklist or unblacklist an address (governance-role accounts cannot be blacklisted).

  • Can call setWhitelistMode to toggle whitelist-only trading mode.

  • Can call setWhitelist to whitelist or unwhitelist an address.

  • Can call setPriceImpactLimitConfig to configure maximum sell price impact.

  • Can call setPriceImpactExempt to exempt an address from price-impact limits.

  • Can call setWalletCooldownConfig to configure global wallet cooldown settings.

  • Can call setWalletCooldownExempt to exempt an address from wallet cooldown.

  • Can call setMevProtectionConfig to configure MEV protection parameters.

  • Can call setMevProtectionExempt to exempt an address from MEV protection.

  • Can call setVelocityLimitConfig to configure transaction velocity limits.

  • Can call setVelocityLimitExempt to exempt an address from velocity limits.

  • Can call setTrustedFactory to mark a PancakeSwap factory as trusted for keeper pair registration.

  • Can call setTrustedRouter to mark a router as trusted for transfer-tax exclusion.

  • Can call setTrustedKeeper to authorize or deauthorize a trusted keeper address.

EMERGENCY_ROLE: Immediate circuit-breaker pause authority (also available to GOVERNANCE_ROLE via onlyEmergencyOrGov).

  • Can call pause to halt token transfers, optionally including governance accounts when includeOwner is true.

  • Can call cancelAction to cancel a previously queued timelocked operation (guardian mechanism, also accessible by GOVERNANCE_ROLE and SECURITY_ROLE).

Trusted keepers (trustedKeepers mapping, gated by onlyTrustedKeeper): Off-chain monitoring wallets authorized to register new DEX pairs from trusted factories.

  • Can call registerPairFromFactory to register a PancakeSwap pair whose factory is trusted and whose token pair includes NTE.

  • Keeper status is set by SECURITY_ROLE or GOVERNANCE_ROLE through setTrustedKeeper.

Timelock / self-call (onlyTimelock, requires msg.sender address(this)): Sensitive operational changes reachable only after GOVERNANCE_ROLE queues and executes a call to address(this) through the native timelock engine.

  • Can call setAllTaxBasisPoints to update buy, sell, and transfer tax rates.

  • Can call configureAutoLiquidity to configure auto-liquidity routing from tax proceeds.

  • Can call setTreasury to update the tax treasury address.

  • Can call setEmergencyRescueVault to update the emergency rescue vault destination address.

  • Can call emergencyWithdrawToken to recover ERC-20 tokens to emergencyRescueVault.

  • Can call emergencyWithdrawBNB to recover native BNB to emergencyRescueVault (subject to a 30-day post-launch lock).

  • Can call unpause to resume trading after an emergency pause.

  • Can call setDexPairStatus to register or deregister a DEX pair address.

  • Can call setPancakeRouter to update the active PancakeSwap router.

  • Can call setPancakePair to update the primary PancakeSwap pair.

  • Can call setCircuitBreaker to configure circuit-breaker threshold and exemptions.

  • Can call grantRole to grant any role (including GOVERNANCE_ROLE, SECURITY_ROLE, EMERGENCY_ROLE, TREASURY_ROLE) to an account.

  • Can call revokeRole to revoke a role from an account.

  • Can call renounceOwnership to set _owner to the zero address.

  • Can call transferOwnership to transfer the stored _owner address (ownership does not gate any function directly; access control is role-based).

emergencyRescueVault: Mutable rescue destination set at deployment to initialOwner; not a caller role, but the sole permitted recipient enforced during emergency withdrawals.

  • Withdrawals through emergencyWithdrawToken and emergencyWithdrawBNB revert unless to equals emergencyRescueVault.

NTECategoryManagersol

GOVERNANCE_ROLE (queried dynamically from the NTE contract): Full administrative authority over the category manager, including emergency recovery operations.

  • Can call emergencyWithdrawToken to recover stuck ERC-20 tokens from the contract to NTE's emergency rescue vault.

  • Can call emergencyWithdrawBNB to recover native BNB from the contract to NTE's emergency rescue vault (subject to 30-day post-launch lock derived from NTE's launchTime).

  • Can access all onlyRoleOrGov(SECURITY_ROLE) functions as a fallback (see SECURITY_ROLE below).

SECURITY_ROLE (or GOVERNANCE_ROLE as fallback, queried dynamically from the NTE contract): Controls category management and signer authorization without timelock delay.

  • Can call setCategoryEnabled to enable or disable a transaction category for new categorized transfers.

  • Can call updateCategoryName to rename an existing transaction category.

  • Can call addCategory to create a new transaction category (auto-incremented ID, max 255 categories).

  • Can call addAuthSigner to authorize a new off-chain signer address for categorized transfer signature verification.

  • Can call removeAuthSigner to revoke authorization from an off-chain signer, immediately invalidating all future signatures from that address.

Authorized Signers (isAuthSigner mapping): Off-chain backend service addresses that produce ECDSA signatures authorizing categorized token transfers.

  • Their valid signatures are required for any user to execute a categorized transfer via any of the 50 semantic entry points.

  • Signatures encode: contract address, from, to, amount, category, reference ID, nonce, deadline, and chain ID.

  • Signature revocation is immediate upon removeAuthSigner — previously signed but unexecuted transactions become invalid.

Potential Risks

Partial Repository Scope vs. Deployed Ecosystem: The audit scope is limited to NTE.sol, while the repository also contains NTECategoryHelper.sol, NTELiquidityManager.sol, NTEMigrationHelper.sol, and NTEStaking.sol. NTE.sol does not import these files and binds to them only through runtime addresses configured via configureAutoLiquidity, setHelperBypass. Security properties of tax routing, helper self-transfers, and categorized payment flows therefore depend on out-of-scope contract behavior that is not verified within the scoped file.

Liquidity Management Logic Externalized: Auto-liquidity in NTE.sol is limited to splitting collected tax between treasury and liquidityCollector inside _transferWithTax. The configured liquidityCollector must be a separate contract address, and _configureAutoLiquidity requires that address to pass _isContract. Swap-and-LP execution, balance management, and operational logic for that collector live outside the scoped source and are only reachable when SECURITY_ROLE or GOVERNANCE_ROLE grants helperBypass to the collector via setHelperBypass.

PancakeSwap Router, Factory, and Pair Dependency: NTE.sol integrates with PancakeSwap through IPancakeRouter, IPancakeFactory, and IPancakePair. Deployment may call _initializeDexPair to query factory(), WETH(), and getPair() or createPair(). Ongoing transfers use isPancakePair for buy/sell tax classification, _calculatePriceImpact reads getReserves() and token0()/token1(), and registerPairFromFactory validates factory() on candidate pairs. setPancakeRouter, setPancakePair, and setDexPairStatus (timelocked) can repoint these integrations after deployment.

ERC20 Token Contract Dependency: Beyond native NTE balances, NTE.sol depends on external ERC20 behavior for rescue and configuration checks. _emergencyWithdrawToken uses IERC20(token).balanceOf(address(this)) and a low-level token.call with IERC20.transfer.selector to support non-standard return values. _configureAutoLiquidity refuses collector migration when balanceOf(oldCollector) > 0, so correctness of collector switching depends on external token balance reporting.

Trusted Keeper and Factory Registry Dependency: DEX pair expansion relies on off-chain or bot callers holding trustedKeepers status. registerPairFromFactory reads IPancakePair(pair).factory(), token0(), and token1(), and requires the factory to appear in trustedFactory before setting isPancakePair[pair] = true. Pair tax treatment for new pools therefore depends on keeper liveness and on SECURITY_ROLE or GOVERNANCE_ROLE maintaining setTrustedFactory and setTrustedKeeper mappings.

Asymmetric Pause and Unpause Paths: pause(bool includeOwner) is callable by EMERGENCY_ROLE or GOVERNANCE_ROLE and sets _paused immediately, optionally blocking governance senders when pauseIncludesOwner is true. Resuming transfers requires a timelocked call to unpause() through executeAction(address(this), ...) because unpause carries the onlyTimelock modifier. Trading can remain halted until governance completes the full queue-and-execute cycle.

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.

Ownership Transfer and Renouncement Auto-Manage All Roles: The timelocked transferOwnership function automatically grants all four roles to the new owner and revokes them from the old owner. Similarly, renounceOwnership revokes all four roles from the old owner. This couples ownership with role authority — a single timelocked ownership transfer redistributes the entire role hierarchy.

Queued Actions With Fixed Delay and Grace Expiry: The native timelock in NTE.sol enforces TIMELOCK_DELAY of 48 hours and TIMELOCK_GRACE_PERIOD of 7 days. queueAction records an ETA in timelockQueue, and executeAction reverts with TIMELOCK_NOT_READY before the ETA or TIMELOCK_EXPIRED after eta + TIMELOCK_GRACE_PERIOD. If execution is missed inside that window, the action must be re-queued before setTreasury, unpause, grantRole, or other timelocked interfaces can run.

Governance Must Self-Call Through executeAction: Timelocked interfaces such as setAllTaxBasisPoints, emergencyWithdrawToken, and grantRole require msg.sender address(this) via onlyTimelock. Operational changes depend on GOVERNANCE_ROLE correctly encoding calldata and successfully completing executeAction(address(this), data) without TIMELOCK_CALL_FAILED. A failed inner call aborts the queued action after the waiting period.

Additional Time Locks on Tax and BNB Rescue: Even after timelock execution, _setAllTaxBasisPoints enforces TAX_CHANGE_COOLDOWN of 24 hours between tax updates and caps per-update deltas at MAX_TAX_CHANGE_DELTA (250 basis points, 2.5% per tax type). _emergencyWithdrawBNB additionally requires block.timestamp > launchTime + OWNERSHIP_LOCK_PERIOD (30 days). Native rescue remains unavailable through emergencyWithdrawBNB until both the governance timelock cycle and the post-launch waiting period are satisfied.

No Timelock on Category Manager Administrative Operations: All category and signer management functions in NTECategoryManager (addAuthSigner, removeAuthSigner, setCategoryEnabled, addCategory, updateCategoryName) execute immediately without timelock delay. A compromised SECURITY_ROLE could disable all categories (halting categorized transfers), add a malicious signer, or remove legitimate signers in a single transaction.

Contract Can Accumulate Native and ERC20 Balances: NTE.sol exposes receive() to accept native BNB and can hold NTE or other ERC20 tokens sent directly to the contract address. _emergencyWithdrawToken reads IERC20(token).balanceOf(address(this)) before transfer. Tax collection in _transferWithTax also moves tokens from users into treasury and optionally liquidityCollector during normal operation.

Emergency Withdrawal to Mutable Vault Address: The emergencyWithdrawToken and emergencyWithdrawBNB functions (executed via the timelock) can withdraw any ERC-20 token (including NTE itself) and native BNB held by the contract. Withdrawals are restricted to the emergencyRescueVault address, which is set to initialOwner during construction and can be updated via the timelocked setEmergencyRescueVault function. While the timelock delay provides advance notice of vault changes, the mutability means the rescue destination can be redirected if governance is compromised.

Tax Routing Creates Ongoing Third-Party Custody Flows: When autoLiquidityEnabled is true, _transferWithTax computes liquidityAmount from autoLiquidityBps and transfers it to liquidityCollector while sending the remainder to treasury. The timelocked configureAutoLiquidity function can change the collector address and percentage. Tax proceeds therefore accumulate on externally configured addresses whose handling is outside the scoped NTE.sol transfer logic.

Buy, Sell, and Transfer Tax Classification on DEX Activity: _calculateTax classifies flows using isPancakePair and trustedRouters, applying buyTaxBps, sellTaxBps, or transferTaxBps. Timelocked setAllTaxBasisPoints can change rates subject to MAX_TAX_LIMIT, MAX_TOTAL_TAX_LIMIT, delta caps, and TAX_CHANGE_COOLDOWN. Misregistered or newly registered pairs via setDexPairStatus or registerPairFromFactory change which transfers are taxed as buys or sells.

Multi-Layer Transfer Restrictions in _transferWithTax: Standard transfers pass through launch anti-bot checks (antiBotEnabled / antiBotDuration), blacklist and whitelist enforcement, velocity limits, MEV protection (block spacing, minimum hold before sell, contract-to-pair sell blocking), wallet cooldowns, price-impact caps via _calculatePriceImpact, and anti-dump percentage and sellCooldown limits. Each layer is toggled or tuned through SECURITY_ROLE or GOVERNANCE_ROLE configuration functions and can cause SYS_DISABLED, MEV_VELOCITY, PRICE_TOO_HIGH, DUMP_EXCEEDS, or related reverts.

Automatic Circuit Breaker Can Halt All Transfers: When circuitBreakerThresholdBps > 0 and neither party is circuitBreakerExempt, a transfer exceeding (_totalSupply * circuitBreakerThresholdBps) / BASIS_POINTS sets _paused = true, emits CircuitBreakerTripped, and reverts with SYS_DISABLED. The threshold and exemptions are adjustable through timelocked setCircuitBreaker. A single large transfer can therefore trigger a protocol-wide pause until timelocked unpause is executed.

Helper Bypass Path Skips Most Trading Protections: When helperBypass[msg.sender] is true and from msg.sender, _transferWithTax skips anti-bot, velocity, MEV, cooldown, price-impact, anti-dump, and tax logic, retaining only pause, blacklist, and optional whitelist checks controlled by enforceWhitelistOnHelper. setHelperBypass grants this reduced-friction path to designated helper contracts such as the configured liquidityCollector.

Trusted Keeper Dependency for Automated Pair Registration: registerPairFromFactory is restricted to trustedKeepers and is documented for off-chain watchers reacting to factory PairCreated events. The function performs on-chain validation of factory trust and NTE inclusion but does not itself monitor factories. Until a trusted keeper submits registration, new pairs created on a trustedFactory may not be present in isPancakePair, causing those flows to be taxed as ordinary wallet transfers rather than DEX buys or sells.

Centralized Aignature Authority For Categorized Transfers: The NTECategoryManager contract relies on off-chain authorized signers to produce ECDSA signatures that gate all categorized token transfers. The SECURITY_ROLE (or GOVERNANCE_ROLE as fallback) can add or remove signers without timelock delay via addAuthSigner and removeAuthSigner. A compromised authorized signer key could produce valid signatures for arbitrary categorized transfers from any user who has granted token approval to the category manager, up to their approved allowance. Since the contract calls nte.transferFrom(from, to, amount), the signer effectively controls where approved tokens move — the only protection is the user's ERC-20 allowance to the category manager contract.

Delegated Role Authority Without Independent Access Control: NTECategoryManager does not maintain its own role registry — it queries the NTE contract's hasRole function on every permissioned call. If the NTE contract's role assignments are modified (e.g., via timelocked grantRole/revokeRole), the category manager's permissions change implicitly and immediately without any event or notification from the category manager itself. Additionally, if the NTE contract is compromised or its hasRole function returns unexpected values, the category manager's entire access control is compromised by extension.

Findings

F-2026-1785Redundant Ownable Pattern with Unsafe Role Handover Creates Misleading Access Control
Status
fixed
Severity

Medium
F-2026-1780Unrestricted Timelock Execution Enables Multiple Attack Vectors and Bypasses Emergency Rescue Vault Protection
Status
fixed
Severity

Medium
F-2026-1785Residual Balance on Liquidity Collector Permanently Blocks Collector Rotation
Status
fixed
Severity

Low
F-2026-1785Tax-Agnostic _calculatePriceImpact Underestimates Impact for Exempt Sellers
Status
fixed
Severity

Low
F-2026-1781Immutable Emergency Rescue Vault Cannot Be Updated After Deployment Leading to Potential Fund Lock
Status
fixed
Severity

Low
F-2026-1780Role Concentration at Deployment Negates Intended Separation of Privileges
Status
fixed
Severity

Low
F-2026-1785TREASURY_ROLE Defined But Never Used in Access Control
Status
fixed
Severity

Observation
F-2026-1785Removal of Staking Integration Breaks External Staking Contracts and Unlocks All Previously Locked Tokens
Status
mitigated
Severity

Observation
F-2026-1785Circuit Breaker State Assignment Has No Effect
Status
fixed
Severity

Observation
F-2026-1784Outdated NatSpec Comments Reference Removed Owner-Based Access Control and Non-Existent Staking Logic
Status
fixed
Severity

Observation
Code
―
Title
Status
Severity
F-2026-1785Redundant Ownable Pattern with Unsafe Role Handover Creates Misleading Access Control
fixed

Medium
F-2026-1780Unrestricted Timelock Execution Enables Multiple Attack Vectors and Bypasses Emergency Rescue Vault Protection
fixed

Medium
F-2026-1785Residual Balance on Liquidity Collector Permanently Blocks Collector Rotation
fixed

Low
F-2026-1785Tax-Agnostic _calculatePriceImpact Underestimates Impact for Exempt Sellers
fixed

Low
F-2026-1781Immutable Emergency Rescue Vault Cannot Be Updated After Deployment Leading to Potential Fund Lock
fixed

Low
F-2026-1780Role Concentration at Deployment Negates Intended Separation of Privileges
fixed

Low
F-2026-1785TREASURY_ROLE Defined But Never Used in Access Control
fixed

Observation
F-2026-1785Removal of Staking Integration Breaks External Staking Contracts and Unlocks All Previously Locked Tokens
mitigated

Observation
F-2026-1785Circuit Breaker State Assignment Has No Effect
fixed

Observation
F-2026-1784Outdated NatSpec Comments Reference Removed Owner-Based Access Control and Non-Existent Staking Logic
fixed

Observation
1-10 of 11 findings

Identify vulnerabilities in your smart contracts.

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

Repositoryhttps://github.com/nodemeta/nte→
Commitd72f56362d58546dfe5bdbe2b192947ca7e5d1dc
Remediation commit1317487659fbeaea859d36becbeee71e1336b957
WhitepaperN/A
RequirementsREADME.md; NatSpec
Technical RequirementsREADME.md; NatSpec

  • Scope Details

    Repository
    https://github.com/nodemeta/nte→
    Commit
    d72f56362d58546dfe5bdbe2b192947ca7e5d1dc
    Remediation commit
    1317487659fbeaea859d36becbeee71e1336b957
    Whitepaper
    N/A
    Requirements
    README.md; NatSpec
    Technical Requirements
    README.md; NatSpec

Assets in Scope

NTECategoryManager.sol - NTECategoryManager.sol

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.

Disclaimer