Is AZTEC Safe? Smart Contract Security Analysis

Security Findings

1 Crit1 Low2 Info

Critical

Centralized Minting Capability

C-01The `Aztec` token contract includes a `mint` function that is restricted to the contract owner via the `onlyOwner` modifier. This allows the owner to mint an arbitrary and unlimited amount of new tokens at any time. This centralized control over the token supply introduces a critical economic risk, as it can lead to uncontrolled inflation, dilution of existing token holders' value, and potential for malicious manipulation of the token's market dynamics (7.4 Economic, 7.3 Access Control).

IssueThe `Aztec` token contract includes a `mint` function that is restricted to the contract owner via the `onlyOwner` modifier. This allows the owner to mint an arbitrary and unlimited amount of new tokens at any time. This centralized control over the token supply introduces a critical economic risk, as it can lead to uncontrolled inflation, dilution of existing token holders' value, and potential for malicious manipulation of the token's market dynamics (7.4 Economic, 7.3 Access Control).

FixImplement a robust governance mechanism (e.g., DAO, multi-signature wallet with a timelock) to control the minting function. Alternatively, cap the total supply, remove the minting capability after an initial distribution, or introduce a burning mechanism to balance minting. Clearly communicate the minting policy to token holders.

StatusUnresolved

Low

Lack of Pause Mechanism

L-01The contract does not include a pause mechanism (e.g., using OpenZeppelin's `Pausable` contract) to temporarily halt token transfers or other critical operations in case of an emergency, such as a discovered vulnerability or a major market event. While not strictly required for a basic ERC20, a pause function can be a valuable operational tool (7.8 Operations).

IssueThe contract does not include a pause mechanism (e.g., using OpenZeppelin's `Pausable` contract) to temporarily halt token transfers or other critical operations in case of an emergency, such as a discovered vulnerability or a major market event. While not strictly required for a basic ERC20, a pause function can be a valuable operational tool (7.8 Operations).

FixConsider integrating a pause mechanism, such as OpenZeppelin's `Pausable` contract, to provide an emergency stop functionality. This would allow the owner (or a designated role) to temporarily freeze token transfers or minting in unforeseen circumstances, mitigating potential damage.

StatusUnresolved

Info

Reliance on OpenZeppelin Libraries

I-01The `Aztec` contract heavily relies on well-audited and battle-tested OpenZeppelin contracts (ERC20, Ownable2Step, ERC20Permit). This significantly reduces the likelihood of low-level implementation bugs and enhances the overall security posture of the contract (7.2 Code Security, 7.1 Architecture).

IssueThe `Aztec` contract heavily relies on well-audited and battle-tested OpenZeppelin contracts (ERC20, Ownable2Step, ERC20Permit). This significantly reduces the likelihood of low-level implementation bugs and enhances the overall security posture of the contract (7.2 Code Security, 7.1 Architecture).

FixNo specific recommendation. This is a positive architectural choice.

StatusResolved

Info

Two-Step Ownership Transfer Implemented

I-02The contract utilizes OpenZeppelin's `Ownable2Step` for ownership transfers. This pattern requires the new owner to explicitly accept ownership after it has been transferred by the current owner, preventing accidental loss of ownership due to typos or incorrect addresses (7.3 Access Control).

IssueThe contract utilizes OpenZeppelin's `Ownable2Step` for ownership transfers. This pattern requires the new owner to explicitly accept ownership after it has been transferred by the current owner, preventing accidental loss of ownership due to typos or incorrect addresses (7.3 Access Control).

FixNo specific recommendation. This is a strong security practice.

StatusResolved

Category Ratings

TechnicalMedium6/10

The contract leverages battle-tested OpenZeppelin libraries for ERC20, Ownable2Step, and ERC20Permit functionalities, significantly enhancing code security and reliability (7.2 Code Security). The implementation is minimal, primarily extending these libraries with a single `mint` function. The use of `Ownable2Step` for ownership transfers is a strong security practice, mitigating the risk of accidental ownership loss (7.3 Access Control). No complex custom logic is present that could introduce technical vulnerabilities like reentrancy or arithmetic errors.

GovernanceHigh1/10

The primary economic risk stems from the highly centralized control over token supply (7.4 Economic). The `mint` function, callable only by the contract owner, allows for arbitrary creation of new tokens, which can lead to inflation and dilution of existing token holders without external governance mechanisms (7.5 Governance). While this design provides flexibility for the owner, it introduces significant trust assumptions. The `Ownable2Step` pattern for ownership transfer is a positive aspect, providing a secure mechanism for changing the controlling entity.

UpgradesHigh2/10

The Aztec token contract is not designed to be upgradeable (7.7 Upgrades). This means its logic is immutable once deployed, providing certainty regarding its behavior. While immutability prevents future bug fixes or feature enhancements, it eliminates the risks associated with proxy patterns, such as upgradeability misconfigurations or malicious upgrade paths. Any changes to the token's core logic would require a new contract deployment and migration.

Security Checklist

2/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyPass

Holder Composition

100.0% in top 10

100.0% in wallets0.0% in contracts

Effective Concentration100.0%

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

$15.60M across 8 pairs

Uniswap v4ETHanalysed$15.56M Uniswap v4ETH$22.5K Uniswap v3WETH$5.8K Uniswap v4ETH$4.8K Uniswap v4ETH$2.3K Uniswap v4USDT$2.0K

Show 2 more pairsShow less

SupernovaUSDT$958 Uniswap v4USDC$779

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.

Key Addresses

1 addresses

Deployer

0xcbe2…751d

What Raised This Score

6 factors

Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
Mintable supply — no cap found, dilution unbounded
Top-10 concentration > 70% (100.0% total → 100.0% effective; 100.0% in EOAs, 0.0% in contracts — extreme)
Liquidity NOT locked (owner can withdraw — rug-pull risk)
1 Critical 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 AZTEC Safe?