Quantum Audit Logo

Is Alberich Token Safe?

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

Is this your token? Publish your own audit on this page →

Alberich Token ALBRH
0x7adb…b998
Ethereum Not verifiedLast checked 2d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive 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. 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.

1 High1 Medium1 Low2 Informational
Volume 24h
$74.6K
Liquidity
$292.4K
Price
$0.0001248
Token Age
21d
Top 10 Holders
99.5%

Security Findings

1 High1 Med1 Low2 Info
High

Extensive Centralization of Control

H-01The `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.
IssueThe `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.
FixImplement 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.
StatusUnresolved
Medium

Incomplete Vesting Logic and `reservedForVesting` Management

M-01The 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…
IssueThe 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…
FixProvide 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.
StatusUnresolved
Low

Redundant Access Control Check

L-01The `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.
IssueThe `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.
FixConsider 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.
StatusUnresolved
Info

Irreversible Parameter Freezing

I-01The `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.
IssueThe `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.
FixThis 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.
StatusUnresolved
Info

Initial Price Setting Flexibility

I-02The `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.
IssueThe `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.
FixEnsure 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.
StatusUnresolved

Category Ratings

TechnicalLow8/10

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).

GovernanceMedium4/10

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.

UpgradesLow7/10

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.

Security Checklist

4/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

99.5% in top 10
2.3% in wallets97.2% in contracts
Effective Concentration41.1%

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.

Liquidity Depth

$292.4K

The risk score reads depth across every pair. The volume figure and the volume-to-liquidity ratio elsewhere on this page describe only the pair this audit analysed, so the two are not directly comparable.

LP Distribution

LP Locked100.0% · TeamFinance

Key Addresses

1 addresses
Deployer
0x5ea6…3389

What Raised This Score

6 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

Related Audits

6 more on the record
MorphoHigh RiskBeamHigh RiskSuperVerse (SUPER)High Risk00 Token (00)High RiskIxs Token (IXS)High RiskSpice (SFI)High Risk

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