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

Alberichtoken

Audit name:

[SCA] Alberich Token | Token | Nov2025

Date:

Jun 8, 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 Alberichtoken team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.

AlberichToken is an ERC-20 token with extended functionality for token sales, vesting, snapshots, pausability, and reentrancy protection.

Document

NameSmart Contract Code Review and Security Analysis Report for Alberichtoken
Audited By, Khrystyna Tkachuk
Approved ByIvan Bondar
WebsiteN/A
Changelog13/11/2025 - Preliminary Report
26/11/2025 - Final Report
04/06/2026 - Additional Review Preliminary Report
08/06/2026 - Additional Review Final Report
PlatformEVM
LanguageSolidity
TagsERC-20, Vesting, Token Sales
Methodologyhttps://docs.hacken.io/methodologies/smart-contracts→

  • Document

    Name
    Smart Contract Code Review and Security Analysis Report for Alberichtoken
    Audited By
    , Khrystyna Tkachuk
    Approved By
    Ivan Bondar
    Website
    N/A
    Changelog
    13/11/2025 - Preliminary Report
    26/11/2025 - Final Report
    04/06/2026 - Additional Review Preliminary Report
    08/06/2026 - Additional Review Final Report
    Platform
    EVM
    Language
    Solidity
    Tags
    ERC-20, Vesting, Token Sales
    Methodology
    https://docs.hacken.io/methodologies/smart-contracts→

Review Scope

File NameAlberich-TokenInternalTestResultsFinal_2025-10-29.zip
File Hash (SHA256)98c4c5fb3d0477249ca8ba4fcffa275c17a9f565d175ec5b76e8c2127d792c3f
Final File NameUPDATEDAlberichTokenAuditReadySmartContractWithFixes_2025-11-14.sol
Final File Hash (SHA256)a26e0a4d05b91f5fa2bee218f024c61df4f3b6189df1976157898cf674b75bb4
Additional Review File NameUPDATEDAlberichTokenAuditReadyContractWithAllocationFix_2026-05-27.sol
Additional Review File Hash (SHA256)d395b4d0f052e1ae299021cd44ae7f4a5d12ee6d7c43e635116c53bb46ea921a
Additional Review Final File NameUPDATEDAlberichTokenAuditReadyContractRemediation_2026-06-04.sol
Additional Review FInal File Hash (SHA256)d935eec51449f8890722adcba7f2438b91ee1b2fceed2459c437acdc7b9427d7

  • Review Scope

    File Name
    Alberich-TokenInternalTestResultsFinal_2025-10-29.zip
    File Hash (SHA256)
    98c4c5fb3d0477249ca8ba4fcffa275c17a9f565d175ec5b76e8c2127d792c3f
    Final File Name
    UPDATEDAlberichTokenAuditReadySmartContractWithFixes_2025-11-14.sol
    Final File Hash (SHA256)
    a26e0a4d05b91f5fa2bee218f024c61df4f3b6189df1976157898cf674b75bb4
    Additional Review File Name
    UPDATEDAlberichTokenAuditReadyContractWithAllocationFix_2026-05-27.sol
    Additional Review File Hash (SHA256)
    d395b4d0f052e1ae299021cd44ae7f4a5d12ee6d7c43e635116c53bb46ea921a
    Additional Review Final File Name
    UPDATEDAlberichTokenAuditReadyContractRemediation_2026-06-04.sol
    Additional Review FInal File Hash (SHA256)
    d935eec51449f8890722adcba7f2438b91ee1b2fceed2459c437acdc7b9427d7

Audit Summary

15Total Findings
12Resolved
2Accepted
1Mitigated

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

Documentation quality

  • Functional requirements are provided.

  • Technical description is provided.

    • Run instructions are provided.

    • Technical specification is provided.

  • Inline comments exist partially throughout the codebase.

Code quality

  • The code leverages OpenZeppelin and mostly follows best practices and style guides.

    • See informational findings for more details.

  • The development environment is configured.

Test coverage

Code coverage of the project is 0% since no tests were provided.

System Overview

AlberichToken — An ERC-20 token with extended functionality for token sales, vesting, snapshots, pausability, and reentrancy protection. All tokens are minted to the contract itself at deployment, and distributed through controlled mechanisms (purchases, vesting, treasury). No additional minting is possible after deployment.

It has the following attributes:

  • Name: Alberich Token

  • Symbol: ALBRH

  • Decimals: 18

  • Total Supply: 87,600,000,000 tokens (87.6 billion ALBRH)

  • Initial Distribution: 100% minted to contract address at deployment

Privileged roles

The foundation (must also hold FOUNDATION_ROLE): Controls all administrative, treasury, vesting, and lifecycle operations.

  • Can call setTokenPriceWeiPerToken to set the token sale price in wei per token (blocked after parameter freeze).

  • Can call setRoundType to switch between SHO and Public sale rounds (permitted even after parameter freeze).

  • Can call setPurchaseLimits to configure per-wallet purchase caps for SHO and Public rounds (blocked after parameter freeze).

  • Can call setMinTokensPerPurchase to set or disable the minimum token purchase threshold (blocked after parameter freeze).

  • Can call setWhitelist to add or remove addresses from the SHO whitelist in batches (blocked after parameter freeze).

  • Can call setSaleActive to activate or deactivate the token sale.

  • Can call freezeParameters to permanently and irreversibly lock sale parameters (price, limits, whitelist, minimum purchase).

  • Can call pause to pause all token transfers, purchases, and vesting claims.

  • Can call unpause to resume all token transfers, purchases, and vesting claims.

  • Can call withdrawETH to withdraw any amount of ETH from the contract to a specified address.

  • Can call rescueERC20 to transfer any ERC-20 token (excluding ALBRH itself) held by the contract to a specified address.

  • Can call ringForgedBurn to permanently burn unlocked (non-vesting-reserved) ALBRH tokens held by the contract.

  • Can call setStakingContract to set or update the staking contract address.

  • Can call toggleStakingBonusRequirement to enable or disable the staking bonus requirement flag.

  • Can call setVesting to create a linear vesting schedule for any beneficiary, reserving tokens from the contract balance.

  • Can call initiateFoundationTransfer to nominate a new foundation address, initiating a two-step governance handoff.

  • Can call snapshot to create a new ERC-20 balance snapshot.

  • Can call transferAllocation to transfer unlocked (non-vesting-reserved) ALBRH tokens from the contract to any address.

The holder of the DEFAULT_ADMIN_ROLE can:

  • Grant or revoke any role, including FOUNDATION_ROLE and DEFAULT_ADMIN_ROLE

  • Acts as a super-administrator over the entire role hierarchy

The pendingFoundation: Address nominated via initiateFoundationTransfer to receive governance control.

  • Can call acceptFoundationRole to complete the two-step handoff, becoming the new foundation address, receiving FOUNDATION_ROLE, and revoking FOUNDATION_ROLE from the previous foundation.

Potential Risks

System Reliance on External Contracts: The functioning of the system significantly relies on specific external contracts. Any flaws or vulnerabilities in these contracts adversely affect the audited project, potentially leading to security breaches or loss of funds.

  • Applies to: Future staking contract integration (stakingContract address)

Fixed Total Supply Post-Deployment: The token’s total supply is fixed at deployment and cannot be adjusted afterward, which may limit the project’s adaptability and flexibility in managing its economic model.

  • Applies to: 87.6B ALBRH tokens minted at deployment

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.

  • Applies to: All tokens minted to contract address at deployment

Dynamic Array Iteration Gas Limit Risks: The project iterates over large dynamic arrays, which leads to excessive gas costs, risking denial of service due to out-of-gas errors, directly impacting contract usability and reliability.

  • Applies to: setWhitelist() function

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.

  • Applies to: FOUNDATION_ROLE can modify all parameters before freezeParameters()

Coarse-grained Authorization Model Risks: The broad authorization model increases the risk of protocol control loss if any authorized address is compromised, potentially leading to unauthorized actions and significant financial loss.

  • Applies to: Single FOUNDATION_ROLE controls all critical functions

Absence of Time-lock Mechanisms for Critical Operations: Without time-locks on critical operations, there is no buffer to review or revert potentially harmful actions, increasing the risk of rapid exploitation and irreversible changes.

  • Applies to: All admin functions execute immediately (parameter changes, governance handoff, treasury operations)

Incomplete Role Transfer During Foundation Handoff: The acceptFoundationRole function transfers FOUNDATION_ROLE to the new address and revokes it from the previous holder, but does not address DEFAULT_ADMIN_ROLE, which is granted to the deployer in the constructor via _grantRole(DEFAULT_ADMIN_ROLE, msg.sender). Under OpenZeppelin's AccessControl model, the DEFAULT_ADMIN_ROLE holder retains the ability to call grantRole and revokeRole for any role, including FOUNDATION_ROLE. If the original deployer does not explicitly renounce DEFAULT_ADMIN_ROLE after handoff, they retain the capability to revoke FOUNDATION_ROLE from the new foundation or to grant it to an arbitrary address which may brick the execution of functions gated by the onlyFoundation modifier.

Findings

Code
―
Title
Status
Severity
F-2025-1396Single Vesting Limitation Prevents Creation of New Vesting for the Same Address After Completion of Existing One
fixed

Medium
F-2025-1395Insufficient Reserve Validation in Vesting Creation Cause Over-Allocation Risk
fixed

Medium
F-2025-1395Unrestricted Burning of Reserved Tokens May Deplete Vesting Reserves
fixed

Medium
F-2025-1393Freeze Mechanism Blocks Multi-Round Purchase Execution Flow
fixed

Medium
F-2025-1393Unusable Emergency Pause Functionality
fixed

Medium
F-2026-1774Missing Vesting Reservation Floor in _purchase Leads to Permanently Insolvent Vesting Claims
fixed

Medium
F-2025-1396Missing Snapshot Function Can Prevent Core Functionality
fixed

Low
F-2025-1394Immediate Vesting Release Due to Missing Start Time Validation
fixed

Low
F-2026-1774Irreversible Vesting Schedules With Unbounded Duration Can Permanently Lock Reserved Supply
accepted

Low
F-2025-1396Staking Placeholder Functions Are Incomplete and Confusing
accepted

Observation
1-10 of 15 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

File NameAlberich-TokenInternalTestResultsFinal_2025-10-29.zip
File Hash (SHA256)98c4c5fb3d0477249ca8ba4fcffa275c17a9f565d175ec5b76e8c2127d792c3f
Final File NameUPDATEDAlberichTokenAuditReadySmartContractWithFixes_2025-11-14.sol
Final Fila Hash (SHA256)a26e0a4d05b91f5fa2bee218f024c61df4f3b6189df1976157898cf674b75bb4
Additional Review File NameUPDATEDAlberichTokenAuditReadyContractWithAllocationFix_2026-05-27.sol
Additional Review File Hash (SHA256)d395b4d0f052e1ae299021cd44ae7f4a5d12ee6d7c43e635116c53bb46ea921a
Additional Review Final File NameUPDATEDAlberichTokenAuditReadyContractRemediation_2026-06-04.sol
Additional Review Final File Hash (SHA256)d935eec51449f8890722adcba7f2438b91ee1b2fceed2459c437acdc7b9427d7
Whitepaper5. Smart-ContracttoWhitepaperAlignmentReport_v3.0.pdf
Requirements2. AlberichTokenREADMEAuditInstructionsFINAL_2025-10-29 (1)
Technical Requirements4. OverviewAlberichToken (ALBRH)_2025-10-29

  • Scope Details

    File Name
    Alberich-TokenInternalTestResultsFinal_2025-10-29.zip
    File Hash (SHA256)
    98c4c5fb3d0477249ca8ba4fcffa275c17a9f565d175ec5b76e8c2127d792c3f
    Final File Name
    UPDATEDAlberichTokenAuditReadySmartContractWithFixes_2025-11-14.sol
    Final Fila Hash (SHA256)
    a26e0a4d05b91f5fa2bee218f024c61df4f3b6189df1976157898cf674b75bb4
    Additional Review File Name
    UPDATEDAlberichTokenAuditReadyContractWithAllocationFix_2026-05-27.sol
    Additional Review File Hash (SHA256)
    d395b4d0f052e1ae299021cd44ae7f4a5d12ee6d7c43e635116c53bb46ea921a
    Additional Review Final File Name
    UPDATEDAlberichTokenAuditReadyContractRemediation_2026-06-04.sol
    Additional Review Final File Hash (SHA256)
    d935eec51449f8890722adcba7f2438b91ee1b2fceed2459c437acdc7b9427d7
    Whitepaper
    5. Smart-ContracttoWhitepaperAlignmentReport_v3.0.pdf
    Requirements
    2. AlberichTokenREADMEAuditInstructionsFINAL_2025-10-29 (1)
    Technical Requirements
    4. OverviewAlberichToken (ALBRH)_2025-10-29

Assets in Scope

src
2. AlberichToken_AuditReady_SmartContract_FINAL (10-13-2025).sol - src › 2. AlberichToken_AuditReady_SmartContract_FINAL (10-13-2025).sol

Appendix 3. Additional Valuables

Verification of System Invariants

During the audit of Alberich Token, Hacken followed its methodology by performing fuzz-testing on the project's main functions. Foundry,  → a tool used as a testing framework, was employed to check how the protocol behaves under various inputs. Due to the complex and dynamic interactions within the protocol, unexpected edge cases might arise. Therefore, it was important to use fuzz-testing to ensure that several system invariants hold true in all situations.

Invariant

Test Result

testFuzzPurchaseCalculationNoOverflowPassed
testFuzzPurchaseCalculationCorrectnessPassed
testFuzz_PurchaseFloorDivisionPassed
testFuzzSHOCapNeverExceededPassed
testFuzzPublicCapNeverExceededPassed
testFuzzMinPurchaseEnforcedPassed
testFuzzVestingLinearReleasePassed
testFuzzVestingMonotonicPassed
testFuzzVestingReleasedBoundedPassed
testFuzzExtremePriceVeryLowPassed
testFuzzExtremePriceVeryHighPassed
testFuzz_DustAccumulationPassed
testFuzz_PurchaseAtCapBoundaryPassed
testFuzz_VestingBoundariesPassed

  • Invariant

    testFuzzPurchaseCalculationNoOverflow

    Test Result

    Passed

    Invariant

    testFuzzPurchaseCalculationCorrectness

    Test Result

    Passed

    Invariant

    testFuzz_PurchaseFloorDivision

    Test Result

    Passed

    Invariant

    testFuzzSHOCapNeverExceeded

    Test Result

    Passed

    Invariant

    testFuzzPublicCapNeverExceeded

    Test Result

    Passed

    Invariant

    testFuzzMinPurchaseEnforced

    Test Result

    Passed

    Invariant

    testFuzzVestingLinearRelease

    Test Result

    Passed

    Invariant

    testFuzzVestingMonotonic

    Test Result

    Passed

    Invariant

    testFuzzVestingReleasedBounded

    Test Result

    Passed

    Invariant

    testFuzzExtremePriceVeryLow

    Test Result

    Passed

    Invariant

    testFuzzExtremePriceVeryHigh

    Test Result

    Passed

    Invariant

    testFuzz_DustAccumulation

    Test Result

    Passed

    Invariant

    testFuzz_PurchaseAtCapBoundary

    Test Result

    Passed

    Invariant

    testFuzz_VestingBoundaries

    Test Result

    Passed

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