Quantum Audit Logo
Launch App

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

Is Global Dollar Safe?

USDGEthereum
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
Chart
High RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical4/10Governance3/10Upgrades1/10Checks passed3 of 7Findings1 Critical · 1 High · 1 Medium · 1 Low · 1 Info5
SummaryAI Copilot

The USDG contract implements an upgradeable ERC-20 token with a claimable rewards system.

Read the full analysis
What raised the score
  • Ownership not renounced — Timelock 24h delay
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract
  • Top-10 concentration > 50%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced — Timelock 24h delay
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 50% (73.2% total → 66.0% effective; 61.1% in EOAs, 12.1% in contracts — heavy)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 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

Security Checklist

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

Holders

as of audit · Sep 4, 2026
12.1%Contracts61.1%Wallets26.8%Everyone else
12.1%61.1%Wallets26.8%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
73.2%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking12.1%
  • Walletsanonymous holders, free to sell61.1%
  • Everyone elsethe rest of the supply26.8%
Effective concentrationwhat the score reads66.0%
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$24.75M across 11 pairs
Show 4 more pairs

One more pair holds $43 and is not listed. The risk score reads depth across every pair.

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$20.03MShare of depth80.9%
Top-1 Unlocked Holder25.2%
Top-3 Unlocked56.1%
Unlocked LP held by
0x84db…2fb50xa055…99bb0x91ae…5aff0x7774…12880xfaa8…0f5b0x1b69…97c10xc984…d9140x3d41…b5790xfa68…abbc0xafa0…7eff

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

Security Findings

1 Critical1 High1 Medium1 Low1 Info
Critical

Potential for uint64 Balance Overflow/Truncation

The contract uses uint64 for balance and shares within TokenAccountData and PayoutGroupData. This is highly unusual for an ERC-20 token, which typically uses uint256. A uint64 variable can only hold values up to 2^64 - 1 (approximately 1.8 * 10^19). Given the token has 6 decimals, this implies a maximum total supply or individual balance of approximately 1.8 * 10^13 USDG. If the total supply or any account's balance exceeds this limit, an overflow could occur. The behavior of StorageLib.toUint64Balance and StorageLib.toUint64Shares is critical here; if they truncate values rather than reverting on overflow, it could lead to silent loss of funds or incorrect accounting.C-01

Issue

The contract uses uint64 for balance and shares within TokenAccountData and PayoutGroupData. This is highly unusual for an ERC-20 token, which typically uses uint256. A uint64 variable can only hold values up to 2^64 - 1 (approximately 1.8 * 10^19). Given the token has 6 decimals, this implies a maximum total supply or individual balance of approximately 1.8 * 10^13 USDG. If the total supply or any account's balance exceeds this limit, an overflow could occur. The behavior of StorageLib.toUint64Balance and StorageLib.toUint64Shares is critical here; if they truncate values rather than reverting on overflow, it could lead to silent loss of funds or incorrect accounting.

Fix

Re-evaluate the decision to use uint64 for balances. If uint64 is strictly necessary for gas optimization or other reasons, ensure that StorageLib.toUint64Balance and StorageLib.toUint64Shares explicitly revert on overflow. Implement robust checks before any operation that could push a uint64 balance beyond its maximum value. Consider migrating to uint256 for balances if the potential scale of the token could exceed uint64 limits.

Status

Unresolved

High

Unused/Deprecated Storage Variables

The BaseStorageV3 contract contains multiple explicitly named deprecated storage variables (e.g., assetProtectionRoleDeprecated, supplyControllerDeprecated, proposedOwnerDeprecated, betaDelegateWhitelisterDeprecated, nextSeqsDeprecated, EIP712_DOMAIN_HASH_DEPRECATED, DOMAIN_SEPARATOR_DEPRECATED). While __gap variables are used for future compatibility, the presence of these named deprecated variables can lead to confusion, potential misuse if not properly documented and guarded, or storage collisions if not carefully managed during future upgrades. This increases the risk of errors during maintenance or upgrades.H-01

Issue

The BaseStorageV3 contract contains multiple explicitly named deprecated storage variables (e.g., assetProtectionRoleDeprecated, supplyControllerDeprecated, proposedOwnerDeprecated, betaDelegateWhitelisterDeprecated, nextSeqsDeprecated, EIP712_DOMAIN_HASH_DEPRECATED, DOMAIN_SEPARATOR_DEPRECATED). While __gap variables are used for future compatibility, the presence of these named deprecated variables can lead to confusion, potential misuse if not properly documented and guarded, or storage collisions if not carefully managed during future upgrades. This increases the risk of errors during maintenance or upgrades.

Fix

Clearly document the status and purpose of all deprecated variables. Ideally, remove truly unused deprecated variables from the storage layout in a controlled upgrade, ensuring no storage collisions. If they must remain for historical reasons, ensure they are explicitly marked as immutable and cannot be written to or read in a misleading way by new logic. Consider using a dedicated DeprecatedStorage contract or library to isolate such variables.

Status

Unresolved

Medium

Centralized Control Over Token Operations

The contract implements pausing functionality (_isPaused) and address freezing (_isAddrFrozen, _setFrozen), controlled by privileged roles (e.g., DEFAULT_ADMIN_ROLE). While common for stablecoins to enable emergency responses to security incidents or regulatory requirements, this introduces significant centralization risk. Privileged roles have the ability to halt all transfers or freeze specific user funds, which could be exploited or misused.M-01

Issue

The contract implements pausing functionality (_isPaused) and address freezing (_isAddrFrozen, _setFrozen), controlled by privileged roles (e.g., DEFAULT_ADMIN_ROLE). While common for stablecoins to enable emergency responses to security incidents or regulatory requirements, this introduces significant centralization risk. Privileged roles have the ability to halt all transfers or freeze specific user funds, which could be exploited or misused.

Fix

Ensure that the roles controlling these centralized functions are secured by multi-signature wallets and/or Timelocks with appropriate delays. Clearly document the conditions under which these functions would be invoked and the process for their activation and deactivation. Consider implementing a community-driven governance mechanism for critical actions if feasible for the project's roadmap.

Status

Unresolved

Low

Complexity of Multiplier and Payout Logic

The ClaimableRewardsBase contract includes functions such as _getMultiplierAtTime and _updatePayoutGroupBals, which rely on MultiplierGrowthLib and involve complex arithmetic for time-dependent calculations and payout adjustments. While the full implementation of MultiplierGrowthLib.projectMultiplier is not provided, complex financial logic is inherently prone to subtle errors, especially when dealing with multiple parameters, time, and rates.L-01

Issue

The ClaimableRewardsBase contract includes functions such as _getMultiplierAtTime and _updatePayoutGroupBals, which rely on MultiplierGrowthLib and involve complex arithmetic for time-dependent calculations and payout adjustments. While the full implementation of MultiplierGrowthLib.projectMultiplier is not provided, complex financial logic is inherently prone to subtle errors, especially when dealing with multiple parameters, time, and rates.

Fix

Conduct extensive unit and integration testing for all multiplier and payout calculation logic, covering edge cases, boundary conditions, and various time scenarios. Consider formal verification or a mathematical proof of correctness for the core MultiplierGrowthLib functions to ensure their integrity and accuracy under all conditions.

Status

Unresolved

Info

Extensive Inheritance Hierarchy

The USDG contract inherits from a large number of parent contracts: PaxosTokenClaimableRewards, UUPSUpgradeable, ClaimableRewardsBase, BaseStorageV3, AccessControlDefaultAdminRulesUpgradeable, ClaimableRewardsStorageV3, ClaimableRewardsEvents, and TokenAdminEvents. While modularity is beneficial, such a deep and broad inheritance hierarchy can increase code complexity, make it harder to trace logic and state changes, and potentially introduce unexpected interactions or subtle bugs between parent contracts.I-01

Issue

The USDG contract inherits from a large number of parent contracts: PaxosTokenClaimableRewards, UUPSUpgradeable, ClaimableRewardsBase, BaseStorageV3, AccessControlDefaultAdminRulesUpgradeable, ClaimableRewardsStorageV3, ClaimableRewardsEvents, and TokenAdminEvents. While modularity is beneficial, such a deep and broad inheritance hierarchy can increase code complexity, make it harder to trace logic and state changes, and potentially introduce unexpected interactions or subtle bugs between parent contracts.

Fix

Ensure comprehensive documentation and clear architectural diagrams are maintained to explain the contract's structure, inheritance flow, and state variable ownership. Conduct thorough reviews to ensure there are no unintended method overrides or storage collisions due to the complex inheritance. Consider refactoring to reduce the depth or breadth of inheritance if it becomes a significant maintenance burden.

Status

Unresolved

Analysis

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

The USDG contract implements an upgradeable ERC-20 token with a claimable rewards system. It leverages OpenZeppelin's UUPS proxy pattern and AccessControl for robust role management. A critical finding is the use of uint64 for token balances, which introduces a hard limit on total supply and individual balances, posing a significant risk of overflow and fund loss if not meticulously managed. Additionally, deprecated storage variables and centralized control mechanisms warrant attention.

Technical4/10Medium risk

The contract utilizes a modular architecture with clear separation of storage and logic, inheriting from OpenZeppelin's AccessControlDefaultAdminRulesUpgradeable for robust role management (7.1, 7.3). However, a significant technical risk is the use of uint64 for token balances and shares, which could lead to overflows and fund loss if balances exceed ~1.8e13 USDG (7.2). Additionally, the presence of numerous deprecated storage variables in BaseStorageV3 creates potential for storage collisions or confusion during future upgrades (7.7).

Governance3/10High risk

The protocol benefits from a strong governance setup, with the DEFAULT_ADMIN_ROLE controlled by a Timelock, enhancing operational security and decentralization of critical actions (7.5, 7.8). However, the contract retains centralized control mechanisms such as pausing transfers and freezing individual addresses, which, while common for stablecoins, introduces a single point of control over user funds (7.4). The economic model includes a complex multiplier and payout system, which requires thorough validation to prevent calculation errors (7.4).

Upgrades1/10High risk

The contract employs the UUPS upgradeable proxy pattern, with upgrade authorization strictly limited to the DEFAULT_ADMIN_ROLE, ensuring controlled and secure upgrades (7.7). The use of __gap variables in storage contracts demonstrates an awareness of upgrade safety. However, the presence of explicitly named deprecated storage variables in BaseStorageV3 could complicate future storage layout management and potentially lead to storage collisions if not handled with extreme care during subsequent upgrades (7.7).

Final RecommendationWhat to do about this score

Prioritize a thorough review of the uint64 balance implementation, especially the StorageLib.toUint64Balance function, to ensure it handles potential overflows by reverting rather than truncating.

Evaluate the maximum expected total supply and individual balances to confirm uint64 is sufficient for the project's long-term scale. Address all deprecated storage variables by either removing them entirely if unused (ensuring no storage collisions) or clearly documenting their status and ensuring they cannot be accidentally re-used in future upgrades. Strengthen documentation around the centralized control mechanisms and the complex multiplier logic.

Contract & Record

1 audit on record
TypeERC1967Proxy
NetworkEthereum
Token age11mo
Contract0xe343…491d
Deployer0x4b39…6ae5
Proxy Upgrade Controls
Proxy TypeEip1967 Uups
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
Global Dollar 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 2, 202681High

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

Related Audits

6 more on the recordAll audits
BigShortBetsBIGSB · Ethereum81HighFrankencoinZCHF · Ethereum81HighHeyAnonANON · Ethereum81HighKyber Network Crystal v2KNC · Ethereum81HighRe Protocol reUSDREUSD · Ethereum82HighRallyEthereum80High

Would You Like a More Detailed Audit of Global Dollar?

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