> For the complete documentation index, see [llms.txt](https://dashpay.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://dashpay.gitbook.io/docs/network-and-ecosystem/x402-settlement-engine.md).

# 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.**


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://dashpay.gitbook.io/docs/network-and-ecosystem/x402-settlement-engine.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.