Quantum Audit Logo

Is Audius Safe?

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

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

Audius AUDIO
0x18aa…b998
Ethereum
Not verifiedThis 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 today 1 audit on record
Executive SummaryAI Copilot

The AudiusToken contract, deployed as an upgradeable proxy, contains critical vulnerabilities related to its initialization mechanism and access control. The `proxyAdmin` variable, crucial for initialization, is never set, preventing the contract from being properly initialized. Additionally, the `addMinter` and `addPauser` functions lack access control, allowing any caller to grant themselves or others powerful roles, leading to unauthorized token minting or pausing of all token operations. These issues pose severe risks to the token's functionality, integrity, and security.

2 Critical1 High1 Low
Volume 24h
$451.7K
Liquidity
$515.7K
Price
$0.01695
Token Age
5y
Top 10 Holders
64.9%

Security Findings

Critical

Unset `proxyAdmin` Prevents Contract Initialization

C-01The `Initializable` base contract includes a private state variable `proxyAdmin` which is checked in the `initializer` modifier (`require(msg.sender == proxyAdmin, "Only proxy admin can initialize")`). However, this `proxyAdmin` variable is never assigned a value within the provided contract code. As a result, `proxyAdmin` defaults to `address(0)`. This makes it impossible for the `AudiusToken`'s `initialize` function to ever be called successfully, as `msg.sender` can never be `address(0)` in a transaction. This prevents the token from being properly configured (name, symbol, decimals, initial supply, minters, pausers) and renders the contract unusable.
IssueThe `Initializable` base contract includes a private state variable `proxyAdmin` which is checked in the `initializer` modifier (`require(msg.sender == proxyAdmin, "Only proxy admin can initialize")`). However, this `proxyAdmin` variable is never assigned a value within the provided contract code. As a result, `proxyAdmin` defaults to `address(0)`. This makes it impossible for the `AudiusToken`'s `initialize` function to ever be called successfully, as `msg.sender` can never be `address(0)` in a transaction. This prevents the token from being properly configured (name, symbol, decimals, initial supply, minters, pausers) and renders the contract unusable.
FixEnsure the `proxyAdmin` variable in the `Initializable` contract is correctly set during the deployment or initialization process. A common pattern for UUPS proxies is to not have an `Initializable` contract with its own `proxyAdmin` for initialization, but rather rely on the proxy's admin for upgrade authorization. If this `proxyAdmin` is intended for initialization, it must be set via a constructor or an accessible setter function, or consider using a battle-tested `Initializable` contract fr…
StatusUnresolved
Critical

Public `addMinter` and `addPauser` Functions Lack Access Control

C-02The `addMinter(address account)` and `addPauser(address account)` functions in `MinterRole` and `PauserRole` contracts, respectively, are declared `public` and do not include any access control modifiers (e.g., `onlyOwner`, `onlyAdmin`). This allows any external caller to invoke these functions and grant themselves or any arbitrary address the `Minter` or `Pauser` role. A malicious actor could become a Minter to mint an unlimited supply of tokens, or become a Pauser to halt all token transfers, minting, and burning operations, leading to severe economic manipulation or denial of service.
IssueThe `addMinter(address account)` and `addPauser(address account)` functions in `MinterRole` and `PauserRole` contracts, respectively, are declared `public` and do not include any access control modifiers (e.g., `onlyOwner`, `onlyAdmin`). This allows any external caller to invoke these functions and grant themselves or any arbitrary address the `Minter` or `Pauser` role. A malicious actor could become a Minter to mint an unlimited supply of tokens, or become a Pauser to halt all token transfers, minting, and burning operations, leading to severe economic manipulation or denial of service.
FixImplement strict access control for `addMinter`, `removeMinter`, `addPauser`, and `removePauser` functions. These functions should only be callable by a highly trusted entity, such as a contract owner (e.g., `onlyOwner` modifier) or a multi-signature wallet. Consider a robust governance mechanism for managing these critical roles.
StatusUnresolved
High

Potential for Re-initialization of Roles

H-01While the main `AudiusToken.initialize` function is protected by the `initializer` modifier, the `MinterRole.initialize` and `PauserRole.initialize` functions are also `public initializer`. If the critical initialization flaw (C-01) were resolved, and assuming the `proxyAdmin` is set, these role-specific `initialize` functions could potentially be called directly via `delegatecall` from the proxy by an attacker if the `proxyAdmin` is compromised or if the `initializer` modifier's `initialized` check is bypassed in a specific scenario. This could lead to re-setting the initial minter or pauser, potentially overriding legitimate roles.
IssueWhile the main `AudiusToken.initialize` function is protected by the `initializer` modifier, the `MinterRole.initialize` and `PauserRole.initialize` functions are also `public initializer`. If the critical initialization flaw (C-01) were resolved, and assuming the `proxyAdmin` is set, these role-specific `initialize` functions could potentially be called directly via `delegatecall` from the proxy by an attacker if the `proxyAdmin` is compromised or if the `initializer` modifier's `initialized` check is bypassed in a specific scenario. This could lead to re-setting the initial minter or pauser, potentially overriding legitimate roles.
FixEnsure that role-specific `initialize` functions are either internal and called only once by the main contract's `initialize` function, or that their `initializer` modifier correctly prevents re-execution in all upgrade scenarios. A robust `Initializable` pattern should prevent any `initialize` function from being called more than once on the same logical contract instance.
StatusUnresolved
Low

Use of Older Solidity Compiler Version

L-01The contract is compiled with Solidity version `^0.5.0`. While `SafeMath` is used to mitigate integer overflow/underflow, newer Solidity versions (e.g., `0.8.x` and above) include built-in overflow/underflow checks by default, reducing reliance on external libraries for this specific concern. Newer compilers also offer various optimizations, bug fixes, and improved security features.
IssueThe contract is compiled with Solidity version `^0.5.0`. While `SafeMath` is used to mitigate integer overflow/underflow, newer Solidity versions (e.g., `0.8.x` and above) include built-in overflow/underflow checks by default, reducing reliance on external libraries for this specific concern. Newer compilers also offer various optimizations, bug fixes, and improved security features.
FixConsider upgrading the Solidity compiler version to `0.8.x` or higher. This would allow for the removal of `SafeMath` (as arithmetic operations would revert on overflow/underflow by default) and provide access to the latest language features and security improvements. Thorough testing would be required after such an upgrade.
StatusUnresolved

Category Ratings

TechnicalHigh2/10

The contract utilizes the SafeMath library, which effectively prevents integer overflow/underflow vulnerabilities (7.2 Code Security). However, a critical flaw exists where the `proxyAdmin` variable in the `Initializable` base contract is never set, rendering the `initialize` function unusable and preventing the token from being properly deployed and functional (7.1 Architecture, 7.8 Operations). Furthermore, the `addMinter` and `addPauser` functions are publicly accessible, allowing any external caller to grant themselves minting or pausing capabilities, which is a severe access control bypass (7.3 Access Control).

GovernanceHigh1/10

The economic model relies on controlled minting and pausing capabilities. While the `_mint` and `_burn` functions are internal and `pause`/`unpause` are restricted by `onlyPauser` (7.4 Economic), the governance over these roles is severely compromised. The `addMinter` and `addPauser` functions lack any access control, allowing any address to acquire these powerful roles (7.5 Governance). This means an attacker could grant themselves minting rights, leading to arbitrary token inflation, or pausing rights, causing a denial of service for all token transfers.

UpgradesHigh1/10

The contract is designed to be upgradeable via a UUPS proxy pattern, indicated by the `Initializable` base contract and `______gap` variables for storage compatibility (7.7 Upgrades). However, the custom `Initializable` contract's `proxyAdmin` variable, which is checked by the `initializer` modifier, is never set. This prevents the `initialize` function of the `AudiusToken` from ever being called successfully, making the initial deployment of the token logic non-functional in an upgradeable context. This fundamental flaw undermines the entire upgradeability and deployment process.

Security Checklist

Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Proxy Upgrade Controls

Proxy TypeEip1967 Uups
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

36.6% in wallets28.2% in contracts
Effective Concentration47.9%

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

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

Top-1 Unlocked Holder99.3%
Top-3 Unlocked99.9%

Key Addresses

Deployer
0xde21…ca04
Unlocked LP Held By
0x7b46…1aa50xd6fc…85a30xceed…79130xcea8…ca760xfb73…8ff40x28a2…f6190xc18a…05db0x59b5…24480x90ac…191c0x67ca…296e

No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.

What Raised This Score

  • Ownership NOT renounced (admin/mint authority retained)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 30% (64.9% total → 47.9% effective; 36.6% in EOAs, 28.2% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 99.3% (independent LP — depth risk)
  • LP top3 unlocked holders = 99.9% (independent LP — depth risk)
  • 2 Critical finding(s) from audit
  • 1 High 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

HarryPotterObamaSonic10Inu (BITCOIN)High RiskLego Pepe (LEPE)High RiskGraph Token (GRT)High RiskGnosis Token (GNO)High RiskInterfold (FOLD)High RiskTokenFi (TOKEN)High Risk

Would You Like a More Detailed Audit of Audius?

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

Get Detailed Audit