Quantum Audit Logo
Launch App

On-chain security analysis — is it a scam or legit?

Is Alberich Token Safe?

ALBRHEthereum
Not verified This record has not gone through deep verification and is not being monitored. The score is a dated snapshot — the token’s risk can change at any time.Own this token? Put it under verification →
Last checked Sep 4, 2026 · 1 audit on record
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical8/10Governance4/10Upgrades7/10Checks passed6 of 7Findings1 High · 1 Medium · 1 Low · 2 Info5
SummaryAI Copilot

The AlberichToken contract implements an ERC20 token with integrated sale, snapshot, and vesting capabilities, leveraging OpenZeppelin's battle-tested libraries for core functionalities.

Read the full analysis
What raised the score
  • Ownership not renounced
  • Top-10 concentration > 30%
  • Token age < 30 days
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced (admin/mint authority retained)
  • Top-10 concentration > 30% (99.5% total → 41.1% effective; 2.3% in EOAs, 97.2% in contracts — moderate)
  • Token age < 30 days (still settling)
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit

Each factor is an on-chain fact recorded at the time of this analysis. The score is computed from them by a deterministic function, so the same contract returns the same score for anyone who runs the audit. How scores are computed

Security Checklist

as of audit · Sep 46 of 7 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
97.2%Contracts2.3%
97.2%Contracts
ContractsWalletsEveryone elseBubble area = share of supply
99.5%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking97.2%
  • Walletsanonymous holders, free to sell2.3%
  • Everyone elsethe rest of the supply0.5%
Effective concentrationwhat the score reads41.1%
How holder types affect the score

Share held by contracts — treasury, vesting, bridge or staking — is discounted against share held by wallets when the score is computed: a contract cannot decide to sell the way an anonymous holder can, though it can still be drained or voted to sell. Effective concentration is the figure the risk score is actually calculated from.

Holder balances as recorded by the audit of Sep 4, 2026

Liquidity

as of audit · Sep 4$292.4K

The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$292.4KShare of depth100.0%
LP Locked100.0% · TeamFinance

Security Findings

1 High1 Medium1 Low2 Info
High

Extensive Centralization of Control

The FOUNDATION_ROLE (and implicitly DEFAULT_ADMIN_ROLE) holds extensive power over critical contract functions, including setting token sale parameters (setTokenPriceWeiPerToken, setPurchaseLimits, setSaleActive), managing the whitelist (setWhitelist), withdrawing all accumulated ETH (withdrawETH), burning tokens (ringForgedBurn), and pausing the contract. This centralizes trust in a single entity or a small group of individuals, introducing a significant single point of failure. A compromise of the foundation's private key or malicious intent could lead to severe consequences, such as draining funds, manipulating token prices, or halting the sale.H-01

Issue

The FOUNDATION_ROLE (and implicitly DEFAULT_ADMIN_ROLE) holds extensive power over critical contract functions, including setting token sale parameters (setTokenPriceWeiPerToken, setPurchaseLimits, setSaleActive), managing the whitelist (setWhitelist), withdrawing all accumulated ETH (withdrawETH), burning tokens (ringForgedBurn), and pausing the contract. This centralizes trust in a single entity or a small group of individuals, introducing a significant single point of failure. A compromise of the foundation's private key or malicious intent could lead to severe consequences, such as draining funds, manipulating token prices, or halting the sale.

Fix

Implement a multi-signature wallet (e.g., Gnosis Safe) for the FOUNDATION_ROLE and DEFAULT_ADMIN_ROLE to distribute control and require multiple approvals for critical operations. This significantly reduces the risk associated with a single point of failure. Clearly define and communicate the responsibilities and operational procedures for these roles.

Status

Unresolved

Medium

Incomplete Vesting Logic and reservedForVesting Management

The provided contract code includes a Vesting struct, a vestings mapping, and a reservedForVesting state variable, which is crucial for managing token supply during sales by excluding vested tokens from the unlockedBalance. However, the functions responsible for creating vestings, claiming vested tokens, and critically, updating reservedForVesting are truncated. Without the full implementation of these functions, the integrity of the vesting mechanism and the accuracy of unlockedBalance in _purchase cannot be fully assessed. This could lead to scenarios where tokens intended for vesting are prematurely sold, or tokens become permanently locked if reservedForVesting is not co…M-01

Issue

The provided contract code includes a Vesting struct, a vestings mapping, and a reservedForVesting state variable, which is crucial for managing token supply during sales by excluding vested tokens from the unlockedBalance. However, the functions responsible for creating vestings, claiming vested tokens, and critically, updating reservedForVesting are truncated. Without the full implementation of these functions, the integrity of the vesting mechanism and the accuracy of unlockedBalance in _purchase cannot be fully assessed. This could lead to scenarios where tokens intended for vesting are prematurely sold, or tokens become permanently locked if reservedForVesting is not co…

Fix

Provide the complete implementation of all vesting-related functions, including createVesting, claimVestedTokens, and any internal logic that updates reservedForVesting. Ensure that reservedForVesting is accurately incremented when vesting schedules are created and decremented precisely when vested tokens are claimed, preventing discrepancies in the unlockedBalance calculation.

Status

Unresolved

Low

Redundant Access Control Check

The onlyFoundation modifier checks both require(msg.sender == foundation, "not foundation") and _checkRole(FOUNDATION_ROLE, msg.sender). In the constructor, msg.sender is granted both DEFAULT_ADMIN_ROLE and FOUNDATION_ROLE, and foundation is set to msg.sender. While a foundation transfer mechanism is implied by events, if the foundation address is always expected to possess the FOUNDATION_ROLE, one of these checks becomes redundant. This does not introduce a vulnerability but adds unnecessary gas cost and complexity.L-01

Issue

The onlyFoundation modifier checks both require(msg.sender == foundation, "not foundation") and _checkRole(FOUNDATION_ROLE, msg.sender). In the constructor, msg.sender is granted both DEFAULT_ADMIN_ROLE and FOUNDATION_ROLE, and foundation is set to msg.sender. While a foundation transfer mechanism is implied by events, if the foundation address is always expected to possess the FOUNDATION_ROLE, one of these checks becomes redundant. This does not introduce a vulnerability but adds unnecessary gas cost and complexity.

Fix

Consider simplifying the onlyFoundation modifier. If the foundation address is strictly managed to always hold the FOUNDATION_ROLE, then _checkRole(FOUNDATION_ROLE, msg.sender) should suffice, as AccessControl handles role management robustly. Alternatively, if foundation can be an address without the role, the current dual check is appropriate but should be clearly documented.

Status

Unresolved

Info

Irreversible Parameter Freezing

The freezeParameters() function, callable by the foundation, permanently sets parametersFrozen to true. Once frozen, critical token sale parameters such as tokenPriceWeiPerToken, shoPurchaseLimit, publicPurchaseLimit, and minTokensPerPurchase cannot be changed. While this provides certainty and immutability for sale conditions post-freeze, it removes all flexibility for future adjustments, even in unforeseen circumstances or market changes.I-01

Issue

The freezeParameters() function, callable by the foundation, permanently sets parametersFrozen to true. Once frozen, critical token sale parameters such as tokenPriceWeiPerToken, shoPurchaseLimit, publicPurchaseLimit, and minTokensPerPurchase cannot be changed. While this provides certainty and immutability for sale conditions post-freeze, it removes all flexibility for future adjustments, even in unforeseen circumstances or market changes.

Fix

This is a design choice. Ensure that the implications of irreversible parameter freezing are fully understood and accepted by the project stakeholders. Clearly communicate this immutability to potential participants. If any flexibility is desired, consider alternative designs that allow for limited, time-gated, or governance-approved parameter adjustments.

Status

Unresolved

Info

Initial Price Setting Flexibility

The foundation has the ability to set the tokenPriceWeiPerToken to any non-zero value via setTokenPriceWeiPerToken() before freezeParameters() is called. This grants significant control over the initial token valuation and sale terms. While this is an intended feature for initial setup, it means the foundation can unilaterally determine the token's price before the sale parameters are locked.I-02

Issue

The foundation has the ability to set the tokenPriceWeiPerToken to any non-zero value via setTokenPriceWeiPerToken() before freezeParameters() is called. This grants significant control over the initial token valuation and sale terms. While this is an intended feature for initial setup, it means the foundation can unilaterally determine the token's price before the sale parameters are locked.

Fix

Ensure transparency regarding the initial token price setting process. Clearly communicate the mechanism and timing of price finalization to the community. Consider publishing the intended price well in advance or using a pre-determined, auditable pricing formula if greater decentralization or trustlessness is desired.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

The AlberichToken contract implements an ERC20 token with integrated sale, snapshot, and vesting capabilities, leveraging OpenZeppelin's battle-tested libraries for core functionalities. The contract exhibits a high degree of centralization, with the 'FOUNDATION_ROLE' controlling critical parameters and operations. While standard security patterns like reentrancy guards and pausing are correctly applied, the vesting mechanism's full implementation and management of 'reservedForVesting' are not visible in the provided code, posing a potential risk. The contract is not upgradeable, ensuring immutability but limiting future flexibility.

Technical8/10Low risk

The contract leverages battle-tested OpenZeppelin libraries for ERC20, access control, pausing, and reentrancy protection, enhancing code security (7.2). Standard Solidity 0.8.20 features prevent integer overflows/underflows. Reentrancy guards are correctly applied to external calls and payable functions. However, the critical vesting logic and the mechanism for updating reservedForVesting are not fully provided, which could impact token availability and sale integrity (7.1, 7.2).

Governance4/10Medium risk

The contract exhibits a highly centralized governance and economic model, with the FOUNDATION_ROLE (and DEFAULT_ADMIN_ROLE) possessing extensive control over all critical parameters (7.3, 7.4). This includes setting token price, managing sale rounds, withdrawing funds, and burning tokens. While this offers operational efficiency, it introduces a significant single point of failure and requires absolute trust in the foundation's integrity. Parameters can be permanently frozen, which provides certainty but removes future flexibility.

Upgrades7/10Low risk

The contract is not designed with an upgradeability pattern (7.7), meaning its logic is immutable once deployed. This eliminates risks associated with upgrade mechanisms, such as proxy misconfigurations or malicious upgrades. However, it also means that any discovered vulnerabilities or desired feature enhancements would necessitate a new contract deployment and token migration.

Final RecommendationWhat to do about this score

Strengthen the security posture by completing and thoroughly auditing the vesting mechanism, ensuring reservedForVesting is accurately managed throughout the token lifecycle.

Consider implementing a multi-signature wallet for the FOUNDATION_ROLE and DEFAULT_ADMIN_ROLE to mitigate the risks associated with centralized control. Clearly document the operational procedures and responsibilities for these critical roles.

Contract & Record

1 audit on record
TypeAlberichToken
NetworkEthereum
Token age21d
Contract0x7adb…b998
Deployer0x5ea6…3389
Badge for your website
Alberich Token security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Sep 2, 202654Medium

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Related Audits

6 more on the recordAll audits
MorphoEthereum54MediumBeamEthereum54MediumSuperVerseSUPER · Ethereum54Medium00 Token00 · Ethereum54MediumIxs TokenIXS · Ethereum54MediumSpiceSFI · Ethereum54Medium

Would You Like a More Detailed Audit of Alberich Token?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit Is this your token? Publish your own audit on this page