# x402 Settlement Engine

The **x402 Settlement Engine** is DashPay’s core mechanism for linking **offline payment proofs** to **on-chain finality** — enabling seamless, machine-verifiable settlement of value that begins in disconnected environments and concludes with cryptographic trust.

Inspired by the long-unused HTTP 402 “Payment Required” status code, x402 introduces a **standardized request/response format for payments**, allowing agents, apps, devices, or humans to request a service or asset and be challenged with a verifiable payment requirement — even without an account or UI.

***

#### **How x402 Works in DashPay**

1. **Request Triggered**\
   A device, user, or agent attempts to access a service, perform an action, or complete a transaction (e.g. “unlock this door”, “buy this file”, “tap to pay”).
2. **x402 Payment Challenge Issued**\
   The recipient (merchant, API, device) returns a **402 challenge** with a structured payment request — including amount, asset, chain, and optional metadata.
3. **Proof of Payment Generated**\
   The sender responds with an **ephemeral zero-knowledge proof** or a signed token, confirming they meet the required balance or payment conditions — without revealing identity or address.
4. **Local Acceptance & Logging**\
   The recipient verifies the proof offline. If valid, the action is approved and the transaction is logged as **pending**.
5. **Reconnection & Reconciliation**\
   Once either party regains network access, the stored payment proof is submitted to the x402 engine, which performs **zk-reconciliation**, resolves conflicts, and publishes a final on-chain record.

***

#### **Key Properties**

* **Asynchronous Finality**\
  Payments do not require real-time blockchain interaction. Transactions are trustless, but not network-bound.
* **Chain-Agnostic Design**\
  x402 supports multiple EVM and non-EVM chains (Base, Solana, Polygon, BSC, etc.) and selects networks based on cost, latency, and availability.
* **No Wallet Address Exposure**\
  Transactions do not reveal public keys, wallet addresses, or metadata. All data exchanged is ephemeral and context-specific.
* **HTTP-Compatible Format**\
  x402 payment challenges and responses can travel through standard HTTP request flows, making them developer-friendly and bot-accessible.
* **Facilitator Optionality**\
  Third-party relayers can optionally monitor for payment fulfillment and return confirmation status to off-chain services — useful for merchants, APIs, or automated agents.

***

#### **x402 in Action**

Use cases where the x402 engine shines:

* A vending machine issues a 402 challenge; the user taps and pays locally
* An AI agent hits an API and receives a 402 payment requirement; it fulfills autonomously
* Two users trade value over NFC; the proof settles on-chain via x402 when they reconnect
* A dApp requests a pay-per-access fee; DashPay wallet handles the challenge without prompting

***

#### **Why x402 Matters**

Most payment systems conflate **authorization, identity, and confirmation**. x402 separates them — and builds a new payment layer that is:

* Machine-readable
* Human-optional
* Offline-resilient
* Privacy-preserving
* Future-proof

The x402 Settlement Engine is how DashPay makes **every transaction programmable, verifiable, and final — even when it starts in the dark.**