Quantum Audit Logo

Is Global Dollar Safe?

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

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

Global Dollar USDG
0xe343…491d
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

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.

1 Critical1 High1 Medium1 Low1 Informational
Volume 24h
$4.64M
Liquidity
$20.03M
Price
$1.0002
Token Age
11mo
Top 10 Holders
73.2%

Security Findings

1 Crit1 High1 Med1 Low1 Info
Critical

Potential for `uint64` Balance Overflow/Truncation

C-01The 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.
IssueThe 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.
FixRe-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.
StatusUnresolved
High

Unused/Deprecated Storage Variables

H-01The `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.
IssueThe `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.
FixClearly 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.
StatusUnresolved
Medium

Centralized Control Over Token Operations

M-01The 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.
IssueThe 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.
FixEnsure 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.
StatusUnresolved
Low

Complexity of Multiplier and Payout Logic

L-01The `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.
IssueThe `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.
FixConduct 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.
StatusUnresolved
Info

Extensive Inheritance Hierarchy

I-01The `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.
IssueThe `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.
FixEnsure 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.
StatusUnresolved

Category Ratings

TechnicalMedium4/10

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

GovernanceHigh3/10

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

UpgradesHigh1/10

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

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

73.2% in top 10
61.1% in wallets12.1% in contracts
Effective Concentration66.0%

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

$24.75M across 11 pairs
Curve stblUSDCanalysed$20.03M80.9%Uniswap v4USDC$1.52M6.1%Uniswap v4USDC$1.33M5.4%Uniswap v4USDC$1.03M4.1%Uniswap v4USDT$665.4K2.7%Uniswap v4USDC$126.1K0.5%
Show 4 more pairsShow less
Uniswap v3USDC$29.0K0.1%Uniswap v4USDT$18.1K0.1%Balancer v3USDC$4.9K0.0%BalancerUSDC$2.0K0.0%

One more pair holds $43 and is not listed.

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 Holder25.2%
Top-3 Unlocked56.1%

Key Addresses

11 addresses
Deployer
0x4b39…6ae5
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.

What Raised This Score

9 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

Related Audits

6 more on the record
BigShortBets (BIGSB)Critical RiskFrankencoin (ZCHF)Critical RiskRe Protocol reUSD (REUSD)Critical RiskRallyCritical RiskTurtleCritical RiskSyrup Token (SYRUP)Critical Risk

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