Skill reference · security — PPOps documentation

This manual targets 0.1.0-beta.3. Read the source and availability policy before installing. Historical reports retain their original scope.

These rules are mandatory.

Merchant daemon

Accept only a RAILGUN shareable viewing key.
Never request or load a merchant mnemonic, spending key, full wallet backup, or payer secret.
Treat the viewing key as confidential financial metadata: it reveals the receiver’s private history even though it cannot spend.
Store config and secret values in separate regular, non-symlink, owner-only files. Pass file paths, not secret values.
Bind to loopback by default. If remote access is required, place an authenticated TLS reverse proxy/private network in front and keep the PPOps API token server-side.
Use independent merchant-signing, API, database-encryption, and webhook keys.
Publish the expected merchant signer through a channel independent of the checkout/request URL.

Payer

Run tools/ppops-payer in a separate trust domain.
Never copy payer secrets to the merchant host or evidence bundle.
Verify request signature, chain, token, amount, expiry, recipient, and expected signer before proof generation.
Run prepare/no-send first. A send requires explicit approval of amount and fee ceilings.
Treat ambiguous submission as pending/recovery work, never permission to retry with new notes.

Reconciliation

Never weaken finality, PPOI, matching, quorum, or exact-once requirements to regain availability.
Never manually mark an intent paid.
Never infer successful payment from a transaction hash or public receipt alone.
Do not fulfill twice: verify HMAC, timestamp, schema, and event-ID uniqueness atomically.

Evidence

Exclude viewing/spending material, API and HMAC keys, RPC credentials, transaction hashes, 0zk/EVM addresses, encrypted memo references, externalReference, invoice/customer identifiers, and raw logs containing any of them.

Read repository SECURITY.md, docs/SECURITY.md, and docs/THREAT-MODEL.md before handling real value.