> For the complete documentation index, see [llms.txt](https://docs.inpuls.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.inpuls.ai/problem-and-solution.md).

# Problem & Solution

<figure><img src="https://1250914366-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FYlvuJiwLvwNQVT4zbMe2%2Fuploads%2Fu4ADPkCkWikp4keoNNXQ%2Fbanner.png?alt=media&amp;token=c9f45dcc-214e-4513-9dca-a0c1fe94d955" alt=""><figcaption></figcaption></figure>

x402 enables pay‑per‑request over HTTP via the `402 Payment Required` status code. Today, merchants usually price their offers in a single asset (e.g., USDC on Base). Buyers, however, often hold *other* assets. **Any‑Asset Routing (AAR)** is a minimal, composable extension that lets a buyer **“pay with what they have”** while the protocol **deterministically routes and settles** to the merchant’s desired asset.

***

AAR defines a standard handshake between client, facilitator (router), and merchant so that:

* Clients can present a `RouteRequest` describing **what they hold** and the **offer they want to satisfy**.
* Facilitators respond with a signed `RouteQuote` defining **how to convert** the buyer’s asset into the merchant’s accepted asset(s) within explicit constraints (amount, slippage, deadline).
* x402 receipts bind `offerId` + `quoteId` + `amountOut` so merchants can **verify locally** without bespoke integration.
* Optional staking and reputation create incentives for high‑quality routing while preserving permissionless participation.

***

The result: **higher conversion, lower integration cost**, and a foundation for further protocol‑level features like split payouts, refunds, and streaming‑402.