Stablecoins, Payments & the Agentic Economy | Boston Blockchain Week 2026

Hey. I was just me talking with them in the little break room and I'm like I love being with these people cuz they're the smart ones. I think they're so smart. And I love being able to to moderate you guys today. So, if we I know he gave your names, I'd love for you guys just to give a little brief introduction and everything.

We'll go down the road.

Thank you. Hey everybody. Tom Hook, I'm the global chief compliance officer of MoonPay. I've been in the crypto industry since 2018. Previously Circle and Bitstamp.

Um and in my free time I teach a course at Boston University on crypto regulation and payment systems. Happy to be here.

Hi everybody. I'm Amanda. I'm a senior software engineer at Coinbase. I work on the X402 and on-chain AI payments team. Previously at Bison Trails and I'm based here in Boston.

I'm so glad you're all here.

Hello, my name's Lani Greenwall. I'm the founder and CEO of Olympus. We are the largest proactive security provider for the space. We provide mathematical guarantees around smart contracts with customers like Circle, Securitize, Aave, Uniswap, most of kind of the the fun players.

Hello everyone. I'm Anil Nandyal. I'm a senior solutions architect at AWS. I work with in the fintech space with cryptocurrency customers. Think of centralized and decentralized exchanges as well.

So, I'm here to speak on agent commerce with the team and we were part of the I was also part of the agentic payments products that we've launched. So, we'll be chatting about that as well.

And just like Ian said, we're going to look a little under the hood. So, we're going to get going here so we have plenty of time. So, um we just Okay, I'm going to talk to Amanda first. 165 million X402 transactions, but only about $50 in volume. That is 30 cents a transaction.

Is that real commerce? Look at that slide. Um is that real commerce? Are we we testing on each other? And if you don't mind, give everybody a little understanding of what XPRT is.

So everybody understands that.

Yeah, just really um so for those of you aren't familiar with XPRT, it is an open payments protocol so that you can send money over the internet like the same way you might send like an email, you send it like data but it's on the blockchain. It's um open-source, Coinbase sort of we pioneered it but it is now part of the Linux Foundation and chain agnostic and anybody can build on it. So um you should try it out. But um yes, it is real commerce. The the main use case right now is machine-to-machine payments and micro-payments which are quite tricky to do with our like normal payment rails using credit cards and things like that because they all cost money.

They they take fees. But if you do it over the blockchain, the fees are minimal. It's gas. It's just a transaction. Very cool.

Um and the one thing you might notice, the average price per transaction is not high cuz people are not humans are not buying shoes like agents are not buying shoes for you. Machines are paying other machines for data. That's usually that's where we're at right now but it is very much real volume.

And now do you mind elaborating a little bit on how AWS launched XPRT on Coinbase?

Yeah, sure. So AWS collaborated with Coinbase and Stripe to launch agent agent core payments product and this allows agentic architectures or agents to be able to make these transactions high volume transactions and you can set payment limits per session per transaction and other guardrails. Right? So and we also solve the other side of the agent e-commerce which is to be able to monetize the the content or APIs or MCPs which is which is next of what's coming up, right? So, people are creating content.

Enterprises want to be able to monetize that, and you know, these are both sides of the uh equation is what I would say on the agent e-commerce. So, we've launched those products as well.

Just real quick, Amanda and you know, out of scope for an agent, cannot hold a credit card or open a bank account. It has to spend from a funded wallet. Is that the real reason the whole conversation is lens on stable coins first? You know what I mean, you guys?

I think so. I mean, that's that's my experience is that you an agent is software. Software is not a person. If you're not a person, you can't have a bank account, you can't have a credit card. Um but an agent can have a crypto wallet, and you can put money in it, and then it can use it.

And that's that's sort of how we ended up with stable coins, blockchain transactions in the first place.

Is it a constraint or a preference?

So, it's it's more like an authorization that that a human will give to the agents to authorize on their behalf. So, I would say it's it's a both, combination of both.

Okay, awesome. Awesome. Great. All right. Um who's the customer KYC and authorization, Amanda, real quick.

A software cannot pass KYC, so who's the customer, and where does the chain of authorization break?

Right.

very, very question.

Yeah, um I think right. Software is not a person, like we just all established. So, like you Neil said, the customer is the person who passes KYC, um and can authorize the agent to do things, and can delegate, but the customer is still the human person on the other side of the keyboard. Um

Yeah.

Yeah, go ahead.

Keep going.

Oh, and uh the mandate chain doesn't really break, because if you are a human and you are authorizing your agent, what the agent does is your responsibility. Even if it were you could authorize a person and say, "Go do these things for me as my agent." If they go rogue, it's still on you because you authorized their activity.

And Tom, what do you think about the I know you've got something some light to shed on this.

Yeah, I I think it kind of ties into the second question where, you know, this is why for a lot of those transactions right now there's a human in the loop.

Yeah.

Um and it depends really are you doing a regulated financial transaction or is it a peer-to-peer, you know, transfer of funds between two crypto wallets? Um and when you're dealing with a regulated financial transaction, you need to do KYC, right? You need to have uh a customer and that is where uh you know, I'm the I'm the non-technical person on the on the panel and and that is where you have to have a human who's KYC'd, who has an account. Uh and to Aman's point, that is where, you know, it is uh they are authorizing um the agent to to make transactions on their behalf, but a lot of the times right now, um the hu- the tee up the transaction and then the human says yes or no. Um and that's that's a big part of uh the flow when it comes to at least like agentic commerce from that perspective.

Yeah, Neil, you want to add something?

And then maybe I'll I'll modify that a little bit and say the human in the loop authorizes the transactions first and then they become human on the loop. So, they're just monitoring what's happening and then their agents are doing these actions. Think of Hermes and Open Cloak that are actually just doing everything for the humans.

Right, so yeah.

But when can we rely on it and when can't we rely on it? Do either of you guys want to answer that? Is there an answer to that?

It's so it's interesting. It kind of goes to the proving the authorization. Um and that is I think right now why, you know, for example, MoonPay has a product called PayBox um that is kind of an agentic wallet infrastructure. Uh but ultimately, if that agent, if you're teeing up your agent to work in a regulated financial product, you again, it's teed up, they have to agree, you know, you as the customer have to say yes, I authorize that agent. Where we need to move to for this to more quickly and and more efficiently is how do we pre-authorize those agents to take a certain number of transactions or certain amount of transactions.

And a lot of this ties into protections. I heard on the last panel people were talking about consumer protection. A lot of this ties to consumer protection. How do you deal with fraud? How do you deal with unauthorized transactions?

Chargebacks. You know, this is why you'll see, you know, Visa, MasterCard, Amex are setting up these kind of registering your agents platforms. And that is, you know, they're vetting and ensuring that, you know, you can't come back and say, "I didn't authorize my agent to buy those shoes."

what proves that it Tell us what proves it.

You know, I think that's what we're still trying to figure out and there's probably like probably technical ways that these folks can kind of talk through that and I think that's what needs to get kind of built in so that you can, you know, set your agent up and say, you know, go buy me that pair of shoes uh in the right size when it comes available uh but then not challenge it to Amex and uh and and fight it.

Exactly.

You have something to add on?

Yeah, I'll piggyback on that. I just say like the first lever of that question is an access question, right? What does my agent have access to and what are the boundaries in which it can operate? So, it has a set and allocated wallet of X amount. So, there's no fathomable world where it can spend more than the $100 in its wallet, right?

It's not like you're giving them unlimited Amex. Now, where they spend that, let's say you put guardrails, you can buy shoes, you can't buy shoes. An agent will always um prioritize optimization to the fastest path. Right? So, it's not even necessarily malicious intent, but if it means buying a sandal, maybe that's not a shoe.

How do you define what right where right it actually comes down to properties and definitions. Um and so, the access question is almost more important than the autonomous question, which is like where are the rules? And then when you get into really particular boundaries like high-level systems like AWS, the rules are critical, right? So like again, moving maybe away from agents into like where rules and I'll I'll elaborate on what we do in formal methods and mathematical guarantees and all the technical nitty-gritty there, but we were talking about this in the the break the break room earlier, which is AWS is a the organization Amazon is just a huge distributed system. If that system goes down, it's going to cost them from business metric standpoint billions and billions of dollars per second probably if I was betting then, right?

Um and so they must have properties and guarantees around what a system can and cannot do and those need to be mathematically verified. Um because the access and what can go wrong is is astronomical. In this case with $100, how much can go wrong? We can lose $100. That is our worst case, right?

So mathematical guarantees and what level of security boundaries we put in place with systems depends on the consequences of if they go wrong. And to figure out the boundaries of what can go wrong is the access question in the first place. In in what room is it operating? What doors can it open or close, right?

Right. That's good. And what about the compliance layer on top? Like could you speak a little bit about like refunds, authorized capture, like the protocol layer, the interface, and the compliance layer on top? Could you speak a little bit about that?

I mean, I think that's where we're still really evolving and that is where, you know, the exciting part of my job is working with folks like uh like the co-panelists and, you know, I need it I need to be able to prove X. How do you do that? Um and having that back and forth, like that's the fun of what's going on right now is being able to, you know, go to a regulator um and say, you know, this wasn't fraud because of X. This wasn't um going back to uh you know, a credit card company. This This wasn't unauthorized because these guardrails were set and agreed to by the human whose account we're working on.

Um and so I think that's a lot of the exciting evolution going on right now.

Yeah, and this can be for anybody but you two, especially you, Tom. Somebody has to buy the stablecoin the agent will spend. What does an on-ramp have to do differently for an agent than for a person?

In for

on that?

100% I think that ties into the regulated versus unregulated aspect. And when I say regulated, I mean like a regulated financial transaction that requires either a banking license or a money transmitter license, for example, in the US. In something like that, you need to have the human in the loop authorized. We're dealing with regulators who are getting savvy and comfortable with crypto, but now we're getting them savvy in crypto with AI and agentic commerce and putting the two together. We need to be very kind of thoughtful and careful how we do that.

Now, that you as a human can load a wallet and supply that to your agent and give it the ability to spend that. Now you're dealing with a peer-to-peer transaction. That's how most agentic commerce works. And so, in that aspect, you have a lot more freedom and speed to do that and the controls are built in from like an authorization perspective, less on the regulated front of proving that I'm dealing with Tom Hook and verifying his identity, more verifying the authorization of moving funds on chain.

And I'll also probably add there because the security comes here, right? So, when when we talk about agents making transactions, a couple of things that come to mind are the secret access to these agent wallets, right? So, they should be really secure that the secret should not be leaked and the secret should be stored in some kind of an identity So, in AWS, we have like an AWS agent core identity that gives identity for the agents and also be able to store those wallet secrets securely. The second thing is on the prompts that these agents are actually being fed with, right? So, we all hear about prompt injection attacks or even natural language prompts that jailbreak these agents, right?

So, we want to make sure that there is a deterministic path for every transaction that validates whether the transaction is an authorized transaction or not and how much the spending limit is is is actually you know is validated right so those are the things that should stay out of the agentic loop and it should stay on the mode of the deterministic path and those are the guardrails that you want your agents to have.

And before we move on let's talk about trust. So how do you win the trust of people before the transaction even starts like what kind of mechanisms how do you do that because that's a big that's a big thing for people.

Yeah. Yeah so my my thesis lately has been that um UI is the first trust layer. So if like design is often kind of a afterthought in a lot of software but at this point because we're dealing with the space between the computer and the human in order to build that trust it's necessary it's important. You need to make sure the user understands exactly what they're doing where their money is coming from where their money is going the guardrails and like safeguards that are in place and have make sure they really understand it and give them very clear ways to like revoke access set guardrails set spending limits and like try and educate them as much as possible into what what is actually happening here because yeah if you you can I mean anybody can do anything with AI but not everybody can clearly understand it and I think that's like that's the risk and that's where the trust gap happens.

I'll um piggyback just on the topic of of guardrails and I'll go into it a little bit more but a guardrail is is a boundary you set and like I said an agent's always going to optimize for the outcome. So if you put the boundary don't go past that line but the agent's optimal goal is to shoot the soccer ball into the net and then that is behind that line it will always break your boundary. You have no assertion that it will actually follow suit to the guardrail.

It's good. That's right.

So it's it's an important distinction. Again when you're thinking about like what's the worst that can happen um with a guardrail if the worst thing can happen is astronomically bad, it will break it. Yeah, and I think like that's the Anil's point which is like take the guardrails out of the non-deterministic path or find some way to deterministically like enforce them somehow. That is a big question like so for example for the agentic wallet product that that I work on for example the spending guardrails are not up to the agent. It's like oh please don't spend more than $10.

It's like you said if the wallet's empty you can't spend any more money. That's it. You're done.

access controls.

Yeah, exactly.

Absolutely.

That's good. That's good.

Because I think on the trust layer beyond just the technical side I think is you know there's evolving regulation. I think there's more regulation and guidelines than the you know more people are willing to trust. Also think there's you know to your point anybody can pop on Claude and have it build something these days. That doesn't mean it's safe and secure, right? So working with you know using companies that have built out you know information security certifications and all of these you know licenses and regulations that sit behind them to show that this isn't just you know you know I spent my Saturday building a building a tool for you to spend money on but it's something that you can trust as a regulated product.

Awesome. Awesome. Let's talk a little bit about the security of the autonomous code. Johnny, will you talk a little bit you make a case for formal methods? What does a mathematical guarantee give me that a test suite does not and why does it matter that the proof is independent instead of the AI checking its own work?

Give us a little bit of tell us a little bit about that.

Yeah, great question. So I think it's important to start with the history of formal methods and what they are. So formal methods is like a blanket category and it means mathematical guarantees and there's different ways to do that and different tooling that does that but Um, lot of people think formal methods they think formal verification, which is a proof that gives the mathematical guarantees. Now, formal methods was originally for mission-critical systems. What mission-critical means is in the event of failure, it is catastrophic.

Good example of this, what happens if our plane crashes? Catastrophic. What happens if our medical device fails? Catastrophic, right? So, there are very specific core banking system.

What happens if that fails? Right? So, they're very specific instances. And um, in these instances, how did they solve for that? Well, they went to all the universities and they found the smartest mathematical PhDs and they said, "Tell me what we need to prove and then prove it.

Write the Write it Handwrite it." So, great, not scalable. Um, and uh, the other question there is like, "Did you get the smartest PhD? How much did he sleep? Did he do it 100% well?"

And that's also a little bit of a betting game. So, how do you make it not a betting game and how do you make it scalable? That's what we do. We're the first company to ever automate formal methods at scale and put it into production in real-world systems. So, what I mean by that is 150 billion 55 billion in volume circulate through our systems before going out with um, in the digital assets uh, economy.

So, like, Circle or Ave or any of these ecosystems are using us to mathematically guarantee components of their code before they put anything into production. Um, and and why is that Why is that critical? Because in the event of failure, lots of money will be lost. So, that is that's catastrophic. Um, so, your question was what Why?

Why formal methods versus like a guardrail and and why why is it necessary? It's necessary in the event of if it is um, if it goes wrong, it's catastrophic. And now that we're moving into the agentic future, um, more and more things are becoming mission-critical because of the bounds um, of access that these agents have. So, for example, historically, software had a human in the loop um, and it had very, very aggressive constraints. Now, this agent can update customer records, right?

So, so you have to be very clear, okay, but it cannot uh, delete an entire Like, you have to have conditions that must always hold true because in the event that they don't, it would completely wipe a company. And so so that's the difference that we're moving into a world where more and more systems are mission-critical because of the advancements of AI and and the digital asset ecosystem.

How likely uh is it for an agent to actually uh stay inside the guardrails? Do you have any examples of like the code breaking out? Like

Yes. So it's very likely.

Okay.

[laughter]

Like Replut had that incident, right? Like a year ago where the entire database was um was down. I think uh Amazon alone has had more sev sev zeros this year than it ever has in its history. Um and and again, you know, they're not giving us the diagnostics there, but we can put one and one together, right? Um and and that's often attributed to like more and more code is written by AI.

It's not checked as aggressively because the AI's checking itself on what it thinks is correct.

That's good.

But there is no third party validating what actual like correctness means. And someone needs to define that and define the scope of what absolutely cannot go wrong. Cuz maybe a few things can. Maybe the front end can get a little janky and and that that isn't going to ruin the company, is it?

Right.

Yeah, but um if if my internal information goes over to Amanda, Amazon's dead, right? So So there are constraints of what can and can't happen and where we allow kind of AI or or intention to differ from from um from differ from like intention to actually what what means production. It's like behavioral drift. That that's okay in some cases. Actually many cases.

We can have like a janky UI. We can have a little bit like of a of a behavioral drift, but we can't have certain security properties, compliance properties

Right.

drift, right? There needs to be actual mathematical guarantees that certain properties must hold. And as organizations grow larger and customers become more and more like important, so like if you have any publicly traded companies on your customer base, right? The the controls need to be much more aggressive.

Got it. Got it. And you know, AWS uses deterministic controls for AI agents. What does that mean in practice, and what can an agent simply not do?

So, we we discussed earlier that we want to set guardrails and spend controls per session, per transaction. So, you can say spend $5 in 10 days, right? Or or spend you know, $1. Yeah, you can set those limits. So, that's number one.

Having end-to-end visibility into what the agents are doing, being able to trace through all of those executions and say, "Okay, this is what is visible or not, right?" So, and uh we already discussed about security, but the other side of the equation is having the policy engine, some kind of a store where every agent agent interaction is validated against these deterministic controls. And so, we have like something called as agent core policy engine that allows you to create natural language policies that allow you to define those, and there is like a open source cedar templates that can be created. It's a little bit more depth, but yeah. So, you can create those guardrail controls and make sure that the agents go through this deterministic path.

So, I'll pause there. Yeah.

So, this is my question I had for you guys when we were meeting about the panel was about blockchain. Can blockchain be the accountability layer? Am I giving it too much credit? Like, you know, if your private keys can make sure your agent doesn't go rogue. This is open to anybody.

Cuz this is from a compliance standpoint, a compliance thing. What do you What do you guys think? Am I giving it too much credit? Or can this Can blockchain be that accountability layer?

I mean, blockchain can be a part of the accountability, for sure. Like, cuz you you know, you can you can verify authorization. Like, I authorized this happened because I only have access to my private key, and so I'm the only one who can sign this transaction. Um or I, the agent, whatever. Like But um

And that's your proof that you did it.

That's the proof that that it it it occurred and you didn't go rogue. And you have yeah, you have an immutable record. You have the you have the blockchain. You have the chain.

Yeah.

Um and so you can also prove that it happened, which is basically how XBRLE 2 works on some level where like the transaction occurs, the money settles, and then the original person who requested the money was like, "Hey, you can pay me for this." They go they go check the blockchain. They go, "Yeah, sure, you totally sent it, but I I'm going to go check myself."

Okay.

[snorts]

So you think it could be part of it.

be part of it. There's like there are additional pieces that are being built at the protocol layer to things like signed receipts where you just trade back and forth with the counterparty. Um details about the transaction, I agree to this, you agree to this, I agree to this. Okay, let's all go have a party. And then the transaction occurs and you have an audit log.

But I think to Anil's point, like having an actual log of what happened is um you're not only that's not going to be solely on the blockchain. It just can't.

It can't do that. Yeah. Okay, well that was my thought. Let's talk a little bit about pilot to production, what fails first. Uh this is to Tom and Anil, you guys can share this.

Almost every design today has a human confirming the transaction. What has to be true before we let go of that check? So real quick, both you guys, if you guys don't mind comment on that.

Yeah, I think it kind of tied back to some of the my comments earlier and kind of the amazing work that's going on uh with these folks is we have to be able to prove that you authorized the agent to do those actions. And I think

Yeah.

you know in order to get there, there are lots of different ways from a mathematical and from an engineering way, but ultimately I have to, you know, describe this and prove this to a regulator, uh to people. Um and so there is, you know, to you know, kind of back to Amanda's response on that last question, um showing that it happened doesn't prove that it was meant to happen. And so I think the proving that it was meant to happen is the harder part to do and I think that goes into, you know, you're going to see I think more clearly more building around this and more commoditizing how we register agents and register what they're allowed to do, what they are given to interact with and things like that.

Okay. Um what about guardrail this could be for another Johnny. Guardrail adherence in production not in testing what is the first thing that slips? Either one of you guys.

So when transactions happen at machine speed right so anything can happen so that's kind of where the guardrails are really required and so the controls spend controls being able to set the policy level controls are most important. So that's I see that as a you know a must have.

What do you think?

Yeah I I mean I would piggyback on that just with if you are not putting mathematical proofs around what it can and cannot do you must control access aggressively. So you must be able to lay out worst case with what it can see. It can do it and you you must be able to come to terms with that.

Awesome awesome.

Your test might hold and you know 99 times out of 100 but it will break in the one potentially yeah.

Yeah and what about a framework that around this what does a framework look like?

Um I mean the way I I I think about this is if I have a agents that I want to use you know I think a starting point is kind of what you're seeing some of the credit card companies do. You've got to register your agent with them. You're registering that this is my agent this is what I'm allowing it to do and again what that helps in is just like you know if you have someone steals your credit card you have the ability to challenge what happened there. If this goes rogue and you've said hey Amex or Visa I told you that this agent was only allowed to do X Y and Z with my card and you let it do otherwise that's not a me problem that's a you problem. At least that's the argument.

Kelly, your word against your agent.

100%, which is where I think this region the Yes, especially when you know, as as Jenny said, it's they're going to look to get away around things, not out of maliciousness, but out of trying to solve things the best, most efficient way possible. So, yeah, I think that's again kind of what I said in the beginning. This is the fun stuff that we're trying to solve, but scary and frustrating at the same time.

And I believe OpenAI and Anthropic both independently have done studies on this and and a large-scale study I was looking um at most recently that OpenAI did, they were essentially measuring that, like, will it overrule guardrails for optimization? And again, nothing malicious, just optimization, get to the path quickest. And 79 times out of 100 it will.

And I think like reminds me of a

There's um there's there's a caveat there. Sometimes it's because the language, the human-readable language that you give it and and it might be where you're going, yes, is allows for inferences of what does this mean? And it allows the AI to actually decipher, okay, this means this is more important than that. So, here's where where formalization and I'll I'll continue to toot my horn here, is like if you can formalize and actually say like this is exactly what it means.

Yeah, at a granular level, to the to the to the teaspoon. Then it then it won't, right?

And I think that ties into I was thinking about this when we were talking about trust and how do you develop trust? I think a big part of that is enablement. I think a lot of There's a the availability of a lot of tools right now. That doesn't mean we all know how to use them, right? Like you wouldn't give someone a car and just let them drive it.

And so I think that's a big piece of this is coming up with standards and enabling people to understand how to use those standards and then we're all speaking, you know, the similar dialogue, similar language, then when we go to defend something, we all know that this meant X and and we're all agreeing to that kind of common language. Um I think that's important.

All right, we're going to do a real quick lightning round. One real thing and one thing that's hype. No matter how loud it gets this week, one real thing in the next 12 months. And then something that's hype. I mean, let's start with you.

Come on, let's let's real quick lightning round.

Can we start on the other end?

to Okay, you got to think? All right, now you got to go.

So, the the number of transactions that are happening are real we are at the inflection point where there are more bots that are hitting the content and MCPs and and this is the time to monetize. So, the that is the real. So, the hype again is again the protocols are still being written, going through modifications, so the different versions of the protocols. So, the evolution is happening at the same time, right? So, that's

Love it. Awesome.

Um okay, so I'd say the real thing on the security side is the attack surface, meaning the amount of space that's vulnerable is continuing to get larger and larger and um what will go wrong will will be shocking to everyone in the next 12 months. Hype. Um I would say on the digital asset side is how many players are actually pushing things into production. So, a lot of people are researching or allocating resources to look into digital assets and what they can produce and on the agent stablecoin, all these layers, um lending protocol, like whatever it may be, but very few are actually making real moves to put them into production and make them usable. Okay.

Great. So, a lot of talk, no walk.

[laughter]

I love that. I love that.

I love that.

Um okay, what's real? What's real is um we have uh programmable agents using programmable money on programmable blockchains and um I feel like we haven't scratched the surface on that and I'm very excited to see where that goes because ERC-20s are just smart contracts and you can do all kinds of things with them. Um so, that is real and I wish someone would do something cool with that. And hype-wise, I like you're not going to have an agent like booking all of your travel without you there, which I think would be great cuz I

People are scared of that.

People are scared and like

scared of that.

And like or or doing all of your trading for you without you there.

Right.

Um but like we're we're getting there, but fully fully autonomous is not quite uh between a human and agent not quite there.

Yeah, I think on the real side I think regulators are going to start to step into this realm more and more. Um New York Department of Financial Services, which is a very active regulator, made comments uh maybe a month or two ago about them starting to look into agentic commerce even though um you know, many of these transactions like aren't regulated in and of themselves. So, I think we are going to start to see um some growth there and I think what that means for companies like ours is to be on the front for foot to show that we are thinking about guardrails and how to keep people safe and kind of educate them. Um hype, I tend to agree that I think we are starting to build some great tools and the ability in an ecosystem to use these, but I think the it's going to take longer than 12 months to build up the trust for mass adoption and having an agents do uh all of your stuff and we can all sit around and and do nothing.

Well, can you guys give them a hand? Thank you guys so much for being here. You guys are doing this. So, I appreciate you guys. Thank you so much.

[applause]