Sam Broner of a16z crypto published Agents will pay like locals, not tourists. The core argument is that we're designing agent payments with a tourist's frame. In a bazaar, tourists haggle at every stall, pay cash, and repeat one-off interactions. Locals operate differently. The butcher buys from the fisherman on credit. The tailor settles monthly with the weaver. Broner's diagnosis: agents will behave like locals.
Why will agents act like businesses? Two reasons:
The best experiences are pre-designed. Users don't want an agent that compares prices and negotiates terms at every checkout. They want one that already knows which vendors are reliable, has pre-negotiated pricing, and can transact instantly.
Agents are infinitely replicable, but economies of scale are not. A travel agent booking a million flights a year gets better terms from airlines than one booking ten. Only ChatGPT has the distribution to negotiate direct partnerships with Shopify, Amazon, and Expedia. Smaller startups are stuck with automated browsers or reverse-engineered APIs, paying retail fees. This is why agents will converge to a few dominant players per vertical.
In this structure, there are two payment relationships: 1) user to agent (subscriptions, per-task fees, credit lines), and 2) agent to vendor (pre-negotiated B2B terms, volume pricing, net-30 invoices). This is, in fact, how credit cards work today. The issuer maintains a retail relationship with the consumer; the acquirer maintains a commercial relationship with the merchant.
So are cards the answer for agent payments? Only halfway.
Cards are widely accepted, work well for $20–$1,000 transactions, and include built-in arbitration and cancellation. But two problems remain:
Card technology was designed around humans. Approvers, UIs, 3D Secure — nearly all infrastructure assumes a human in the loop. The number of PSPs, POS terminals, and merchant endpoints is too large, and agent adoption is moving too fast, for a smooth upgrade.
The fee structure. Visa doesn't support sub-cent payments, and there's a fixed 30-cent fee per transaction. Streaming $0.001/second to a compute provider or sending micropayments for API access simply doesn't work on card rails.
This is where stablecoins enter. No 30-cent minimum fee. An agent streaming $0.001/second and a manufacturer settling a $50,000 vendor invoice can use the same rail.
Patrick and John Collison published the Stripe 2025 Annual Letter. Total payment volume: $1.9 trillion (34% YoY growth), processing roughly 1.6% of global GDP. Here's the worldview of the company behind those numbers.
The most notable section is Stripe's five-level framework for agentic commerce:
Level 1: the agent fills out web forms on your behalf.
Level 2: you describe a situation — "back-to-school supplies for a 3rd grader who likes K-Pop and tennis" — and the agent finds products.
Level 3: the agent starts remembering your preferences. Level 4: you delegate — "do back-to-school shopping, under $400."
Level 5: no prompt needed. The agent reads your calendar, preferences, and budget, then purchases proactively.
Stripe's own assessment: we're currently "at the boundary of Levels 1 and 2."
The Collisons compare this moment to the mid-90s when HTTP, HTML, URL, and DNS were being created. "Every Google had an AltaVista" is the key line — an implicit prediction that today's proliferation of agentic commerce protocols will consolidate. Stripe's moves reflect this conviction. ACP, built with OpenAI, is already live in ChatGPT with Walmart, Etsy, and Instacart. SPTs (Shared Payment Tokens) are a new payment primitive that lets agents initiate payments without exposing credentials. Notably, Stripe opened SPTs to competitors like Klarna and Affirm, making them available even for merchants who don't use Stripe.
Stablecoins are the other headline. "Crypto winter but stablecoin summer" — while Bitcoin fell 50% from its October high, stablecoin payment volume doubled to roughly $400 billion. For the first time, stablecoin volume decoupled from crypto asset prices. An estimated 60% is B2B payments. Bridge ($1.1B acquisition) volume grew 4x.
Mastercard released an open spec called Verifiable Intent. The core question is straightforward: when an AI agent buys something on behalf of a human, how do you prove the agent actually followed the user's rules?
Today, this is a trust-me situation. A user says "buy headphones under $300 from Amazon." The agent spends $500 at a random store. The only evidence is platform logs — logs the platform controls. Users bear the risk of unauthorized charges, merchants bear the risk of chargebacks, and payment networks can't determine who's at fault.
Verifiable Intent solves this with a cryptographic signature chain. Not logs — signatures. Tamper with any part and the entire chain breaks. The structure has three layers:
L1: The issuer (bank or card company) signs. "This public key belongs to this user." Valid for roughly one year.
L2: The user signs. "I delegate authority to this agent key, within these constraints." Valid for 24 hours to 30 days. Constraints include allowed merchants, allowed products, amount ranges, and cumulative budgets.
L3: The agent signs. "Here's what I actually did." Valid for roughly 5 minutes.
Each layer includes a hash of the previous layer, and the signing key must match one pre-registered in the layer above.
If L1 states "this user's public key is X," then L2 can only be signed with key X.
If L2 states "this agent's public key is Y," then L3 can only be signed with key Y. This key binding is implemented via a standard field called cnf.jwk (RFC 7800). Swap any layer underneath and the hash mismatches. Forge a key and the signature fails.
A concrete example makes this more intuitive. Say Alice uses a Mastercard.
Her card issuer issues L1 once, certifying Alice's device key.
Alice tells her agent: "Buy wireless headphones under $300 from AudioShop or SoundStore." Her mobile app creates L2 — allowed merchants: AudioShop, SoundStore; allowed products: Sony WH-1000XM5, Bose QC Ultra; amount range: $100–$300; agent key binding included. Alice signs with Face ID and walks away.
The agent finds a Sony WH-1000XM5 at AudioShop for $279. The merchant signs a checkout JWT containing the cart details.
The agent uses this JWT to create L3a (payment proof) and L3b (checkout proof), sending them to the payment network and merchant respectively.
Both sides verify the L1→L2→L3 signature and hash chain. The network additionally checks L2 constraints: is $279 under $300? Is AudioShop on the allowed list?
Everything passes. Payment authorized. Alice gets a notification.
What's interesting is that L3 splits into two. L3a goes to the payment network (includes amount, payee, and card info but hides the cart). L3b goes to the merchant (includes cart contents and checkout JWT but hides payment details). Same L2 underneath, but each party sees only the disclosures relevant to them.
Integrity between the two L3s is guaranteed by a checkout hash. L3a carries it as transaction_id, L3b as checkout_hash — both are hashes of the same checkout JWT. This independently verifies that the payment and checkout reference the same cart.
The constraint types are fairly specific: allowed merchant lists (allowed_merchant), approved products with max quantities (line_items), per-transaction amount ranges (payment.amount), allowed payees (payment.allowed_payee), cumulative budget caps (payment.budget), agent recurrence limits (payment.agent_recurrence), and merchant-managed subscription setup (payment.recurrence). If the agent exceeds budget, uses an unapproved merchant, or buys an unauthorized product, the payment network rejects it at verification time.
On protocol integration, VI is not tied to any specific payment protocol. It can plug into Google's UCP or OpenAI/Stripe's ACP via extension mechanisms. Where the agent payment protocols covered in issues 1 and 2 solve "how do you pay," VI solves "how do you prove the payment was legitimate."
Subscribe to FLAVOR by moyed
Support FLAVOR by moyed
FLAVOR by moyedThings I read Last Week #9
<100 subscribers
FLAVOR by moyedWeb Proof, Make more data verifiable
API for everything without permisson (and legally)
FLAVOR by moyed10 Weeks of Journey into vFHE
i’ve been working on deep dive into vFHE ((verifiable Fully Homomorphic Encryption)) for last 10 weeks.
FLAVOR by moyedI read Sentient Whitepaper So You don’t need to
Sentient, Platform for 'Clopen' AI Models
Sam Broner of a16z crypto published Agents will pay like locals, not tourists. The core argument is that we're designing agent payments with a tourist's frame. In a bazaar, tourists haggle at every stall, pay cash, and repeat one-off interactions. Locals operate differently. The butcher buys from the fisherman on credit. The tailor settles monthly with the weaver. Broner's diagnosis: agents will behave like locals.
Why will agents act like businesses? Two reasons:
The best experiences are pre-designed. Users don't want an agent that compares prices and negotiates terms at every checkout. They want one that already knows which vendors are reliable, has pre-negotiated pricing, and can transact instantly.
Agents are infinitely replicable, but economies of scale are not. A travel agent booking a million flights a year gets better terms from airlines than one booking ten. Only ChatGPT has the distribution to negotiate direct partnerships with Shopify, Amazon, and Expedia. Smaller startups are stuck with automated browsers or reverse-engineered APIs, paying retail fees. This is why agents will converge to a few dominant players per vertical.
In this structure, there are two payment relationships: 1) user to agent (subscriptions, per-task fees, credit lines), and 2) agent to vendor (pre-negotiated B2B terms, volume pricing, net-30 invoices). This is, in fact, how credit cards work today. The issuer maintains a retail relationship with the consumer; the acquirer maintains a commercial relationship with the merchant.
So are cards the answer for agent payments? Only halfway.
Cards are widely accepted, work well for $20–$1,000 transactions, and include built-in arbitration and cancellation. But two problems remain:
Card technology was designed around humans. Approvers, UIs, 3D Secure — nearly all infrastructure assumes a human in the loop. The number of PSPs, POS terminals, and merchant endpoints is too large, and agent adoption is moving too fast, for a smooth upgrade.
The fee structure. Visa doesn't support sub-cent payments, and there's a fixed 30-cent fee per transaction. Streaming $0.001/second to a compute provider or sending micropayments for API access simply doesn't work on card rails.
This is where stablecoins enter. No 30-cent minimum fee. An agent streaming $0.001/second and a manufacturer settling a $50,000 vendor invoice can use the same rail.
Patrick and John Collison published the Stripe 2025 Annual Letter. Total payment volume: $1.9 trillion (34% YoY growth), processing roughly 1.6% of global GDP. Here's the worldview of the company behind those numbers.
The most notable section is Stripe's five-level framework for agentic commerce:
Level 1: the agent fills out web forms on your behalf.
Level 2: you describe a situation — "back-to-school supplies for a 3rd grader who likes K-Pop and tennis" — and the agent finds products.
Level 3: the agent starts remembering your preferences. Level 4: you delegate — "do back-to-school shopping, under $400."
Level 5: no prompt needed. The agent reads your calendar, preferences, and budget, then purchases proactively.
Stripe's own assessment: we're currently "at the boundary of Levels 1 and 2."
The Collisons compare this moment to the mid-90s when HTTP, HTML, URL, and DNS were being created. "Every Google had an AltaVista" is the key line — an implicit prediction that today's proliferation of agentic commerce protocols will consolidate. Stripe's moves reflect this conviction. ACP, built with OpenAI, is already live in ChatGPT with Walmart, Etsy, and Instacart. SPTs (Shared Payment Tokens) are a new payment primitive that lets agents initiate payments without exposing credentials. Notably, Stripe opened SPTs to competitors like Klarna and Affirm, making them available even for merchants who don't use Stripe.
Stablecoins are the other headline. "Crypto winter but stablecoin summer" — while Bitcoin fell 50% from its October high, stablecoin payment volume doubled to roughly $400 billion. For the first time, stablecoin volume decoupled from crypto asset prices. An estimated 60% is B2B payments. Bridge ($1.1B acquisition) volume grew 4x.
Mastercard released an open spec called Verifiable Intent. The core question is straightforward: when an AI agent buys something on behalf of a human, how do you prove the agent actually followed the user's rules?
Today, this is a trust-me situation. A user says "buy headphones under $300 from Amazon." The agent spends $500 at a random store. The only evidence is platform logs — logs the platform controls. Users bear the risk of unauthorized charges, merchants bear the risk of chargebacks, and payment networks can't determine who's at fault.
Verifiable Intent solves this with a cryptographic signature chain. Not logs — signatures. Tamper with any part and the entire chain breaks. The structure has three layers:
L1: The issuer (bank or card company) signs. "This public key belongs to this user." Valid for roughly one year.
L2: The user signs. "I delegate authority to this agent key, within these constraints." Valid for 24 hours to 30 days. Constraints include allowed merchants, allowed products, amount ranges, and cumulative budgets.
L3: The agent signs. "Here's what I actually did." Valid for roughly 5 minutes.
Each layer includes a hash of the previous layer, and the signing key must match one pre-registered in the layer above.
If L1 states "this user's public key is X," then L2 can only be signed with key X.
If L2 states "this agent's public key is Y," then L3 can only be signed with key Y. This key binding is implemented via a standard field called cnf.jwk (RFC 7800). Swap any layer underneath and the hash mismatches. Forge a key and the signature fails.
A concrete example makes this more intuitive. Say Alice uses a Mastercard.
Her card issuer issues L1 once, certifying Alice's device key.
Alice tells her agent: "Buy wireless headphones under $300 from AudioShop or SoundStore." Her mobile app creates L2 — allowed merchants: AudioShop, SoundStore; allowed products: Sony WH-1000XM5, Bose QC Ultra; amount range: $100–$300; agent key binding included. Alice signs with Face ID and walks away.
The agent finds a Sony WH-1000XM5 at AudioShop for $279. The merchant signs a checkout JWT containing the cart details.
The agent uses this JWT to create L3a (payment proof) and L3b (checkout proof), sending them to the payment network and merchant respectively.
Both sides verify the L1→L2→L3 signature and hash chain. The network additionally checks L2 constraints: is $279 under $300? Is AudioShop on the allowed list?
Everything passes. Payment authorized. Alice gets a notification.
What's interesting is that L3 splits into two. L3a goes to the payment network (includes amount, payee, and card info but hides the cart). L3b goes to the merchant (includes cart contents and checkout JWT but hides payment details). Same L2 underneath, but each party sees only the disclosures relevant to them.
Integrity between the two L3s is guaranteed by a checkout hash. L3a carries it as transaction_id, L3b as checkout_hash — both are hashes of the same checkout JWT. This independently verifies that the payment and checkout reference the same cart.
The constraint types are fairly specific: allowed merchant lists (allowed_merchant), approved products with max quantities (line_items), per-transaction amount ranges (payment.amount), allowed payees (payment.allowed_payee), cumulative budget caps (payment.budget), agent recurrence limits (payment.agent_recurrence), and merchant-managed subscription setup (payment.recurrence). If the agent exceeds budget, uses an unapproved merchant, or buys an unauthorized product, the payment network rejects it at verification time.
On protocol integration, VI is not tied to any specific payment protocol. It can plug into Google's UCP or OpenAI/Stripe's ACP via extension mechanisms. Where the agent payment protocols covered in issues 1 and 2 solve "how do you pay," VI solves "how do you prove the payment was legitimate."
FLAVOR by moyedWeb Proof, Make more data verifiable
API for everything without permisson (and legally)
FLAVOR by moyed10 Weeks of Journey into vFHE
i’ve been working on deep dive into vFHE ((verifiable Fully Homomorphic Encryption)) for last 10 weeks.
FLAVOR by moyedI read Sentient Whitepaper So You don’t need to
Sentient, Platform for 'Clopen' AI Models
Share Dialog
Share Dialog
No comments yet