Quantum Audit Logo

Is AUSD Safe?

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

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

AUSD AUSD
0x0000…012a
Ethereum Not verifiedLast checked 2d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The AgoraDollar contract serves as the implementation logic for an EIP-1967 Transparent Proxy, functioning as an ERC-20 token with additional EIP-2612 and EIP-3009 features. The contract employs a custom StorageLib for explicit storage management and a comprehensive role-based access control system. Key risks include significant centralized control through powerful roles and the proxy admin, and a critical limitation in the audit scope due to the unavailability of the AgoraDollarCore contract's source code, preventing a full verification of core logic.

1 Critical1 High2 Medium1 Low1 Informational
Volume 24h
$2.68M
Liquidity
$34.17M
Price
$0.9999
Token Age
2y
Top 10 Holders
88.8%

Security Findings

1 Crit1 High2 Med1 Low1 Info
Critical

Centralized Control via Proxy Admin and Extensive Roles

C-01The contract design exhibits significant centralization of control. The owner of the EIP-1967 Transparent Proxy's `ProxyAdmin` (0x6889…30e2, an EOA) possesses ultimate authority over contract upgrades, allowing for arbitrary changes to the contract's logic. Additionally, the contract employs numerous powerful roles (Minter, Burner, Pauser, Freezer, Bridge Minter/Burner, Rate Limit Manager) which, if compromised or misused, can lead to severe economic consequences such as arbitrary token minting, freezing of user funds, or halting all token operations. This represents a high trust assumption placed on these privileged addresses (7.3 Access Control, 7.5 Governan…
IssueThe contract design exhibits significant centralization of control. The owner of the EIP-1967 Transparent Proxy's `ProxyAdmin` (, an EOA) possesses ultimate authority over contract upgrades, allowing for arbitrary changes to the contract's logic. Additionally, the contract employs numerous powerful roles (Minter, Burner, Pauser, Freezer, Bridge Minter/Burner, Rate Limit Manager) which, if compromised or misused, can lead to severe economic consequences such as arbitrary token minting, freezing of user funds, or halting all token operations. This represents a high trust assumption placed on these privileged addresses (7.3 Access Control, 7.5 Governan…
FixImplement multi-signature wallets (e.g., Gnosis Safe) for the `ProxyAdmin` owner and all critical administrative roles. Consider introducing time-locks for sensitive operations like upgrades or role changes to provide a delay for community review and emergency intervention. Clearly document the responsibilities and operational procedures for each role.
StatusUnresolved
High

Incomplete Audit Scope due to Missing Core Logic

H-01The provided source code is for the `AgoraDollar` contract, which inherits from `AgoraDollarCore` and utilizes `StorageLib`. Crucially, the source code for `AgoraDollarCore` and `StorageLib` was not provided. Without these core components, a comprehensive security audit of critical functionalities such as token transfers, minting, burning, access control enforcement, pausing mechanisms, and EIP-2612/EIP-3009 signature verification cannot be performed. This significantly limits the ability to identify potential vulnerabilities in the fundamental operations of the token (7.1 Architecture, 7.2 Code Security).
IssueThe provided source code is for the `AgoraDollar` contract, which inherits from `AgoraDollarCore` and utilizes `StorageLib`. Crucially, the source code for `AgoraDollarCore` and `StorageLib` was not provided. Without these core components, a comprehensive security audit of critical functionalities such as token transfers, minting, burning, access control enforcement, pausing mechanisms, and EIP-2612/EIP-3009 signature verification cannot be performed. This significantly limits the ability to identify potential vulnerabilities in the fundamental operations of the token (7.1 Architecture, 7.2 Code Security).
FixProvide the complete source code for `AgoraDollarCore` and `StorageLib` to enable a full and thorough security audit of all contract functionalities. Until a full audit is completed, the security posture of the core token logic remains unverified.
StatusUnresolved
Medium

Storage Collision Risk in Custom Upgradeable Design

M-01The contract employs a custom `StorageLib` to manage explicit storage slots for different modules (ERC20, ERC2612, EIP3009, etc.). While this approach is intended to prevent storage collisions in an upgradeable proxy environment, it introduces significant complexity. Any future upgrades or modifications to `AgoraDollarCore` or `StorageLib` must meticulously adhere to the defined storage layout. A single miscalculation or oversight in slot allocation could lead to critical data corruption, overwriting essential state variables, or causing unexpected contract behavior (7.1 Architecture, 7.7 Upgrades). The `Initializable` pattern, crucial for preventing reinitialization, must also be correctly…
IssueThe contract employs a custom `StorageLib` to manage explicit storage slots for different modules (ERC20, ERC2612, EIP3009, etc.). While this approach is intended to prevent storage collisions in an upgradeable proxy environment, it introduces significant complexity. Any future upgrades or modifications to `AgoraDollarCore` or `StorageLib` must meticulously adhere to the defined storage layout. A single miscalculation or oversight in slot allocation could lead to critical data corruption, overwriting essential state variables, or causing unexpected contract behavior (7.1 Architecture, 7.7 Upgrades). The `Initializable` pattern, crucial for preventing reinitialization, must also be correctly…
FixEnsure rigorous testing and formal verification of the `StorageLib` and its interaction with `AgoraDollarCore` to confirm correct storage slot allocation and prevent collisions. Implement a robust upgrade testing framework that includes simulating storage layout changes. Document the storage layout explicitly and enforce strict review processes for any changes to `AgoraDollarCore` or `StorageLib` that affect storage.
StatusUnresolved
Medium

Denial of Service via Pausing Mechanisms

M-02The contract includes multiple pausing mechanisms (e.g., `isTransferPaused`, `isMintPaused`, `isFreezingPaused`, `isSignatureVerificationPaused`, `isBridgingPaused`). While intended for emergency situations, these controls grant significant power to halt critical operations. Typically managed by a `PAUSER_ROLE`, misuse or compromise of this role could lead to a denial of service for users, preventing them from transferring tokens, minting new tokens, or performing other essential functions. This introduces a single point of failure for operational continuity (7.2 Code Security, 7.8 Operations).
IssueThe contract includes multiple pausing mechanisms (e.g., `isTransferPaused`, `isMintPaused`, `isFreezingPaused`, `isSignatureVerificationPaused`, `isBridgingPaused`). While intended for emergency situations, these controls grant significant power to halt critical operations. Typically managed by a `PAUSER_ROLE`, misuse or compromise of this role could lead to a denial of service for users, preventing them from transferring tokens, minting new tokens, or performing other essential functions. This introduces a single point of failure for operational continuity (7.2 Code Security, 7.8 Operations).
FixImplement multi-signature control for the `PAUSER_ROLE` to distribute authority and reduce the risk of a single point of compromise. Clearly define the conditions under which pausing mechanisms can be activated and deactivated, and ensure these are communicated transparently to users. Consider adding a time-lock for unpausing operations to allow for community oversight.
StatusUnresolved
Low

Compiler Version Mismatch

L-01The `pragma solidity 0.8.28` directive in the provided source code indicates that the contract is intended to be compiled with Solidity version 0.8.28. However, the prefill data specifies a `compiler_version: 0.8.21`. While minor version differences within the 0.8.x series are often backward compatible, it is best practice to compile contracts with the exact pragma version to ensure consistent behavior, avoid potential compiler-specific issues, and prevent unexpected warnings or errors that might arise from subtle changes between compiler versions (7.2 Code Security).
IssueThe `pragma solidity 0.8.28` directive in the provided source code indicates that the contract is intended to be compiled with Solidity version 0.8.28. However, the prefill data specifies a `compiler_version: 0.8.21`. While minor version differences within the 0.8.x series are often backward compatible, it is best practice to compile contracts with the exact pragma version to ensure consistent behavior, avoid potential compiler-specific issues, and prevent unexpected warnings or errors that might arise from subtle changes between compiler versions (7.2 Code Security).
FixEnsure that the contract is compiled using the exact Solidity compiler version specified in its `pragma` directive (0.8.28). Update the deployment pipeline or documentation to reflect the correct compiler version.
StatusUnresolved
Info

Redundant `proxyAdminAddress()` in Implementation

I-01The `proxyAdminAddress()` function in the implementation contract reads a `proxyAdminAddress` from its own storage via `StorageLib`. In a standard EIP-1967 Transparent Proxy setup, the actual proxy admin address is stored in the proxy contract itself (at a specific storage slot). Storing a copy of this address within the implementation's storage is redundant and could potentially lead to inconsistencies if the proxy admin is changed directly on the proxy but not updated in the implementation's storage. While likely intended for informational purposes, it could be misleading (7.1 Architecture).
IssueThe `proxyAdminAddress()` function in the implementation contract reads a `proxyAdminAddress` from its own storage via `StorageLib`. In a standard EIP-1967 Transparent Proxy setup, the actual proxy admin address is stored in the proxy contract itself (at a specific storage slot). Storing a copy of this address within the implementation's storage is redundant and could potentially lead to inconsistencies if the proxy admin is changed directly on the proxy but not updated in the implementation's storage. While likely intended for informational purposes, it could be misleading (7.1 Architecture).
FixConsider removing the `proxyAdminAddress()` function from the implementation contract, as the authoritative source for the proxy admin address is the proxy contract itself. If it must remain, clarify in documentation that this is a cached or informational value and not the authoritative source of truth for the proxy's admin.
StatusUnresolved

Category Ratings

TechnicalMedium4/10

The contract utilizes `ShortStrings` for gas-efficient name/symbol storage and a custom `StorageLib` for explicit storage management, which is a positive for upgradeability (7.1 Architecture). However, a comprehensive technical review is significantly hampered by the absence of the `AgoraDollarCore` source code (7.2 Code Security), making it impossible to fully verify critical core logic such as transfers, minting, burning, and signature verification. The custom `StorageLib` for explicit storage slots, while designed to prevent collisions, adds complexity and requires rigorous adherence in future upgrades (7.1 Architecture).

GovernanceHigh1/10

The contract implements a robust role-based access control system with distinct roles for various operations, such as Minter, Burner, Pauser, and Freezer (7.3 Access Control). However, the design relies heavily on centralized control through these numerous powerful roles, as well as the owner of the `ProxyAdmin` (7.5 Governance). If these roles are compromised or misused, there is a significant risk of economic impact, including arbitrary minting, freezing of user funds, or halting critical operations (7.4 Economic).

UpgradesHigh1/10

The contract utilizes the EIP-1967 Transparent Proxy pattern, providing a standard mechanism for upgradeability. The custom `StorageLib` explicitly defines storage slots, aiming to prevent storage collisions during upgrades (7.7 Upgrades). However, this custom storage management introduces complexity; any future upgrades must strictly maintain the defined storage layout to avoid data corruption. The `Initializable` pattern, likely implemented in `AgoraDollarCore`, is critical for preventing reinitialization attacks and must be correctly implemented and used (7.7 Upgrades). The `ProxyAdmin` owner has ultimate control over contract upgrades (7.8 Operations).

Security Checklist

1/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Proxy Upgrade Controls

Proxy TypeEip1967 Transparent
AdminOZ ProxyAdmin
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

88.8% in top 10
42.0% in wallets46.7% in contracts
Effective Concentration60.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

$52.05M across 6 pairs
Uniswap v3USDCanalysed$34.17M65.6%UnknownUSDC$9.30M17.9%Uniswap v4USDC$8.44M16.2%Uniswap v3USDT$125.0K0.2%Curve stblUSDT$12.9K0.0%Curve stblUSDC$3020.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 Holder74.3%
Top-3 Unlocked100.0%

Key Addresses

6 addresses
Deployer
0xfe6e…771b
Unlocked LP Held By
0x491e…a44e0x0dcd…a1530xc6dc…40a60x8b94…aaf50xde51…a29f

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

What Raised This Score

12 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • OZ ProxyAdmin -> Admin is EOA (single key controls upgrades)
  • Top-10 concentration > 50% (88.8% total → 60.7% effective; 42.0% in EOAs, 46.7% in contracts — heavy)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 74.3% (independent LP — depth risk, pool = 66% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 66% of DEX liquidity)
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 2 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
SpaceX xStock (SPCXX)Critical RiskBananaCritical RiskPonsCritical RiskGoldfish (GGBR)Critical RiskHumanity (H)Critical RiskVision (VSN)Critical Risk

Would You Like a More Detailed Audit of AUSD?

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

Get Detailed Audit