Quantum Audit Logo

Is PayPal USD Safe?

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

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

PayPal USD PYUSD
0x6c3e…a0e8
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The audit covers the PYUSD token contract, an ERC-20 compatible stablecoin implementation utilizing an upgradeable proxy pattern. The contract leverages OpenZeppelin's AccessControl for role-based permissions, enabling centralized control over critical functions such as pausing, freezing addresses, and managing token supply via an external `SupplyControl` contract. While the code quality is generally high and follows established patterns, the inherent centralization and reliance on external components introduce significant governance and economic risks. Upgradeability is well-structured, though the presence of deprecated storage variables warrants careful management.

2 High1 Medium1 Low1 Informational
Volume 24h
$51.57M
Liquidity
$100.15M
Price
$1.0001
Token Age
6mo
Top 10 Holders
88.0%

Security Findings

2 High1 Med1 Low1 Info
High

Centralized Control and Single Points of Failure

H-01The contract design grants significant power to several privileged roles. The `DEFAULT_ADMIN_ROLE` can set the `supplyControl` contract, which governs minting and burning. The `ASSET_PROTECTION_ROLE` can freeze/unfreeze addresses and wipe their balances, directly affecting user funds. The `PAUSE_ROLE` can halt all token transfers. This high degree of centralization, while common for stablecoins, creates multiple single points of failure where the compromise or misuse of any associated private key could lead to severe financial losses or operational disruption.
IssueThe contract design grants significant power to several privileged roles. The `DEFAULT_ADMIN_ROLE` can set the `supplyControl` contract, which governs minting and burning. The `ASSET_PROTECTION_ROLE` can freeze/unfreeze addresses and wipe their balances, directly affecting user funds. The `PAUSE_ROLE` can halt all token transfers. This high degree of centralization, while common for stablecoins, creates multiple single points of failure where the compromise or misuse of any associated private key could lead to severe financial losses or operational disruption.
FixImplement multi-signature wallets or time-locked contracts for all privileged roles (DEFAULT_ADMIN_ROLE, PAUSE_ROLE, ASSET_PROTECTION_ROLE) to introduce a higher level of security and prevent single points of failure. Clearly document the responsibilities and operational procedures for each role.
StatusUnresolved
High

Critical Reliance on External `SupplyControl` Contract

H-02The `increaseSupplyToAddress` and `decreaseSupplyFromAddress` functions (minting and burning logic) delegate critical permission checks to an external `supplyControl` contract. The security and correct configuration of this external contract are paramount. If the `supplyControl` contract is compromised, misconfigured, or contains vulnerabilities, it could allow unauthorized minting, burning, or manipulation of the token supply, leading to a loss of peg or trust.
IssueThe `increaseSupplyToAddress` and `decreaseSupplyFromAddress` functions (minting and burning logic) delegate critical permission checks to an external `supplyControl` contract. The security and correct configuration of this external contract are paramount. If the `supplyControl` contract is compromised, misconfigured, or contains vulnerabilities, it could allow unauthorized minting, burning, or manipulation of the token supply, leading to a loss of peg or trust.
FixEnsure the `SupplyControl` contract itself undergoes rigorous security audits and is managed with the highest security standards. Implement robust monitoring for any changes or suspicious activity related to the `SupplyControl` contract. Consider implementing circuit breakers or emergency mechanisms in the main token contract to mitigate risks if the `SupplyControl` contract becomes compromised.
StatusUnresolved
Medium

Deprecated Storage Variables

M-01The `BaseStorage` contract contains numerous `Deprecated` variables (e.g., `ownerDeprecated`, `assetProtectionRoleDeprecated`, `supplyControllerDeprecated`). While the `__gap_BaseStorage` array is correctly used for upgradeability, the presence of these deprecated variables indicates past storage layout changes. Without careful management, this could lead to confusion, unintended interactions, or potential storage collisions in future upgrades if not properly accounted for, especially if these slots were previously active and their data needs to be explicitly handled or discarded.
IssueThe `BaseStorage` contract contains numerous `Deprecated` variables (e.g., `ownerDeprecated`, `assetProtectionRoleDeprecated`, `supplyControllerDeprecated`). While the `__gap_BaseStorage` array is correctly used for upgradeability, the presence of these deprecated variables indicates past storage layout changes. Without careful management, this could lead to confusion, unintended interactions, or potential storage collisions in future upgrades if not properly accounted for, especially if these slots were previously active and their data needs to be explicitly handled or discarded.
FixMaintain clear documentation of all storage layout changes, including the purpose and fate of deprecated variables. During future upgrades, meticulously verify the storage layout to ensure no collisions occur with current or future variables. Consider explicitly clearing or zeroing out deprecated storage slots if their data is no longer relevant to prevent accidental re-use or misinterpretation.
StatusUnresolved
Low

Public `initialize` Function

L-01The `initialize` function is declared as `public`. While the `_getInitializedVersion()` and `_initialize()` logic from OpenZeppelin's `Initializable` pattern prevents re-initialization, making it safe, it is generally a best practice to restrict access to `initialize` to prevent accidental calls or to make its purpose clearer. In a proxy setup, `initialize` is typically called only once by the proxy admin.
IssueThe `initialize` function is declared as `public`. While the `_getInitializedVersion()` and `_initialize()` logic from OpenZeppelin's `Initializable` pattern prevents re-initialization, making it safe, it is generally a best practice to restrict access to `initialize` to prevent accidental calls or to make its purpose clearer. In a proxy setup, `initialize` is typically called only once by the proxy admin.
FixConsider adding an `onlyProxyAdmin` or similar modifier to the `initialize` function if it's intended to be called exclusively by the proxy administrator, or if the `_initialize` function itself doesn't already restrict access sufficiently. This improves clarity and reduces the attack surface, even if the current implementation is functionally safe.
StatusUnresolved
Info

Non-Standard Decimal Count (6 Decimals)

I-01The PYUSD token uses 6 decimals, which is a non-standard choice for many ERC-20 tokens, where 18 decimals are most common (e.g., ETH, USDC, USDT). While this is a design decision and not a vulnerability in the contract itself, it can lead to compatibility issues or unexpected behavior when interacting with DeFi protocols, exchanges, or wallets that are primarily designed or assume 18-decimal tokens. Users and integrators must be explicitly aware of this difference.
IssueThe PYUSD token uses 6 decimals, which is a non-standard choice for many ERC-20 tokens, where 18 decimals are most common (e.g., ETH, USDC, USDT). While this is a design decision and not a vulnerability in the contract itself, it can lead to compatibility issues or unexpected behavior when interacting with DeFi protocols, exchanges, or wallets that are primarily designed or assume 18-decimal tokens. Users and integrators must be explicitly aware of this difference.
FixEnsure all documentation, user interfaces, and integration guides prominently highlight that PYUSD uses 6 decimals. Developers integrating with PYUSD should be advised to explicitly handle the decimal conversion to avoid precision errors or miscalculations.
StatusUnresolved

Category Ratings

TechnicalMedium5/10

The technical implementation (7.2 Code Security) demonstrates good practices, utilizing Solidity 0.8.x for automatic overflow/underflow checks and custom errors for robust handling. Standard ERC-20 functions are correctly implemented, and batch operations are included. However, a significant technical risk (7.6 External) arises from the reliance on the external `SupplyControl` contract for minting and burning permissions, making its security and configuration paramount. The use of `unchecked` blocks for loop increments in batch functions is a minor gas optimization.

GovernanceHigh1/10

The contract exhibits a high degree of centralization (7.5 Governance, 7.4 Economic), which is typical for a stablecoin but represents a significant risk. The `DEFAULT_ADMIN_ROLE` can change the `SupplyControl` contract, effectively controlling minting and burning. The `ASSET_PROTECTION_ROLE` has the power to freeze addresses and wipe balances, directly impacting user funds. The `PAUSE_ROLE` can halt all token transfers. These powerful roles create single points of failure, where compromise of any associated private key could lead to severe economic consequences.

UpgradesHigh1/10

The contract is designed for upgradeability using an `AdminUpgradeabilityProxy` and adheres to OpenZeppelin's upgradeable patterns (7.7 Upgrades), including `_disableInitializers()` and `__gap` storage for future compatibility. It inherits from `AccessControlDefaultAdminRulesUpgradeable`, ensuring proper initialization and role management in an upgradeable context. However, the presence of numerous `Deprecated` storage variables in `BaseStorage` indicates a history of storage layout changes, requiring meticulous attention during future upgrades to prevent storage collisions or unexpected behavior.

Security Checklist

1/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeZeppelin Os Legacy
AdminEOA (single key controls upgrades)
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

88.0% in top 10
63.6% in wallets24.4% in contracts
Effective Concentration73.4%

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

$140.87M across 19 pairs
Uniswap v4USDSanalysed$100.15M71.1%Curve stblUSDC$39.33M27.9%Curve stblcrvUSD$1.09M0.8%Uniswap v3USDC$189.9K0.1%Uniswap v3USDT$45.4K0.0%Uniswap v4USDC$32.0K0.0%
Show 4 more pairsShow less
Uniswap v3USDT$26.4K0.0%Uniswap v4ZIK$5.8K0.0%Curve stblUSDC$8640.0%Curve stblDAI$8450.0%

The 9 remaining pairs hold $1.4K between them and are 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 Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

2 addresses
Deployer
0x3b21…35db
Unlocked LP Held By
0x89d8…6b2a

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

What Raised This Score

11 factors
  • Ownership NOT renounced — owner is an EOA (single private key)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Admin is EOA (single key controls upgrades)
  • Top-10 concentration > 70% (88.0% total → 73.4% effective; 63.6% in EOAs, 24.4% in contracts — extreme)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 71% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 71% of DEX liquidity)
  • 2 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
NEXOCritical RiskCronos (CRO)Critical RiskEpic Chain (EPIC)Critical RiskDAPPOS (DOS)Critical RiskICPCritical RiskAZTECCritical Risk

Would You Like a More Detailed Audit of PayPal USD?

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

Get Detailed Audit