In early October, Mastercard announced an expansion of Agent Pay with new trust and intelligence services that add context to AI-initiated transactions. They form the intelligence layer of the Agent Pay Trust Framework, which groups identity, intent, controls, execution and intelligence, and they extend agent verification (KYA) into the program so that financial institutions and merchants can recognize agents. Cloudflare's chief strategy officer is quoted in the announcement. Read next to TRM's finding that on-chain agent registries are voluntary and rarely used, it suggests the identity gap is being addressed first inside the card networks.

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.