PAX Gold PAXG

Claim: No public cryptographic inventory or quantum threat model has been published by Paxos for PAXG.

Coverage basis: Absence of documentation confirmed by exhaustive search of paxos.com, GitHub repositories, Etherscan, and all official PAXG materials.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical uncertainty · Score treatment: score-reducing

Quantum blocker: No public cryptographic inventory: Readiness & Risk Cap 10.

Assurance: Absence of a cryptographic inventory is confirmed with high confidence through comprehensive review of all official Paxos channels. This is a quantum-critical uncertainty because without an inventory, the full attack surface cannot be verified.

Per QRI Section 9.1, this subfactor applies to designs that started out vulnerable. PAXG inherited Ethereum's ECDSA vulnerability and added token-specific admin key vulnerabilities. No PQ-native exemption applies.

• https://github.com/paxosglobal/paxos-gold-contract
• https://www.paxos.com/pax-gold
• https://www.paxos.com/terms-and-conditions/pax-gold-terms-conditions

Claim: No quantum-specific evidence record (code references, specs, audits, transaction analytics) has been published by Paxos.

Coverage basis: Absence confirmed through search of all official Paxos repositories and documentation.

Implementation score: 0 · Evidence confidence: High

Issue classification: assurance-only caveat · Score treatment: score-reducing

Assurance: While no quantum-specific evidence record exists, the classical code and audits are publicly available and verified. The absence of quantum assessment reduces the Implementation Score to 0.00 for this subfactor.

• https://github.com/paxosglobal/paxos-gold-contract

Claim: All PAXG token-specific spend authorization — including admin functions (mint, burn, freeze, wipe, upgrade, pause) and user delegated transfers (betaDelegatedTransfer) — relies exclusively on Ethereum's native ECDSA (secp256k1) via msg.sender checks and ecrecover.

Coverage basis: Source code analysis of PAXGImplementation.sol and AdminUpgradeabilityProxy at 0x45804880De22913dAFE09f4980848ECE6EcbAf78. User ERC-20 transfers inherit Ethereum L1 ECDSA per QRI Section 7.2.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: All PAXG admin spend authorization is ECDSA-only. A quantum adversary could forge admin signatures to mint, burn, freeze, wipe, or upgrade.

Assurance: Source code verified on Etherscan. Classical audits (ChainSecurity, CertiK) confirm contract correctness but contain no quantum analysis. The quantum vulnerability is directly observable from public code and on-chain transaction history.

User ERC-20 transfer/approve authorization is inherited from Ethereum L1 and not separately scored here per token inheritance rules. This subfactor score reflects token-specific admin authorization paths only. betaDelegatedTransfer uses ecrecover for ECDSA recovery — another quantum-vulnerable path.

• https://etherscan.io/token/0x45804880de22913dafe09f4980848ece6ecbaf78
• https://github.com/paxosglobal/paxos-gold-contract/blob/master/contracts/PAXGImplementation.sol

Claim: All PAXG admin role addresses (owner, supplyController, assetProtectionRole, feeController) are standard Ethereum EOAs. These addresses have transacted on-chain (contract deployment, initialization, supply operations, Set events), permanently exposing their secp256k1 public keys.

Coverage basis: On-chain transaction history at Etherscan shows the contract creator (0x36C2E652...) deployed the proxy. Admin role addresses are readable from contract storage and have emitted events requiring on-chain transactions. Standard Ethereum address model provides no key-rotation mechanism without abandoning the address.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Admin public keys are long-exposure (permanently visible on-chain). No key-rotation mechanism exists. Quantum attack can be performed offline with no time constraint.

Assurance: Long-exposure classification is confirmed by the fact that admin addresses have emitted on-chain events (SupplyControllerSet, OwnershipTransferProposed, AdminChanged, Upgraded) requiring transactions that expose public keys. User account exposure is inherited from Ethereum L1.

Per QRI Section 7.3, long-exposure (at-rest) attack surfaces represent the most immediate quantum risk. Admin key exposure is structural: the contract cannot function without admin transactions, and each admin transaction permanently exposes the sender's public key.

• https://etherscan.io/token/0x45804880de22913dafe09f4980848ece6ecbaf78
• https://etherscan.io/address/0x45804880de22913dafe09f4980848ece6ecbaf78

Claim: PAXG is an ERC-20 token with no independent consensus mechanism.

Coverage basis: N/A — token architecture has no validator set, no consensus protocol, no VRF, no block production.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

• https://github.com/paxosglobal/paxos-gold-contract

Claim: PAXG token state (balances, allowances, frozen status) relies on Ethereum L1 state integrity. Token-specific state-integrity is protected by the proxy admin key (ECDSA), which controls contract upgrades. There are no KZG/pairing-based commitments in the PAXG contract.

Coverage basis: Source code analysis. The AdminUpgradeabilityProxy allows the admin to change the implementation contract. The PAXGImplementation contains no custom cryptographic commitments, accumulators, or ZK proof systems.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Proxy upgrade is controlled by an ECDSA-only admin key. A quantum adversary could upgrade the contract to a malicious implementation, compromising all token state integrity.

Assurance: No KZG ceremonies, pairing-based proofs, or data-availability sampling dependencies exist in PAXG. The state-integrity risk is limited to the proxy admin key compromise vector.

PAXG's simple ERC-20 design avoids many complex state-integrity risks (no nullifiers, no accumulators, no ZK circuits). However, the proxy upgradeability introduces a quantum-vulnerable state-integrity path.

• https://etherscan.io/token/0x45804880de22913dafe09f4980848ece6ecbaf78
• https://github.com/paxosglobal/paxos-gold-contract/blob/master/contracts/PAXGImplementation.sol

Claim: PAXG has no privacy layer, shielded transactions, ZK proofs, note encryption, viewing keys, or stealth addresses.

Coverage basis: Source code and documentation confirm PAXG is a standard transparent ERC-20 token with no privacy features.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

• https://github.com/paxosglobal/paxos-gold-contract/blob/master/contracts/PAXGImplementation.sol

Claim: PAXG is an ERC-20 token with no independent P2P network.

Coverage basis: N/A — token architecture has no P2P layer.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Claim: No public evidence exists that Paxos uses quantum-resistant HSMs, multisig, or custody solutions for PAXG admin keys. Admin key management is opaque.

Coverage basis: No public documentation, attestation, or audit of Paxos's admin key custody for PAXG. Paxos's newer token contracts documentation mentions multisig for admin roles, but the PAXG contract uses single-address roles with no on-chain multisig enforcement.

Implementation score: 0 · Evidence confidence: Very Low

Issue classification: quantum-critical uncertainty · Score treatment: score-reducing

Quantum blocker: Paxos's admin key custody practices are not publicly verifiable. No evidence of PQ-resistant HSM or multisig protection for PAXG admin keys.

Assurance: Evidence confidence is Very Low because Paxos's internal key management is opaque. The PAXG contract's on-chain roles are single-address (no on-chain multisig), though Paxos could use off-chain multisig via contract-level coordination. This uncertainty cannot be resolved from public evidence.

Paxos's newer token contracts (paxos-token-contracts repo, v2.1.0 from Jan 2026) state admin roles 'utilize multisignature contracts.' However, the PAXG contract (deployed ~2019, Solidity 0.4.24) pre-dates this architecture and uses single-address admin roles. It is unclear whether PAXG benefits from the same multisig infrastructure. Even if multisig is used, signers would still use ECDSA keys.

• https://github.com/paxosglobal/paxos-token-contracts

Claim: 0% of PAXG value-at-risk is quantum-protected. All ~$100M+ market cap is on Ethereum with ECDSA-only protection for both user transactions (inherited) and admin keys (token-specific).

Coverage basis: Etherscan shows 470,301 total transfers, ~$100M+ market cap. No PQ protection exists at any layer. Admin keys control the entire supply.

Implementation score: 0.05 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: 0% value-at-risk protected. Readiness & Risk Cap for <25% coverage: score 1/20 for the subfactor.

Assurance: Market cap data from Etherscan/Ethplorer as of evaluation date. Value-at-risk includes the entire circulating supply plus the integrity of the gold backing, which depends on admin key security.

Per QRI Section 9.3.1, <25% coverage receives a subfactor score of 1 (out of 20 subfactor weight). Since the Implementation Score is 0.05 (1/20), the subfactor contribution is 1. PAXG is not PQ-native and has no classical ownership namespace exemption.

• https://etherscan.io/token/0x45804880de22913dafe09f4980848ece6ecbaf78

Claim: No PAXG admin wallets (owner, supplyController, assetProtectionRole) have been migrated to PQ protection. No evidence of quantum-resistant custody for any critical Paxos-controlled wallet.

Coverage basis: Absence of any PQ migration evidence for PAXG admin keys confirmed through all official sources.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: No admin wallets migrated to PQ protection. Critical treasury/admin keys remain ECDSA-only.

Assurance: Paxos is a regulated trust company (OCC-regulated) and likely uses institutional-grade custody, but there is zero public evidence of quantum-resistant protection for PAXG admin keys.

• https://www.paxos.com/pax-gold
• https://github.com/paxosglobal/paxos-gold-contract

Claim: No legacy vulnerable pools have been identified, measured, deprecated, frozen, or migrated by Paxos for quantum-security purposes.

Coverage basis: Absence of any quantum-specific deprecation or measurement of vulnerable accounts confirmed through all official sources.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical uncertainty · Score treatment: score-reducing

Assurance: The absence of quantum-specific legacy pool identification is clearly evidenced. This is primarily a preparedness gap reflecting the project's overall lack of quantum attention.

PAXG does have a freeze/wipe mechanism (assetProtectionRole) that could theoretically be used for quantum-related asset protection, but this mechanism itself is quantum-vulnerable (ECDSA-only).

Claim: No public quantum migration or protection roadmap exists for PAXG.

Coverage basis: Absence confirmed through exhaustive search of all Paxos official channels, documentation, and repositories.

Implementation score: 0 · Evidence confidence: High

Issue classification: assurance-only caveat · Score treatment: score-reducing

Assurance: This is scored as assurance-only because while the absence of a roadmap creates uncertainty about future migration, it does not independently create a new quantum attack path beyond those already identified. The score reduction is through the normal Implementation Score mechanism.

Roadmaps are not production protection per QRI. Score reflects complete absence of any quantum migration planning.

• https://www.paxos.com/pax-gold
• https://github.com/paxosglobal/paxos-gold-contract

Claim: No PQ/hybrid account creation, wallet tooling, transaction paths, custody paths, user-facing warnings, education, or migration prompts exist for PAXG.

Coverage basis: Absence confirmed. PAXG relies entirely on standard Ethereum wallets and tooling with no quantum-specific features.

Implementation score: 0 · Evidence confidence: High

Issue classification: operational/product caveat · Score treatment: score-reducing

Assurance: This is an operational gap that reflects the complete absence of quantum migration infrastructure. While it does not independently create a new attack path, it means users have no tools to protect themselves even if they wanted to.

For PAXG user transactions, migration accessibility is tied to Ethereum L1's capabilities. Token-specific admin migration would require Paxos to deploy PQ-protected admin mechanisms, which is not planned or designed.

• https://www.paxos.com/pax-gold

Claim: No enforcement mechanisms exist for PAXG quantum migration. No deprecation, freeze, disabled legacy signing, restricted withdrawals, or mandatory migration deadlines have been proposed.

Coverage basis: Absence confirmed through all official sources.

Implementation score: 0 · Evidence confidence: High

Issue classification: operational/product caveat · Score treatment: score-reducing

Assurance: The existing freeze mechanism (assetProtectionRole) could theoretically be repurposed for quantum-related enforcement, but this mechanism is itself quantum-vulnerable, creating a circular dependency.

Paxos's centralized control model could theoretically enable rapid migration enforcement (via contract upgrade and freeze powers), but the absence of any plan or public commitment means this cannot be scored as migration readiness.

Claim: No quantum-specific emergency disclosure, incident-response, or governance process has been published by Paxos for PAXG.

Coverage basis: Absence confirmed through all official sources. Paxos has a general security contact ([email protected] for newer tokens) but no quantum-specific process.

Implementation score: 0 · Evidence confidence: High

Issue classification: assurance-only caveat · Score treatment: score-reducing

Assurance: Per QRI Section 8.2, the absence of a formal quantum-specific incident-response playbook does not by itself create a Readiness & Risk Cap. It is scored here through the normal subfactor mechanism.

Paxos's newer token contracts (paxos-token-contracts) include a @custom:security-contact annotation. The PAXG contract (v0.4.24, older) does not include this. Even if a security contact exists, no quantum-specific process has been published.

• https://github.com/paxosglobal/paxos-token-contracts

Claim: PAXG uses no post-quantum cryptography. All authorization relies on Ethereum's native ECDSA (secp256k1).

Coverage basis: Source code analysis confirms complete absence of any PQC algorithms, hybrid-PQC constructions, or non-standard quantum-resistant primitives.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: No PQC or hybrid-PQC algorithms in use for any PAXG authorization path.

Assurance: The absence of PQC is trivially verifiable from public source code. Implementation Score of 0.00 is fully supported.

• https://github.com/paxosglobal/paxos-gold-contract/blob/master/contracts/PAXGImplementation.sol

Claim: No quantum-specific cryptographic audit exists for PAXG. Classical audits (ChainSecurity, CertiK) are from circa 2019–2020 and contain no quantum-threat analysis.

Coverage basis: Classical audits are referenced in the PAXG README but are stale and scope-mismatched. No PQ audit exists.

Implementation score: 0 · Evidence confidence: High

Issue classification: assurance-only caveat · Score treatment: score-reducing

Assurance: Classical audits are scope-mismatched for quantum. Since there is no PQ implementation to audit, the Implementation Score of 0.00 reflects the absence of any quantum-critical implementation rather than audit quality. If a PQ implementation existed, audit freshness would affect Confidence, not the QRI Score.

Audits referenced: ChainSecurity (PAXG-specific), CertiK (formal verification), Nomic Labs, ChainSecurity, and Trail of Bits (Paxos Standard, which PAXG is based on). All are classical-only.

• https://github.com/paxosglobal/paxos-gold-contract/blob/master/README.md

Claim: PAXG has no PQ implementation. The classical ERC-20 implementation is open-source and verified on Etherscan.

Coverage basis: This subfactor evaluates the openness of the PQ/hybrid-PQC implementation. Since no PQ implementation exists, it cannot receive credit.

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: score-reducing

Assurance: The classical implementation is open-source (MIT license) and verified. This subfactor would score higher if a PQ implementation existed and was similarly open. Currently scores 0.00 because there is no PQ implementation to be open-source.

The classical code quality and openness are good software practices but do not contribute to quantum readiness.

• https://github.com/paxosglobal/paxos-gold-contract
• https://etherscan.io/token/0x45804880de22913dafe09f4980848ece6ecbaf78

Claim: No documented parameter agility or PQ upgrade path exists for PAXG. The proxy upgrade mechanism provides a technical path but no planned PQ migration.

Coverage basis: The AdminUpgradeabilityProxy technically allows contract upgrades, but no PQ-specific upgrade path, parameter agility specification, or algorithm migration plan has been documented.

Implementation score: 0 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: score-reducing

Assurance: The proxy architecture provides a technical foundation for future PQ upgrades, but without any documented plan, algorithm selection, or parameter agility specification, this potential path does not constitute current quantum readiness.

A future Ethereum L1 PQ migration (e.g., account abstraction, PQ precompiles) could provide the infrastructure for PAXG admin key migration, but Paxos would still need to proactively migrate admin keys. No plan exists for this.

• https://github.com/paxosglobal/paxos-gold-contract/blob/master/contracts/PAXGImplementation.sol

Claim: PAXG uses no stateful PQ signatures (XMSS, LMS, SPHINCS+). This subfactor evaluates risks specific to stateful PQ schemes.

Coverage basis: N/A — no stateful PQ signatures are in use.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Claim: No performance or resource-impact analysis for PQ signature deployment has been published for PAXG.

Coverage basis: Absence confirmed through all official sources.

Implementation score: 0 · Evidence confidence: High

Issue classification: assurance-only caveat · Score treatment: score-reducing

Assurance: Per QRI Section 8.2, the absence of a formal performance benchmark does not by itself create a Readiness & Risk Cap. It is scored through the normal subfactor mechanism.

For PAXG admin transactions (infrequent mint/burn/freeze operations), PQ signature size and verification cost would likely be acceptable. For user ERC-20 transfers, PQ performance impact would be inherited from Ethereum L1's PQ migration.