Quantum Audit Logo
Launch App

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

Is Avail (Wormhole) Safe?

AVAILBase
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
Technical5/10Governance2/10Upgrades1/10Checks passed1 of 5Findings2 High · 1 Low · 2 Info5
SummaryAI Copilot

The Avail (Wormhole) token contract is an upgradeable ERC20 token utilizing OpenZeppelin's AccessControlDefaultAdminRules for robust access management.

Read the full analysis
What raised the score
  • Ownership not renounced — strong Multisig
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 99.1%
  • LP top3 unlocked holders = 100.0%
  • 2 High finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced — strong Multisig (3-of-5)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 30% (90.3% total → 38.4% effective; 3.8% in EOAs, 86.5% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 99.1% (independent LP — depth risk, pool = 81% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 81% of DEX liquidity)
  • 2 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

Security Checklist

as of audit · Sep 41 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintMintable
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
86.5%Contracts3.8%9.7%Everyone else
86.5%Contracts3.8%9.7%
ContractsWalletsEveryone elseBubble area = share of supply
90.3%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking86.5%
  • Walletsanonymous holders, free to sell3.8%
  • Everyone elsethe rest of the supply9.7%
Effective concentrationwhat the score reads38.4%
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$81.5K across 2 pairs

The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$65.9KShare of depth80.8%
Top-1 Unlocked Holder99.1%
Top-3 Unlocked100.0%
Unlocked LP held by
0xfa2b…52bb0x5c3b…25af0x7963…0305

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

Security Findings

2 High1 Low2 Info
High

Centralization Risk: Unlimited Minting by MINTER_ROLE

The mint function allows an address with the MINTER_ROLE to mint an arbitrary amount of tokens to any account. This introduces a significant centralization risk, as a compromise of the MINTER_ROLE key or malicious action by its holder could lead to hyperinflation of the token supply, devaluing existing tokens and potentially causing a loss of user funds. This is a common pattern for wrapped tokens but represents a critical point of failure.H-01

Issue

The mint function allows an address with the MINTER_ROLE to mint an arbitrary amount of tokens to any account. This introduces a significant centralization risk, as a compromise of the MINTER_ROLE key or malicious action by its holder could lead to hyperinflation of the token supply, devaluing existing tokens and potentially causing a loss of user funds. This is a common pattern for wrapped tokens but represents a critical point of failure.

Fix

Implement strict operational security for the MINTER_ROLE address. Consider adding additional controls such as multi-signature requirements for minting transactions, rate limits on minting, or time-locks for large mints. Clearly communicate the implications of this centralized control to users.

Status

Unresolved

High

External Dependency Risk: Wormhole Bridge Security

The Avail (Wormhole) token is a wrapped asset whose value is directly dependent on the security and integrity of the underlying Avail token and the Wormhole bridge. Any vulnerability, exploit, or operational failure within the Wormhole bridge could lead to a de-pegging event, where the wrapped token loses its backing and value. This is an inherent risk for bridged assets and is outside the scope of this contract's direct control.H-02

Issue

The Avail (Wormhole) token is a wrapped asset whose value is directly dependent on the security and integrity of the underlying Avail token and the Wormhole bridge. Any vulnerability, exploit, or operational failure within the Wormhole bridge could lead to a de-pegging event, where the wrapped token loses its backing and value. This is an inherent risk for bridged assets and is outside the scope of this contract's direct control.

Fix

Conduct continuous monitoring and due diligence on the security posture of the Wormhole bridge. Establish clear emergency response plans in case of a bridge compromise. Users should be made fully aware of the risks associated with relying on external bridging solutions.

Status

Unresolved

Low

Lack of Emergency Pause Mechanism

The contract lacks a mechanism to pause critical operations (e.g., transfers, minting, burning) in emergency situations. While not strictly required for a basic ERC20, a pause function can be crucial for mitigating damage during unforeseen events, such as a critical vulnerability discovery, a bridge exploit affecting the underlying asset, or other black swan events.L-01

Issue

The contract lacks a mechanism to pause critical operations (e.g., transfers, minting, burning) in emergency situations. While not strictly required for a basic ERC20, a pause function can be crucial for mitigating damage during unforeseen events, such as a critical vulnerability discovery, a bridge exploit affecting the underlying asset, or other black swan events.

Fix

Consider implementing an PausableUpgradeable mechanism from OpenZeppelin. This would allow a designated role (e.g., the DEFAULT_ADMIN_ROLE or a dedicated PAUSER_ROLE controlled by the multisig) to temporarily halt contract operations, providing a safety switch during emergencies.

Status

Unresolved

Info

Usage of reinitializer(2)

The initialize() function uses reinitializer(2). This allows the function to be called multiple times during the contract's lifecycle, specifically after an upgrade, as long as the version number is incremented. While this is an intended feature for complex upgrade scenarios in OpenZeppelin's upgradeable pattern, it requires careful management to prevent unintended re-initialization or state corruption if not used correctly.I-01

Issue

The initialize() function uses reinitializer(2). This allows the function to be called multiple times during the contract's lifecycle, specifically after an upgrade, as long as the version number is incremented. While this is an intended feature for complex upgrade scenarios in OpenZeppelin's upgradeable pattern, it requires careful management to prevent unintended re-initialization or state corruption if not used correctly.

Fix

Ensure that all future upgrades correctly manage the initializer versioning. Document the intended use cases for re-initialization and ensure that any state changes made during re-initialization are thoroughly tested and do not conflict with existing storage or logic.

Status

Unresolved

Info

Correct Use of _disableInitializers() in Constructor

The contract correctly calls _disableInitializers() in its constructor. This is a crucial best practice for upgradeable contracts, as it prevents the constructor from being called on the implementation contract directly, which could lead to a 'shadow' state or bypass initialization logic when the contract is deployed as an implementation behind a proxy.I-02

Issue

The contract correctly calls _disableInitializers() in its constructor. This is a crucial best practice for upgradeable contracts, as it prevents the constructor from being called on the implementation contract directly, which could lead to a 'shadow' state or bypass initialization logic when the contract is deployed as an implementation behind a proxy.

Fix

No action required. This is a correctly implemented best practice.

Status

Unresolved

Analysis

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

The Avail (Wormhole) token contract is an upgradeable ERC20 token utilizing OpenZeppelin's AccessControlDefaultAdminRules for robust access management. While the technical implementation is sound, significant risks stem from the centralized minting authority and the inherent dependency on the Wormhole bridge for token backing. The contract's upgradeability and administrative roles are well-secured by a multisig and time-locked mechanisms.

Technical5/10Medium risk

The contract leverages battle-tested OpenZeppelin upgradeable libraries for ERC20, ERC20Permit, and AccessControl (7.1 Architecture). The implementation of mint and burn functions is straightforward and adheres to standard patterns (7.2 Code Security). The use of reinitializer(2) ensures proper upgradeability. However, the contract's core functionality relies on the external Wormhole bridge, introducing an inherent technical dependency (7.6 External) which is a significant risk factor.

Governance2/10High risk

Access control is robust, utilizing OpenZeppelin's AccessControlDefaultAdminRulesUpgradeable which enforces time-locks for DEFAULT_ADMIN_ROLE changes, enhancing governance security (7.3 Access Control, 7.5 Governance). The proxy admin is also secured by a 3/5 multisig. A primary economic risk is the centralized MINTER_ROLE, which can mint an unlimited supply of tokens (7.4 Economic). The token's value is also entirely dependent on the security and integrity of the Wormhole bridge (7.4 Economic, 7.6 External), making it susceptible to bridge exploits.

Upgrades1/10High risk

The contract is implemented as a TransparentUpgradeableProxy, following OpenZeppelin's upgradeable pattern. The initialize function correctly uses reinitializer(2), and the constructor disables initializers, preventing re-initialization attacks (7.7 Upgrades). The proxy's admin is a 3/5 multisig, providing a secure and decentralized control over upgrades (7.7 Upgrades, 7.8 Operations). Storage slot collisions are mitigated by OpenZeppelin's explicit storage slot definitions.

Final RecommendationWhat to do about this score

Implement robust operational security measures for the MINTER_ROLE to prevent unauthorized token inflation, such as multi-signature control or time-locks for minting operations.

Conduct thorough due diligence and continuous monitoring of the Wormhole bridge's security, as it represents a critical external dependency for the token's value. Consider implementing an emergency pause mechanism to mitigate risks during critical bridge incidents or other unforeseen circumstances.

Contract & Record

1 audit on record
TypeTransparentUpgradeableProxy
NetworkBase
Token age1y
Contract0xd89d…057a
Deployer0xd230…c865
Proxy Upgrade Controls
Proxy TypeEip1967 Transparent
AdminOZ ProxyAdmin → Multisig 3-of-5
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
Avail (Wormhole) 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. Aug 12, 202661Medium

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

Related Audits

6 more on the recordAll audits
LayerZeroZRO · Base61MediumNovalonNVLN · Base61MediumJito Staked SOLJITOSOL · Base62MediumMorpho TokenMORPHO · Base60MediumTether USDUSDT · Base60MediumevoBase60Medium

Would You Like a More Detailed Audit of Avail (Wormhole)?

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