Known limitations
Technical boundaries, network dependencies, and security scope for this release.
Current snapshot
- v0.1 supports RAILGUN only.
- The current operational profile is Arbitrum One and native USDC.
- The payer needs enough private native USDC already marked Spendable, including the Broadcaster fee.
- A fresh shield may remain ShieldPending while PPOI matures.
- The bundled payer is reference and verification tooling, requiring appropriate technical knowledge to run.
- The QR hands off a signed request URL; automatic consumer-wallet connections and QR compatibility are not validated.
- Payout, refunds and automatic balance preparation are not implemented.
Privacy boundary
A viewing key cannot spend, but it reveals the receiver’s private history. Compromise of the PPOps host or viewing capability can expose the merchant payment graph. The sender and authorized receiver can recover the encrypted memo.
Infrastructure providers may observe network timing and availability metadata. PPOps does not claim IP-layer anonymity.
External dependencies
Self-hosting does not remove Arbitrum/Ethereum finality, RPC providers, PPOI nodes, RAILGUN SDK/proving artifacts, DNS/network or the merchant webhook receiver. Waku and Broadcaster availability also apply to the optional reference-payer Broadcaster path.
Payment boundary
OBSERVED != FINALIZED != SPENDABLE != PAID
credited settlement = FINALIZED + SPENDABLE + MATCHEDPPOps has no manual paid override. When a dependency or state is unavailable it fails closed instead of weakening finality, PPOI or matching policy.