A conference talk by Steve Kaliski of Stripe on building payment infrastructure for autonomous AI agents. Covers secure credential transmission, making businesses discoverable to agents, and designing guardrails—illustrated with live code examples—that make autonomous spending safe as agent-driven purchasing becomes a core capability. # Video Identity Observations: "Building safe Payment Infrastructure for the autonomous economy — Steve Kaliski, Stripe" ## Explicit Self-Description - **Speaker affiliation**: The speaker states directly: *"I'm from Stripe"* and later *"I'm a principal software engineer at Stripe."* - **Role history**: He describes his role scope: - *"Spent my first four years leading our issuing team, so that's our product that lets developers create physical and virtual credit cards."* - *"In the last two years, I've been exploring how to let robots spend money and how Stripe businesses can adapt to that new kind of buyer."* ## Claimed Scope - **Topic scope**: Building payment infrastructure for AI agents, framed as *"how we can let robots spend money and how businesses can receive money from robots."* - **Presenter versus channel scope**: The claims here are about the speaker's work at Stripe, not explicitly about the publishing channel. No statement in the transcript describes the channel itself. ## Intended Audience (Observable) - **Technical developer audience**: The talk assumes familiarity with: - LLM tools and agent harnesses (*"as you are in cloud code or codex or any other kind of application"*) - APIs, HTTP status codes, and web servers (demos use curl, a 402 status code, server endpoints) - Stripe integration patterns (*"a common Stripe integration… I'd create a payment intent and on line 39 I'd collect that payment method"*) - **Conference-talk setting**: Evidence includes *"I have 2 minutes and 9 seconds if people have questions"* and an audience Q&A at the end, indicating a live developer/industry conference context. ## Observable Presentation Patterns - **Demonstrated technical depth with live demos**: The speaker shows three working demonstrations — shared payment tokens, the machine payments protocol (with Tempo), and the agent-to-commerce protocol (ACP, built with OpenAI) — rather than discussing concepts abstractly. - **Structured argumentation**: Clear thesis framing: > *"Discovery and exploration benefit from non-determinism… But credentials, payments, and checkout require determinism."* - **Partner ecosystem framing**: Repeatedly credits collaborators: *"Stripe and our partners have worked together on,"* *"we worked with our friends at Tempo,"* *"what we built with Open AI being the agent to commerce protocol."* - **Transparency about limits**: When asked about payment volume stats, responds *"We don't have public stats on any of that"* — demonstrates a pattern of declining to fabricate or disclose undisclosed data. - **Product-adjacent, not product-pitch**: Focus is on infrastructure problems and solutions rather than a sales pitch, though Stripe products (Issuing, Stripe Press, Stripe Projects) appear as examples; Stripe Projects is confirmed only when an audience member asks (*"yes, Stripe projects is built on shared payment tokens"*). ## Notes for Channel-Level Synthesis - No curated metadata was supplied, so identity context comes solely from the title and transcript. - The title identifies the speaker and employer ("Steve Kaliski, Stripe"), suggesting a channel that hosts named industry speakers, but the transcript contains no explicit channel self-description. # Delivery Observations — Steve Kaliski, Stripe ## Tone & Overall Register - **Conversational and informal** throughout the talk. Filler words appear frequently: "Um," "you know," "sort of," "like." > "So, um we probably we're going to zoom through this cuz all we talked about today is agents, I imagine." - **Self-deprecating humor and light asides** punctuate technical content: > "let's just let the robot operate a human operate Well, hopefully not operate a human, but uh concerning slip" > "not accidentally spend a gazillion dollars on a card." ## Vocabulary & Terminology - Consistently uses **"robot"** and **"agent"** interchangeably as the buyer archetype: > "how we can let robots spend money and how businesses can receive money from robots" - **"Determinism" vs. "non-determinism"** is the recurring conceptual axis of the talk — the core framing word. - Stripe-internal and technical vocabulary: "shared payment tokens," "payment intent," "PSP," "402 status code," "blast radius," "harness," "scoped to seller." ## Recurring Phrases & Rhetorical Patterns - **Signposted takeaway framing** — he explicitly flags key takeaways early: > "if I just want to take away, if you stop listening for the rest of the presentation, discovery and exploration benefit from non-determinism" > "So again, maybe another takeaway, agents are already economic actors" - **"So again"** as a frequent connector to restate or emphasize points (appears multiple times: "So again, scope to seller," "So, again, um closing that window of of improved determinism"). - **Parallel enumeration** — lists structured as repeated sentence stems: > "I can buy from the wrong place. I can buy the wrong thing. I can spend the wrong amount. I can use the wrong credential." - **Anticipated shared knowledge** — he addresses the audience as peers who already know the basics: > "we all know this, but uh crudely, an agent is just calling LM and calling tools." > "nothing surprising here" ## Teaching Habits - **Problem → bad approach → ideal approach → demo** structure, used for each of the three solutions (shared payment tokens, machine payments protocol, ACP). - **Live demos with narration** of what's happening on screen: > "So, we're going to go ahead and we're going to create that credential." > "Let me check again. Yep." - **Deliberately shows failure first**, then success, as a teaching device: > "but what we'll see is we actually had a failure here. So, the request amount, which was $50, is greater than the amount that was uh mandated." - **Human/robot equivalence comparisons** to explain abstractions: > "the left-hand side dashboard is for a human, and the right-hand side, robots prefer code." > "the human-friendly way to look at it, but our equivalency um is the robot-friendly way of looking at it." - **Concrete narrative examples** (purple vs. orange T-shirt, fake amazon.com lookalike, price drift across regions) to ground abstract risks. ## Audience Interaction & Closing - **Tracks his own time aloud** at the end: > "I have 2 minutes and 9 seconds if people have questions." > "Well, I'm at zero now, so thank you everyone." - **Q&A responses are direct and unembellished** — admits limits rather than speculating: > "We don't have public stats on any of that, but I think in general we're very encouraged by it." - Accepts audience correction/plug gracefully: > "Uh yes. Thank you for that plug. I did not have time to include that." ## Uncertainty Notes - Delivery cues like "Um" and "you know" frequency suggest live, lightly scripted delivery, but **transcription quality is rough** (e.g., "HP requests" for "HTTP requests," "LM" for "LLM"), so some verbal habits may be transcription artifacts rather than speaker choices. - No curated metadata was provided, so observations rest solely on the transcript; timestamps are bracketed markers, not verified audio positions. # Position Record: Building Safe Payment Infrastructure for the Autonomous Economy — Steve Kaliski (Stripe) ## Speaker - **Steve Kaliski**, Principal Software Engineer at Stripe; led the issuing team for four years; last two years exploring how robots/agents can spend money and how businesses can accept money from them. ## Core Thesis - **Key separation**: discovery and exploration *benefit from non-determinism*; credentials, payments, and checkout *require determinism*. Kaliski calls this the "isolation of how do I find things or what should I do from how am I going to transact." - **Agents are already economic actors**: they spend via tokens/currency through subscriptions to LLM providers; the open question is enabling other currencies, spend patterns, payment methods, and business interactions. ## Stated Problems Kaliski frames an agent crudely as "just calling LLM and calling tools," spending both. Baseline approach (agent operating a browser like a human) risks four failure modes: - **Wrong place** — agent can't certify it's on the right domain (fake lookalike sites). - **Wrong thing** — agent may buy the wrong item or something 10x more expensive. - **Wrong amount** — prices drift, miscalculations, currencies, taxes; "the number your robot may extract from the page may not actually be the amount of money that you want to spend." - **Wrong credential** — pasted card numbers can go to the wrong place; some payment methods are hard or impossible for an agent to relay. The base approach of pasting card numbers is "bad" — slow, finicky, hard to observe outcomes; hence PSPs and APIs exist. "In Stripe parlance, the dashboard is for a human, and robots prefer code." ## Solutions Presented (Stripe + partners) ### 1. Shared Payment Tokens - Agent collects a payment credential and shares it with a seller across hundreds of payment method types; the token encodes a **mandate/smart contract** limiting use to a particular seller, amount, currency, and time window. - Enforced by Stripe; auditable; minimizes "blast radius" even if the agent is duped by a domain or parses amounts incorrectly. - **Seller transparency preserved**: brand, last four digits, credit type are still shared so sellers can apply existing risk systems — "we're not trying to do something secret from the seller." - Demo: $50 charge against a $25-limited, 30-day, seller-scoped Visa token fails; a compliant charge succeeds. ### 2. Machine Payments Protocol (with Tempo) - Tool calls are HTTP requests that should be payable; ephemeral interactions use a **402 status code** to communicate the need to pay, with the shared payment token supplied to complete the exchange. - Demo: paid endpoint costs a penny, paid in USD on the Tempo blockchain; transaction lands on-chain. ### 3. Agent-to-Commerce Protocol (ACP, with OpenAI) - Standard APIs/objects expressing how checkouts work across the web; back-and forth between agent, seller, and PSP relays structured state (line items, base price, tax, fulfillment options) rather than the agent scraping UIs. - Goal: minimize disputes and chargebacks from the agent incorrectly relaying details; "the seller remains in control" and keeps the customer relationship and risk signals. - Demo with Stripe Press: product catalog expressed in JSON; agent initiates checkout; payment via shared token. ## Prescriptive Position - Businesses should make products **agent-friendly** (expose structured APIs, not just web UIs) to maximize deterministic flows. - TLDR: keep non-determinism for discovery; shift payments, checkout, and credentials toward exclusively deterministic mechanisms. "Non-deterministic planner and constraints with verifiable parties and structured negotiation results in a small radius of risk." ## Q&A Positions - **Blockchain hosting**: Stripe supports multiple networks including Base and Tempo; transaction data lives on-chain, and Stripe replicates a product view in its own system. - **Recurring budgets**: analogous to giving a business a card with periodic permission; similar to OAuth access/refresh flow for subsequent usage; for larger budgets, "just pick a higher number" — still scoped to individual sellers, and "you could just create infinite of them." - **Stripe Projects**: confirmed as "built on shared payment tokens" plus seller expression of products; the recurring point covers the monthly aspect. - **Volumes**: "We don't have public stats on any of that," but Stripe is "very encouraged" and excited to support more businesses accepting agent payments. (Unresolved — no data shared.) ## Qualifications / Tensions Noted - Kaliski's aside "hopefully not operate a human, concerning slip, hopefully it doesn't come true" — humor flagging unease about the browser-operation approach. - Crypto vs. cards treated as interchangeable within flexible payment flows; no claim of one being preferred. - Volume/adoption evidence is absent despite two years of work; only stated encouragement. # Video Attribution Record ## Video Identification - **Title:** Building safe Payment Infrastructure for the autonomous economy — Steve Kaliski, Stripe - **Video ID:** `01a15ca9-118b-7b2e-8f86-2139acbdeca8` - **Format:** Conference/talk presentation with live demos, followed by audience Q&A ## Speakers and Roles ### Primary Speaker — Creator/Presente - **Steve Kaliski** — self-identified as **Principal Software Engineer at Stripe** - First four years at Stripe: led the **issuing team** (physical/virtual credit cards) - Last two years: exploring how robots/agents can spend money and how Stripe businesses adapt to agent buyers ### Secondary Speakers — Q&A Questioners (unnamed audience members) - **Questioner 1:** Asked about blockchain hosting (Tempo vs. Stripe data ownership) - **Questioner 2:** Asked about recurring budgets/subscriptions with shared payment tokens (mentions "Open Claw" and a $25/week example) - **Questioner 3:** Asked whether "Stripe projects" is a wrapper of the discussed primitives - **Questioner 4:** Asked about payment volume/number of agent payments since starting two years ago No narrator or other identified roles present. No names given for the Q&A questioners. ## Referenced Sources, Products, and Third-Party Claims ### Stripe products/features (speaker's own claims) - **Shared payment tokens** — credentials scoped to seller, amount, currency, time; enforced by Stripe; claimed to work across payment method types; auditable - **Stripe Issuing** - **Stripe Press** — Stripe's book store, used in demo - **Agent-to-Commerce Protocol (ACP)** — described as built "with OpenAI" (speaker claim) - **Stripe Projects** — confirmed by speaker (in response to a questioner's plug) to be built on shared payment tokens ### Third-party partners referenced - **Tempo** — partner in "machine payments protocol"; demo transaction described as "path USD on the tempo blockchain" - **OpenAI** — claimed partner on the Agent-to-Commerce Protocol ### Third-party services/platforms mentioned - Claude Code ("cloud code"), Codex — as examples of agent harnesses where tokens proxy spending - **Base** and **Tempo** networks — speaker claims Stripe supports multiple networks and replicates product views of on-chain data in Stripe's systems ### Technical standards referenced - HTTP **402 status code** for payment-required responses - OAuth access/refresh flow analogy for recurring credential usage ## Promotional Segments ⚠️ - The presentation is given **by a Stripe employee showcasing Stripe products** (shared payment tokens, ACP, Stripe Press, Stripe Projects); demos use Stripe integrations and a Stripe internal test account. This constitutes sustained product demonstration/promotion for Stripe and its partners (Tempo, OpenAI) throughout the talk, not an isolated segment. ## Provenance and Availability Limits - **No public usage stats:** Speaker explicitly stated Stripe does not have public statistics on the volume or number of agent payments ("We don't have public stats on any of that"). - **No curated metadata supplied** — no speaker biography, timestamps, cited publications, or comment availability information was provided with this source. - **Timestamps:** Not present in the transcript; demo sequences and Q&A cannot be time-located. - **Questioner identities:** Not established in the source. ## Notes on Uncertainty - Partner attributions (Tempo, OpenAI) are the speaker's own claims and unverified by other sources in this material. - Quotation example: speaker stated *"We don't have public stats on any of that"* regarding agent payment volumes. Just want to thank everyone for being here. Um, I'm from Stripe and today I'm going to talk about building safe payment infrastructure for the autonomous economy or how we can let robots spend money and how businesses can receive money from robots. So just about me, I'm a principal software engineer at Stripe. Spent my first four years leading our issuing team, so that's our product that lets developers create physical and virtual credit cards that historically would be for humans and increasingly for robots. In the last two years, I've been exploring how to let robots spend money and how Stripe businesses can adapt to that new kind of buyer. And if I just want to take away, if you stop listening for the rest of the presentation, discovery and exploration benefit from non-determinism, right? So the amazing thing about LLMs is huge corporate of information, the world's information can predict and and recommend code or products or businesses for you. But credentials, payments, and checkout require determinism. So not just benefit from it, but require it. So that's sort of isolation of how do I find things or what should I do from how am I going to transact is sort of the critical separation. So we're going to talk about agents as economic actors, all the bad things that can happen, the solutions that that Stripe and our partners have worked together on to fix those, and then a little bit of what's next. So again, maybe another takeaway, agents are already economic actors, right? They have their own currency and tokens. So as you are in cloud code or codex or any other kind of application, you were in effect spending money, right? It might be proxied through the subscription you have or converted from the tokens that are being inputted or outputted turning into dollars, but in effect we're already letting them spend, right? Just not with any business but the LM uh provider that they're working with. So, how do we enable other currencies and other spend patterns and other payment methods and other business interactions is our is our main question. So, um we probably we're going to zoom through this cuz all we talked about today is agents, I imagine. So, uh agents produce text. Sometimes they need to read or write data or interact with third parties. They do so using tools, and sometimes those tools require money. So, how do we safely enable this? Um again, we all know this, but uh crudely, an agent is just calling LM and calling tools. They're spending both of them. Um and the tools in particular we're going to talk about are search, credential management, and payment. It's the magic, but it's also the risk. So, uh what are the main problems? Um I can buy from the wrong place. I can buy the wrong thing. I can spend the wrong amount. I can use the wrong credential. So, the base approach uh in sort of the open class style, let's just let the robot operate a human operate Well, hopefully not operate a human, but uh concerning slip, uh hopefully it doesn't come true. Let the robot just operate the browser like a human. Um So, wrong place. Well, first, how does an agent certify it's in the right place or domain? Um how do I know that, you know, maybe the the website looks a lot like, you know, amazon.com, but is, you know, amazon. whatever and and is a fake one. Um the wrong thing. Uh you could stumble through a site looking for a purple T-shirt, and you could maybe, less concerningly, buy an orange T-shirt, but you could also, you know, uh buy something that's 10 times more expensive. The wrong amount. Um you know, as we know, at least for me, I've seen totally different prices here than back at home. Prices can drift. There's miscalculations, different currencies, taxes, and so on. Like, the number you your robot may extract from the page may not actually be the amount of money that you want to spend. And of course, wrong credential. Um you could paste your credit card, it could go the wrong place. Um, but, you know, as as here, there are other different payment methods that are hard or if not impossible for an agent to relay. So, we want to be able to solve all four of those things. And again, the basic approach of taking a card number, bad. Browsing a site can be finicky, filling forms, clicking pay, it's all slow, um, hard to observe outcomes. And, you know, this isn't unique to payments, right? It's the same as operating any web app or anything that has a monetary risk. And that's why MSPs and uh, APIs exist. So, you know, in Stripe parlance, the the left-hand side dashboard is for a human, and the right-hand side, robots prefer code. So, the ideal approach is you know, something where we can bind to a merchant. We can enforce spend policies. It can be API-driven and thus programmatic. And you can have verifiable identities. So, I'm going to talk about three different things that Stripe and our partners have built together around credentials, payment flows, and checkout to illustrate how we're trying to solve all of those problems. So, first I want to talk about shared payment tokens. And the idea here is that, um, you know, first, not all payment methods are, you know, universal like credit cards. Um, some are expressed in different ways. Um, but there's also no way to enforce spend limits or controls when you just hand a card number to someone else, right? You're going to trust them that they charge the amount that you parsed out of the page or whatnot. And what we built with shared payment tokens is this idea that an agent collect a payment credential and it can share it with the seller, you know, across hundreds of different payment method types. And it can encode sort of like a mandate or smart contract, the limitations of that credential to be used by a particular seller. So, you know, we'll do a demo in a second, but I can apply usage limits to specific currencies, to amounts, for time, and a particular seller. So, even if I've been, you know, duped by a domain or you know, haven't parsed the amount correctly, I can still apply what I think is right in terms of the amount and the particular seller that I'm targeting. So again, scope to seller, it's enforced by Stripe, works across payment methods, and it's auditable. So, I'm going to jump into a quick demo just to show you how that works. So, let's look at um kind of a common Stripe integration. So, I have my seller Stripe account and I want to charge uh $50. So, I normally I would create a payment intent and on line 39 I'd collect that payment method myself and it would run and that's all great. Um but now instead of collecting the payment method on my website, an agent is collecting a payment method that it may have already received from its human operator or through the subscription that backs the harness or whatever it may be. So, we're going to introduce a second Stripe account. And this is the agent Stripe account. And it's going to provision a shared payment token. Let's say it collect had collected a Visa card. And it's going to say that this Visa card, which has a much higher credit limit, is only going to work for $25 and it's only going to work for the next 30 days and it's scoped to this particular seller, illustratively, my internal test account. So, we're going to go ahead and we're going to create that credential. And instead of the seller using a payment method that they've collected, they're going to receive a token that's been granted to them and try to run the payment. So, let's Cool. So, the first thing we see is that we created that new shared payment token, which applies to that Visa card, it's active, it has that $25 limit, and it's going to expire in 30 days. Now, what's important as part of this also is we don't want the seller to be fully hidden from what's happening. So, in the same way that they would have otherwise collected a card and knew the brand and knew the last four and so on, um we still send that information over. So, the the brand and the last four, the credit type, they can use all these inputs in their existing risk analysis. So, an important part here, too, is that we're not trying to do something secret from the seller. We still want to provide the relevant information to the seller so that they can still apply their exact their previous uh risk systems um so that, you know, they they can accept payment. Um, but what we'll see is we actually had a failure here. So, the request amount, which was $50, is greater than the amount that was uh mandated. So, again, we like collected a credential, we shared it, we applied a limit, we trusted the seller, the seller tried to do more, and now Stripe enforced a limitation. So, uh again, like this would work across any payment method type, and, you know, now that we you know, can lower the cost, we'll see that uh this actually goes through. Yep, that payment went through. So, now we're able to securely send a credential, apply limits, make sure there's a minimized blast radius, um and still allow the seller to process payments as they normally would. Now, um that covers credential sharing, but there's two more parts to this. This how do we actually associate payment to a product, and then how do we do checkout? So, uh the second thing we built uh we worked with our friends at Tempo was what we call the machine payments protocol. So, back to that original point around tool calls, um well, tool calls are just sort of HP requests that agents can make. Um, and HP requests um should be able to be paid for, right? So, one way is you pass in an API key, but sometimes those interactions with tools can be ephemeral. So, we want to be able to communicate the need to pay um in those HP requests by returning a 402 status code, and then supply that credential that we showed earlier um so that we can actually get a good back. So, um we've covered uh Uh, how do we get credentials, how do we know to pay for them and associate with the actual product we're buying? So, again, um closing that window of of improved determinism. Um So, maximize determinism. Let's do demo. So, now if we jump over here, I'm going to start a server. This server's a regular sort of uh web server. It has protected endpoints that now require payment. So, let's say my robot is calling one of these endpoints to try to execute a tool. Make a curl request to it. It fails. Tells us that we need to pay. It gives us some uh encoded payload that explains what we're buying and who we're paying for and the what we're paying for and the mechanism to pay for it. Um and I can go ahead and uh pay for it now. So, now we get some extra information back because we're speaking that protocol. We can see that it's going to cost a penny um this to this particular recipient. Um it'll be path USD on the tempo blockchain. And I can go ahead and approve it. So, now that goes through, get our success, and then we can see a transaction landed on the blockchain. So, uh we're, you know, able to create credentials that have limited use. Now we can be uh told by a seller how they want money and have it be associated with the actual re- resource I'm requesting. And now I can send them funds. Um but the last part is um let's just jump back in. It's like we're not always buying API calls, right? And sometimes the uh details uh of the purchase matter quite a bit, right? The tax amount, maybe there's that, there's uh restrictions about the amount of things I could buy. All the things that a typical e-commerce site is trying to convey. And to that earlier point around, you know, the the robot, you know, stumbling around a checkout page, there are a lot of details that we want to be able to relay back to the agent and ultimately back to the human buyer to make sure that the thing we're buying is is the thing we think we're buying, right? We want to minimize disputes and chargebacks and so on. And if we have this proxy layer of the agent in between, we run the risk of incorrectly relaying those details. So, what we built with Open AI being the agent to commerce protocol is a standard set of APIs and objects that can explain how checkouts work across the web. So, similar to the last thing we showed where the seller kind of conveys the need to pay, we establish a back and forth between agent, a seller, and their PSP, where every single time the agent wants to create a checkout or update the quantity or pick a shipping amount, the seller can relay sort of like a tool called relay back the latest state, respond to that request, and ultimately result in payment. So, we can sort of illustrate how this works with a real business. Let's spin up a server here. So, Stripe operates something called Stripe Press. It's our store of books. This is obviously a very cool, human-friendly way to look at it, but our equivalency um is the robot-friendly way of looking at it. So, um the ACP protocol or ACP covers a few things. How do we express a product catalog, right? So, instead of the robot stumbling around and having to click on links and figure out what to buy, we can express our products just in JSON with images and descriptions and pricing. And then the robot can pick one of those and initiate a checkout. So, uh Uh, we can pull up a familiar UI, maybe I'm asking for recommendations about AI books. And on the right-hand side we'll see the requests that the agent makes. So, it tells a little bit about the buyer, the line items and quantity it wants. And then the seller can relay back basically the state of the cart. So, instead of the robot trying to, you know, pull information, you know, out of a UI like this, it has structured data that I can refer to. So, uh, the line items, the base price of each, applicable tax, the different fulfillment options, and so on. So, nothing surprising here, but, you know, our goal is to sort of establish that determinism, right? Where like we've segued from discovery, where maybe we were doing some web crawling, now we've transitioned to just purely programmatic back and forth. So, you know, as I change payment methods or I change shipping, and ultimately pay, those back and forth happen. Payments goes through using something like a shared payment token or otherwise to relay those credentials. Let me check again. Yep. So, you know, at the end we we have API-driven commerce flows that are flexible to different payment methods, whether they're crypto or cards or any of the other hundreds of payments that exist. And critically, the seller remains in control. They continue to have the relationship that they expected to have with customer, but also receive the signals um and risk data that they need to safely interact with agents. And sort of the, you know, goes without saying most of us have already done this with with our products, but, you know, we want to make our products agent-friendly. Um, and if we only expose you web UIs or or or applications like that, um we increase the likelihood of non, you know, the non-determinism interacting with our businesses. Instead, we should make them age friend agent-friendly um to maximize the deterministic flows that agents have with our businesses. So, leveraging things like shared payment tokens or wallets or other technologies to then manage those credentials safely um is then important for agents so that they're able to uh yeah, not accidentally spend a gazillion dollars on a card. Um so TLDR, discovery we should keep with non-determinism that's perfect. Payments and checkout and credentials we want to shift towards exclusively deterministic. Um so non-deterministic planner and constraints with verifiable parties and structured negotiation results in a small radius of risk and hopefully safe uh payments between agents and businesses. So that's all I got. Thank you. I have 2 minutes and 9 seconds if people have questions. \>\> You mentioned blockchain. \>\> Yeah. \>\> What is this hosted by Temple or is it Stripe or do they own their own separate data? \>\> Yeah, so um you know, Stripe supports a number of different uh protocols and and a uh variety of networks including Base and Tempo. The transaction data uh innately lives on those chains and then Stripe replicates the sort of product view of that data in our own system. \>\> Yep. But why factor \>\> This guy. \>\> Um the shared payment tokens are really cool. Uh in terms of say like recurring budgets and payments, like I'm thinking of you know, I want to give Open Claw $25 a week to use with like a particular model. How how does that uh kind of factor in? \>\> Yeah, so you touched on two points the sort of the subscription thing and then sort of more enduring policies. Um on the subscription side um in the same way you give a credit card to a business and you permit it to spend $25 or whatever on a on a periodic basis but it still uses the same credential. Uh we have a similar idea there as well. Sort of similar to in OAuth access and refresh flow where you can sort of like request uh subsequent usage. Um and then on the another part about like uh uh sort of more balanced budgets the sort of equivalency can work here where you just pick a higher number. We still scope it to individual sellers, but you could just create infinite of them. \>\> Um so I'm wondering is Stripe projects just effectively a wrapper of these primitives that you've discussed during the session? \>\> Uh yes. Thank you for that plug. I did not have time to include that, but yes, Stripe projects is built on shared payment tokens. And then the mannerism in which seller or SAS business can express their products as And then the point touched on the recurring part is how the monthly part would work. \>\> Thank you. \>\> You mentioned that you have started this 2 years ago. I'm wondering about the the number of such payments done and the volume If you can share something \>\> We don't have public stats on any of that, but I think in general we're very encouraged by it and we're really excited about trying to support more businesses in accepting that type of payment. Well, I'm at zero now, so thank you everyone. Appreciate it.