Phala Pay 0.10.0

Changed (operators)

• Confirmation uses bounded head-only probes: Depth six probes at the fixed estimated-depth
  anchor plus 4/12/28/60/124 seconds, Safe three and Finalized seven at 384-second intervals.
  Height-only exhaustion enters slow lane L and rechecks after 60 seconds, ten minutes, then
  hourly; it confirms when both heads qualify without waiting for checkpoint. DB gauges alert
  on ten-minute L occupancy and current/rolling-entry totals above one per environment.
  Missing/conflicting evidence stays in S under one shared atomic read lease and backoff;
  terminal evidence flows directly to valuation. Re-inclusion can change position but cannot
  change transfer identity. Price retries reuse the exact new-path proof linked atomically to the
  current final marker; legacy markers and proofs predating S require fresh watcher evidence.
  Finalized price failures retain the ten-method per-endpoint ceiling. Expand-only
  counters/history survive rollback, but N-1 keeps its old RPC allocation. Production's operational
  deposit allocation is 46/day (staging 20) to retain 10.04% shared Infura budget headroom.

Breaking (operators)

• Replace the deprecated Chainalysis oracle with verified OFAC SDN snapshots and audited manual
  supplements. Allow outbound HTTPS to the SLS and its published S3 host. The service verifies
  the publication hourly; without a fresh snapshot, negative answers hold (default limit 24h).
  chain.sanctions_oracle remains parsed for N-1 rollback and is removed in N+1. Before a
  production rollback, pause all screening-dependent fund processing, regardless of manual
  entries, until N is restored and verified screening is healthy. A passing database/binary
  rollback drill does not authorize settlement with N-1's stale oracle.

• The pilot permanently caps issued addresses at 1,000 per chain, counting all historical
  addresses. Quotes and deposit addresses return non-retryable 422 address_capacity_reached
  at the cap. Operators must run the pre-upgrade count check; alerts warn at 70% and 90%.
  Capacity growth requires a reviewed paid-provider or token-wide scanning/indexer upgrade.

• Replace RPC company, budget and group registries with one strict rpc read/verify pair per
  route or price chain. Seal the complete secret set with TOPUP_RPC_ANKR_KEY and
  TOPUP_RPC_INFURA_KEY. Deploy preflight checks the actual compose environment path.

• Quote cancellation requests keep the quote open and its exposure reserved until its address
  catches up to dual finalized coverage past expires_at. Quote objects add
  cancel_requested_at; completion emits quote.canceled. Expiry uses the same evidence gate.

• Fresh quote price snapshots are capped at 60 per price chain/environment/UTC day. Exhaustion
  returns retryable 503 price_unavailable; the twelve-second reuse limit is unchanged.
  Production and staging share provider free quotas: their operational deposit allocations are
  46/day and 20/day respectively. Keep hourly dual custody on every routed chain/token pair;
  the required positive max_attached_pending_refunds deployment setting enforces production's
  limit of two attached-pending refunds and staging's limit of one per environment.

• Remove RPC recovery/resume commands, member pools, review sweeps, single-source backstops and
  custom head-poll flags. The expand-only migration preserves rollback to the prior stable
  release, whose RPC frozen/anchor/recovery state must be resolved before starting this version.

Added

• Admin-signed manual sanctions add/remove endpoints with transactional audit, snapshot
  provenance in screening evidence and daily reports, and sanctions refresh/freshness metrics,
  alerts and an operator runbook. Activating a snapshot re-screens current and pending treasuries
  and pending refund destinations across all EVM chains.

• API-key authentication uses a database slot gate sized to half the pool (at least one slot).
  A checksum-valid Bearer key waiting more than 250 ms returns 503 unavailable with
  Retry-After: 1; the request has not executed. Malformed or checksum-invalid keys still return
  401 without taking a slot. Payer reads, health checks, and admin authentication use their
  existing admission paths.

• Object-scoped transaction-hash hint endpoints for quotes and deposit addresses acknowledge
  admitted requests with 202 received, use client-secret or merchant write authentication, and only
  record dual-verified successful routed transfers at confirmation. Hard call, time, concurrency
  and UTC daily task limits fall back to scanning; hints never establish negative coverage.
  Complete evidence is fetched independently after both endpoints reach confirmation depth;
  receipt lag and confirmation-time reorgs stay within the whole-task budget. Endpoint readiness
  loss parks tasks, and cancellation or panic releases running tasks. Hint counters expose budget
  claims, recorded deposits, exhaustion, deferral and parking. Object credentials gate rate limits;
  hint endpoints omit peer-IP limits because TCP ingress shares one peer across all clients.

• Dual finalized coverage and per-address backfill markers, independently verified deposit evidence,
  and durable agreed checkpoints. Contract code mismatch freezes only its chain; audited lifts
  require a fresh passing dual-source check.

Changed

• Confirm and finality-watch checks of absent transfers share durable once-only unresolved entry
  timestamps and the one-minute/ten-minute/hourly schedule. Due unresolved deposits at the
  persisted finality checkpoint are checked only by the watcher; agreed positive transfer evidence
  returns provisional correction and valuation to confirm, retaining unresolved entry history.
  Coverage freezes immediately when dual-agreed boundary hashes contradict persisted checkpoint
  or coverage evidence. Refund concurrency is a required positive deployment setting (production
  2, staging 1); the one-new-attachment rolling-24-hour limit and reservation safety are unchanged.

• Unresolved deposit finality checks back off from every minute for the first ten minutes unresolved,
  to every ten minutes until six hours, then hourly; normal newly due finalization and the
  one-hour pending-after-reorg alert are unchanged. Only one service-known replacement candidate
  may be read on both endpoints; multiple candidates alert and keep the deposit unresolved.
  DB-derived per-chain gauges track current unresolved stock immediately and distinct first
  unresolved entries over the rolling 24 hours, retaining resolved entries in that window.
  Either environment total above one alerts; operators must pause new quotes until both
  counts return to at most one. The first unresolved timestamp survives rechecks and rollback.

• Payment discovery runs every five minutes, dual finalized checkpoints are independently
  verified and published every ten minutes, and complete dual log coverage runs hourly.
  Observation-chain contract recovery remains every minute and admitted hint processing keeps
  its seconds-scale fast path. Without hints, discovery adds up to five minutes (mean 2.5), plus
  confirmation and processing. Newly due deposit finality/reversal and checkpoint-conflict detection
  add up to ten minutes plus processing; log-only conflicts still wait for coverage. Expiry,
  cancellation completion and reservation release still require dual coverage: allow chain
  finality plus ten minutes for the checkpoint, one hour for coverage and five seconds for expiry.
  Coverage lag now warns after two hours; Sentry monitors track all three independent cadences.
  Every sixth coverage round scans up to 19,200 blocks (every six hours); normal rounds retain
  3,000 blocks. Healthy continuous recovery can clear a 24-hour-equivalent backlog within twelve
  hours, subject to the recovery-day deposit/factory operational caps. Failures, restarts and
  address backfill extend these bounds. Custody remains hourly and coverage-pinned, so a newly
  finalized discrepancy can take about 130 minutes plus RPC time to freeze the chain. Chain-time
  quote eligibility is unchanged; later processing can change fresh valuation and sanctions results.

• Breaking: Each environment enforces its configured attached-pending refund cap (production
  two, staging one) and admits one new refund transaction attachment per rolling 24 hours across all merchants and modes. mark_paid returns
  non-retryable 422 refund_attachment_limit_exceeded when either limit would be exceeded; contact
  the operator before sending or attaching another payout. Refusals keep the pending reservation,
  idempotent repeats consume no quota, and existing attachments continue dual-source verification.
  Admitted transaction hint tasks are capped at 80 per environment/UTC day; fresh quote snapshots
  remain capped at 60 per price chain/environment/UTC day, with alerts at both caps.

• Breaking: Refund transactions never seen by either endpoint after 24 hours remain pending
  and keep their reservation, with TopupRefundProgressAge alerting the operator. They no longer
  become failed with transaction_not_found or emit refund.failed; merchants cannot refund
  the reserved amount again or cancel after mark_paid. Attached refunds are checked every 60 s
  for the first 30 min, every 10 min until 24 h, then hourly until finalized verification resolves
  them. Historical failure values remain readable.

• Breaking: Global API overload on transaction-hint endpoints returns the standard retryable
  503 unavailable instead of 202 received, before reading the request body. Admitted hints
  retain their quiet acknowledgement behavior.

• Removed the per-source pre-authentication budget: Phala's TCP ingress exposes only the shared
  gateway's WireGuard address, so one client could exhaust it and cause every merchant to receive
  429. There is no per-client-IP limiting; see
  [A...

Phala Pay 0.10.0-rc.6

Pre-release of the changes under [Unreleased] in CHANGELOG.md, without the SDKs.

Verify

deploy/verify-release.sh
checks this release as Deploy does (self-hosting guide).

Phala Pay 0.10.0-rc.5

Pre-release of the changes under [Unreleased] in CHANGELOG.md, without the SDKs.

Verify

deploy/verify-release.sh
checks this release as Deploy does (self-hosting guide).

Phala Pay 0.10.0-rc.4

Pre-release of the changes under [Unreleased] in CHANGELOG.md, without the SDKs.

Verify

deploy/verify-release.sh
checks this release as Deploy does (self-hosting guide).

Phala Pay 0.10.0-rc.3

Pre-release of the changes under [Unreleased] in CHANGELOG.md, without the SDKs.

Verify

deploy/verify-release.sh
checks this release as Deploy does (self-hosting guide).

Phala Pay 0.10.0-rc.1

Pre-release of the changes under [Unreleased] in CHANGELOG.md, without the SDKs.

Verify

deploy/verify-release.sh
checks this release as Deploy does (self-hosting guide).

Phala Pay 0.9.3-rc.1

Pre-release of the changes under [Unreleased] in CHANGELOG.md, without the SDKs.

Verify

deploy/verify-release.sh
checks this release as Deploy does (self-hosting guide).

Phala Pay 0.9.2

Fixed

• Chainlink sources omitting rpc_group_b with rpc_group: a when the route's second RPC group is
  literally a (e.g. ["x", "a"]) previously read one group twice, silently losing A/B
  independence. Upgrading reads two independent groups and may newly reject quotes as divergent.
  Configurations setting rpc_group_b explicitly are unaffected and need no action.
• Sequencer uptime validation now checks the groups the service reads; previously it looked up
  a/b literally while the service resolved them as route aliases. Runtime is unchanged.
  Configurations that only validated under the old lookup may now be rejected by config check.
  Shipped staging, example, and examples/ configurations use non-alias sequencer group names and are
  unaffected.

Python SDK (phala-pay)

Changed

• The 60 resource method signatures that previously declared request_deadline and
  upgrade_tolerance now show **options in help() and inspect.signature(); the accepted
  runtime keywords are unchanged. Unknown-keyword TypeError messages no longer include the
  method name prefix.

Deprecated

• The legacy PhalaPay constructor is deprecated and emits DeprecationWarning; it will be
  removed in 0.10.0. Configure pins or use PhalaPay.from_env() instead.

SDKs

@phala/pay 0.9.2, @phala/pay-react 0.9.2, and @phala/pay-server 0.9.2 on npm;
phala-pay 0.9.2 on PyPI.

Verify

deploy/verify-release.sh
checks this release as Deploy does (self-hosting guide).

Phala Pay 0.9.2-rc.1

Pre-release of the changes under [Unreleased] in CHANGELOG.md, without the SDKs.

Verify

deploy/verify-release.sh
checks this release as Deploy does (self-hosting guide).

Phala Pay 0.9.1

Upgrading from 0.8.x

• 0.9.0 cannot be deployed with Deploy. Upgrade 0.8.x directly to 0.9.1 and follow every step of
  0.9.0's "Upgrading from 0.8.x",
  including the pre-upgrade backup and the one-time bootstrap_maintenance: true.

Fixed

• Deploy fetches deploy/deadline.sh with deploy/verify-release.sh at the release commit, so release
  verification no longer fails before any change (0.9.0's Deploy stopped at "Verify the release").
  A CI check keeps all three consumers fetching every script verify-release.sh sources.
• The 0.9.0 kit's example environment failed topup config check; production examples now use
  Chainlink USDC/USDT routes, and PHA is explicitly limited to noncommercial rehearsal.
  CI validates every shipped environment config and example route template.
• Cross-org callers can now pass SENTRY_DSN; the example passes the maintenance key and
  bootstrap_maintenance input.

SDKs

@phala/pay 0.9.1, @phala/pay-react 0.9.1, and @phala/pay-server 0.9.1 on npm;
phala-pay 0.9.1 on PyPI.

Verify

deploy/verify-release.sh
checks this release as Deploy does (self-hosting guide).