qWICKpay
the x402 facilitator
for every EVM chain

Facilitator API · x402 v1 and v2

Two endpoints do the
work. Verify, then
settle.

qWICKpay is a self-hosted x402-rs facilitator (Apache-2.0). Your server answers HTTP 402; the payer's agent signs an authorization; you hand that signed object to us and we broadcast it and pay the gas.

We never hold the money. The payer signs "pay this merchant exactly this much" — a facilitator can only relay that or refuse it. Which is why the fee is a flat amount charged to the merchant, never a slice of the payment.

Base URL https://402.wick.pics

The pill in the header checks /health from your browser. Until it reads live, this host is not routed yet — the facilitator runs on loopback and these docs go live the moment the hostname does.

01 · Endpoints

The whole surface.

Six routes. Bodies are JSON. Both x402 envelope versions are accepted — send x402Version: 1 or 2 and the same field appears in the reply.

Table scrolls sideways →

EndpointAuthWhat it does
GET/supported none The list of {x402Version, scheme, network} kinds this facilitator will accept, plus the signer address that pays gas on each chain. Read it at boot instead of hard-coding a chain list. Cached 60s at the edge of our gate.
GET/health none Liveness. 200 means the facilitator answered. Anything else means it did not — treat a 502 here as "do not present payments right now".
POST/verify none Is this signed authorization valid, right now, for these requirements? Returns {"isValid": true|false, "invalidReason": …}. Nothing moves on-chain. Free, and rate-limited per IP and per payer address.
POST/settle X-Merchant-Token Broadcast it. Returns {"success": true, "transaction": "0x…", "network": …}. This is the metered call: one settlement, one unit off your balance. Response carries X-Gate-Settlement-Id and X-Gate-Charged-From (free or bundle).
POST/bundles X-PAYMENT Buy settlements — over x402 itself. Post {"chain":"eip155:369","count":1000} with no payment and you get a 402 with the requirements; post it again with the signed X-PAYMENT header and the 200 body carries your merchant token, once.
POST/echo/{caip2} none A free, verify-only test target for one chain — it answers 402 with a real, signable set of requirements for that network, and on the retry it verifies your signature and tells you what it saw. It never settles, so no money moves and nothing is charged.

Errors are JSON and say why. A refusal carries {"error": "<reason>", "message": "<plain english>"} — for example below_minimum, unsupported_chain, chain_paused, merchant_rate_limit, duplicate_settlement. A 504 settlement_unknown is the one ambiguous answer: the broadcast may have happened, so that authorization is never presented again — check the chain.

02 · Networks

CAIP-2 ids, and who pays the gas.

Click an id to copy it. These rows mirror GET /supported — if the two ever disagree, /supported is right and this table is stale.

Table scrolls sideways →

NetworkCAIP-2SchemesMin settlementGas signer
PulseChain v2 exact 0.0008 USDC 0x3EAaD5af…F743cF
Base v1 exact · v2 exact · v2 upto 0.0010 USDC 0xB1314850…99D2Af
BNB Chain v2 exact · v2 upto 0.0024 USDC 0x71F5a759…b56D69
Polygon v1 exact · v2 exact · v2 upto 0.0021 USDC 0x52D89fFe…de810b2
Arbitrum v2 exact · v2 upto 0.0035 USDC 0xaf9BE973…82724a
Ethereum v2 exact · v2 upto 0.0560 USDC 0x88caE498…9Aae0D

Green = live. Arbitrum and Ethereum are listed but their gas float is not funded, so /supported advertises them and a settlement on them will not go out until we fund the signer. Minimum settlement is that chain's measured gas cost in the payment asset's atomic units: we refuse to spend more on gas than the payment moves. The signer addresses are public, hold gas only, and are echoed back by /supported.

PulseChain runs the permit path. The bridged stables there (USDC 0x15D3…1f07, DAI 0xefD7…F305, USDT 0x0Cb6…1A2f) have no EIP-3009 — measured on-chain: all three revert on TRANSFER_WITH_AUTHORIZATION_TYPEHASH() and answer standard EIP-2612 instead. So PulseChain settles over x402 v2 exact with extra.assetTransferMethod = "permit2", via canonical Permit2 and the deployed X402ExactPermit2Proxy. That is also why there is no upto scheme on PulseChain: that proxy is not deployed there.

PulseChain, measured: no EIP-3009, standard EIP-2612.

Measured 2026-08-28 by eth_call against https://rpc.pulsechain.box (chainId 0x171 = 369), with Base USDC as the control that has to answer. Every cell below is one read-only call anyone can repeat.

Selector correction, read first. The 4-byte selector of TRANSFER_WITH_AUTHORIZATION_TYPEHASH() is 0xa0cc6a68. A value that has been circulating, 0x7ac2ff7b, is not that selector — it reverts on every token, Base USDC included, so any “no EIP-3009” verdict taken with it proves nothing. The rows below use the correct selector and the control comes back positive.

Table scrolls sideways →

TokenChainTRANSFER_WITH_AUTHORIZATION_TYPEHASH()
0xa0cc6a68
RECEIVE_WITH_AUTHORIZATION_TYPEHASH()
0x7f2eecc3
authorizationState()
0xe94a0102
PERMIT_TYPEHASH()
0x30adf81f
nonces()
0x7ecebe00
USDC 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913Base · eip155:84530x7c7c6cdb… ✓0xd099cc98… ✓0 ✓0x6e71edae… ✓0 ✓
USDC 0x15D38573d2feeb82e7ad5187aB8c1D52810B1f07PulseChain · eip155:369REVERTREVERTREVERT0x6e71edae… ✓0 ✓
DAI 0xefD766cCb38EaF1dfd701853BFCe31359239F305PulseChain · eip155:369REVERTREVERTREVERT0x6e71edae… ✓0 ✓
USDT 0x0Cb6F5a34ad42ec934882A05265A7d5F59b51A2fPulseChain · eip155:369REVERTREVERTREVERT0x6e71edae… ✓0 ✓

The PERMIT_TYPEHASH all three return is 0x6e71edae12b1b97f4d1f60370fef10105fa2faae0126114a169c64845d6126c9 = keccak256("Permit(address owner,address spender,uint256 value,uint256 nonce,uint256 deadline)")standard EIP-2612, not DAI’s holder/expiry/allowed variant, even for the token called DAI. EIP-712 domain data a payer client needs: USDC name = "USD Coin from Ethereum", DAI "Dai Stablecoin from Ethereum", USDT "Tether USD from Ethereum"; version = "1" on all three; decimals 6 / 18 / 6.

The contracts the permit path needs are already there. eth_getCode at the addresses x402-rs actually uses (sha256 of the runtime bytecode, first ten hex):

Table scrolls sideways →

ChainPermit2 0x000000000022D473030F116dDEE9F6B43aC78BA3X402ExactPermit2Proxy 0x402085c248EeA27D92E8b30b2C58ed07f9E20001X402UptoPermit2Proxy 0x4020A4f3b7b90ccA423B9fabCc0CE57C6C240002
Base · 8453presentbcf0d9a12e41a4ff7607
PulseChain · 369presentbcf0d9a12eMISSING
Polygon · 137presentbcf0d9a12e41a4ff7607
Arbitrum · 42161presentbcf0d9a12e41a4ff7607
Avalanche · 43114presentbcf0d9a12eMISSING
BNB · 56presentbcf0d9a12e41a4ff7607

X402ExactPermit2Proxy is byte-identical on all six chains (a deterministic CREATE2 deploy) — nothing had to be deployed for PulseChain. Permit2’s hash differs per chain only because it bakes its chain-specific domain separator into an immutable. X402UptoPermit2Proxy is absent on PulseChain and Avalanche, which is why upto is not offered there. One trap: the address in the x402-rs x402-chain-eip155/README.md, 0x4020615294c913F045dc10f0a5cdEbd86c280001, has zero bytecode on all six chains; the constant in chain/permit2.rs is the one that runs.

Reproduce one cell: curl -s https://rpc.pulsechain.box -H 'content-type: application/json' -d '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{"to":"0x15D38573d2feeb82e7ad5187aB8c1D52810B1f07","data":"0xa0cc6a68"},"latest"]}' → an execution reverted error. Swap the address for Base USDC on a Base RPC and the same call returns the typehash.

03 · Pricing

Three free. Then a flat fee, per settlement.

Charged to the merchant, never to the payer, and never as a percentage of what moves — a facilitator that could take a cut would be a facilitator that could touch the money.

Table scrolls sideways →

ChainGas cost, measured 2026-08-28Price per settlementBundle unit (atomic USDC)
PulseChain$0.0008$0.0022000
Base$0.0010$0.0009900
BNB Chain$0.0024$0.0055000
Polygon$0.0021$0.0055000
Arbitrum$0.0035$0.0077000
Ethereum$0.0560gas at cost + $0.00561000 · snapshot

Gas measured as 70,000 gas × live gas price × live token price. Ethereum's bundle unit is a snapshot of a moving number and is re-measured, not trusted. Prices are re-measured monthly; an increase gets 30 days' notice on this page, a cut takes effect immediately.

How you buy

Bundles of 100 / 1,000 / 10,000 settlements (any count between 1 and 100,000, actually) at that chain's unit price, bought through POST /bundles — which is itself an x402 resource: it answers 402 in USDC on Base to the house address, you sign, you post again, and the receipt hands back your merchant token. The first token issued to a payer carries 3 free settlements, once, in total across all chains — enough to see it work on two chains plus one retry.

04 · Quickstart

Pick your side of the wire.

Three tracks. Most people need exactly one of them.

TRACK A

Merchant

You sell something over HTTP and want to be paid for it. You answer 402, then call /verify and /settle.

Go to the handler →
TRACK B

Payer / agent

You are the buyer — a script, an agent, a wallet. You sign an authorization and retry with a header. You never talk to us.

Go to the client →
TRACK C

Echo test

You want to see the shapes on a real chain before writing anything. Free, verify-only, no money moves.

Go to the echo →
Track A

Merchant — a FastAPI handler, end to end

The shape is always the same: no payment header → answer 402 with your requirements; payment header present → verify, do the work, settle. Verify first and settle last, so work that fails is never charged for. Both calls take the same three-key envelope.

merchant.py — python 3.11 · fastapi · httpx
# pip install fastapi uvicorn httpx
import base64, json, os
import httpx
from fastapi import FastAPI, Request
from fastapi.responses import JSONResponse

FACILITATOR = "https://402.wick.pics"
TOKEN       = os.environ["QWICKPAY_MERCHANT_TOKEN"]   # from POST /bundles
PAY_TO      = "0xYourMerchantAddress"
ASSET       = "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913"  # USDC on Base

app = FastAPI()


def requirements(price_atomic: str) -> dict:
    # x402 v1 PaymentRequirements. 'resource' is signed over by the payer,
    # so it MUST be the exact URL they were told to pay.
    return {
        "scheme": "exact",
        "network": "base",                # v1 name; v2 uses "eip155:8453"
        "maxAmountRequired": price_atomic,   # atomic units. 6 dp => "410000" = $0.41
        "asset": ASSET,
        "payTo": PAY_TO,
        "resource": "https://your.api/gpu/hour",
        "description": "1 hour of rtx4090 time. No refunds; charged after delivery.",
        "mimeType": "application/json",
        "outputSchema": None,
        "maxTimeoutSeconds": 120,
        "extra": {"name": "USD Coin", "version": "2"},
    }


def envelope(payload: dict, reqs: dict) -> dict:
    # The one shape /verify and /settle both take.
    return {"x402Version": payload.get("x402Version", 1),
            "paymentPayload": payload,
            "paymentRequirements": reqs}


def facilitator(path: str, body: dict, *, token: str = "") -> dict:
    headers = {"Content-Type": "application/json"}
    if token:
        headers["X-Merchant-Token"] = token      # /settle only. Never log it.
    r = httpx.post(f"{FACILITATOR}{path}", json=body, headers=headers, timeout=150)
    r.raise_for_status()
    return r.json()


@app.post("/gpu/hour")
async def rent(request: Request):
    reqs  = requirements("410000")
    header = request.headers.get("x-payment", "")

    # ---- 1. no payment yet: quote the price and stop.
    if not header:
        return JSONResponse(status_code=402, content={
            "x402Version": 1,
            "error": "X-PAYMENT header is required",
            "accepts": [reqs],
        })

    payload = json.loads(base64.b64decode(header))

    # ---- 2. verify. Nothing moves on-chain. Free.
    v = facilitator("/verify", envelope(payload, reqs))
    if not v.get("isValid"):
        return JSONResponse(status_code=402, content={
            "error": "payment_invalid",
            "reason": v.get("invalidReason"),
            "accepts": [reqs],
        })

    # ---- 3. DO THE WORK HERE, before any money moves.
    result = start_the_lease()          # yours. If it raises, nothing was charged.

    # ---- 4. settle. This is the metered call.
    s = facilitator("/settle", envelope(payload, reqs), token=TOKEN)
    if not s.get("success"):
        tear_down(result)               # do not run what you could not charge for
        return JSONResponse(status_code=402, content={
            "error": "settlement_failed", "reason": s.get("errorReason")})

    return JSONResponse(
        content={"ok": True, "tx": s.get("transaction"), "result": result},
        headers={"X-PAYMENT-RESPONSE": base64.b64encode(
            json.dumps(s).encode()).decode()},
    )
One thing worth doing before you reserve anything

/verify is a signature check. It says the authorization is well-formed and currently fundable — it does not promise the settle will land. If your "work" costs you real money before the settle (a machine, a lease, an API call you pay for), read the chain yourself first: the payer's balance, the nonce state, the validity window. An empty wallet can sign a valid authorization all day.

Track B

Payer / agent — sign, retry, done

A payer never talks to qWICKpay. You talk to the merchant, twice: once to be told the price, once with a signature attached. The only thing your key does is sign an off-chain EIP-712 message — no RPC, no node, no gas.

the client we ship — sidecar/x402-client.py
# stdlib + eth_account. No web3, no node, no RPC.
pip install eth-account

# 1. Look before you sign. --dry-run stops after printing the price
#    and the fee disclosure. Do this first against any new server.
python3 x402-client.py --url https://your.api/gpu/hour --dry-run

# 2. Pay for real. The key never leaves the process; prefer the env var.
export X402_CLIENT_KEY=0x<payer private key>
python3 x402-client.py \
  --url https://your.api/gpu/hour \
  --blocks 1 \
  --ssh-pubkey "$(cat ~/.ssh/id_ed25519.pub)"

# --key 0x...          payer key inline (env X402_CLIENT_KEY is safer)
# --url URL            the 402-protected resource (env X402_URL)
# --ssh-pubkey KEY     passed to the merchant; how a GPU rental lets you in
# --x402-version 1|2   which envelope to sign
# --dry-run            print the challenge, sign nothing, spend nothing

Under the hood it is two HTTP requests. If you would rather write your own client, this is the entire protocol:

the raw pair — curl
# ---- 1. ask without paying. You get the price, signed-over, in one object.
curl -s -X POST https://your.api/gpu/hour -H 'Content-Type: application/json' -d '{}'

# HTTP/1.1 402 Payment Required
# {
#   "x402Version": 1,
#   "error": "X-PAYMENT header is required",
#   "accepts": [{
#     "scheme": "exact",  "network": "base",
#     "maxAmountRequired": "410000",
#     "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
#     "payTo": "0x085cacDDd02fe32212DEEfFC858D197b31b80719",
#     "resource": "https://your.api/gpu/hour",
#     "description": "1 hour of rtx4090 time. Price $0.40 + fee $0.01 = $0.41",
#     "maxTimeoutSeconds": 120,
#     "extra": {"name": "USD Coin", "version": "2"}
#   }]
# }

# ---- 2. sign accepts[0] off-chain, then send the SAME request again
#         with the base64 payload in X-PAYMENT.
curl -s -X POST https://your.api/gpu/hour \
  -H 'Content-Type: application/json' \
  -H "X-PAYMENT: $(cat payload.json | base64 -w0)" \
  -d '{}'

# HTTP/1.1 200 OK
# X-PAYMENT-RESPONSE: eyJzdWNjZXNzIjp0cnVlLCJ0cmFuc2FjdGlvbiI6IjB4…
# {"ok": true, "tx": "0x9f2a…", "result": {…}}

What you are signing. On Base, BNB, Polygon, Arbitrum and Ethereum that is an EIP-3009 transferWithAuthorization — one exact amount, to one exact address, valid for one short window. On PulseChain the stables have no EIP-3009, so it is the EIP-2612 permit path through Permit2 instead. Either way it authorizes one transfer and cannot be replayed for a second.

Track C

Echo — see the real shapes, spend nothing

POST /echo/{caip2} is a merchant that never gets paid. It answers a real 402 for the chain you name, with real requirements you can actually sign, and on the retry it runs your payload through /verify and hands back what it saw. It never calls settle, so there is nothing to charge and no transaction to find. Use it to shake out envelope versions, asset decimals and domain data before you point a client at a live merchant.

echo on PulseChain — curl
# 1. the challenge — one chain, free, no token needed
curl -s -X POST https://402.wick.pics/echo/eip155:369 \
  -H 'Content-Type: application/json' -d '{}' | jq .

# 2. sign accepts[0], then send it back. Verify-only: nothing settles.
curl -s -X POST https://402.wick.pics/echo/eip155:369 \
  -H 'Content-Type: application/json' \
  -H "X-PAYMENT: $(base64 -w0 < payload.json)" \
  -d '{}' | jq .

# POST /echo with no chain lists the chains it will echo for.
# A v1 network alias works too where the chain has one: /echo/base
curl -s -X POST https://402.wick.pics/echo | jq '.chains'

# and the two calls that need nothing at all:
curl -s https://402.wick.pics/health   | jq .
curl -s https://402.wick.pics/supported | jq '.kinds, .signers'
Javascript, Next.js, Express, Hono

We do not ship JS middleware and we are not going to copy someone else's into this page. The x402 project maintains working examples for all of those — point them at https://402.wick.pics as the facilitator URL and they behave the same as the Python above. github.com/x402-foundation/x402examples/.

05 · The merchant token

One credential, held by the seller.

Payers never authenticate to us — they never reach us at all. The only party who holds a credential is the merchant, and the only thing it authorizes is spending settlements the merchant already bought. It is a bearer string: send it as X-Merchant-Token on POST /settle and nowhere else. /verify does not want it, /supported does not want it, and the payer must never see it.

You get one the first time you buy a bundle. It is shown once, in that response, and we keep only its SHA-256 — there is no "show me my token again" call, because there is nothing to show. Store it the moment it appears. If you lose it, the operator can rotate it, which invalidates the old one; your balance survives.

buying 1,000 PulseChain settlements — the 402 and the retry
# ---- ask for a bundle with no payment: you get the requirements.
curl -s -X POST https://402.wick.pics/bundles \
  -H 'Content-Type: application/json' \
  -d '{"chain":"eip155:369","count":1000}'

# HTTP/1.1 402
# {"x402Version":1, "error":"X-PAYMENT header is required",
#  "accepts":[{"scheme":"exact","network":"base",
#    "maxAmountRequired":"2000000",        <- 1000 x 2000 atomic = $2.00 USDC
#    "asset":"0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
#    "payTo":"0x085cacDDd02fe32212DEEfFC858D197b31b80719",
#    "resource":"https://402.wick.pics/bundles", ...}]}

# ---- sign it (USDC on Base), post the same body again.
curl -s -X POST https://402.wick.pics/bundles \
  -H 'Content-Type: application/json' \
  -H "X-PAYMENT: $(base64 -w0 < payload.json)" \
  -d '{"chain":"eip155:369","count":1000}'

# HTTP/1.1 200
# {
#   "merchant_id": 7, "chain": "eip155:369", "count": 1000,
#   "balance": 1000, "free_settlements_remaining": 3,
#   "tx": "0x…", "total_paid_atomic": "2000000",
#   "merchant_token": "…",
#   "merchant_token_note": "This is the only time this token is shown."
# }

Buy a second bundle from the same payer address and it is added to the existing tokenmerchant_token comes back null, because there is no new one to issue.

06 · Griefing controls

What stops a stranger draining the gas float.

A facilitator pays the gas for other people's transactions, which makes free settlement a standing invitation to burn our money. Four things stand in the way, and they are worth knowing about because they are also the four ways a legitimate call can be refused. Settlement requires a merchant token, so an anonymous caller can verify all day and settle nothing. Every chain has a minimum settlement equal to its measured gas cost — we will not spend more moving a payment than the payment is worth, and a call under that line comes back 402 below_minimum with the floor in the body. Rate limits apply per IP and per payer address on /verify, per merchant on /settle, and there is a cap on how many settlements are in flight at once; over any of them you get a 429 with a retry_after_seconds. And the gas floats are deliberately small, topped up under a daily cap, and watched — if a float drains faster than the recorded settlements explain it, that chain pauses and returns 503 chain_paused until a human looks. None of that is a promise about uptime; it is a description of what will refuse you and why.

07 · FAQ

The questions that come up first.

How do refunds work?

They do not, and that is structural rather than a policy we chose. The payer signs an authorization for an exact amount to an exact address. There is no over-payment to return, no balance sitting with us, and no account to credit. If the merchant needs to give money back, the merchant sends it — it is their address that was paid.

This is why the order in Track A matters: verify, deliver, then settle. Work that fails before the settle costs the payer nothing, which is a much better answer than a refund.

What can a facilitator do to my money?

Broadcast the transfer you signed, or not broadcast it. That is the complete list. We are never a party to the transfer — the authorization names the merchant as recipient and the amount is fixed by the payer's own signature, so we cannot redirect it, cannot skim it, and cannot make it larger. The worst we can do is fail to relay it, in which case no money moves at all.

That constraint is also the pricing model: a per-settlement fee to the merchant is the only shape a fee can take when you cannot touch the payment.

Why is PulseChain different?

Because its bridged stablecoins do not implement EIP-3009, the standard the rest of x402's exact scheme leans on. We measured it on-chain on 2026-08-28: bridged USDC, DAI and USDT on PulseChain all revert on TRANSFER_WITH_AUTHORIZATION_TYPEHASH(), RECEIVE_WITH_AUTHORIZATION_TYPEHASH() and authorizationState(), while Base USDC — the control — answers all three. All three PulseChain tokens do answer standard EIP-2612 (PERMIT_TYPEHASH, nonces).

So PulseChain settles over the permit path: the payer signs an EIP-2612 permit naming canonical Permit2 as spender plus a Permit2 authorization witnessing the recipient, and the facilitator calls the already-deployed X402ExactPermit2Proxy, which does permit → transfer atomically. Nothing needed deploying. It is x402 v2 only, and it is exact only — the upto proxy is not on that chain.

Do I need an account?

Not as a payer — you never touch us. As a merchant, "your account" is a token that appeared once in a bundle receipt and a balance of settlements behind it. No email, no signup form, no dashboard login. The first bundle purchase creates it.

Which x402 version should I send?

Send what your client library speaks; both are accepted and the reply echoes the version you sent. Practically: v1 uses names like "base" and "polygon" and works on Base and Polygon here. v2 uses CAIP-2 ids like "eip155:8453", works on all six chains, and is the only way to reach PulseChain. If you are writing something new, write v2.

What happens if a settle times out?

You get 504 settlement_unknown, and that is the honest answer rather than a failure: the facilitator may have broadcast the transfer before it stopped answering. That authorization is marked claimed and will never be presented again by us — so it cannot double-spend — and the settlement is recorded with status unknown. Check the chain for the payer's nonce before you decide what happened. Do not re-sign.

Is a settlement charged if it fails?

No, when we can tell it failed. A 4xx from the facilitator is its verdict on the request — nothing was broadcast — and the unit goes back to your balance. A timeout or a 5xx is ambiguous, and an ambiguous settlement keeps the charge, because the alternative is refunding units for transactions that did in fact go out.

Do you run this yourself, or is it hosted somewhere?

We run it. It is the open-source x402-rs facilitator, self-hosted, with a small gate of our own in front of it that does the metering, the minimums and the rate limits. We wrote the gate; we did not write the facilitator, and we did not invent the protocol.

08 · Upstream

Read the source, not just us.

Everything below is somebody else's work that this service depends on. If our docs and theirs disagree about the protocol, theirs is right.

09 · The honest version

qWICKpay is one facilitator implementation of an open protocol — we run a self-hosted x402-rs facilitator (Apache-2.0) behind a metering gate we wrote. x402 originated at Coinbase and is governed under the Linux Foundation; we are operators of it, not its authors.

On PulseChain: we are not aware of another x402 facilitator serving it, which is a statement about what we have looked for, not a claim about what exists. Arbitrum and Ethereum appear in /supported but their gas floats are not funded, so treat them as listed rather than running. There are no uptime or latency figures on this page because we have not been running long enough to have honest ones, and there will not be any until we do.

The prices here were measured on 2026-08-28 and are re-measured monthly. Every settlement lands on a public receipts tape. The first merchant on this rail is our own GPU service, compute.pangle.online, and it is billed the same way as anyone else.