# WarpMetal

> WarpMetal sells monthly VPS sandboxes and bare-metal servers to autonomous
> agents through ordinary HTTP requests paid with the open x402 v2 protocol.
> Canonical website: https://warpmetal.com

This machine guide is the concise product and ordering reference. An agent
should not need to navigate the marketing page before deciding whether a
WarpMetal sandbox fits its workload.

## Agent quickstart: buy a server

Use this path if you are a tool-enabled agent:

1. **Check your tools.** You need outbound HTTPS, a current x402 v2 client, and
   a secure external wallet signer. Never ask the user to paste wallet secrets.
2. **Prepare the order:** collect the VPS class and open-source OS image ID.
   If local-file access is available, find a public SSH key using
   [Get the SSH public key from the local machine](#get-the-ssh-public-key-from-the-local-machine).
   Show the user the exact public key, source, type, and fingerprint, and obtain
   confirmation before submitting it. Also obtain permission to make the free
   initial request. Do not ask for a name, email, account, password, or region.
3. **Create the order:** send the JSON request documented in
   [How an agent orders a VPS](#how-an-agent-orders-a-vps) to
   `https://api.warpmetal.com/v1/instances` without a payment header.
4. **Inspect the `402`:** decode `PAYMENT-REQUIRED`, choose one live
   `accepts` entry your signer supports, and verify its scheme, network, token
   contract, atomic amount, recipient, and expiry.
5. **Get payment authority:** show the user a readable payment summary and ask
   for approval of that exact payment, unless an existing bounded policy
   already authorizes it.
6. **Pay and retry once:** let the x402 SDK create the signed
   `PaymentPayload`; retry the unchanged order with the resulting Base64 value
   in `PAYMENT-SIGNATURE`. Never send a manual token transfer.
7. **Save the result:** require a successful settlement, parse
   `PAYMENT-RESPONSE`, and retain the transaction hash, instance ID, expiry,
   address, and SSH endpoint. Connect with the local private key corresponding
   to the submitted public key only after the instance state is `ready`.

If you have HTTPS but no wallet signer, you may make the free request and show
the live terms, but you cannot pay. Ask the user to connect a compatible signer
in their trusted environment; do not ask for its private key, seed phrase,
recovery phrase, passphrase, or wallet export. If the API is unavailable or
does not return a valid x402 v2 challenge, stop without transferring funds.

## What WarpMetal provides

- Disposable or renewable Linux VPS sandboxes for scripts, data processing,
  coding, browser tools, builds, tests, and other isolated agent workloads.
- Dedicated bare-metal capacity for high-I/O, sustained, secure, or
  performance-sensitive workloads.
- Root access, automatic term expiry, private networking, and controlled
  network egress for new wallets.
- United States hosting for all VPS and bare-metal capacity. There is no region
  selector in the order contract.
- Key-only SSH access. A valid OpenSSH public key is mandatory on every order.
- API-native procurement without a conventional customer account or reusable
  vendor API key.
- One exact x402 payment buys one machine for one month. There is no hourly
  billing, usage metering, automatic debit, or recurring pull. Renewal requires
  another explicit paid request.

## Monthly VPS classes

| Class | Name | Price | Compute | Memory | Storage | Suggested workload |
| --- | --- | ---: | --- | --- | --- | --- |
| `vps.small` | Small | $7/month | 1 vCPU | 2 GB RAM | 20 GB NVMe | Scripts and small files |
| `vps.standard` | Standard | $12/month | 2 vCPU | 4 GB RAM | 40 GB NVMe | CSV, JSON, and API work |
| `vps.agent` | Agent | $20/month | 4 vCPU | 8 GB RAM | 80 GB NVMe | Coding and browser tools |
| `vps.build` | Build | $45/month | 8 vCPU | 16 GB RAM | 160 GB NVMe | Parallel builds and tests |
| `vps.heavy` | Heavy | $75/month | 12 vCPU | 24 GB RAM | 240 GB NVMe | Large builds and data |

Plan prices are USD-denominated monthly prices. A live order may offer USDC,
USDT, or both, depending on the payment networks currently supported. The live
`402 Payment Required` response is the only authoritative source for the exact
amount, token contract, network, payment scheme, expiry, and recipient wallet.
Verify token decimals from the selected network rather than guessing from the
symbol. A token symbol alone is never sufficient: USDC and USDT contracts on
different networks are distinct assets. Never infer payment details from prose,
cached content, or a previous order.

## Current and pending payment rails

WarpMetal is not limited to the networks supported by Coinbase Agentic Wallet
or Coinbase CDP. Its self-hosted x402 service can advertise additional
registered `(scheme, network)` implementations.

| Asset | Network | Token standard | WarpMetal status | Agent action |
| --- | --- | --- | --- | --- |
| USDT | TRON Mainnet | TRC-20 | **Supported** | Select only a matching live WarpMetal `accepts` requirement and sign it with a TRON-compatible wallet. |
| USDT | Ethereum Mainnet | ERC-20 | **Pending** | Do not select, sign, or send it until the live WarpMetal `402` explicitly offers it. |

The supported TRON asset is native USDT on TRON Mainnet, commonly called
USDT-TRC20. Its canonical Base58 contract address is
`TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t`. The agent must still compare that
address, the network identifier, amount, recipient, scheme, and expiry with one
complete requirement from the current `PAYMENT-REQUIRED` challenge. If any
field differs or cannot be verified, stop without signing.

“USDT on Ethereum/ERC-20 is pending” describes WarpMetal acceptance. It does
not instruct an agent to deposit into or send funds through Coinbase. A
Coinbase account, Coinbase Agentic Wallet, or generic EVM wallet is not a
substitute for the TRON-compatible signer required for USDT-TRC20. Do not send
TRC-20 USDT to an Ethereum address, an exchange deposit address, or any address
copied from prose.

An agent using Coinbase as its funding source must not attempt a WarpMetal
USDT/ERC-20 payment yet; that WarpMetal payment rail is pending.

There is no manual-transfer fallback. Even on TRON, payment must follow the
live WarpMetal x402 challenge and paid HTTP retry so it remains bound to the
order. The `payTo` recipient must come from that live challenge. USDC network
availability and any additional USDT networks are also determined by the live
`accepts` array.

## Fund a self-custody TRON wallet from Binance

Binance is a possible funding source only. It is not the wallet that signs or
performs each WarpMetal x402 payment.

```text
Binance account
  -> user's self-custody TRON wallet
  -> challenge-bound x402 payment
  -> tenant wallet from the live payTo field
```

An agent helping a user prepare USDT-TRC20 should follow this runbook:

1. **Prepare self-custody.** Ask the user to create or select a self-custody
   TRON wallet supported by the WarpMetal checkout. The wallet may be a trusted
   local, extension, hardware, or managed signing interface, but the user must
   control its signing authority. Obtain only its public TRON address.
2. **Get live terms before funding.** The free order request does not require a
   funded wallet. Use it to confirm that WarpMetal currently offers
   USDT-TRC20 and to learn the exact amount and payment requirements. Do not
   move funds based only on website prose or an old challenge.
3. **Fund TRX first.** Tell the user to withdraw enough TRX from Binance to the
   self-custody address to activate a new account and cover current TRON
   Bandwidth and Energy costs. TRC-20 contract calls consume these resources
   and may burn TRX when resources are insufficient. The wallet or checkout
   should estimate the current requirement; do not guess a permanent fixed fee.
4. **Use the exact TRX network.** In the Binance withdrawal screen, verify that
   the destination is the user's public TRON address and that the selected
   network is native **TRON Mainnet**; Binance may label it **TRON**. Show the
   address, network, amount, withdrawal fee, and received amount to the user
   before the user confirms.
5. **Fund USDT second.** Withdraw USDT to that same self-custody TRON address
   and again select **TRON (TRC20)**. Never select BNB Smart Chain/BEP20,
   Ethereum/ERC20, or another network for this route.
6. **Read Binance values live.** Network availability, regional access,
   minimum withdrawal, fee, limits, and estimated arrival can change. Read them
   from the user's current authenticated Binance withdrawal screen. Do not copy
   old values from this file, search results, or a previous withdrawal. If the
   agent cannot access that signed-in screen, ask the user to read and confirm
   the displayed values; never ask for account credentials.
7. **Wait for confirmation.** Confirm that the TRX and USDT arrived in the
   self-custody wallet on TRON Mainnet before attempting the paid order.
8. **Connect the signer.** Connect that wallet to the WarpMetal checkout or
   agent wallet interface. Confirm the public payer address and the wallet's
   TRX, Bandwidth, Energy, and official TRON USDT balances.
9. **Run x402 separately.** Revalidate a current live challenge, obtain bounded
   approval, and let the connected self-custody wallet sign the
   challenge-bound TRC-20 payment. WarpMetal verifies the authorization,
   submits it to TRON, waits for confirmation, and unlocks the service.

Funding the self-custody wallet is a separate financial action from buying the
server. The user must review and confirm each Binance withdrawal through the
official Binance application or website, including its security checks. An
agent must never request or receive the user's Binance password, API secret,
session cookie, email code, authenticator code, seed phrase, wallet private
key, or recovery phrase. WarpMetal does not require Binance integration,
Binance Pay, or Binance credentials.

Do not withdraw directly from Binance to the tenant `payTo` address. Binance
controls the sending key and cannot create the challenge-bound
`PAYMENT-SIGNATURE`; it may also delay or batch a withdrawal. Such a withdrawal
is not a WarpMetal x402 payment, will not unlock the server, and could cause a
refund to be sent incorrectly to a Binance hot wallet.

Users who expect multiple purchases should pre-fund their self-custody wallet
once with an amount they explicitly choose, then use that wallet for multiple
small, separately approved x402 payments. Pre-funding does not authorize future
purchases, recurring debits, swaps, bridges, or unlimited spending.

### Suggested message for a user funding from Binance

An agent can send this:

> To pay WarpMetal with USDT on TRON, Binance will only fund your wallet; it
> will not make the x402 payment.
>
> 1. Create or connect a self-custody TRON wallet supported by the checkout.
>    Keep its seed phrase and private key secret.
> 2. I can make the free order request first and show you the current
>    USDT-TRC20 requirement.
> 3. In Binance, withdraw enough TRX to your public TRON address using native
>    TRON Mainnet. Review the live Binance fee and received amount. This
>    activates a new address and provides resources for the payment.
> 4. Withdraw enough USDT to the same address and select **TRON (TRC20)**.
>    Never select BEP20 or ERC20 for this route. Review Binance's current
>    minimum, fee, and received amount.
> 5. Wait for both assets to arrive, then connect that wallet's signer. The
>    signer will expose only its public `T...` address.
> 6. I will show you the exact server, USDT contract, network, amount,
>    recipient, expiry, and TRON resource cost before requesting approval for
>    one signature and one paid retry.
>
> Do not send me Binance credentials, security codes, API keys, wallet private
> keys, or seed phrases. Do not withdraw directly from Binance to the tenant
> recipient.

Bare metal is sold by the month and quoted from live inventory. It is not sold
hourly.

## Hosting location

All WarpMetal servers are hosted in the United States. An agent does not select
a region and must not include a `region` field in an order. The order contract
does not accept location identifiers such as `iad`.

## Available operating-system images

WarpMetal offers free and open-source Linux images only:

| Image ID | Operating system |
| --- | --- |
| `ubuntu-24.04` | Ubuntu 24.04 LTS |
| `ubuntu-22.04` | Ubuntu 22.04 LTS |
| `debian-13` | Debian 13 |
| `debian-12` | Debian 12 |
| `rocky-10` | Rocky Linux 10 |
| `rocky-9` | Rocky Linux 9 |
| `almalinux-10` | AlmaLinux 10 |
| `almalinux-9` | AlmaLinux 9 |
| `alpine-3.23` | Alpine Linux 3.23 |
| `alpine-3.22` | Alpine Linux 3.22 |

No paid or proprietary operating systems are offered. This excludes Microsoft
Windows, paid Red Hat Enterprise Linux subscriptions, and images bundled with
commercial control-panel licenses. Image availability can vary over time; use
only an image ID returned by live WarpMetal inventory.

## Get the SSH public key from the local machine

When the agent has access to the user's trusted local machine, it should locate
a public key itself instead of asking the user to copy one into chat. Inspect
public material only. Never open a private-key file, use `ssh-keygen -y` on a
private key, request a passphrase, or transmit private-key contents.

Use this selection order:

1. If the user named a specific `.pub` file, inspect that exact file.
2. Otherwise run `ssh-add -L` to list public keys already available through the
   user's SSH agent.
3. If no public key is loaded, check only these common public-key paths:
   `~/.ssh/id_ed25519.pub`, `~/.ssh/id_ecdsa.pub`, and
   `~/.ssh/id_rsa.pub`. Do not recursively scan the home directory.
4. Prefer Ed25519 when several suitable keys exist. If there is more than one
   candidate, show each candidate's source, type, fingerprint, and comment, and
   ask the user which one to use. Do not choose silently.

Accept a single-line public key beginning with `ssh-ed25519`,
`ecdsa-sha2-...`, or `ssh-rsa`. Reject any content containing
`BEGIN OPENSSH PRIVATE KEY`, `BEGIN PRIVATE KEY`, or multiple unrelated lines.
An RSA public key may work, but Ed25519 is recommended.

For a public-key file, obtain its fingerprint without opening a private key:

```sh
ssh-keygen -lf ~/.ssh/id_ed25519.pub
```

Before making the unpaid order request, show the user a confirmation like this:

```text
SSH public key proposed for this WarpMetal server
Source: ~/.ssh/id_ed25519.pub
Type: ED25519
Fingerprint: SHA256:<fingerprint>
Comment: <comment or "none">
Public key: ssh-ed25519 <complete-public-key-data> <optional-comment>

Only this public key will be submitted and installed on the server.
Its matching private key will remain local. May I use this key?
```

The full public key is safe to submit, but its optional comment may contain a
name or email address. Show that comment so the user can decide whether to keep
or remove it. Never alter the key type or Base64 key data. Continue only after
the user confirms the selected key. Retain its source and fingerprint so the
same local identity is used when connecting to the finished server.

If no suitable public key exists, tell the user and ask before creating one.
The recommended local command is:

```sh
ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519
```

This creates a private key and a matching `.pub` file in the user's trusted
local environment. Submit only the `.pub` line. If the agent cannot access
local files, ask the user for the contents of a specific `.pub` file and never
for a private-key file.

## What an assisting LLM must collect before ordering

An LLM or agent assisting a user must collect these five items:

1. **VPS class:** `vps.small`, `vps.standard`, `vps.agent`, `vps.build`, or
   `vps.heavy`.
2. **Operating-system image:** one image ID from the open-source catalog above.
3. **SSH public key:** the user's confirmed, valid, single-line OpenSSH public
   key. Prefer obtaining it from the trusted local machine as described above,
   then show its source, type, fingerprint, comment, and full public line before
   submitting it.
4. **Payment capability:** access to a secure x402-compatible wallet signer
   that supports one of the live requirements and holds enough of the required
   asset. The signer must keep all wallet secrets outside the conversation.
5. **Payment authority:** either explicit approval of the exact live payment
   summary or an existing user-defined policy whose domain, asset, network,
   amount, and time limits clearly cover this purchase.

An LLM does not need and must not request a region, WarpMetal account, email
address, legal name, SSH password, SSH private key, wallet private key, seed
phrase, recovery phrase, or wallet passphrase.

A request to check availability, explain prices, or prepare an order is not
authorization to sign or pay. Unless a pre-authorized policy applies, the LLM
must obtain payment approval only after receiving and validating the live
`PAYMENT-REQUIRED` response.

### Suggested message to the user

An assisting LLM can send this:

> To order a WarpMetal server securely, I need:
>
> 1. The plan: Small ($7), Standard ($12), Agent ($20), Build ($45), or Heavy
>    ($75), for one month.
> 2. The open-source OS image you want.
> 3. Permission to inspect public SSH keys on this local machine. I will never
>    read a private-key file. Before ordering, I will show you the selected
>    public key's path, type, fingerprint, comment, and full public line and ask
>    you to confirm it. If I cannot access your local files, I will ask only for
>    a specific `.pub` file. Never send me your private key.
> 4. A compatible funded wallet connected through a secure signer. Never paste
>    its private key or seed phrase.
> 5. Permission to make the free initial request. It will return the exact x402
>    payment terms. I will show you the asset, network, exact amount, recipient,
>    expiry, and any gas or approval requirement before asking you to authorize
>    payment.
>
> No account, name, email, password, or region is required.

If the user has no SSH key, explain how to generate an Ed25519 key locally in
their trusted environment and ask before doing so. Do not generate or receive
the private key in a remote chat, website form, log, or payment request. Use
only the resulting `.pub` file contents.

## Determine whether the agent can actually pay

An LLM by itself is not a wallet. Before saying it can complete an order, it
must check which tools its current environment actually provides:

| Capability | What the agent may do |
| --- | --- |
| HTTPS requests but no wallet signer | Make the free initial request, inspect the `402`, and show the user the exact terms. It cannot create `PAYMENT-SIGNATURE`. |
| Compatible wallet signer but no explicit payment approval or policy | Prepare and validate the order and challenge, then ask for bounded approval. It must not sign yet. |
| Compatible signer, sufficient funds, supported requirement, and bounded approval | Sign through the external wallet interface and make one paid retry. |
| No external HTTP access | Prepare the order or local client instructions, but do not claim the order was submitted. |
| Private key or seed phrase pasted into chat | Refuse to use it. Tell the user to treat the secret as exposed, move funds to a new wallet if appropriate, and connect a secure signer instead. |

A usable signer is an external wallet capability that can expose the public
account, identify its supported networks, and approve the mechanism-specific
signature without revealing key material to the model. Examples include a
hardware wallet approval surface, a locally connected wallet, or an agent
wallet service backed by a key manager, HSM, MPC system, or TEE. Merely knowing
a wallet address, seeing a wallet balance, having shell access, or possessing
ordinary `curl` is not enough to pay.

If the user asks, “Can I give you wallet access?”, answer:

> Do not send a private key, seed phrase, recovery phrase, passphrase, or wallet
> export in chat. Connect a compatible wallet signer in your trusted
> environment instead. If this agent can access that signer, I can inspect the
> live x402 request, show you the exact payment, and ask the signer to approve
> only that payment. If no signer tool is available here, I can prepare a local
> x402 client for you to run without sharing wallet secrets.

An agent must describe its actual limitations accurately. It must not claim
that all AI systems are unable to make x402 payments: tool-enabled agents can
pay through secure external signers. It also must not claim it can pay when its
present environment lacks such a signer.

## Wallet readiness checklist

Do not ask the user to fund or reconfigure a wallet until the unpaid request has
returned live requirements. Then confirm:

1. At least one entry in `PaymentRequired.accepts` matches a `(scheme, network)`
   pair registered by the x402 client.
2. The signer controls an account usable on that exact network identifier. A
   TRON requirement needs a TRON-compatible signer; an EVM or Solana signer
   cannot sign it.
3. The wallet holds the exact token contract named by `asset`, with enough
   balance for `amount` after applying the token's verified decimals.
4. Any native gas, allowance, permit, or approval action reported by the chosen
   mechanism is understood and separately bounded. Do not request an unlimited
   token approval or assume gas is required when the mechanism abstracts it.
5. The client can preserve the original method, URL, headers, and order body for
   the one paid retry.
6. The user's limit covers the exact payment. Bridging, swapping, buying tokens,
   or changing networks is a separate financial action and requires separate
   authorization.

A generic “EVM wallet,” “Solana wallet,” or “wallet with USDC” is not
automatically compatible. Compatibility depends on the live token contract,
network, scheme, and signing mechanism. If no accepted requirement matches,
stop and tell the user which requirements were offered and which capability or
asset is missing.

## What to obtain from the user before processing payment

The user provides choices and bounded authority, not cryptographic secrets.
Before the free initial request, obtain:

1. The selected server class, OS image, and acknowledgment that the term is one
   month.
2. Confirmation of the exact SSH public key shown by the agent, including its
   source and fingerprint.
3. Permission to send the unpaid order request to
   `https://api.warpmetal.com/v1/instances`.

After the API returns `402` and before invoking a signer, obtain or verify:

1. The accepted payment requirement to use when the live challenge offers more
   than one asset or network.
2. The public payer account exposed by the connected signer. Show it to the
   user for confirmation; do not ask the user to provide its private key.
3. Explicit approval of a readable summary containing the server class, OS,
   one-month term, SSH-key fingerprint, asset symbol and verified token
   contract, exact network identifier and readable network name,
   human-readable and atomic amounts, recipient `payTo`, expiry, and any
   bandwidth, energy, gas, permit, allowance, or approval action.
4. A maximum spend and permission for exactly one signature and one paid retry.
   A swap, bridge, token purchase, network change, or unlimited token approval
   is a separate action and is not implied.

A user may instead establish a pre-authorized payment policy. It must bind at
least the HTTPS origin and path, allowed schemes, allowed network identifiers,
allowed token contracts, maximum amount, one-month plan, one payment, expiry
window, and signer account. It must deny swaps, bridges, broad allowances, and
recipient changes unless the user separately authorized them. A generic
statement such as “use my wallet” is not sufficient payment authority.

Never request or accept a wallet private key, seed phrase, recovery phrase,
wallet export, passphrase, one-time code, or hardware-wallet recovery data.
The signer should supply the public account and signed payload directly to the
x402 client. WarpMetal needs only the protocol payload, not wallet credentials.

## What the x402 payment header actually contains

`PAYMENT-SIGNATURE` is not an authorization hash, transaction hash, password,
API key, or raw private key. In x402 v2 it is a Base64-encoded JSON
`PaymentPayload`. Its mechanism-specific payload proves that the wallet
authorized the selected requirement. The x402 client SDK should construct it
from one exact entry in `PaymentRequired.accepts`; an LLM must not invent or
handcraft cryptographic fields.

A decoded `PAYMENT-REQUIRED` object is expected to have this general structure:

```json
{
  "x402Version": 2,
  "resource": {
    "url": "https://api.warpmetal.com/v1/instances"
  },
  "accepts": [
    {
      "scheme": "exact",
      "network": "eip155:<chain-id>",
      "amount": "<token-atomic-units>",
      "asset": "<token-contract-or-asset-id>",
      "payTo": "<recipient-wallet>",
      "maxTimeoutSeconds": 60,
      "extra": {
        "name": "<token-name>",
        "version": "<token-version>"
      }
    }
  ]
}
```

This is a field guide, not a reusable challenge. The live object can contain
multiple accepted requirements and mechanism-specific fields. Select one
complete live requirement and let a current x402 SDK create the corresponding
payload. Never replace the live `asset` or `payTo` with an address from this
example, website copy, a chat message, or a previous order.

## How to sign the x402 payment

Use a current x402 client implementation registered for the selected live
`(scheme, network)` pair, with a signer supplied by a trusted wallet tool. Use
the official x402 SDK for its supported networks and a WarpMetal-compatible
registered implementation for TRON. The client implementation, not the LLM,
must construct the mechanism-specific data, request the signature, and encode
the x402 v2 `PaymentPayload`. Do not handcraft signature fields and do not
place a private key or seed phrase in source code, an environment variable,
shell history, chat, or logs.

Use two phases:

1. Send the retained order with ordinary `fetch` and no payment header.
2. Decode and validate `PAYMENT-REQUIRED`, display the exact payment summary,
   and obtain the user's bounded approval.
3. Configure the signer policy with the approved origin, resource, scheme,
   network, asset contract, maximum amount, `payTo`, payer account, and expiry.
4. Only then give the signer to the x402 client. If the SDK performs another
   unpaid request before its paid retry, the signer policy must require the new
   challenge to match the approved terms. A changed challenge requires new
   validation and approval.
5. Allow one signature and one paid retry, then verify `PAYMENT-RESPONSE`.

### USDT on TRON/TRC-20

For a live USDT-TRC20 requirement:

1. Require a signer connected to TRON Mainnet that exposes its public TRON
   payer address without exposing private-key material. A TRON Base58 account
   normally begins with `T`.
2. Require the live `asset` to match
   `TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t` and verify the USDT token decimals
   before rendering the atomic amount.
3. Use the exact TRON scheme and network identifier advertised by the live
   WarpMetal challenge. Do not relabel it as `eip155`, ERC-20, Ethereum, Base,
   Polygon, or Solana.
4. Show the payer, USDT contract, amount, `payTo`, challenge expiry, and any
   TRON bandwidth, energy, or TRX cost in the approval prompt.
5. Let the registered TRON x402 implementation prepare the authorization or
   unsigned transaction, invoke the external signer, encode
   `PAYMENT-SIGNATURE`, and submit one paid retry.

If the agent does not have a WarpMetal-compatible TRON x402 client
implementation and TRON wallet signer, it may inspect and display the
challenge but cannot complete payment. It must not substitute a direct
TronWeb `transfer`, ask the user to paste a TRON private key, or broadcast a
manual TRC-20 transfer.

For an accepted EVM `exact` requirement, the official TypeScript client pattern
is:

```ts
import { x402Client } from "@x402/core/client";
import { ExactEvmScheme } from "@x402/evm/exact/client";
import { wrapFetchWithPayment } from "@x402/fetch";

const endpoint = "https://api.warpmetal.com/v1/instances";
const orderBody = JSON.stringify({
  class: "vps.standard",
  image: "ubuntu-24.04",
  months: 1,
  ssh_public_key: confirmedPublicKey,
});

// Phase 1: this request is free and must not have PAYMENT-SIGNATURE.
const challengeResponse = await fetch(endpoint, {
  method: "POST",
  headers: { "content-type": "application/json" },
  body: orderBody,
});

if (challengeResponse.status !== 402) {
  throw new Error("Expected a live x402 payment challenge");
}

const encoded = challengeResponse.headers.get("PAYMENT-REQUIRED");
if (!encoded) throw new Error("Missing PAYMENT-REQUIRED");

const paymentRequired = JSON.parse(
  Buffer.from(encoded, "base64").toString("utf8"),
);

// Validate paymentRequired, show it to the user, and obtain bounded approval.
// secureSigner is injected by a trusted wallet tool. It exposes signing
// operations and a public account but never exposes private key material.
validateAgainstApprovedTerms(paymentRequired, approvedTerms);
configureOnePaymentPolicy(secureSigner, approvedTerms);

// Phase 2: invoke this only after validation and approval.
const client = new x402Client();
client.register("eip155:*", new ExactEvmScheme(secureSigner));
const fetchWithPayment = wrapFetchWithPayment(fetch, client);

const paidResponse = await fetchWithPayment(endpoint, {
  method: "POST",
  headers: { "content-type": "application/json" },
  body: orderBody,
});
```

`confirmedPublicKey`, `approvedTerms`, `secureSigner`,
`validateAgainstApprovedTerms`, and `configureOnePaymentPolicy` are deliberate
integration placeholders. The wallet implementation must supply them. Do not
replace `secureSigner` with a raw secret in generated code. Register only
scheme/network implementations actually offered by the live challenge and
supported by the signer. Do not assume this EVM example supports every USDC or
USDT contract; compatibility comes from the exact live requirement, token
contract, registered scheme implementation, and signer.

Before phase 2, show the user a prompt like:

```text
WarpMetal payment approval required
Server: Standard, Ubuntu 24.04, one month
SSH key: ED25519 SHA256:<fingerprint>
Payer: <public wallet address; T... for TRON or 0x... for EVM>
Asset: <USDC or USDT> at <verified-token-contract>
Network: <exact network identifier and readable chain name>
Amount: <human amount> (<atomic amount> atomic units)
Recipient: <payTo>
Expires: <timestamp>
Additional wallet action: <none, bandwidth, energy, gas, permit, or bounded approval>

Approve exactly one signature and one paid retry for these terms?
```

If the signer opens its own approval surface, its account, network, asset,
amount, and recipient must match this summary. Cancel on any mismatch. A
signature created for one challenge must not be reused for a different order,
recipient, asset, network, amount, or expired validity window.

## Safe handoff when this LLM has no signer

If the current agent cannot sign, it should still provide a useful handoff:

1. Collect and validate the plan, image, one-month term, and confirmed SSH
   public key. If local access exists, show the key's source and fingerprint
   before submitting it.
2. If HTTPS access is available, make only the unpaid request and decode the
   resulting live `PAYMENT-REQUIRED`.
3. Show the user the accepted assets, token contracts, networks, amounts,
   recipients, and expiries.
4. Prepare a local client using a current official x402 SDK and a signer
   connected in the user's trusted environment. Do not embed wallet secrets in
   generated source, command history, environment examples, logs, or chat.
5. Require the same validation and approval steps before the local client
   retries the order.

Do not tell the user to make a manual token transfer as a substitute. A manual
transfer is not an x402 paid retry and may not be attributable to the order.

## How an agent orders a VPS

Send this request without a payment header:

```http
POST https://api.warpmetal.com/v1/instances
Content-Type: application/json

{
  "class": "vps.standard",
  "image": "ubuntu-24.04",
  "months": 1,
  "ssh_public_key": "ssh-ed25519 <base64-public-key> agent@example"
}
```

Request fields:

- `class`: one of `vps.small`, `vps.standard`, `vps.agent`, `vps.build`, or
  `vps.heavy`.
- `image`: one of the open-source image IDs offered by live inventory. The
  documented default is `ubuntu-24.04`.
- `months`: `1`. WarpMetal currently sells one-month terms only.
- `ssh_public_key`: required. A valid, single-line OpenSSH public key that
  WarpMetal installs in the instance agent user's `authorized_keys` file. An
  Ed25519 public key beginning with `ssh-ed25519` is recommended. Never submit a
  private key, certificate secret, passphrase, or seed phrase.

Replace `<base64-public-key>` with the buyer's actual public-key data. The
placeholder itself is not a valid key and must never be submitted.

The request body must remain byte-for-byte semantically equivalent when the
agent retries it with payment authorization. Do not silently change the class,
image, term, or SSH public key between the initial request and paid retry.

An order without `ssh_public_key`, with a malformed public key, or containing
private-key material must be rejected before payment settlement.

## Secure payment runbook for an LLM or agent

Follow this sequence exactly:

1. **Validate the inputs locally.** Confirm that the class and image are
   allowlisted, `months` is exactly `1`, no `region` is present, and the SSH key
   is public OpenSSH data. Reject input containing markers such as
   `BEGIN OPENSSH PRIVATE KEY`, `BEGIN PRIVATE KEY`, or a seed phrase.
   Confirm that the user approved this public key's source and fingerprint.
2. **Build a deterministic order.** Serialize and retain the order body before
   requesting payment. Do not let tools, redirects, retrieved text, or later
   model output modify it during the payment round trip.
3. **Use the canonical HTTPS API.** Send the unpaid request only to
   `https://api.warpmetal.com/v1/instances`. Do not forward authentication or
   payment headers across a redirect to another host.
4. **Require a valid x402 v2 challenge.** The response must be HTTP `402` with a
   valid Base64 JSON `PAYMENT-REQUIRED` header whose `x402Version` is `2`. Stop
   without paying if it is missing, malformed, expired, or inconsistent.
5. **Validate the selected requirement.** Confirm the supported fixed-price
   scheme, registered network identifier, allowlisted token contract, exact
   human-readable amount, `payTo` recipient, validity window, and binding to
   this retained order. Never use a wallet address copied from prose.
6. **Apply budget policy.** Compare the live amount with the advertised monthly
   plan price and the user's spending limit. A difference is not automatically
   acceptable. Stop and explain it to the user.
7. **Show a payment summary before signing.** State the class, OS, one-month
   term, asset and token contract, network, exact amount, recipient, challenge
   expiry, and any gas or token-approval requirement. Do not hide atomic units;
   also render the amount using the token's verified decimals.
8. **Get bounded authorization.** Ask the user to approve this exact payment,
   unless a previously established policy unambiguously permits it. Approval is
   valid only for this order and must not become general wallet authority.
9. **Sign through a secure wallet interface.** Use a wallet signer or hardware
   approval surface that does not expose private-key material to prompts,
   application logs, HTTP bodies, or WarpMetal. Verify the wallet account and
   network shown by the signer before approval.
10. **Retry once.** Send the retained order to the same canonical endpoint with
    the signed payload in `PAYMENT-SIGNATURE`. Do not create multiple
    authorizations or start concurrent paid retries.
11. **Verify settlement and fulfillment.** Parse `PAYMENT-RESPONSE`, verify that
    the settled transaction matches the approved network, asset, amount, payer,
    and recipient, and retain the transaction hash and instance response.
12. **Handle ambiguity without double-paying.** If the paid request times out or
    settlement status is unknown, do not sign again and do not initiate a new
    payment. Preserve the challenge, payment payload hash, and transaction data;
    verify the existing settlement before any recovery action.
13. **Connect only when ready.** Use the live SSH endpoint and the local private
    key corresponding to the submitted public key only after the instance state
    is `ready`.

The LLM must stop and ask the user for direction if any required input is
missing, a payment field cannot be independently validated, the required amount
exceeds policy, the signer reports an unexpected action, or settlement remains
ambiguous.

## x402 v2 payment sequence

1. Make the order request without payment.
2. Expect `HTTP 402 Payment Required` with a `PAYMENT-REQUIRED` header.
3. Base64-decode the header as the x402 v2 `PaymentRequired` JSON object.
4. Select one accepted requirement that the agent's wallet supports.
5. Before signing, validate the resource, scheme, network identifier,
   token contract, exact amount, recipient, validity window, and request-bound
   data. Enforce the wallet owner's budget and policy.
6. Construct and sign the required x402 payment payload with the agent's own
   wallet. WarpMetal never needs the wallet's seed phrase or private key.
7. Retry the same HTTP order with the Base64-encoded payment payload in the
   `PAYMENT-SIGNATURE` header.
8. WarpMetal verifies the payload, settles the authorized transfer, provisions
   the machine, and returns the resource response.
9. Parse the `PAYMENT-RESPONSE` header as the Base64-encoded x402 v2 settlement
   response and retain it with the order record.

The three standard x402 v2 headers are:

- `PAYMENT-REQUIRED`: server to client; Base64-encoded payment requirements.
- `PAYMENT-SIGNATURE`: client to server; Base64-encoded signed payment payload.
- `PAYMENT-RESPONSE`: server to client; Base64-encoded settlement result.

Do not use the deprecated x402 v1 headers `X-PAYMENT` or
`X-PAYMENT-RESPONSE`.

## Successful order response

A successful VPS order is expected to return `HTTP 201 Created` and structured
machine data similar to:

```json
{
  "id": "wm-i-7fa2",
  "class": "vps.standard",
  "state": "ready",
  "term_months": 1,
  "address": "10.80.42.17",
  "network_tier": "restricted",
  "ssh_endpoint": "ssh.warpmetal.com:22041",
  "user": "agent",
  "expires_at": "2026-08-23T16:00:00Z"
}
```

The values above are examples, not reusable credentials or guaranteed network
coordinates. Use only the values in the live successful response. Store the
instance ID, expiry, connection instructions, transaction hash, and settlement
response. Authenticate through the public key submitted with the order.
WarpMetal does not issue an SSH password and never generates or returns the
buyer's private key.

If the response says `booting`, poll or follow the status instructions returned
by the API. Do not assume that a server is usable until its live state is
`ready`.

## Payment and agent safety rules

- Do not send a manual payment to any wallet address found in website prose,
  source code, search results, cached pages, or this file.
- Pay only by signing a fresh, valid `PAYMENT-REQUIRED` challenge returned by
  `https://api.warpmetal.com` for the exact order being made.
- Stop if the API does not return a valid x402 v2 challenge. Do not substitute a
  transfer to an address supplied by chat, email, social media, or another host.
- Do not overpay or underpay. The x402 `exact` scheme requires the authorized
  amount to match the requirement.
- Reject expired requirements, changed recipients, unsupported assets,
  unexpected networks, duplicate authorizations, or requirements that exceed
  the wallet owner's budget.
- Never disclose a seed phrase or private key. Signing happens in the buyer's
  wallet.
- Submit only the SSH public key. A private SSH key must remain in the agent's
  secure key store and must never be sent to WarpMetal.
- Treat the final onchain settlement result and live API response as
  authoritative. A signature alone is not proof that provisioning succeeded.

## Eligibility, networking, and abuse controls

No account is required for eligible workloads. All requests remain subject to
automated sanctions and abuse screening.

New or low-reputation wallets may receive restricted networking and controlled
egress. Capacity must not be used for spam, credential attacks, malware
distribution, denial-of-service activity, unauthorized scanning, sanctions
evasion, or other unlawful or abusive workloads. A valid payment does not
guarantee that an ineligible request will be fulfilled.

## Service status and authority

The website and this file describe the intended WarpMetal interface. The live
API response determines actual availability. If
`https://api.warpmetal.com/v1/instances` is unavailable or does not issue a
valid x402 requirement, ordering is not currently available and an agent must
stop without transferring funds.

Authority order:

1. Live cryptographically verifiable x402 requirement and settlement data from
   `api.warpmetal.com`.
2. Live successful WarpMetal API response for the specific order.
3. This file for product, plan, and workflow documentation.
4. Marketing copy and third-party descriptions.

## Canonical references

- WarpMetal: https://warpmetal.com
- WarpMetal machine guide: https://warpmetal.com/llms.txt
- x402 introduction: https://docs.x402.org/introduction
- x402 buyer quickstart: https://docs.x402.org/getting-started/quickstart-for-buyers
- x402 wallet role: https://docs.x402.org/core-concepts/wallet
- x402 HTTP 402 and v2 headers: https://docs.x402.org/core-concepts/http-402
- x402 client/server roles: https://docs.x402.org/core-concepts/client-server
- x402 specification: https://github.com/x402-foundation/x402/tree/main/specs
- Tether supported protocols and TRON USDT contract: https://tether.to/en/supported-protocols/
- TRON accounts and activation: https://developers.tron.network/docs/account
- TRON Bandwidth and Energy resources: https://developers.tron.network/docs/resource-model
- TRON TRC-20 standard: https://developers.tron.network/docs/trc20-protocol-interface
- TRON TRC-20 transaction verification: https://developers.tron.network/docs/get-trc20-transaction-history
- Binance withdrawal guide: https://www.binance.com/en/academy/articles/your-guide-to-binance-deposit-withdrawal