Audit name:
[SCA] Dubadu | ForeversToken | Sep2026
Date:
Sep 10, 2026
Table of Content
Introduction
We express our gratitude to the Dubadu team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
FOREVERS is a non-upgradeable ERC-20 token on Ethereum. Holders transfer FRVRS under a fixed 0.1% levy on EOA-to-EOA movements, further issuance is gated to a designated minter under a 150 billion token cap, and approvals can be granted through EIP-2612 permit. The audit covered ForeversToken and the shared ForeversConstants library.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Dubadu |
| Audited By | Kerem Solmaz |
| Approved By | Olesia Bilenka |
| Website | forevers.market |
| Changelog | 09/09/2026 - Preliminary Report |
| 10/09/2026 - Final Report | |
| Platform | Ethereum |
| Language | Solidity |
| Tags | Fungible Token, Permit Token, Token Standards, Centralization, Signatures |
| Methodology | https://docs.hacken.io/methodologies/smart-contracts→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Dubadu
- Audited By
- Kerem Solmaz
- Approved By
- Olesia Bilenka
- Website
- forevers.market
- Changelog
- 09/09/2026 - Preliminary Report
- 10/09/2026 - Final Report
- Platform
- Ethereum
- Language
- Solidity
- Tags
- Fungible Token, Permit Token, Token Standards, Centralization, Signatures
Review Scope | |
|---|---|
| Repository | https://gitlab.com/dubadu-portal-llc-group/contracts/-/tree/main→ |
| Commit | 1be3f52 |
Review Scope
- Commit
- 1be3f52
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
The repository README is an unmodified GitLab template and does not describe the protocol, deployment model, or token economics.
In-scope files carry NatSpec on the public surface, including the fixed transfer levy, minter locks, and fee-authority locks. Several constants in ForeversConstants document rules that belong to out-of-scope modules and are not enforced by ForeversToken.
Code quality
The implementation uses Solidity 0.8.28 with OpenZeppelin ERC-20, ERC-20Capped, and ERC-20Permit.
Access checks are inline rather than modifiers, inheritance is limited to the token stack plus the project interface, and the token is not proxied. Several business logic issues related to missing edge cases were identified and reported.
Test coverage
Line coverage of ForeversToken stands at 100% (83 of 83 lines; 95 of 95 statements; 25 of 25 branches) as measured by the Foundry coverage tool against the 52-test token suite.
ForeversConstants contains compile-time constants only and has no executable lines to cover. The provided repository omits Foundry configuration and vendor libraries, so this figure was obtained by reconstituting that toolchain with OpenZeppelin v5.2.0. Separate fuzz and invariant files exist for the fee path.
System Overview
FOREVERS is a capped ERC-20 named Forevers with symbol FRVRS and 18 decimals. Construction mints 1.5 billion tokens to a non-zero open-market address and records a non-zero fee treasury. The remaining supply up to 150 billion tokens can be created only by the stored minter. The token is not proxied and exposes no pause, blacklist, or burn interface.
ForeversToken inherits OpenZeppelin ERC-20, ERC-20Capped, and ERC-20Permit. The immutable deployer may assign and freeze the minter and the fee authority while those pointers are unlocked. The first successful mint also freezes the minter pointer. Only the minter may mint under the cap or permanently revoke minting. Only the fee authority may rotate the fee treasury. Standard transfers, transfer-from, approve, and permit remain public.
A ten basis point levy is applied inside the balance-update hook when both counterparties have empty code, the movement is not a mint or burn, and the recipient is not the fee treasury. The levy is credited to the treasury and the remainder to the recipient through inner updates that do not re-enter the hook. Transfers that involve a contract, the treasury as recipient, or mint and burn move the full amount.
Out of scope but interacting after wiring: Emission is the intended minter, EmissionMultisig is the intended fee authority, and FreezeLock pulls FRVRS through ordinary ERC-20 transfers. ForeversConstants supplies the hard cap, initial mint, and basis-point denominator used by the token, plus lock duration, signer layout, and emission stage bounds used by those other contracts.
Privileged Roles
Deployer: Assigned immutably to the constructor caller. While the matching lock is unset, this role can assign the minter and the fee authority and can freeze those pointers after a non-zero address is stored. After both locks, the deployer has no remaining writers on this contract. Compromise before lock allows retargeting of mint authority and fee-treasury control. The token does not wrap this key in a timelock or on-chain quorum.
Minter: A single stored address. This role can mint any amount up to the remaining cap and can permanently revoke further minting. The token does not enforce emission stages. Compromise after lock allows minting of the unused cap or an early revoke that ends issuance.
Fee authority: A single stored address,This role can rotate the fee treasury to any non-zero address with immediate effect. Prior treasury balances are not moved. The token does not enforce a signer count or delay on that rotation.
Potential Risks
Scope Definition and Security Guarantees: The audit covers ForeversToken and ForeversConstants only. The repository also contains Emission, EmissionMultisig, and FreezeLock. Those contracts are the intended minter, fee authority, and lockbox after wiring. Defects in their authorization can still drive minting, minter revocation, and fee-treasury rotation on the in-scope token.
System Reliance on External Contracts: After the deployer assigns the minter and fee authority, remaining issuance and levy routing on ForeversToken are driven by those stored addresses. The intended minter is Emission and the intended fee authority is EmissionMultisig, both outside this review. A defect or key compromise in those contracts can mint up to the unused cap, permanently end issuance, or redirect future transfer levies.
Centralized Minting to a Single Address: Post-deploy issuance on ForeversToken is gated to one minter address. The constructor mints 1.5 billion tokens to the open-market recipient. The remainder up to 150 billion tokens is mintable by that minter with no on-chain schedule or quorum inside the token.
Absence of a Token Burn Mechanism: ForeversToken has no burn path. The transfer levy moves tokens to the fee treasury and does not destroy them. Supply can stay flat or increase up to the cap.
Owner's Unrestricted State Modification: While the matching lock is unset, the deployer of ForeversToken may assign the minter and the fee authority to any non-zero address. There is no allowlist, bytecode check, or interface check. A mistaken or malicious assignment before lock can grant minting of the unused cap or control of levy routing to an unintended address.
Coarse-grained Authorization Model Risks: Each privileged role on ForeversToken is a single address with full power over its surface. The minter can both mint any amount up to the remaining cap and permanently revoke minting. The fee authority can rotate the treasury to any non-zero address with immediate effect. Compromise of either address is sufficient for the full matching action set.
Absence of Time-lock Mechanisms for Critical Operations: Minter assignment, minter lock, fee-authority assignment, fee-authority lock, treasury rotation, mint, and minter revoke complete in the calling transaction. Holders have no on-chain delay in which to observe a pointer change or a large mint.
Insufficient Multi-signature Controls for Critical Functions: Every privileged check on ForeversToken compares the caller to one stored address. The token does not require a quorum. A 2-of-3 layout exists only as unused constants in ForeversConstants and as the intended out-of-scope EmissionMultisig after wiring.
Single Points of Failure and Control: Until locks, the deployer can replace the minter and the fee authority. After wiring, the minter alone can mint the remaining cap or end issuance, and the fee authority alone can redirect future levies. Key custody cannot be verified from the token bytecode.
Administrative Key Control Risks: The deployer is the constructor caller, typically a single key. While unlocked, that key can point mint and fee-authority slots at any non-zero address. After intended wiring those slots may hold out-of-scope contracts, but the token stores addresses only and does not require a multisig implementation.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2026-1927 | Empty-Code Check Exempts Delegated Accounts From The Transfer Fee | accepted | Medium | |
| F-2026-1929 | Missing Self-Address Check In Fee Treasury Results In Unrecoverable Fees | accepted | Low | |
| F-2026-1929 | Missing Sender Check Against Fee Treasury In _update | accepted | Observation | |
| F-2026-1927 | Missing Revocation Check In Minter Assignment Emits A Minter Address That Can Never Mint | accepted | Observation | |
| F-2026-1927 | Unreferenced Constants And Duplicated Declarations Leave Documented Rules Unenforced | accepted | 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://gitlab.com/dubadu-portal-llc-group/contracts/-/tree/main→ |
| Commit | 1be3f5232f4054adaf02b847150496fc3bbbd90a |
| Whitepaper | forevers.market/whitepaper |
| Requirements | NatSpec |
| Technical Requirements | NatSpec |
Scope Details
- Commit
- 1be3f5232f4054adaf02b847150496fc3bbbd90a
- Whitepaper
- forevers.market/whitepaper
- Requirements
- NatSpec
- Technical Requirements
- NatSpec
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.