Agentic week: the payment stack grew a brake pedal

Five changes shipped in the agent payment stack this week. Four of them are limits. The layer has stopped optimising for how to pay and started optimising for how not to overpay.

The week of 14 to 21 August produced no new payment protocol, no new chain, no new scheme. What it produced was a default spending cap in the x402 client SDKs, a new non-terminal settlement state, an infrastructure-layer payment limit at an AWS general availability launch, and a proposed accounting rule for the asset all of this moves.

That is a recognisable phase change. A payment rail adds capabilities while it is being adopted and adds constraints once it is being operated. This week was almost entirely the second kind.

1. x402 clients now refuse to sign more than one dollar

The largest change of the week is a default. PR #3124, merged on 13 August, added declarative spendControls to the TypeScript x402Client. The Python port and the Go port both merged on 18 August, eleven minutes apart. Together the three touched 321 files.

The behaviour is the part worth reading twice. A client built with fromConfig now applies a default cap of one US dollar on recognised pegged assets, and it applies it inside accept selection — before any user policy runs, and before anything is signed. Non-default assets are not payable at all unless you list them. There is no way to accidentally inherit a permissive configuration, because the permissive configuration has to be written down.

const client = x402Client.fromConfig({
  schemes: [{ network: "eip155:*", client: new ExactEvmScheme(signer) }],
  spendControls: {
    maxAmountPerPayment: "$1",        // USD cap on recognised pegged assets
    allowedAssets: [
      // opt-in non-default asset, atomic cap
      { network: "eip155:*", asset: "0xCustomToken", maxAmountPerPayment: "2000000" },
      // override the USD cap for a default asset by ticker
      { network: "eip155:*", asset: "USDC", maxAmountPerPayment: "1000000" },
    ],
  },
  // spendControls: false  -> any asset, no caps
});

Two design decisions make this more than a convenience wrapper. First, caps are expressed either in USD (for assets the SDK recognises as pegged) or in atomic units per asset, which means the client does not have to trust a price feed to enforce a limit on a token it does not recognise. Second, each mechanism package now declares its own DEFAULT_ASSETS table, so "recognised" is a property of the SDK build rather than of runtime discovery.

The releases carrying it are @x402/core 2.23.0 on npm and x402 2.20.0 on PyPI, both published on 18 August. For context on how much surface this default now covers: @x402/core alone recorded 871,818 npm downloads in the thirty days to 19 August.

2. settlement_pending: the state between paid and failed

On 17 August, PR #3083 added a shared EVM constant across the exact, upto and batch-settlement flows:

// ErrSettlementPending: broadcast succeeded; receipt wait failed (RPC/timeout).
// Non-terminal - return with the tx hash so the caller can reconcile
// onchain before retrying.
ErrSettlementPending = "settlement_pending"

The failure it addresses is mundane and expensive. A facilitator broadcasts a transaction, gets a valid hash back, and then fails to retrieve the receipt because an RPC endpoint times out or errors. Before this change, the receipt-wait failure surfaced as a terminal error such as invalid_exact_evm_failed_to_get_receipt. A caller reading a terminal error does the reasonable thing and retries. If the original transaction confirmed, the buyer paid twice.

The stated rule in the PR is deliberately conservative: treat every receipt-wait exception after a valid broadcast hash as settlement_pending, because the exception type cannot prove the transaction will not confirm. The old error strings were kept and annotated as reserved wire values that must not be reassigned, which is the correct handling for a protocol where facilitators and clients from different SDK generations talk to each other.

This is the kind of change that only appears once something runs in production. The facilitator API was specified as verify and settle, success or failure. Real settlement has a third outcome — broadcast, unknown — and it now has a name.

3. AgentCore payments GA: two protocols behind one integration

AWS made AgentCore payments generally available on 18 August, after a preview that launched with x402 support. The GA scope is broader than the preview in one specific way: it is now protocol-agnostic at the API surface, supporting both x402 and the Machine Payments Protocol co-authored by Stripe and Tempo. A developer integrates once; AgentCore negotiates whichever protocol the merchant speaks.

The x402 feature AWS chose to highlight at GA is the upto scheme — authorise a ceiling, settle the actual consumption — which it frames as the enabler for pay-per-inference and dynamic pricing. That is a notable endorsement. Of the four x402 schemes, upto is the one built for exactly the shape of an inference call, where the price is unknown until the tokens are counted.

The rest of GA follows the week's theme. Payment limits are enforced at the infrastructure layer rather than in agent code, sessions carry spending caps and expiry, and the wallet credential is structurally separated from the agent so the agent can initiate authorised payments without holding unrestricted wallet access. There is also a curated Coinbase Bazaar MCP server of pay-per-use x402 endpoints exposed through AgentCore Gateway, and Quick Create for provisioning Coinbase credentials from the console.

4. MCP: a Tier 1 Rust SDK and seven channels collapsed into one

MCP had a governance week rather than a protocol week. On 21 August the Rust SDK was promoted from Tier 2 to Tier 1 for both the 2026-07-28 revision and the draft. The promotion is notable for how it was justified: independent re-verification with the official conformance suite against the frozen 2025-11-25 and 2026-07-28 requirement sets, scoring 67/67 on server conformance, 50/50 on client conformance and 12/12 on labels, plus published versioning, dependency-policy and roadmap documents and same-day spec tracking. Tier status is now an evidence claim, not a popularity one.

The underlying crate is not a side project. rmcp has passed 21.3 million all-time downloads on crates.io, with 3.1.4 published on 20 August.

The day before, the Authorization Interest Group was re-chartered into a single venue. Six #auth-wg-* Discord channels plus #enterprise-managed-auth-ig were archived, with each live topic — DPoP, workload identity federation, SEP-2643 and fine-grained authorisation, tool scopes, and enterprise-managed authorisation interop — continuing as a thread in one channel. The charter now says the group's output is drafts and demos, that accepting SEPs stays on the normal sponsor plus core-maintainer path, and that a thin agenda cancels the call.

Consolidation after a specification ships is a healthy signal. The 2026-07-28 rewrite spawned a lot of parallel authorisation venues; a month after the spec is final, the project is choosing one room over seven.

5. FASB proposes a rule for holding the money

On 18 August the Financial Accounting Standards Board issued a proposed Accounting Standards Update titled Statement of Cash Flows (Topic 230): Cash Equivalents — Disclosure Enhancement and Evaluation of Certain Digital Assets. It does not change the definition of a cash equivalent. It adds illustrative examples clarifying when a digital asset already meets it.

Three characteristics are required: an on-demand contractual cash redemption right, a direct redemption right with the issuer for known amounts of cash, and segregated reserve assets held by the issuer at least one-to-one in short-term, highly liquid assets. Entities presenting cash equivalents would also have to disclose the significant components annually — Treasury bills, commercial paper, money market funds, stablecoins — whether or not any of them are digital. Comments close on 19 November 2026.

For an operator running agents that hold a working balance, this is the difference between a stablecoin float sitting in a line item nobody wants to explain and one sitting next to T-bills. It is a treasury story, not a protocol story, but it removes a real objection to funding an autonomous agent from a corporate balance sheet.

Also this week

The ERC-8004 contracts README gained a Robinhood Chain mainnet section on 15 August, listing the same canonical vanity addresses used everywhere else — 0x8004A169… for identity, 0x8004BAa1… for reputation. The identity proxy resolves to the same IdentityRegistryUpgradeable implementation we found on Ethereum during our on-chain audit, was created on 17 July, and had recorded 16 transactions in total when we checked the explorer on 21 August. The deployment is real; the usage is not there yet.

Fireblocks was added to the x402 facilitator list on 20 August, offering vault-backed settlement where private keys never leave Fireblocks — the fourteenth entry in that table. And on 21 August a 1,530-line SVM profile for batch-settlement merged, specifying long-lived payment channels on Solana with cumulative vouchers and a payer-signed request_close as the interoperable refund path, finalised by the facilitator after a grace period configurable from 15 minutes to 30 days. That is the Solana counterpart to the batch-settlement scheme we covered in July.

A2A, by contrast, shipped nothing structural: the repository's only commits in the window were governance roster updates and a build fix for JSON schema generation.

What it means for LLM4Agents

The spend-controls default changes the buyer's expectations of us. A client that caps itself at one dollar per payment by default will hit that ceiling against per-call inference pricing the moment a request is large or a model is expensive. Two consequences follow. Prices quoted behind a 402 need to stay comfortably inside a sane per-payment envelope, and the upto scheme becomes more attractive than exact for inference, because a ceiling the buyer sets is exactly the shape a capped client wants to sign.

settlement_pending is more urgent than it looks. Any gateway that grants access on settle success and denies on settle failure now has a third branch to write. Treating a pending settlement as a failure means either double-charging a buyer who retries or refusing service to a buyer who already paid. The correct handling is to hold the transaction hash, serve or queue the request, and reconcile on-chain — which requires a reconciliation path that most billing code does not currently have.

AWS choosing upto for pay-per-inference is validation and pressure at once. It confirms the metered-settlement thesis the gateway is built on, and it also means the largest cloud provider is now shipping an abstraction layer over both x402 and MPP. Being reachable through that layer matters more than being reachable directly: an agent built on AgentCore does not choose our protocol, it chooses our inventory.

The FASB proposal, finally, removes a quiet blocker on the demand side. As we noted in last week's roundup, the constraint on machine payments right now is purchasable inventory, not rails. But the second constraint is a finance team that cannot classify the float. That objection has a proposed answer as of this week.

Staying on the frontier

One — handle settlement_pending explicitly. Add the third branch to the settle path: on settlement_pending, persist the transaction hash, do not charge again, and reconcile against the chain before any retry. Ship it before the SDK version that emits it becomes the common one.

Two — price inside the default envelope. Publish per-call prices that a client with a one-dollar cap can pay without configuration changes, and document exactly which requests can exceed it. A buyer who has to edit spendControls to use the gateway is a buyer who does not use the gateway.

Three — lead with upto for inference. Exact pricing fits a fixed resource. Inference is not one. Quote a ceiling at request time, settle the tokens actually consumed, and make the difference between authorised and settled visible in the receipt.

Four — get the inventory into the abstraction layers. AgentCore now routes across protocols and exposes curated x402 endpoints through its Gateway. Discovery surfaces of that kind are becoming the acquisition channel. Being listed where a transacting agent already looks beats being reachable by anyone who reads our docs.

Five — publish the treasury story alongside the technical one. If a finance team can now argue that the operating float is a cash equivalent, give them the artefacts that argument needs: which stablecoin, which issuer, which redemption right, and a per-call receipt trail that reconciles to it.