Quantum Audit Logo

Is Auki Token Safe?

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

Auki Token AUKI
0xf956…5df4
Base
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.
Last checked today 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

This audit reviews the `AukiToken` contract, which serves as the implementation for a UUPS proxy. While the full source code for the `AukiToken` implementation was not directly provided, the audit was conducted based on the provided interfaces, libraries, and pre-filled contract metadata, inferring a standard OpenZeppelin-based ERC20 token with access control and upgradeability features. The contract leverages well-audited OpenZeppelin libraries, which enhances its security posture. Key areas of focus include access control for minting and upgrades, the inherent risks of the `permit` function, and general upgrade safety considerations.

1 Medium1 Low3 Informational
Volume 24h
$71.5K
Liquidity
$464.4K
Price
$0.008462
Token Age
2y
Top 10 Holders
82.9%

Security Findings

1 Med1 Low3 Info
Medium

Centralized Control over Token Operations and Upgrades

M-01The `AukiToken` contract, as inferred from the provided interfaces and metadata, likely implements `AccessControlUpgradeable` and `UUPSUpgradeable`. This implies that critical functions such as token minting (given `has_mint: true`) and contract upgrades are controlled by specific roles (e.g., `MINTER_ROLE`, `DEFAULT_ADMIN_ROLE`). While the prefill indicates these roles are managed by a 4-of-6 multisig wallet, which significantly mitigates the risk of a single point of failure, it still represents a centralized authority. Compromise of the multisig signers could lead to unauthorized minting, malicious upgrades, or other detrimental actions.
IssueThe `AukiToken` contract, as inferred from the provided interfaces and metadata, likely implements `AccessControlUpgradeable` and `UUPSUpgradeable`. This implies that critical functions such as token minting (given `has_mint: true`) and contract upgrades are controlled by specific roles (e.g., `MINTER_ROLE`, `DEFAULT_ADMIN_ROLE`). While the prefill indicates these roles are managed by a 4-of-6 multisig wallet, which significantly mitigates the risk of a single point of failure, it still represents a centralized authority. Compromise of the multisig signers could lead to unauthorized minting, malicious upgrades, or other detrimental actions.
FixEnsure robust operational security practices for the multisig wallet and its signers. Consider implementing time-locks for critical administrative actions (e.g., upgrades, role changes) to provide a window for community review or emergency intervention. Explore decentralized governance mechanisms for future iterations if applicable to further distribute control.
StatusUnresolved
Low

Standard `permit` Function Front-Running Risk

L-01The presence of `IERC20PermitUpgradeable` indicates the token supports the `permit` function, allowing users to approve token spending off-chain via signed messages. While convenient, this mechanism is susceptible to front-running. An attacker monitoring the mempool could observe a legitimate `permit` transaction, then submit their own transaction with a higher gas fee to approve and spend the tokens before the original transaction is confirmed. This is an inherent characteristic of the `permit` design and not a flaw in the implementation itself.
IssueThe presence of `IERC20PermitUpgradeable` indicates the token supports the `permit` function, allowing users to approve token spending off-chain via signed messages. While convenient, this mechanism is susceptible to front-running. An attacker monitoring the mempool could observe a legitimate `permit` transaction, then submit their own transaction with a higher gas fee to approve and spend the tokens before the original transaction is confirmed. This is an inherent characteristic of the `permit` design and not a flaw in the implementation itself.
FixEducate users about the potential for front-running when using the `permit` function. Advise them to be cautious when broadcasting signed messages and consider using services that protect against front-running if available. Implementations can also consider adding a `deadline` parameter to `permit` calls to limit the window of vulnerability.
StatusUnresolved
Info

Reliance on OpenZeppelin Upgradeable Contracts

I-01The contract heavily relies on OpenZeppelin's battle-tested upgradeable contracts and libraries (e.g., `AddressUpgradeable`, `CountersUpgradeable`, `StorageSlotUpgradeable`, `AccessControlUpgradeable`, `ERC20Upgradeable`, `UUPSUpgradeable`). This is a significant strength, as these libraries are widely used and have undergone extensive audits and community review. However, any future vulnerabilities discovered in these underlying libraries could potentially affect this contract.
IssueThe contract heavily relies on OpenZeppelin's battle-tested upgradeable contracts and libraries (e.g., `AddressUpgradeable`, `CountersUpgradeable`, `StorageSlotUpgradeable`, `AccessControlUpgradeable`, `ERC20Upgradeable`, `UUPSUpgradeable`). This is a significant strength, as these libraries are widely used and have undergone extensive audits and community review. However, any future vulnerabilities discovered in these underlying libraries could potentially affect this contract.
FixStay informed about security updates and advisories from OpenZeppelin. Regularly review the dependencies for any reported vulnerabilities and be prepared to upgrade the implementation if critical issues are identified in the underlying libraries.
StatusUnresolved
Info

Potential for Storage Collisions in Custom Upgrades

I-02While OpenZeppelin's UUPS pattern is designed to prevent storage collisions, any custom storage variables added to the `AukiToken` implementation or incorrect inheritance order in future upgrades could potentially lead to storage collisions. This occurs when a variable in a new implementation occupies the same storage slot as a different variable in the previous implementation, leading to data corruption or unexpected behavior.
IssueWhile OpenZeppelin's UUPS pattern is designed to prevent storage collisions, any custom storage variables added to the `AukiToken` implementation or incorrect inheritance order in future upgrades could potentially lead to storage collisions. This occurs when a variable in a new implementation occupies the same storage slot as a different variable in the previous implementation, leading to data corruption or unexpected behavior.
FixAdhere strictly to OpenZeppelin's storage layout guidelines for upgradeable contracts. When adding new state variables in future upgrades, always append them to the end of the contract's storage layout. Thoroughly test all upgrade paths in a staging environment to identify and prevent potential storage collisions before deploying to production.
StatusUnresolved
Info

Re-initialization Attack Vector

I-03UUPS proxy implementations are generally susceptible to re-initialization attacks if the `initialize` function is not properly protected. An attacker could call `initialize` again on the implementation contract (if not properly disabled) or on the proxy itself, potentially resetting critical state variables or re-assigning administrative roles. OpenZeppelin's `UUPSUpgradeable` typically includes mechanisms like `_disableInitializers` in the constructor and the `initializer` modifier to prevent this.
IssueUUPS proxy implementations are generally susceptible to re-initialization attacks if the `initialize` function is not properly protected. An attacker could call `initialize` again on the implementation contract (if not properly disabled) or on the proxy itself, potentially resetting critical state variables or re-assigning administrative roles. OpenZeppelin's `UUPSUpgradeable` typically includes mechanisms like `_disableInitializers` in the constructor and the `initializer` modifier to prevent this.
FixEnsure that the `initialize` function in the `AukiToken` implementation is protected by the `initializer` modifier and that `_disableInitializers()` is called in the constructor of the implementation contract to prevent direct calls to `initialize` on the implementation itself. Verify that the proxy's `initialize` function can only be called once.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The technical architecture appears sound, relying heavily on battle-tested OpenZeppelin upgradeable contracts and libraries (7.1 Architecture). This approach significantly reduces the likelihood of common coding errors and vulnerabilities (7.2 Code Security). The use of `AddressUpgradeable` and `CountersUpgradeable` demonstrates adherence to robust utility patterns. No direct reentrancy vectors or integer overflow/underflow issues were identified based on the provided interfaces, as Solidity 0.8+ provides default overflow checks and OpenZeppelin libraries are designed to prevent such issues.

GovernanceHigh1/10

The contract exhibits centralized control over critical functions such as token minting and contract upgrades (7.3 Access Control, 7.5 Governance). This control is managed by a 4-of-6 multisig wallet, which is a strong mitigation against single points of failure, but still represents a centralized authority. The token's economic model includes minting capabilities, which could lead to inflation if not managed responsibly (7.4 Economic). The `permit` function introduces a known front-running risk for users, though this is an inherent characteristic of the ERC-20 Permit standard.

UpgradesHigh1/10

The contract utilizes the UUPS proxy pattern, a robust and widely adopted standard for upgradeability (7.7 Upgrades). This pattern allows for future enhancements and bug fixes without deploying a new contract. Upgrade authorization is expected to be restricted to a privileged role, likely controlled by the project's multisig, which enhances security. Standard OpenZeppelin UUPS implementations are designed to prevent common upgrade-related issues like storage collisions and re-initialization attacks, contributing to a secure upgrade path.

Security Checklist

1/5 checks passed
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

82.9% in top 10
79.2% in wallets3.7% in contracts
Effective Concentration80.7%

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

$708.7K across 9 pairs
Uniswap v3WETHanalysed$464.4K65.5%PancakeswapWETH$131.5K18.5%AerodromeUSDC$70.7K10.0%AerodromeAERO$23.6K3.3%Uniswap v4ETH$17.6K2.5%Uniswap v3USDC$7200.1%
Show 3 more pairsShow less
Hydrex CLAMMUSDC$2560.0%AerodromeWETH$690.0%Uniswap v4DINO$10.0%

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 Holder93.8%
Top-3 Unlocked96.3%

Key Addresses

11 addresses
Deployer
0xc4f8…41cd
Unlocked LP Held By
0x7d75…9ec70x8700…36590xd9ba…32650x1fcc…edea0x8e61…6f210xf8f0…32540x72bb…4f510x8795…aeb70x9b38…a4e10x2434…56f5

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 (4-of-6)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 70% (82.9% total → 80.7% effective; 79.2% in EOAs, 3.7% in contracts — extreme)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 93.8% (independent LP — depth risk, pool = 66% of DEX liquidity)
  • LP top3 unlocked holders = 96.3% (independent LP — depth risk, pool = 66% of DEX liquidity)
  • 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
RIZEHigh RiskXMAQUINA (DEUS)Critical RiskTownsCritical RiskICPCritical RiskEthy AI by Virtuals (ETHY)High RiskGAME by Virtuals (GAME)Critical Risk

Would You Like a More Detailed Audit of Auki Token?

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

Get Detailed Audit