Q1 2026 Security & Compliance Report44 incidents, $482M in losses, insights from 11 industry leaders.
Read the report

Audit name:

[SCA] NEBA Token | NEBA-Token | Oct2025

Date:

Oct 17, 2025

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 NEBA Token team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.

NEBA Token is a secure, upgradeable ERC-20 token implementation designed to combine regulatory readiness with strong operational controls. It integrates role-based access management, pausable transfers, and UUPS upgradeability, ensuring a controlled token environment with built-in mechanisms for emergency halts and governance-driven upgrades.

Document

NameSmart Contract Code Review and Security Analysis Report for NEBA Token
Audited By, Seher Saylik
Approved By
Websitehttps://nebatoken.com
Changelog10/10/2025 - Preliminary Report
17/10/2025 - Final Report
PlatformEVM
LanguageSolidity
TagsFungible Token, ERC20
Methodologyhttps://hackenio.cc/sc_methodology
  • Document

    Name
    Smart Contract Code Review and Security Analysis Report for NEBA Token
    Audited By
    , Seher Saylik
    Approved By
    Changelog
    10/10/2025 - Preliminary Report
    17/10/2025 - Final Report
    Platform
    EVM
    Language
    Solidity
    Tags
    Fungible Token, ERC20

Review Scope

Repositoryhttps://github.com/JayP11/NEBA-Token
Commit27107b87fae8617d61d387b90421d90aab0efb4e
Retest1f432d15fa540ce0b56bd64d50ef14af128ddf30

Audit Summary

5Total Findings
5Resolved
0Accepted
0Mitigated

The system users should acknowledge all the risks summed up in the risks section of the report

{Finding_Table?columns=title,severity,status&setting.filter.type=Vulnerability}

Documentation quality

  • Functional requirements are evident from the spec: fixed 1B supply at init, role-gated pausing/unpausing, and UUPS-based upgrading.

  • The in-code comments provide a sufficient technical overview of access control, pause flow, and upgrade authorization.

Code quality

  • Implements Solidity best practices with OpenZeppelin upgradeable libraries (ERC20, Pausable, AccessControl, UUPS), custom errors, and explicit events.

  • Upgradeable deployment is correctly structured (initializer pattern, disabled constructor, storage gap, proxy-safe overrides), indicating a properly configured development approach.

Test coverage

Code coverage of the project is 100% (branch coverage).

  • All core functionalities such as deployment, pausing, unpausing, role-based access control, upgrades, and transfers are thoroughly tested.

  • The development team included integration, unit, fuzz, and invariant tests, validating both normal and edge-case behaviours across multiple roles.

  • Invariant tests confirm total supply consistency and prevent balance overflows, while fuzz tests simulate randomized user interactions under varying conditions.

System Overview

NEBAToken is an upgradeable ERC-20 compliant token designed with enhanced administrative control and safety mechanisms. It features a fixed total supply of 1 billion tokens minted at initialization and allocated to the designated treasury address. The contract implements role-based access control to separate key responsibilities, allowing specific roles to handle pausing, and upgrading while keeping minting closed post-deployment.

It has the following attributes:

  • Name: NEBA Token

  • Symbol: NEBA

  • Decimals: 18

  • Total Supply: 1,000,000,000 tokens

Privileged roles

  • The DEFAULT_ADMIN_ROLE of the NEBAToken contract holds full administrative privileges, including the ability to grant and revoke any other role within the system. This role effectively governs the token’s access control and overall management.

  • The ADMIN_PAUSER_ROLE can pause and unpause the contract, enabling or restoring token transfers during emergency or maintenance situations.

  • The BOT_PAUSER_ROLE is limited to pausing the contract and is intended for automated systems or bots to halt token activity in response to predefined triggers or abnormal behavior.

  • The UPGRADER_ROLE is authorized to upgrade the contract’s implementation through the UUPS proxy mechanism, granting the ability to deploy new logic versions while retaining the existing contract state.

Potential Risks

Centralized Role Control: DEFAULT_ADMIN_ROLE, ADMIN_PAUSER_ROLE, and UPGRADER_ROLE concentrate authority in core functionalities. Compromise or misuse can pause transfers, reassign roles, or change logic.

Flexibility and Risk in Contract Upgrades: The UUPS pattern allows logic upgrades at any time by the UPGRADER_ROLE, creating trust and governance risk if the upgrader is compromised or deploys faulty code.

Absence of Upgrade Window Constraints: No on-chain timelock or mandatory delay precedes upgrades, increasing the chance of rapid deployment of unvetted implementations.

Insufficient On-Chain Multi-Signature Controls: The contract does not enforce multi-signature for privileged actions. The team states a multi-signature wallet will be used operationally, which should materially reduce this risk once implemented.

Fixed Supply Central Allocation: The entire 1,000,000,000 NEBA supply is minted to the admin treasury at initialization, creating a single point of control over initial distribution.

Out-of-Scope Components: Off-chain deployment scripts, governance processes, and any future upgrade implementations are not covered by this audit and may introduce additional risk if misconfigured or unaudited.

Findings

Code
Title
Status
Severity
F-2025-1341Pausing Disables Allowance Revocation Leaving Users Exposed During Emergencies
fixed

Medium
F-2025-1341Inaccurate NatSpec on initialize() Function
fixed

Low
F-2025-1340Initializer Could Be Front-run
fixed

Low
F-2025-1341Reentrancy Guard Included but Never Used Creates False Sense of Protection
fixed

Observation
F-2025-1340Floating Pragma
fixed

Observation
1-5 of 5 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/JayP11/NEBA-Token
Commit27107b87fae8617d61d387b90421d90aab0efb4e
Retest1f432d15fa540ce0b56bd64d50ef14af128ddf30
WhitepaperN/A
Requirementsdocs, README.md
Technical Requirementsdocs, README.md, NEBAToken.md
  • Scope Details

    Commit
    27107b87fae8617d61d387b90421d90aab0efb4e
    Retest
    1f432d15fa540ce0b56bd64d50ef14af128ddf30
    Whitepaper
    N/A
    Requirements
    docs, README.md
    Technical Requirements
    docs, README.md, NEBAToken.md

Assets in Scope

contracts
NEBAToken.sol - contracts › NEBAToken.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.

Additional Considerations

This security assessment was conducted in accordance with the NIST SP 800-115 – Technical Guide to Information Security Testing and Assessment . This guideline provides a structured foundation for planning, executing, and documenting technical evaluations such as testing, vulnerability assessments, and code reviews. Hacken’s internal methodology and security assessment framework extend these principles to blockchain environments to ensure consistency, repeatability, and verifiable outcomes.

Disclaimer