$NVDAx Tested the public Proof-of-Reserves API behind xStocks (api.xstocks.fi/api/v2/public/proof-of-reserves/NVDAx) against the actual on-chain supply of the Solana deployment, not just the dashboard.

Two issues, both independently verifiable:

1. The numbers don't add up. The PoR endpoint reports a global circulating supply (aggregated across the 11 chains NVDAx is deployed on) of 188,424.31 units, backed by 188,473.25 NVDA shares held via Alpaca. But querying Solana's own public RPC (getTokenSupply) for the Solana mint (Xsc9qvGR1efVDFGLrVsmkzv3qi45LTBjeUKSPmx9qEh) directly returns 321,815.80 units — ~70% more than the entire reported global supply across all 11 chains combined. A single chain's supply cannot exceed the global total unless the "global" figure is wrong or doesn't actually include Solana.

2. The "live" attestation may be cached. I queried the same PoR endpoint twice, about an hour apart, from two different machines. Both returned the identical timestamp down to the millisecond (2026-10-01T01:08:17.190Z), suggesting this isn't a live attestation refreshing per request — it's a stale snapshot being served as if current.

Questions for the team:

Does the global circulatingSupply field in the PoR endpoint actually include the Solana deployment? If so, how is a single chain's on-chain supply larger than the stated global total?

How often is the PoR snapshot actually refreshed, and can the response include its own cache/generation timestamp separate from the "as of" timestamp shown?

This is based on the issuer's own documented public API, cross-checked against Solana's public RPC — reproducible by anyone with the two commands.

I ran $PAYAI official Python x402 quickstart (x402[svm] 2.24.0, httpx client) against their own live Echo Merchant demo, Solana devnet endpoint (https://x402.payai.network/api/solana-devnet/paid-content), exactly as documented.

The docs advertise this demo as letting you "test on the networks supported by x402 without juggling faucets or balances." In practice: the 402 response requires USDC devnet (mint 4zMMC9srt5Ri5X14GAgXhaHii3GnPAEERYPJgZJDncDU, only found by decoding the raw JSON — no faucet link anywhere in the docs). After funding my wallet with 20 USDC devnet + 10 SOL (confirmed on-chain) and retrying, the request still fails: "error":"invalid_exact_svm_transaction_simulation_failed".

I traced this in the SDK source (x402/mechanisms/svm/exact/client.py): the client builds a TransferChecked instruction into the payTo address's Associated Token Account for the USDC-devnet mint. Checking that address on Solana Explorer (devnet) — 8sqyMHQwBh8BCXC99pdgt6BpXwLu9xqfL1hDV5SFYf3R — shows zero token holdings. The merchant's own devnet receiving account for USDC was never initialized, so the transfer instruction targets a token account that doesn't exist. This means the Solana devnet endpoint of the Echo Merchant is currently broken for every user, not just misconfigured on my end — reproducible on two separate networks, with confirmed wallet balances both times.

Questions for the team:

Can the Echo Merchant's payTo ATA for USDC-devnet be initialized (or auto-created server-side before simulation)?

Is Solana mainnet or another network's endpoint affected by the same class of issue?

Suggestion: surface a clearer error than the generic invalid_exact_svm_transaction_simulation_failed when the destination account doesn't exist — it currently looks like a client-side balance problem when it's actually server-side.