Clear interfaces.
Private payments.

Explore Kage’s privacy-first x402 architecture for autonomous agents. This guide covers the integration interface, self-custody model, and payment flow.

The payment lifecycle

x402 is an HTTP payment protocol. A resource server asks for a payment, a client authorizes it, and a facilitator verifies and settles it. Kage's privacy design replaces the directly identifiable payer with a path from a shielded balance.

1. Request

   The agent requests a paid resource, such as GET /v1/inference.

2. Receive HTTP 402

   The seller replies with 402 Payment Required and a PAYMENT-REQUIRED header describing the price, asset, network, and scheme.

3. Sign on your device

   The agent selects a supported scheme and signs a payment using its own keys. It repeats the request with a PAYMENT-SIGNATURE header.

4. Verify and settle

   The seller submits the payload to the facilitator's /verify and /settle routes. A validated transaction is submitted for settlement.

5. Deliver

   After success, the seller returns 200 OK with the resource and a PAYMENT-RESPONSE header. The payment path has no direct link back to the payer's original wallet.

Keep the middleware. Configure the rail.

For the standard exact path, the seller keeps the existing x402 endpoint, USDC price, network, and payTo wallet. Configure a production-ready privacy facilitator that actually supports those requirements.

import { HTTPFacilitatorClient } from "@x402/core/server";

// Same middleware. A private payment rail.
const facilitator = new HTTPFacilitatorClient({
  url: "https://your-kage-node.example/x402",
});

// Keep your routes, prices, and payTo wallet.
// Point this template at your deployed facilitator.

Configure your facilitator URL. Replace the reserved .example address with your deployed endpoint. Confirm that it supports /verify, /settle, and /supported before connecting your server.

Responsibilities remain explicit

The seller specifies what is accepted and owns the receiving wallet. The facilitator verifies the payload and submits settlement. Do not serve a paid resource based on a frontend animation or an unverified receipt.

Confidential and fully shielded designs are not interchangeable with standard exact. They need matching client and server scheme support. Fully shielded receiving additionally needs a seller-side key process.

Your keys, on your machine.

The agent workflow creates keys on your machine, funds a self-custodied shielded balance, prepares privacy work ahead of time, and signs payments only when the agent encounters an accepted 402 offer.

# Agent payment workflow
kage init                  # create keys on your device
kage shield --amount 10    # fund your private balance
kage prepare               # prepare before the 402
kage pay <x402-endpoint>    # sign with your keys, pay privately

The command reference describes the wallet interface. Executing it requires a compatible wallet implementation; a CLI binary is not distributed through this website. Verify the package source, release hash, and deposit address before use.

Before a production implementation

Verify wallet release hashes and audits, store encrypted recovery material, enforce per-payment and total spending limits, and validate the seller's asset, scheme, network, and destination. Retries must reconcile an existing payment rather than blindly create a second one.

Know what is hidden. And what isn't.

Privacy is not an absolute guarantee

Network metadata, deposit and withdrawal timing, distinctive amounts, a small anonymity set, compromised keys, or implementation defects may affect privacy. A shielded payment alone does not hide the HTTP request from the seller or automatically protect the agent's IP address.

Before sending funds, verify the deployment’s supported networks, independent security reviews, fee policy, and key-custody model. Interface compatibility alone does not establish security or mainnet readiness.