Block announced on September 24 that it joined the x402 Foundation, the Linux Foundation body that now stewards the protocol, and that it has contributed Bitcoin Lightning payment support to the standard. The change had been visible a day earlier in x402's public repository. Block also said it will keep contributing to Lightning support and take part in the Foundation's working groups, adding to its earlier work on the open-source agent goose and the Universal Commerce Protocol. x402 volume has settled almost entirely in USDC, so Lightning would add a bitcoin-denominated option, as Lightspark did for MPP in March. The announcement describes an addition to the specification, and there is no usage data yet on Lightning payments through x402.

The number of x402 settlements processed by known facilitators on Base, Solana and Polygon between May 2025 and September 2026, totaling $52.7 million and averaging roughly $0.26 per settlement (TRM Labs, report published September 9, 2026; average is our calculation).

The count is large, but the more informative figure sits one step further down: after screening out self-payments and other anomalous flows, $25.6 million remained as likely commerce, and only 0.6% to 7.5% of that value appeared to come from agents. TRM notes that these bounds may understate real agent activity, so the figure is best read as a range for what can be measured today, not as a ceiling. Last month's edition counted payments; this month the open question is who made them.

Three of this month's stories ask the same question from different directions: when a payment arrives, what does it tell us about who sent it?

TRM Labs gives the plainest version. On x402, a scheduled script, a load test and an AI agent can leave identical records on-chain. The rail works, and what it records is a receipt, which says that value moved but little about the payer.

Incumbents are answering from the other side. Mastercard is extending agent verification into Agent Pay, and India's NPCI is reportedly building spending limits, audit trails and identity checks into its framework for UPI. In both cases the answer lives with the network operator, which is a reasonable design when the operator is known and accountable. On open rails the same question has to be answered differently. More settlement options are arriving underneath the same payment request, Lightning through Block's contribution to x402 and Arc through Circle, and each carries its own answer to what a payment can prove.

This is where the research behind Bit2 begins. The History of Bit2, published this month, traces how requirements such as cryptographic receipts, confidentiality and delegated wallets with spending restrictions led the team to a client-side validation design. In that design, receipts and spending policies are properties of the payment itself and are not inferred afterwards from chain data.

Whether agents will end up identified by registries, by networks or by the payments themselves is still open. TRM observes that registries exist today but are voluntary and mostly unused. Perhaps the more useful question for the coming months is which of these answers agents and merchants will actually adopt, and what each one costs them in privacy. We will keep following it in the next editions.

A space to slow down, read deeper, and sit with ideas worth more than a scroll.

How does a Bitcoin research lab end up designing a payment network for AI agents? Sergio Lerner traces the path from BitVM and BitVMX to client-side validation, including the analysis that led the team to look beyond Lightning for machine-scale payments. The piece also covers what has been built so far and how the project is meant to evolve.