Quantum Audit Logo
Launch App

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

Is PayPal USD Safe?

PYUSDEthereum
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
Technical5/10Governance1/10Upgrades1/10Checks passed1 of 5Findings2 High · 1 Medium · 1 Low · 1 Info5
SummaryAI Copilot

The audit covers the PYUSD token contract, an ERC-20 compatible stablecoin implementation utilizing an upgradeable proxy pattern.

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

Security Checklist

as of audit · Sep 41 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintMintable
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
24.4%Contracts63.6%Wallets12.0%Everyone else
24.4%Contracts63.6%Wallets12.0%
ContractsWalletsEveryone elseBubble area = share of supply
88.0%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking24.4%
  • Walletsanonymous holders, free to sell63.6%
  • Everyone elsethe rest of the supply12.0%
Effective concentrationwhat the score reads73.4%
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$140.87M across 19 pairs
Show 4 more pairs

The 9 remaining pairs hold $1.4K between them and are 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$100.15MShare of depth71.1%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x89d8…6b2a

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

Security Findings

2 High1 Medium1 Low1 Info
High

Centralized Control and Single Points of Failure

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

Issue

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

Fix

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

Status

Unresolved

High

Critical Reliance on External SupplyControl Contract

The 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.H-02

Issue

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

Fix

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

Status

Unresolved

Medium

Deprecated Storage Variables

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

Issue

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

Fix

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

Status

Unresolved

Low

Public initialize Function

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

Issue

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

Fix

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

Status

Unresolved

Info

Non-Standard Decimal Count (6 Decimals)

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

Issue

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

Fix

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

Status

Unresolved

Analysis

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

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.

Technical5/10Medium risk

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.

Governance1/10High risk

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.

Upgrades1/10High risk

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.

Final RecommendationWhat to do about this score

It is crucial to implement robust security measures for all privileged roles (DEFAULT_ADMIN_ROLE, PAUSE_ROLE, ASSET_PROTECTION_ROLE), ideally through multi-signature wallets or time-locked contracts, to mitigate the risks associated with centralized control.

A thorough audit and continuous monitoring of the external SupplyControl contract are essential, as its integrity directly impacts the token's supply mechanics. For future upgrades, carefully manage the deprecated storage variables to ensure no collisions occur and that the storage layout remains consistent.

Contract & Record

1 audit on record
TypeAdminUpgradeabilityProxy
NetworkEthereum
Token age6mo
Contract0x6c3e…a0e8
Deployer0x3b21…35db
Proxy Upgrade Controls
Proxy TypeZeppelin Os Legacy
AdminEOA (single key controls upgrades)
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
PayPal USD 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, 202672High
  2. Aug 11, 202671High

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

Related Audits

6 more on the recordAll audits
Agoras TokenAGRS · Ethereum72HighNEXOEthereum73HighCronosCRO · Ethereum73HighEpic ChainEPIC · Ethereum73HighDAPPOSDOS · Ethereum71HighICPEthereum71High

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