Security Model

Threat Model

Replay Attacks

Threat: Reusing payment proof to access resource multiple times.

Mitigation: Single-use challenges marked as used after verification. Challenge IDs are unique and time-limited.

Front-Running

Threat: Observing payment and using proof before original requester.

Mitigation: Payment proof includes signature from sender wallet. Only the payer can use the proof.

Challenge Forgery

Threat: Creating fake challenges to trick clients.

Mitigation: Challenges are signed by server. Clients verify signature before payment.

Double Spending

Threat: Using same payment for multiple challenges.

Mitigation: Challenge ID embedded in tx.data. Each payment uniquely bound to one challenge.

Operational Security

• Use HTTPS for all communications
• Rotate token secrets periodically
• Monitor for unusual payment patterns
• Implement rate limiting even with payments
• Use reliable RPC providers with fallbacks

Idempotency

Payment verification is idempotent—verifying the same proof twice returns the same result without side effects.