PHA value-capture and supply-overhang verification (multi-agent deep-research test)

Archon — independent primary-source follow-up: payment necessity, PHA route readiness, and staking reward allocation.

1. Cloud payment requirement (check bb4166e5).
Phala's current pricing FAQ lists card payments via Stripe, crypto via Coinbase Commerce, and enterprise bank transfers [1]. This is affirmative documentation of non-PHA payment options, supporting “PHA is not mandatory for the advertised Cloud payment routes.” It does not enumerate the assets actually enabled for Phala's Coinbase checkout. I did not authenticate, create a checkout, or make a payment; that merchant-specific inventory remains unverified.

2. New payment-layer evidence: Phala Pay [2–4].
The official Pay overview describes configurable ERC-20 deposits credited in USD, and says Phala operates an instance for Phala Cloud. This is a more specific source to investigate alongside the pricing FAQ, not proof that the FAQ's processor list is current.
The Pay configuration documentation explicitly says PHA production is unavailable until two independent pricing sources are implemented and Allowed [3]. The GitHub PHA example is labelled local/sandbox noncommercial rehearsal only; its mainnet address and livemode:true are NOT deployment or production-readiness proof [4].
Classification: PHA payment functionality is documented as a constrained rehearsal/template path; a live Phala Cloud PHA payment route is not verified. Do not simplify this to either “PHA payment code does not exist” or “PHA is mandatory/live.”

3. Reward funding versus holder revenue (checks 1ca0c575 / 371c13f2).
The compute-provider introduction assigns 70% of token supply to a mining reward pool, split 20% treasury, 40% Ethereum staking rewards and 40% GPU miners; it explicitly links Ethereum staking incentives to that mining share [5]. These are shares of an allocation, NOT a current annual emission rate or percentages of Cloud revenue.
It also documents vPHA collateral requirements for GPU providers. That is a distinct potential token-locking utility; it is not a demonstrated conversion of Cloud sales into token purchases.
The staking guide describes rewards increasing the vPHA exchange rate [6]. Together these pages supply a documented mining-allocation funding explanation beyond the staking guide alone. They do NOT establish that all actual vault inflows follow that model, exclude additional revenue funding, or quantify customer-growth-to-PHA demand.

Limits and next checks.
No contracts, vault transfers, deployed payment configuration, buybacks, burns or revenue-routing flows were verified here. No overall investment verdict or synthesis support is given. Compare current vault inflows with disclosed distribution schedules, then seek an explicit revenue-to-token mechanism and attributable transactions.

Method feedback.
Add separate fields for customer payment asset, provider collateral, reward allocation, actual reward cashflows, payment environment, production eligibility, deployed configuration and measured demand. Treat template flags as implementation context, not adoption evidence. The .md documentation URLs failed in the browsing tool with unsupported text/markdown; their HTML equivalents worked. An older cached raw GitHub view differed from the current HTML example; do not silently combine them. This contribution cites the explicitly labelled current HTML example and Pay configuration, with that retrieval limitation disclosed.

Sources [1]–[6] are primary, linked in the evidence entries. Checked during this turn on 2026-10-21 UTC; observedAt records completion of this verification pass, not a claimed exact HTTP response timestamp. Shared source overlap with Masters Chief and Prime is disclosed for [1], [5], [6]. New Pay sources add implementation/readiness context. No wallet action or paid data was used.