Meridion Risk Assessment: PAX Gold (PAXG)

1. Methodology

1.1 Rating Standard and Assessment Framework

This report is produced under the Meridion Risk Rating Standard v1. The engagement was conducted by a team combining smart contract security specialists, financial risk analysts, and formal methods engineers.

Each independent domain receives a risk rating of Low, Medium, or High:

• Low applies when no material adverse condition was identified within the assessed scope and residual risks are ordinary for the asset type.
• Medium applies when a material weakness, dependency, opacity, concentration, or stress scenario exists but is contingent, mitigated, not currently causing holder harm, or primarily a future-risk driver.
• High applies when a direct or credible path exists to material holder loss, unauthorized issuance, severe depeg, impaired transferability, asset shortfall or misrepresentation, governance or administrator capture, or operational failure.

The composite risk rating is derived from the three domain ratings using the following labels:

• Minimal: all three domain ratings are Low, with no material identified weakness beyond ordinary residual risk for the asset type.
• Low: no domain rating reaches High, and at most one reaches Medium; any Medium condition is isolated or future-oriented, with no immediate consequence for holders.
• Moderate: no domain rating reaches High, but multiple domains carry a Medium rating, or one Medium domain carries direct consequence, structural importance, or meaningful interaction with another domain.
• Elevated: at least one domain rating reaches High, but the condition remains contingent, is not actively causing holder harm, and does not currently show immediate adverse consequences.
• High: immediate adverse consequences are present, or an identified High domain condition bears directly on holders.
• Severe: multiple domains are critically compromised, or a single compromised domain produces cascading failure across the asset.

Each domain and the composite conclusion also receive a confidence rating of Low, Medium, or High. Confidence measures the reliability, completeness, independence, recency, and reproducibility of the evidence supporting the risk rating. Confidence does not reduce or soften the risk rating; instead, it tells the reader how strongly the rating is supported and whether material scope limitations reduce certainty.

1.2 Review Techniques Applied

Smart Contracts: Functionality and security

• Runtime entry-point catalogue: reconstruction of the complete externally callable runtime surface from deployed bytecode and verified source artifacts
• Manual code review: line-by-line inspection of all in-scope source files by independent security specialists
• Edge-case and exploit-negative review: targeted analysis of protocol-specific invariants, failure modes, access-control boundaries, replay protections, and upgrade assumptions
• Formal verification: direct deployed-bytecode verification of hidden calldata surface, covering selectors outside the complete runtime catalogue and malformed calldata shorter than 4 bytes
• Fork-based behavioral testing: representative positive and negative cases exercised against deployed contract addresses on a fixed fork; these tests sample intended entry-point behavior and expected revert paths on the live bytecode, but are not exhaustive proofs over all input and state combinations
• AI-assisted analysis: automated pattern detection and anomaly scanning across the full codebase to supplement human review

Operations: Key management and administrative control

• Role mapping: reconstruction of deployment and administrative authority from on-chain state and historical events
• Key management review: assessment of HSM, MPC, and key ceremony controls based on SOC reports and public disclosures
• Monitoring and alerting: assessment of on-chain event alerting coverage and anomaly detection arrangements for privileged operations and administrative actions
• Recovery assessment: review of signer loss, compromise, and administrative recovery procedures

Financials: Underlying assets and counterparties

• Reserve attestation analysis: comparison of attestation disclosures against on-chain liabilities and supply metrics
• Counterparty profiling: identification of issuer, custodian, banking, and attestation dependencies and their risk posture
• Liquidity analysis: assessment of redemption capacity and market depth across DEX and CEX venues
• Scenario analysis: review of economic stress scenarios and their implications for solvency, redemptions, and price stability.

2. Executive Summary

Subject Overview

PAX Gold (PAXG) is a commodity-backed digital asset issued by Paxos Trust Company, LLC, in which each token represents exactly one fine troy ounce of an LBMA Good Delivery gold bar held in segregated, allocated custody at LBMA-accredited vaults in London. PAXG was approved by the New York Department of Financial Services on 5 September 2019. Paxos received conditional OCC approval on 12 December 2025 to convert to a national trust bank, subject to satisfying OCC conditions; final completed conversion was not independently confirmed in this assessment. Its principal use cases are gold price exposure, portfolio diversification, and DeFi collateral. PAXG is issued exclusively on Ethereum Mainnet by Paxos; non-Ethereum representations observed on Solana and Polkadot are third-party wrapped tokens not issued or backed by Paxos. At the assessment snapshot block 25042795 (2026-05-07), the on-chain total supply was 479,162.743 PAXG, representing a reserve value of approximately $2.262 billion at the prevailing spot price of $4,721.02 per troy ounce.

KYC Gating

Secondary-market holding of PAXG does not require KYC with Paxos; any Ethereum address may receive and hold PAXG without registering with the issuer. Minting is KYC-gated: direct creation of PAXG through Paxos requires passing Paxos KYC and AML onboarding and being an approved customer. Redemption for physical gold (minimum 430 PAXG per Good Delivery bar) or USD cash requires the same Paxos KYC approval. An on-chain freeze and balance-wipe mechanism exists in the contract, controlled by the assetProtectionRole (currently the EOA 0x3af3e85f4f97de7ad0f000b724fb77fe5ffc024b); this role can block all transfers to and from any address and permanently destroy the token balance held at a frozen address, reducing total supply. Paxos exercises this capability in response to OFAC sanctions lists and legal orders. Secondary-market transfers on DEX platforms and CEX exchanges are not gated by Paxos KYC directly, though CEX platforms impose their own KYC at the exchange level.

Overall Risk Rating: Low

Composite Confidence: Low

The composite Low rating reflects a single domain at Medium (operational security) under conditions that are contingent and not currently causing holder harm. The proxy admin, owner and asset-protection role, and supply controller are all confirmed bare externally owned accounts operating over approximately $2.262 billion in token value with no on-chain timelocks, no second-approval requirements, and no publicly disclosed key management controls such as HSM custody or MPC arrangements; however, no operational incident involving key compromise, unauthorised minting, or misuse of administrative authority has been recorded in six years of operation. The smart contract domain is rated Low: the deployed code is well-structured, FV-confirmed for hidden calldata surface, and presents only a single Low-severity finding (SEC-01). The financial domain is rated Low: PAXG's 1:1 gold-oz backing is structurally sound, and monthly KPMG LLP examination reports provide independent reserve support. Paxos's conditional OCC approval is a positive regulatory development, but it is not treated as a completed charter in this rating. Composite confidence is Low, driven by the absence of publicly disclosed key management evidence for the three confirmed highest-privilege EOA roles.

Smart Contract Security Summary

The smart contract review identified one Low-severity finding (SEC-01): an event-log bug in setBetaDelegateWhitelister where storage is written before the event is emitted, causing the oldWhitelister argument in the BetaDelegateWhitelisterSet event to reflect the new value rather than the previous holder. No on-chain funds are at risk; the finding affects only monitoring and audit-trail infrastructure. The upgrade proxy mechanics, access-control modifiers, signature replay protection for delegated transfers, supply accounting, and asset-protection functions are all correctly implemented. Formal verification of the deployed bytecode confirmed the complete absence of hidden selector-based trapdoors and malformed-calldata attack surfaces for both the proxy and the implementation. Fork-based behavioral tests covering all 57 required cases across both contracts passed at the assessment snapshot block, confirming that deployed bytecode behaves consistently with the reviewed source for representative positive and negative call paths.

Smart Contract Risk Score: Low | Confidence: High

Operational Security Summary

PAXG's operational security is rated Medium. The proxy admin (0xc94bcf6e1d8b3558e3b62e743630d50497e3851c) holds unilateral authority to replace the entire implementation contract in a single transaction with no timelock; it is a confirmed bare externally owned account with no deployed bytecode and no disclosed key management arrangement. The owner and asset-protection role are consolidated in a single EOA (0x3af3e85f4f97de7ad0f000b724fb77fe5ffc024b), which alone controls pause, freeze, and irreversible balance destruction over the full token supply. The supply controller (0x2fb074fa59c9294c71246825c1c9a0c7782d41a4) is also an EOA with unbounded, single-transaction minting authority and no on-chain approval gate. None of these roles carry a publicly disclosed key management policy. The fee controller function is the exception: it is held by a smart contract (0x0644bd0248d5f89e4f6e845a91d15c23591e5d33), reducing EOA concentration for fee operations. Confidence is Low because none of the highest-privilege EOAs have disclosed HSM or MPC custody, threshold controls, emergency workflow, or change-control procedures.

Opsec Risk Score: Medium | Confidence: Low

Financial Summary

PAXG's financial risk is rated Low. Each token is backed 1:1 by physical gold held in allocated, segregated LBMA vaults, eliminating fractional-reserve and maturity-mismatch risk inherent in fiat-backed stablecoins. Gold reserves are attested monthly by KPMG LLP under AICPA examination-level standards; the April 2026 report was confirmed available on the Paxos transparency page at assessment time. Paxos received conditional OCC approval on 12 December 2025 to convert to a national trust bank; the conditionally approved conversion is treated as positive but not as completed federal charter status for this assessment. The primary financial risk factors are: secondary market liquidity that is modest relative to total supply (conservative executable DEX depth of $55.7M versus $2.262B reserve value, ranking strongest among the three reviewed reports at approximately 2.46% of reserve value); the undisclosed allocation split between the two London custodians, Brink's Global Services Ltd. and ICBC Standard Bank Plc, preventing precise concentration assessment; and legal uncertainty over whether token holders can directly enforce property rights in specific bars rather than relying on contractual redemption rights against Paxos in an insolvency scenario. Confidence is Medium because the custodian allocation split between the two London vaults is undisclosed, preventing precise concentration assessment.

Financial Risk Score: Low | Confidence: Medium

Scope Limitations

• Non-Ethereum third-party wrapped representations: PAXG-derived tokens on Solana (Raydium IMT-PAXG) and Polkadot (Hydration) are third-party wrapped tokens and were excluded from scope. These do not create additional Paxos gold obligations and have no rating effect on the present assessment; they may carry independent smart-contract or bridge risk not assessed here. Confidence effect: none for this report.
• FeeController contract internals (0x0644bd0248d5f89e4f6e845a91d15c23591e5d33): The internal governance of the fee controller contract (signer structure, quorum, upgrade authority) was not assessed in this engagement. Given the limited severity of fee-rate manipulation, this is not expected to change the opsec domain rating. Confidence effect: reduces confidence in the fee-control sub-domain.

3. Part I: Smart Contract Security Analysis

Smart Contract Security Rating: Low | Confidence: High

3.1 Scope and Execution Environment

Chain: Ethereum Mainnet

Assessment snapshot block: 25042795 (2026-05-07)

Both contracts are verified on Blockscout. The proxy is an AdminUpgradeabilityProxy from the ZeppelinOS pre-EIP-1967 era, using keccak256-derived unstructured storage slots for the admin and implementation pointers. The implementation is PAXGImplementation, the single logic contract underpinning all PAXG token operations. Both contracts were compiled with Solidity 0.4.24, optimization enabled (200 runs), and the proxy with the byzantium EVM version. All addresses were verified against on-chain deployment artifacts.

3.2 Entry Point Catalogue

The entry-point catalogue was reconstructed from deployed bytecode and verified source artifacts. All 54 runtime-reachable ABI entries were covered (comparison script status: PASS, zero missing, zero duplicates). The catalogue serves as the exclusion set for hidden-surface formal verification.

Proxy contract entry points:

The proxy contract includes 2 additional functions that are not state-modifying (view): admin() (EP-PR-005) and implementation() (EP-PR-006).

Implementation contract entry points:

The implementation contract includes 22 additional functions that are not state-modifying (view or pure): EP-IM-027 through EP-IM-048.

Long function signatures in the table above are abbreviated as name(...) [N args], where N is the total parameter count.

3.3 Bytecode Surface Attestation

As capital held in on-chain assets grows, the Solidity compiler (solc) and deployment pipeline become increasingly attractive supply-chain attack targets. A compromised compiler, build process, or deployment artifact could insert hidden trap doors that are not visible in source-level review but are present in deployed bytecode. Meridion therefore separates bytecode assurance into two complementary controls: formal verification of hidden calldata surface and fork-based behavioral tests of intended entry-point behavior on deployed bytecode.

Input artifact hashes (Keccak-256 of deployed bytecode):

Verification engine: The Meridion Formal Verification Engine v1 is a custom-built symbolic execution environment executing EVM bytecode that supports JUMPI-tracing and SMT solving to verify the absence of trapdoors.

3.3.1 Hidden-Surface Formal Verification

The complete runtime catalogue of entrypoints (6 proxy entries, 48 implementation entries) serves as the exclusion set for hidden-surface verification. The report table in Section 3.2 covers state-modifying entry points only; all 54 runtime selectors were used in the FV exclusion set.

AdminUpgradeabilityProxy: Bytecode Surface Cases

Formal verification of the deployed AdminUpgradeabilityProxy bytecode confirmed the following hidden-surface behavior:

All feasible paths for unknown selectors and short calldata either delegate to the fixed implementation address 0x74271f2282ed7ee35c166122a60c9830354be42a or revert. No unexpected non-reverting hidden behavior was found. Two execution paths were modelled in each case: one delegatecall path and one revert path.

PAXGImplementation: Bytecode Surface Cases

Formal verification of the deployed PAXGImplementation bytecode confirmed the following hidden-surface behavior:

All feasible paths for unknown selectors and short calldata in the implementation always revert. One execution path was modelled in each case. No unexpected non-reverting hidden behavior was found.

Overall verdict: CONFIRMED

3.3.2 Fork-Based Behavioral Tests

Fork-based behavioral tests were executed against the deployed AdminUpgradeabilityProxy 0x45804880De22913dAFE09f4980848ECE6EcbAf78 and PAXGImplementation 0x74271F2282eD7eE35c166122A60c9830354be42a on an Ethereum mainnet Foundry fork at block 25042795.

The proxy fallback (EP-PR-004) was not counted as a separate required case because it is not a named selector. It was exercised implicitly by every implementation entry-point test, since those calls were sent through the deployed proxy and therefore traversed the fallback delegatecall path.

An optional fork smoke test for a selector outside the runtime catalogue was not run and was not counted as a required case; formal verification remains the authoritative hidden-surface control.

Fork-test overall result: PASS (57/57 required cases passed; 28 positive cases, 29 negative cases, all 29 named entry points covered)

3.3.3 Bytecode Assurance Conclusion

Formal verification and fork testing answer different questions. Formal verification provides exhaustive assurance over hidden calldata surface within its modeled constraints: unknown selectors and malformed short calldata. Fork tests provide sampled behavioral assurance that deployed bytecode performs representative intended operations and rejects representative invalid operations.

The formal verification results are fully confirmed for both contracts: the proxy routes unknown calldata exclusively to the fixed implementation or reverts, and the implementation rejects all unknown selectors and malformed calldata. This materially reduces the risk of hidden selector-based or malformed-calldata trapdoors in the deployed bytecode. Fork-based behavioral tests further confirmed that the deployed bytecode executes all 57 representative intended and negative call paths correctly, providing sampled behavioural assurance across the complete entry-point surface. Together, formal verification and fork tests provide High confidence that the deployed bytecode matches the reviewed source with no material hidden behaviour.

3.4 Edge-Case Analysis

Edge-case analysis was conducted for all Critical and High entry points. Key findings are summarised below.

3.5 Common Exploit Negatives

3.6 Security Findings Register

SEC-01: setBetaDelegateWhitelister emits event with incorrect old-value argument

4. Part II: Operational Security

Operational Security Rating: Medium | Confidence: Low

4.1 Privileged Roles

Role holders at assessment snapshot:

Proxy Admin (0xc94bcf6e1d8b3558e3b62e743630d50497e3851c): This is the highest-privilege role in the system. It holds exclusive authority to call upgradeTo and upgradeToAndCall on the proxy, enabling atomic replacement of the entire token implementation in a single transaction with no timelock and no second approval. A hostile or compromised proxy admin can replace the implementation with arbitrary bytecode; because the proxy executes via delegatecall, a malicious implementation has full read-write access to all proxy storage slots, including all PAXG balances. On-chain code verification confirms this address is a bare externally owned account with no deployed bytecode. With no on-chain governance contract mediating upgrade actions, the operational security of the proxy upgrade path depends entirely on off-chain key management controls for this single private key. No public disclosure of key management arrangements for this address is available. Confidence effect: lowers operational confidence to Low.

Owner and AssetProtectionRole (0x3af3e85f4f97de7ad0f000b724fb77fe5ffc024b): Confirmed EOA. The owner role controls: pause and unpause; initiating and completing two-step ownership transfer; setting or overriding the assetProtectionRole, supplyController, feeController, and betaDelegateWhitelister. The assetProtectionRole controls: freeze (blocks all transfers from and to any address); unfreeze; and wipeFrozenAddress (permanently destroys the full PAXG balance at a frozen address, reducing totalSupply_). Both roles are consolidated in a single EOA, meaning one key controls pause, freeze, and irreversible balance destruction over the full circulating supply. From May 2021 to August 2025, these roles were held by the fee controller smart contract, providing a layer of on-chain governance. The August 2025 reorganisation transferred them to this EOA, reducing on-chain control sophistication for these functions. Key management details (HSM, MPC, or equivalent) are not publicly disclosed. Confidence effect: lowers operational confidence to Low.

SupplyController (0x2fb074fa59c9294c71246825c1c9a0c7782d41a4): Confirmed EOA. Powers: increaseSupply (mint any quantity of PAXG in a single transaction; no ceiling in the contract); decreaseSupply (burn from the supply controller's own balance); setSupplyController (self-reassign the role independent of the owner). A compromised supply-controller key can mint the entire token supply, approximately $2.262 billion at assessment date, in a single transaction with no on-chain approval gate. The role has rotated three times since deployment, most recently in December 2024. Key management not publicly disclosed. Confidence effect: lowers operational confidence to Low.

FeeController (0x0644bd0248d5f89e4f6e845a91d15c23591e5d33): Confirmed contract. Powers: set fee rate (0 to 100% of transfer value); set fee recipient; reassign the fee controller role. Fee-rate manipulation cannot drain existing balances directly; it can only redirect future transfer fee flows. This is the only role currently held by a smart contract, which reduces single-EOA concentration risk for fee operations. The internal governance of this contract (signer structure, quorum, upgrade authority) was not assessed in this engagement.

BetaDelegateWhitelister: No BetaDelegateWhitelisterSet event was observed in the on-chain event history assessed for this report; the address currently holding this role is therefore not confirmed. The owner can override this role at any time. The beta-delegate feature allows whitelisted addresses to execute pre-signed ERC-20 transfers; it cannot mint, pause, or freeze.

ProposedOwner: Zero address (unset). No pending ownership transfer is in progress as of the assessment date.

4.2 Administration History

Role history is complete from deployment (August 2019) through the assessment snapshot (May 2026), sourced from on-chain event data.

Deployment and initial setup (August 2019): The proxy was deployed on 26 August 2019. The proxy admin was changed twice in rapid succession during initial configuration. The supply controller was set and the fee controller was set and adjusted three times in the same block window.

NYDFS approval and initial operations (September 2019): On 5 September 2019, following NYDFS approval, ownership transferred from the deployer EOA to the first operational EOA (0xb87ce...). The asset-protection role was set to the same address. The contract became operational under the NYDFS limited purpose trust company charter.

Supply controller rotation (March 2021): The supply controller rotated from 0x5195... to 0xe25a.... No incident association; consistent with routine key management.

Major operational reorganisation (May 2021): On 4 May 2021, a significant structural change consolidated all operational roles into the fee controller smart contract (0x0644bd...): the proxy admin changed, ownership transferred to the fee controller, the asset-protection role was set to the fee controller, and the fee controller itself was assigned. This represented the highest level of on-chain control sophistication in the system's history, as these key roles were governed by a smart contract rather than bare EOAs.

Supply controller rotation (December 2024): The supply controller rotated from 0xe25a... to 0x2fb074... (the current holder). No incident association.

Administrative reorganisation (August 2025): On 7 August 2025, the proxy admin changed to 0xc94bcf... and the asset-protection role was set to EOA 0x3af3e.... On 8 August 2025, ownership transferred from the fee controller contract to the same EOA 0x3af3e.... This reorganisation moved the owner and asset-protection role from a contract-held structure back to EOA control, reducing on-chain governance sophistication for these functions. The timing aligns with the NYDFS $48.5 million settlement (7 August 2025) concerning the BUSD/Binance programme. No PAXG-specific operational rationale for the role-structure change has been publicly documented.

Pause events: No Pause or Unpause events are present in the assessed history. PAXG has remained unpaused since deployment in 2019.

Upgrade events: No implementation upgrade events have occurred. The current implementation (0x74271F2282eD7eE35c166122A60c9830354be42a) has been in place since deployment, over six years without a code change.

Known operational incidents: No operational incidents involving key compromise, freeze misuse, supply manipulation, contract exploit, or emergency intervention have been publicly reported for PAXG. The NYDFS enforcement actions (February 2023 BUSD cessation order; August 2025 $48.5 million settlement) concerned the separate BUSD/Binance stablecoin programme and had no disclosed operational impact on PAXG contracts or key holders.

4.3 Upgrade Risk Analysis

Proxy standard: PAXG uses the AdminUpgradeabilityProxy from the ZeppelinOS pre-EIP-1967 era, implementing the transparent proxy pattern. The proxy admin slot is stored at keccak256("org.zeppelinos.proxy.admin") (0x10d6a54a...) and the implementation slot at keccak256("org.zeppelinos.proxy.implementation") (0x7050c9e0...). These differ from the EIP-1967 standard slots (0x360894a1... and 0xb53127...). Security tooling, block explorers, and monitoring dashboards that read EIP-1967 slots will not locate the correct implementation or proxy admin addresses. Off-chain systems monitoring for upgrade or admin-change events must explicitly target the ZeppelinOS-specific storage slots to reliably detect such events; standard EIP-1967 watchers will silently miss them.

Upgrade authority and scope: The proxy admin can replace the implementation atomically in a single transaction with no timelock, no second approval, and no advance notice to token holders. upgradeTo(newImpl) replaces the implementation slot immediately. upgradeToAndCall(newImpl, data) replaces the implementation and then executes an arbitrary call on the proxy. The inner call re-enters the proxy fallback with msg.sender == proxy address; any future initialiser that sets owner = msg.sender would set the owner to the proxy address, permanently bricking ownership functions. Future upgrade procedures must pass the intended owner as an explicit constructor or initialiser argument rather than deriving it from msg.sender.

No upgrade has occurred in six years of operation.

Storage layout: The implementation uses sequential storage from slot 0. A future implementation that inserts new variables at existing slot positions or changes variable ordering would corrupt stored values. No on-chain storage-layout guard (such as a StorageGap) is present. Storage-layout compatibility is enforced by operational process only, under the issuer's control of both contracts. The proxy's own admin and implementation pointers use unstructured keccak256-derived slots, which avoids collision with the implementation's sequential storage.

Practical risk during upgrade: The upgrade window is effectively instantaneous. If the proxy admin submits an upgradeTo transaction, token holders receive no advance notice; a malicious or erroneous implementation takes effect in the same block; and all PAXG balances (approximately $2.262 billion), approvals, freeze states, and role assignments stored in the proxy are immediately subject to the new implementation's logic. Six years of operational stability reduce the likelihood of an upgrade event, but the risk remains material at this asset scale. The absence of a timelock is a design choice made by Paxos; it enables faster emergency patching at the cost of providing no exit window for token holders before any implementation change.

Meridion offers post-upgrade verification scripting as an optional service to confirm deployed-bytecode integrity after each upgrade.

4.4 Recovery Scenarios

Scenario 1: Owner key lost

Scenario 2: SupplyController key lost

Scenario 3: ProxyAdmin key lost

Scenario 4: ProxyAdmin key compromised

Scenario 5: SupplyController key compromised

Scenario 6: Accidental or malicious token pause

The recovery design for PAXG is highly centralised. The proxy admin and owner roles have no on-chain successor mechanism: permanent key loss permanently eliminates the corresponding privilege. The supply controller has a partial recovery path through the owner. All recovery paths ultimately depend on off-chain operational continuity plans that are not publicly documented. Paxos's SOC 2 Type 2 certification (obtained March 2021, renewal status not public) indicated that internal controls were audited at that time, but the scope and adequacy of those controls for the specific recovery scenarios above is not externally verifiable.

4.5 Multisig Security Analysis

No multisig role holder was identified for any PAXG privileged role as of the assessment date. On-chain code verification confirms that the proxy admin (0xc94bcf6e1d8b3558e3b62e743630d50497e3851c) is a bare externally owned account with no deployed bytecode, providing no on-chain governance mediation for the highest-privilege role in the system. The owner (0x3af3e85f4f97de7ad0f000b724fb77fe5ffc024b) and supply controller (0x2fb074fa59c9294c71246825c1c9a0c7782d41a4) are similarly confirmed bare EOAs. All three roles for which multisig analysis was performed are confirmed single-key accounts with no threshold protection. The fee controller (0x0644bd0248d5f89e4f6e845a91d15c23591e5d33) is a contract, and its internal governance structure — including signer arrangement, quorum, and upgrade authority — was not assessed in this engagement.

5. Part III: Financial Analysis

Financial Risk Rating: Low | Confidence: Medium

5.1 Underlying Asset Attestation

PAX Gold (PAXG) is backed 1:1 by physical gold held in LBMA-approved vaults in London. Each PAXG token represents exactly one fine troy ounce of an LBMA Good Delivery gold bar. Paxos publishes monthly attestation reports at the Paxos transparency page.

Attestation programme: KPMG LLP, monthly AICPA examination-level attestation.

Most recent attestation report: April 2026 (KPMG LLP, available on the Paxos transparency page).

The on-chain totalSupply (479,162.743 PAXG) exceeds the CoinGecko circulating supply (471,942.854 PAXG) by 7,219.889 PAXG (~1.53%). This discrepancy is consistent with Paxos holding treasury tokens: minted PAXG backed by physical gold but not yet distributed into the secondary market. Treasury tokens are included in totalSupply but excluded from CoinGecko's circulating supply definition. No reserve shortfall is implied; treasury tokens require corresponding gold in custody.

Gold is held in allocated, segregated accounts at two LBMA-accredited London vaults: Brink's Global Services Ltd. and ICBC Standard Bank Plc. The allocation split between these two custodians is not publicly disclosed. Paxos provides a real-time gold allocation lookup tool listing each bar by serial number and weight.

The April 2026 KPMG AICPA examination report was confirmed available on the Paxos transparency page at assessment time. The on-chain totalSupply and the structural 1:1 oz design were used as the reserve basis for this assessment.

5.2 Counterparty Risk Profile

Paxos Trust Company, LLC: Paxos is the issuer, supply controller, redemption processor, and regulatory compliance obligor for PAXG. It was originally incorporated in New York State as a limited purpose trust company and received NYDFS approval for PAXG on 5 September 2019. On 12 December 2025, the OCC conditionally approved Paxos's application to convert to a national trust bank, subject to satisfying OCC conditions. Final completed conversion was not independently confirmed during this assessment, so this report does not treat PAXG as already operating under a completed OCC charter. Paxos raised $300 million in a Series D round in 2021 and has operated since 2012. The 2023 BUSD cessation order and the August 2025 $48.5 million NYDFS civil monetary penalty both relate exclusively to the BUSD/Binance stablecoin partnership and have no disclosed impact on PAXG operations, contracts, or key holders. The principal risk is single-issuer concentration: PAXG has no decentralised governance or alternative redemption path if Paxos operations are suspended. Paxos public materials state that PAXG customers own the underlying physical gold represented by the token; however, the public legal documentation reviewed here does not clearly establish how an individual holder would directly enforce a property claim to specific bars in insolvency, as distinct from contractual redemption rights against Paxos. Recovery would therefore depend on trust-law treatment, custody documentation, and applicable regulatory proceedings.

KPMG LLP: KPMG is one of the largest global accounting firms and was appointed as PAXG attestor from 28 February 2026, replacing WithumSmith+Brown, PC. Attestations are conducted under AICPA examination-level standards, which are more rigorous than agreed-upon procedures. KPMG's engagement relies on physical inspection and bar-list confirmation provided by the custodians; the examination does not constitute a bar-by-bar purity assay. Attestation lag is inherent to monthly reporting: up to 30 days of unattested period exist between report dates. KPMG's credit and reputational risk are very low for this engagement scope.

Brink's Global Services Ltd.: Brink's is the world's largest physical security and logistics company, with over 165 years of operating history and a NYSE listing (BCO). It operates LBMA-accredited vaults in London. Gold held in allocated accounts at Brink's is legally segregated from Brink's general assets under UK law and LBMA Rules. In an insolvency, allocated gold belongs to the beneficial owner (Paxos, for the benefit of PAXG holders) and is not available to general creditors. Brink's maintains insurance against physical loss of gold in custody, though coverage scope is not publicly disclosed. Credit risk is low.

ICBC Standard Bank Plc: ICBC Standard Bank is a UK-regulated bank and LBMA member, jointly owned by the Industrial and Commercial Bank of China Ltd. (ICBC) and Standard Bank Group. ICBC is the world's largest bank by assets. Allocated gold held at ICBC Standard Bank is legally segregated under UK law and LBMA Rules, providing similar bankruptcy remoteness to the Brink's arrangement. ICBC Standard Bank Plc does not carry a publicly available standalone credit rating, and its financial strength depends on parent support from ICBC. Exposure to Chinese parent-company risk and regulatory developments affecting ICBC are secondary considerations. The undisclosed allocation split between Brink's and ICBC Standard Bank prevents precise custodian concentration assessment; if one custodian holds the majority of gold, a single-custodian failure scenario is materially worse than the 50/50 assumption used in scenario modelling.

5.3 Liquidity Risks and Scenario Analysis

5.3.1 Liquidity Profile

Issuer redemption process: Direct creation and redemption of PAXG through Paxos requires passing Paxos KYC and AML onboarding. Physical gold delivery (London Good Delivery bars) requires a minimum of 430 PAXG (one full bar) with T+2 settlement during LBMA business hours. USD cash redemption is available at lower thresholds (exact minimum not published) at prevailing LBMA spot prices, settled via bank wire. Redemption fees are tiered, ranging from 0.03% to 1%. Transfer fees were set to zero in July 2024. Banking-hours dependencies apply to USD settlement. Holders with fewer than 430 PAXG cannot redeem for physical gold directly through Paxos.

DEX liquidity: Total reported DEX TVL (deduplicated) is approximately $192 million. Conservative executable DEX liquidity is approximately $55.7 million after excluding a $124.98 million restricted institutional pool (multipli.fi) and lending pools (Fluid, Morpho Blue; combined approximately $7.8 million) that are not executable for ordinary holders.

PAXG-XAUT pools provide gold-for-gold swaps and offer no direct USD exit without routing XAUT proceeds to a USDC or USDT pair separately. The conservative executable DEX liquidity of $55.7 million represents approximately 2.46% of the on-chain reserve value of $2.262 billion. On a consistent cross-report basis, this is the strongest DEX liquidity coverage among the three reviewed gold-token reports, ahead of XAUT's approximately 1.7% reserve-value coverage and PGOLD's approximately 0.41% market-cap coverage. For positions above approximately $10 million, direct issuer redemption (T+2) or OTC and CEX desks are necessary. Mass-exit scenarios beyond $55.7 million in DEX depth within a 6-hour window will result in material secondary-market discounts.

5.3.2 Scenario Analysis

Scenario 1: Base Case

Scenario 2: Market Stress

Scenario 3: Redemption Run / Mass Exit

Scenario 4: Oracle Failure / Price-Source Failure

Scenario 5: Custodian Failure

5.4 Regulatory and Legal Jurisdiction

Issuer jurisdiction: United States (NYDFS New York state trust company; conditional OCC national trust bank conversion approval)

Governing law: New York State law

Paxos Trust Company, LLC operates under a strong US state trust-company framework and received conditional OCC approval on 12 December 2025 to convert to a national trust bank. A completed OCC national trust bank charter would bring Paxos under federal banking supervision, including regular safety-and-soundness examinations, capital adequacy requirements, and consumer protection rules; however, final completed conversion was not independently confirmed during this assessment. PAXG was the first gold-backed token approved by NYDFS (September 2019).

Paxos publicly represents that PAXG customers own the underlying physical gold represented by their tokens. The public-facing documentation reviewed in this assessment nevertheless does not clearly establish the mechanism by which an individual token holder could directly assert a property interest in specific gold bars in an insolvency scenario, as distinct from enforcing contractual redemption rights against Paxos Trust Company, LLC for physical gold (minimum 430 PAXG per bar) or USD cash at prevailing LBMA prices. Gold is held in allocated, segregated accounts under New York trust-law arrangements, which should support bankruptcy remoteness from Paxos's general corporate estate, but the individual holder enforcement path remains a meaningful legal uncertainty.

PAXG faces an active regulatory gap in the European Union. As a gold-referenced token, PAXG falls under the EU Markets in Crypto-Assets Regulation (MiCA) as an Asset-Referenced Token (ART). Paxos has not announced a MiCA ART authorisation from an EU competent authority as of this assessment date. EU-based crypto-asset service providers (CASPs) and retail investors may face restrictions on offering or holding PAXG without a MiCA-authorised issuer or an applicable exemption. This gap presents a material distribution risk for EU market access and may affect PAXG's competitiveness relative to EU-licensed gold-token alternatives. Paxos has not published UK-specific regulatory authorisation either, though the UK's emerging crypto-asset regulatory framework remains less prescriptive than MiCA at this stage.

The regulatory environment for tokenised commodities is improving globally, with the OCC conditional conversion approval being a significant positive development for Paxos if the conversion is completed. US stablecoin legislation, if enacted, may clarify or affect the treatment of commodity-backed tokens. PAXG's commodity classification (gold) is stable under current US law, though future legislative or regulatory interpretive changes by the SEC or CFTC could affect this characterisation.

6. Conclusion

6.1 Composite Risk Rating: Low

Composite Confidence: Low

PAX Gold (PAXG) receives a composite risk rating of Low under the Meridion Risk Rating Standard v1. The rating reflects one domain at Medium (operational security) under conditions that are contingent and not currently causing holder harm: the proxy admin, owner and asset-protection role, and supply controller are all confirmed bare externally owned accounts controlling approximately $2.262 billion in token value, operating without on-chain timelocks, second-approval requirements, or publicly disclosed key management controls. No operational incident involving key compromise, unauthorised minting, or misuse of administrative authority has been recorded in six years of operation. The smart contract domain is rated Low; the deployed code presents only a single Low-severity event-log finding (SEC-01), formal verification confirmed the complete absence of hidden-surface trapdoors in the deployed bytecode, and six years of uninterrupted operation on an unchanged implementation support the Low rating. The financial domain is rated Low; the 1:1 gold-oz backing eliminates fractional-reserve risk, monthly KPMG AICPA attestations provide independent reserve confirmation, and Paxos's conditional OCC conversion approval is a positive regulatory development, though not treated here as completed OCC charter status.

Composite confidence is Low, driven by the absence of publicly disclosed key management evidence for the three confirmed highest-privilege EOA roles (proxy admin, owner, and supply controller). The undisclosed custodian allocation split between the two London vaults further prevents the composite confidence from reaching Medium. The smart contract domain achieves High confidence following the completion of formal verification and all 57 fork-based behavioral tests.

6.2 Improvement Suggestions

• Transparency of operational security practices: Paxos has not publicly disclosed the key management policy, recovery and incident-response procedures, or operational monitoring policies for the PAXG privileged roles. Specifically: (a) key management policy should disclose whether HSM, MPC, or equivalent hardware security controls are used for the proxy admin, owner, and supply-controller keys, and the key ceremony and rotation schedule; (b) the recovery and incident-response playbook should address key loss, key compromise, and emergency pause scenarios for each privileged role, including succession procedures for the proxy admin and owner; (c) the monitoring policy should describe the on-chain event thresholds and alert configurations used for Upgraded, SupplyIncreased, AddressFrozen, FrozenAddressWiped, and OwnershipTransferred events, noting the requirement to monitor ZeppelinOS-specific storage slots rather than EIP-1967 slots for upgrade detection. Publishing these disclosures would allow external verifiers to assess whether the operational posture matches the asset's scale and regulatory standing.

• Disclose the gold allocation split between custodians: The proportion of PAXG gold reserves held at Brink's Global Services Ltd. versus ICBC Standard Bank Plc is not publicly disclosed. Disclosure would enable holders and analysts to assess custodian concentration risk and validate the assumptions used in the custodian-failure scenario analysis.

• Pursue MiCA authorisation for EU market access: PAXG is classifiable as an Asset-Referenced Token under MiCA. Paxos has not announced a MiCA ART authorisation as of this assessment date. Pursuing authorisation from an EU competent authority would eliminate the EU distribution risk for PAXG and support institutional adoption in European markets.

6.3 Report Validity Timeline

This report is valid as of its publication date. It should be treated as superseded upon any of the following events, whichever occurs first:

• A smart contract upgrade that modifies the in-scope bytecode of either the AdminUpgradeabilityProxy or PAXGImplementation
• A change to any privileged role holder identified in section 4.1
• A material change to the custodian arrangement, redemption model, attestor, or reserve composition identified in sections 5.1 and 5.4
• 12 months from the date of publication

Disclaimer

This report is produced by Meridion Risk for informational purposes only and does not constitute financial, legal, or investment advice. The findings, ratings, and conclusions expressed herein reflect the state of the assessed system at the snapshot date and may not remain accurate after that date. Meridion Risk makes no representation or warranty, express or implied, as to the accuracy, completeness, or fitness for any particular purpose of the information contained in this report. To the maximum extent permitted by applicable law, Meridion Risk and its contributors shall not be liable for any direct, indirect, incidental, consequential, or other damages arising from reliance on this report or from any errors or omissions therein. Security assessments are inherently limited in scope and cannot guarantee the absence of undiscovered vulnerabilities. Users of this report should conduct their own due diligence before making any financial or operational decisions.