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 | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for NEBA Token |
| Audited By | , Seher Saylik |
| Approved By | |
| Website | https://nebatoken.com→ |
| Changelog | 10/10/2025 - Preliminary Report |
| 17/10/2025 - Final Report | |
| Platform | EVM |
| Language | Solidity |
| Tags | Fungible Token, ERC20 |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for NEBA Token
- Audited By
- , Seher Saylik
- Approved By
- Website
- https://nebatoken.com→
- Changelog
- 10/10/2025 - Preliminary Report
- 17/10/2025 - Final Report
- Platform
- EVM
- Language
- Solidity
- Tags
- Fungible Token, ERC20
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/JayP11/NEBA-Token→ |
| Commit | 27107b87fae8617d61d387b90421d90aab0efb4e |
| Retest | 1f432d15fa540ce0b56bd64d50ef14af128ddf30 |
Review Scope
- Repository
- https://github.com/JayP11/NEBA-Token→
- Commit
- 27107b87fae8617d61d387b90421d90aab0efb4e
- Retest
- 1f432d15fa540ce0b56bd64d50ef14af128ddf30
Audit Summary
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_ROLEof theNEBATokencontract 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_ROLEcan pause and unpause the contract, enabling or restoring token transfers during emergency or maintenance situations.The
BOT_PAUSER_ROLEis 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_ROLEis 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-1341 | Pausing Disables Allowance Revocation Leaving Users Exposed During Emergencies | fixed | Medium | |
| F-2025-1341 | Inaccurate NatSpec on initialize() Function | fixed | Low | |
| F-2025-1340 | Initializer Could Be Front-run | fixed | Low | |
| F-2025-1341 | Reentrancy Guard Included but Never Used Creates False Sense of Protection | fixed | Observation | |
| F-2025-1340 | Floating Pragma | 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/JayP11/NEBA-Token→ |
| Commit | 27107b87fae8617d61d387b90421d90aab0efb4e |
| Retest | 1f432d15fa540ce0b56bd64d50ef14af128ddf30 |
| Whitepaper | N/A |
| Requirements | docs, README.md |
| Technical Requirements | docs, README.md, NEBAToken.md |
Scope Details
- Repository
- https://github.com/JayP11/NEBA-Token→
- Commit
- 27107b87fae8617d61d387b90421d90aab0efb4e
- Retest
- 1f432d15fa540ce0b56bd64d50ef14af128ddf30
- Whitepaper
- N/A
- Requirements
- docs, README.md
- Technical Requirements
- docs, README.md, NEBAToken.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.
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.