The other direction: an agent pays someone else's paywall
x402 micropayments covered your org paying 1Claw. This is an agent paying a paywall it does not control, under a cap it does not choose for itself.
The earlier x402 lesson is about being on the receiving end of a 402: your org's own API usage, billed by 1Claw. 1claw pay is the other direction. Your agent's task hits somebody else's paywall mid-run and needs to pay it to continue. The two problems look similar and the trust model is the opposite: last time you were deciding whether to sign 1Claw's own challenge. Now your agent is deciding whether to sign a stranger's.
- The CLI holds the network connection and nothing else. It sends the vault the exact bytes the paywall served; the vault computes the digest and decides what may be signed.
- The digest binds the transfer value that will actually leave the wallet, not the challenge's maxAmountRequired ceiling. What a human approves and what gets signed cannot drift apart.
- Keys never leave the vault. The CLI gets back an X-PAYMENT header, never key material.
- Pay is off until a human turns it on with PATCH /v1/agents/{id}/pay/settings, and an agent cannot turn it on for itself.
The raw 402 challenge is the preimage the vault signs against. The CLI never re-parses it into fields and sends those instead, because anything reinterpreted first would fall outside what was actually approved. This is the same principle as validating the raw x402 challenge rather than a summary of it, taught in the earlier x402 lesson, applied to the paying side instead of the receiving side.
--mode is a request, not a guarantee: the vault only honours it where the agent's own configured policy already allows it. strict asks for a passkey touch on every payment. session asks for a spending grant instead, a capped, time-bounded delegation created once by a human. auto asks for no ceremony at all, and is only reachable for an agent explicitly configured to run unattended.
- pay_require_passkey defaults to true. While it is true, every payment needs a human touch, and an allowlisted recipient does not bypass that; the allowlist only widens which recipients a grant may cover once one exists.
- An agent with pay_require_passkey false and no payTo allowlist pays nobody. A null allowlist is not a wildcard for an unattended agent; it means no one.
- A spending grant cannot exceed the agent's own pay_grant_max_usd or pay_grant_max_ttl_secs. A grant is a delegation inside limits already set, never a way around them.
- The cap is decremented in a single guarded statement as payments are signed, so two concurrent payments from the same grant cannot both spend the last dollar.
Limits are charged at signing, not at settlement. A signature that was produced and then reported lost still consumed authority, because the paywall may yet present it. The response says so explicitly: {"recorded": "signed_failed", "limit_released": false}. Only a vault-verified reconciliation can return that headroom, and it is not built yet, so "the payment failed, let me spend again" is the one claim a client must not be able to make on its own say-so.
What can actually be paid is deliberately short. USDC and USDT on Base, Optimism, Avalanche and BNB Chain settle over EIP-3009. Solana settles the same challenge with a signed SPL transfer instead, chosen by the chain rather than by a flag, because EIP-3009 does not exist on Solana and an SPL transfer is not something an EVM paywall would ever settle. Every address and mint was verified on-chain by reading the token's own symbol and decimals rather than trusted by name; an asset that is not on the list is refused, not guessed at, because the daily limit is denominated in USD and a fabricated exchange rate would go both in front of the human and into the ledger.
BNB Chain's USDC and USDT are 18 decimals, not the 6 decimals you would assume from Base or Ethereum. Treating them as 6 decimals the way the earlier x402 lab treated Base USDC would understate a payment by a factor of 10^12, the same class of atomic-unit error taught in Lab: send a trillion dollars by mistake, just hiding on a different chain this time.
Decide
An agent configured with pay_require_passkey: false has a payTo allowlist containing one address on Base. Mid-task, it hits an x402 paywall on Solana, from an address that happens to match a name on its Base allowlist string-for-string.
Does the payment go through?
Check your understanding
4 questionsWhat does the payment digest bind, and why does that matter?
An agent has pay_require_passkey set to false and no payTo allowlist configured. What happens when it tries to pay?
A payment is signed, then the client reports the paywall never returned a 200. What does the response say about the spending limit?
Why does Solana use a signed SPL transfer instead of EIP-3009 for the same x402 challenge?