Quantum Audit Logo
Launch App

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

Is AUSD Safe?

Ethereum
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
Critical RiskHow is this score calculated?
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.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract
  • OZ ProxyAdmin -> Admin is EOA
  • Top-10 concentration > 50%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 74.3%
  • LP top3 unlocked holders = 100.0%
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 43 of 7 checks passed
Contract verifiedVerified
OwnershipUnknown
MintMintable
Liquidity lockNot locked
UpgradeabilityUpgradeable
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
46.7%Contracts42.0%Wallets11.2%Everyone else
46.7%Contracts42.0%Wallets11.2%
ContractsWalletsEveryone elseBubble area = share of supply
88.8%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking46.7%
  • Walletsanonymous holders, free to sell42.0%
  • Everyone elsethe rest of the supply11.2%
Effective concentrationwhat the score reads60.7%
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$52.05M across 6 pairs
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$34.17MShare of depth65.6%
Top-1 Unlocked Holder74.3%
Top-3 Unlocked100.0%
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.

Security Findings

1 Critical1 High2 Medium1 Low1 Info
Critical

Centralized Control via Proxy Admin and Extensive Roles

The 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…C-01

Issue

The 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…

Fix

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

Status

Unresolved

High

Incomplete Audit Scope due to Missing Core Logic

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

Issue

The 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).

Fix

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

Status

Unresolved

Medium

Storage Collision Risk in Custom Upgradeable Design

The 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…M-01

Issue

The 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…

Fix

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

Status

Unresolved

Medium

Denial of Service via Pausing Mechanisms

The 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).M-02

Issue

The 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).

Fix

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

Status

Unresolved

Low

Compiler Version Mismatch

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

Issue

The 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).

Fix

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

Status

Unresolved

Info

Redundant proxyAdminAddress() in Implementation

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

Issue

The 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).

Fix

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

Status

Unresolved

Analysis

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

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.

Technical4/10Medium risk

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

Governance1/10High risk

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

Upgrades1/10High risk

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

Final RecommendationWhat to do about this score

Prioritize a full security audit of the AgoraDollarCore and StorageLib contracts to ensure the integrity of core token logic and storage management.

Implement robust multi-signature or time-locked mechanisms for critical administrative roles and the ProxyAdmin owner to mitigate centralized control risks. Establish clear, tested upgrade procedures that meticulously account for the custom storage layout to prevent potential data corruption during future upgrades.

Contract & Record

1 audit on record
TypeAgoraDollarErc1967Proxy
NetworkEthereum
Token age2y
Contract0x0000…012a
Deployer0xfe6e…771b
Proxy Upgrade Controls
Proxy TypeEip1967 Transparent
AdminOZ ProxyAdmin → EOA
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
AUSD 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. Sep 4, 2026100Critical

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

Frequently Asked Questions

What is the AUSD contract address?

The AUSD contract on Ethereum is 0x00000000efe302beaa2b3e6e1b18d08d69a9012a. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is AUSD a scam?

Quantum Audit's risk score for AUSD is 100/100 (Critical risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Mint: Mintable; Liquidity lock: Not locked; Upgradeability: Upgradeable; Honeypot: None found; Buy / sell tax: 0% / 0%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is AUSD liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $52.05M.

Who holds AUSD?

As of Sep 4, 2026, the 10 largest holders own 88.8% of the supply. The Holders section on this page shows who they are by holder type.

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 Is this your token? Publish your own audit on this page