>_ DOCS / UNDERSTANDING P402
SECURITY
MODEL.
How P402 protects your funds, API keys, and agent spending at every layer — from cryptographic signatures to real-time anomaly detection.
Payment Security (EIP-3009)
P402 uses EIP-3009 TransferWithAuthorization for on-chain settlement. This removes the standard ERC-20 two-step (approve → transferFrom) and replaces it with a single off-chain signature that the P402 Facilitator submits on-chain.
Every authorization contains a 32-byte nonce. P402 records used nonces in both PostgreSQL and Redis. Any attempt to resubmit the same nonce returns REPLAY_DETECTED immediately — before any on-chain call is made.
validBefore and validAfter timestamps bound the authorization to a 1-hour window by default. After validBefore passes, the authorization is rejected even if it was never used.
The value field in the authorization must match paymentRequirements.maxAmountRequired exactly. Any discrepancy returns AMOUNT_MISMATCH before on-chain execution.
Signatures are bound to the USDC contract address on Base (domain separator). A signature valid on Base cannot be replayed on any other chain or contract.
The Facilitator checks Base gas price before every settlement. If gas exceeds 50 gwei (configurable), the settlement is rejected with GAS_PRICE_TOO_HIGH. This prevents economic attacks during gas spikes.
API Key Security
Raw API keys (p402_live_...) are shown once at creation and immediately discarded. Only the SHA-256 hash is stored in the database. Even if the database were compromised, raw keys cannot be recovered.
Key verification uses a constant-time comparison (timingSafeEqual) to prevent timing attacks. A slow comparison loop would leak information about how many characters match.
Keys are prefixed p402_live_ (production) or p402_test_ (test mode). This lets you grep logs for accidental key exposure without the key being usable.
Revoked keys are rejected in < 2ms. The revocation propagates to all API gateway nodes via Redis pub/sub — no propagation delay.
Billing Guard
Six independent layers protect against runaway spend. All layers fail closed — when a layer trips, the request is rejected rather than allowed through.
Threat Model
Security disclosures
If you discover a security vulnerability in P402, please report it to security@p402.io. We acknowledge all reports within 24 hours and aim to patch critical vulnerabilities within 72 hours. We do not pursue legal action against good-faith researchers.