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.

On-chain security analysis — is it a scam or legit?
Is AUSD Safe?
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 →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- 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 4Holders
as of audit · Sep 4, 2026- Contractstreasury, vesting, bridge, staking46.7%
- Walletsanonymous holders, free to sell42.0%
- Everyone elsethe rest of the supply11.2%
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- 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 LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.
0x491e…a44e0x0dcd…a1530xc6dc…40a60x8b94…aaf50xde51…a29fNo privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
Security Findings
CriticalCentralized 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
HighIncomplete 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
MediumStorage 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
MediumDenial 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
LowCompiler 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
InfoRedundant 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
proxyAdminAddress() in ImplementationIssue
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 4The 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).
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).
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).
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
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
- 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