Is Avail (Wormhole) (AVAIL) Safe? Smart Contract Security Analysis

Security Findings

2 High1 Low2 Info

High

Centralization Risk: Unlimited Minting by MINTER_ROLE

H-01The `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.

IssueThe `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.

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

StatusUnresolved

High

External Dependency Risk: Wormhole Bridge Security

H-02The 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.

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

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

StatusUnresolved

Low

Lack of Emergency Pause Mechanism

L-01The 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.

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

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

StatusUnresolved

Info

Usage of `reinitializer(2)`

I-01The `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.

IssueThe `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.

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

StatusUnresolved

Info

Correct Use of `_disableInitializers()` in Constructor

I-02The 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.

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

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

StatusUnresolved

Category Ratings

TechnicalMedium5/10

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.

GovernanceHigh2/10

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.

UpgradesHigh1/10

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.

Security Checklist

1/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEip1967 Transparent

AdminOZ ProxyAdmin → Multisig 3-of-5

ImplementationVerified source

Upgrades (30d)0 · stable

Holder Composition

90.3% in top 10

3.8% in wallets86.5% in contracts

Effective Concentration38.4%

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

$81.5K across 2 pairs

AerodromeUSDCanalysed$65.9K Quickswap v4USDC$15.7K

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.1%

Top-3 Unlocked100.0%

Key Addresses

4 addresses

Deployer

0xd230…c865

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.

What Raised This Score

9 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

Is Avail (Wormhole) Safe?

Security Findings

Centralization Risk: Unlimited Minting by MINTER_ROLE

External Dependency Risk: Wormhole Bridge Security

Lack of Emergency Pause Mechanism

Usage of `reinitializer(2)`

Correct Use of `_disableInitializers()` in Constructor

Category Ratings

Security Checklist

Proxy Upgrade Controls

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

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