Trust, Discovery, & Autonomy in the Age of Agentic AI
EG Galano presenting at Agentic Zero at DevConnect in Buenos Aires, Nov 20, 2025
At the Agent Zero conference, Infura’s E.G. Galano explained why AI agents need "receipts," how decentralization builds trust, and why infrastructure providers must evolve to serve non-human users.
The last decade of Ethereum development spent building fundamental primitives like scaling solutions, EIPs, and token standards. This laid the groundwork for the DeFi applications we use today. Today, we are at a similar inflection point for AI agents.
Speaking at the recent Agent Zero conference, EG outlined a compelling vision of how Web3 infrastructure must adapt to a world where autonomous agents are primary users. The key takeaway? The mechanisms needed to decentralize traditional infrastructure are the exact same mechanisms needed to power the agent economy.
Web3 primitives enable discoverability and reliability for Web3 Agents
Here is a look at Galano’s insights on trust, payments, and the architecture of the future.
For the full recording:
The "Amazon Problem" for AI Agents
Your preferences are abstracted by cheapest, fastest, eco-friendly and not necessarily the brand of the delivery
If you are a human looking for a product, you rely on marketplaces like Amazon. You rely on their search results, user reviews, and star ratings to establish trust before you buy. When you look at the emerging landscape of AI agents and Model Context Protocol (MCP) APIs, that discovery layer is missing. "How do you know which ones to use? Does it do what you want? How reliable is it?" EG asked.
Furthermore, agents operate differently than humans. They require absolute verifiability. EG used the metaphor of delivery services: you might trust FedEx's brand, but you still want the tracking number.
"AI and agents want receipts," Galano said. "They want to know... clearly what they're getting in terms of quality of service, availability of service, how much something costs, and ultimately they want some verifiability that it was actually done."
Decentralization Meets Agent Needs
Interestingly, Infura didn't set out specifically to build agent infrastructure. They set out to decentralize their own highly successful, but centralized, RPC service.
This journey led to the creation of DIN (Decentralized Infrastructure Network). As they built DIN, they realized that the problems they were solving for decentralized RPC were identical to the problems facing agent developers.
DIN is designed as a generalized marketplace for consuming services. Its architecture provides the "receipts" agents need:
Watchers: A network that constantly verifies that infrastructure is online, performant, and returning consistent data.
Micropayments (x402): A protocol allowing for seamless, per-request crypto payments, which is far more suited to agent interactions than traditional credit card subscriptions.
On-Chain SLAs: Agents need guarantees that a service they rely on today will be there tomorrow at a promised price. DIN enables on-chain Service Level Agreements secured by staking (via EigenLayer AVS).
DIN’s Marketplace for creating decentralized trust and a routing layer for verifiable Web3 connectivity
The Convergence of Registries and Reputation
DIN’s Watchers and Marketplace protocol adds quality and reputation insights
EG highlighted that the industry is converging on standards for trust. He pointed to ERC-8004, a specification for an on-chain registry for AI agents.
Infura realized their service registry for DIN overlapped significantly with the goals of agent registries. The common thread is reputation. Whether it's an RPC node or an autonomous trading agent, users (human or AI) need a verifiable history of performance to trust it.
Evolving Business Models for Non-Human Customers
A user will likely connect to AI Agents through LLM interfaces or with existing applications
The presentation concluded with a crucial insight for founders and developers: business models change as technology changes. Just as the cloud enabled the shift from expensive software licenses to SaaS subscriptions, the rise of agents will force another evolution.
"Agents are going to be one of your new customers," EG said.
Businesses need to ask themselves if their APIs are digestible by agents. Are they exploring MCP APIs to wrap business logic? Are their payment models flexible enough for programmatic interaction?
The future of Web3 isn't just about humans interacting with dApps; it's about agents interacting with infrastructure, services, and each other. Protocols like DIN are building the verifiable trust layer to make that future possible.
Full transcript (AI-generated):
EG Galano: All right, here we go. Hi everybody. My name is E.G. Galano and I work at Infura. Phil gave you a bit of my background. I started in distributed systems, traditional tech, worked at Sony, did some stuff scaling infrastructure to support their PlayStation streaming network that's now called PlayStation Now.
And when I entered Web3 in 2016, I started to try to apply that knowledge to a space that really didn't make any sense to me. Like people were talking about decentralized identity and self-sovereign systems and all of this stuff that you could do with this Ethereum world computer. And as I was trying to get my bearings, I started with a place that was safe and made sense, which was infrastructure and trying to scale infrastructure. So that's why we started Infura running nodes as a service.
If you use Infura, you're very up to date with what we do. We provide Ethereum data and blockchain data for people to build applications. 10 years later, pretty much since we launched that, there's a bunch of other RPC providers that do the same thing as us. And we've been on an evolution of what Infura becomes as the infrastructure to support Web3 evolves. And that's what I'm supposed to be talking to you about today. We're here at the Agent Zero conference talking about how agents are the infrastructure that's now enabling a lot of new activity on Web3 and what is it that RPC and Ethereum service providers have to do with that.
There's a lot of primitives that were built over the last 10 years of Ethereum. Look at all of the new products that are built, all of the things that stablecoin innovation has pushed forward in mainstream adoption. It wasn't just an opportunity that now exists. That opportunity came over the last 10 years through all of the things that were built. Like there was a lot of research that went into scaling the chains themselves, how you deal with certain UX problems, different EIPs and ERCs, all of this stuff built different primitives that now power DeFi as we can actually use it today. So having a mobile app where you can earn 10% APY is like a very nice and simple concept. But the thing that actually powers that was built over the last 10 years of some of these things that you saw that maybe still exist, some of them don't. But there were a lot of lessons learned. There's a lot of projects out there like Base that are getting huge adoption in the mainstream and Base is built as an OP Stack chain. So optimistic roll-ups helped power that and optimistic roll-ups came through the lessons learned from Plasma group research.
So, we're talking about agents and AI, and there's a lot of things that we can learn from in looking at past patterns and how that played out and how it will continue to apply to new technology like agents.
If you've tried interacting with agents, if you've tried exploring different MCP APIs, one of the things that you immediately encounter is like: Where do you go to find these things? How do you know which ones to use? Does it do what you want? How reliable is it? And that is not a new problem. It's an old one. That problem is previously solved by search. People indexing the internet, checking and seeing what things are worthwhile content and then somebody curating that content and making it more digestible for the consumer.
A marketplace. App stores, those are another example of that. Somebody going out there and curating all of the things that are exploding in a new technological environment, and then applying ratings and reviews because that's the thing that we as humans immediately gravitate towards in terms of sharing our experience with that and understanding what others' experiences were with that so that we can make decisions on what we buy or what we interact with.
That Amazon marketplace type of example is just like one layer. There's layers going all the way down that do the same thing. So I trust that Amazon very likely has what I'm looking for. I go there, I buy something, and then it comes to my house. That next phase of how it gets to my house is through the delivery. And it used to be like it was UPS that always delivered it. And then at one point it was FedEx that always delivered it. And then as more and more providers started to try to serve that market because they saw that there was an opportunity to make money there, they started to serve Amazon and other distributors to do that last mile of delivery.
You really didn't care how it got to you. You didn't have to trust the brand that was bringing you the service. You just cared about the fact that you actually received it. And that's where we start to get into AI and agents. AI and agents want receipts. They want to know that when they're interacting with something, there's a clear understanding of what they're getting in terms of quality of service, availability of service, how much something costs, and ultimately they want some verifiability that it was actually done.
There's a lot of nuance in that problem. A lot of different angles that people are taking like verifiable AI, reproducible results, running agents and AI infrastructure in a TEE or some other type of trusted environment.
We on the Infura side started with X402 as a way to get receipts for API payments. That was our very simple use case that started to introduce us into how we start to provide receipts for things that we're doing in our line of business. We provide an API. How do we actually accept payment for it? This research that we were doing started about three years ago. I did a talk on how we were going to try to decentralize Infura. Infura was called out as being a centralized provider, a single point of failure, a risk to build DeFi on top of because if we went down, it would take down a lot of the infrastructure that powered the decentralized finance world. That was mitigated by the fact that there were a lot of reputable providers that existed out there like our friends at Alchemy and others that were able to provide similar services and you could interact with one or the other.
Doing so required this friction point of accepting a credit card payment on one, accepting a credit card payment on another, getting invoices from both companies, having an account manager with multiple companies. And as more and more chains started to get added, it made this problem more and more difficult for developers.
X402 allows you to interact with all of these service providers in a unified way of paying in a very seamless way, and that's what agents needed. And so as a specification that was really exciting to us and that was our first entry into understanding how what we were building was relevant and tied into all of the activity going on with agent development. It was part of our transition from Infura being a centralized SaaS into what I now work on full-time which is our decentralized protocol called DIN. It stands for the Decentralized Infrastructure Network.
[Does] a high-level architecture of how the DIN protocol works. AI agents, dApps, developers, institutions interact with us as a marketplace protocol. It's not decentralized RPC because our goal was... decentralized RPC isn't enough for this to be like a worthwhile innovation. What we're doing with decentralized RPC can be applied to other APIs that people are building Web3 applications on. And what's the difference between a Web3 application and a traditional Web2 application at the API level? It's just a different type of data. So we started to build this as a generalized marketplace for consuming services. And what is the difference between an MCP or an agent and a service? It's really a nuance at this point. So as a marketplace platform, we have a router that routes traffic out to different entities on the network that serve infrastructure.
The thing that actually verifies that that infrastructure is online and performant and meeting a minimum level of quality and what capabilities they have is a watcher system that we have. A watchtower type network that has a bunch of different checks, consistency checks, different algorithms that score endpoints. And the payments between all of these entities on the network is via crypto using X402 that I just mentioned.
Lastly, we have a staking layer implemented as an EigenLayer AVS so that we're not requiring some new token to stake to join the network and secure the network. It's restaked ETH, like Lido staked ETH, securing our operators to provide new services on the marketplace. So, if you're an API provider or somebody that created a new service, you stake ETH, run this operator and you list your service on the marketplace for people to discover and consume. And that's applicable for agents as well and MCP APIs.
The thing that's needed for these agents and MCP APIs I'm talking about are on-chain SLAs. How do you... you can check it and say, "Okay, it's there. I'm going to start using it. I'm going to build my application to consume that or tell my agent that they can use it." But will it be around in two weeks? Will it be around in three months or in a year? A marketplace protocol like DIN ensures that there is an on-chain contract and guarantee of a service level. So you could say something like, "I want this service providing this MCP that is going to charge this amount for the next 60 days," and you know that there's an on-chain bond that's going to enforce that.
Our watchers currently are supporting us through checking all of our RPC endpoints, doing things like checking latency, checking which regions of the world the infrastructure is actually hosted in. It checks consistency across chain data. Pretty much anything that you can write a custom check for can run on this watcher network. And when we started to apply this to checking MCP, it was easily extensible because it's a fully creative test that anybody can write. Anybody can extend the functionality of this marketplace by writing a test that checks the type of service that they want to consume.
The thing that a lot of people are also talking about when it comes to X402 and agents is discoverability. Tomorrow we'll be speaking at the Trustless Agents Day talking about our participation in the ERC-8004 specification. If you're not familiar with that, it's the specification about having an on-chain registry for AI agents. So, you can see why we started to look very closely at this problem and work with the folks that were behind that ERC because we were building an on-chain registry for services. And as we started to look at our design versus the design for ERC-8004, we were both kind of overlapping in terms of what we were building. I had been pitching DIN as "this is an on-chain service registry." But what ultimately is the difference between an on-chain service registry and an agent registry? I think over time those two things are going to converge.
And the thing that is part of that registry that's super important on the 8004 side is reputation. How do you attest to the reputation of these agents? What we've learned over the last 10 years with verifying the quality, availability, and performance of web services applies to agents as well. The way that you write tests, the way that you periodically check health and how you report that information and how you score it. When we tried to apply a lot of the algorithms that we had for scoring infrastructure to agents, it was very clear that this was something that could immediately provide value.
This is where the evolution of businesses in Web3 and in the traditional web world are going to converge from our perspective. Just like people used to talk about like "Oh I work at a web company" or a "traditional company"—in this day nobody really says that anymore. Every company is a web company. Every company has either an application or some way of interacting with people online and business models are going to also have to evolve to keep up with that.
I used to use this software Tableau for data analytics and the license that I was negotiating at the time with the company was based off of how many CPU cores you were going to run the software on. You had to self-manage the software and your license was tied to if you wanted to run this on like a four core or an eight core machine. SaaS is the evolution of that business model that was enabled by cloud. Cloud was the technology. SaaS was the business model that evolved through that. And look at how that evolved the way that everybody does business today where most of us, including Infura, run a SaaS company. We didn't give you a node software and say we'll charge you $1,000 per core.
A2A, ERC-8004, X402 specifications—more innovations like that are going to continue to define how people interact at an agentic AI level. And businesses are going to evolve. It's not the only channel of delivery. There are still people that sell software in a not SaaS way, but this is a new channel that's going to exist and people need to be paying attention to it and understanding how their business is going to utilize this new channel.
Whether it's a user interacting with a wallet and the wallet has an agentic interface built into it, or people are actually using these platforms that are going to be deploying their own agents, or it's just dApps that are augmenting their capabilities through AI features and data and capabilities. All of that's going to flow through to access existing services, new MCP APIs, and new models that come out over time.
So agents are going to be one of your new customers. How is your current business or product evolving and keeping up with that to be able to serve that? As a developer shop like Infura, it started with being able to support an MCP context for our developer documentation, because if agents don't have that optimal way of pulling your documentation, it's going to prefer to pull it from somebody else that does have that interface. How digestible is your API? Are you considering creating like an MCP API to wrap some of the business level logic and expose that even if you don't know exactly what the use case is? Doing it as like a weekend hackathon, a fun project is something that's worthwhile to do so that you're not missing an opportunity to discover new users and new use cases.
So that's kind of what we're thinking about in terms of how Infura, in this evolution into our decentralized network, solved some of our problems with discoverability through an on-chain registry, the trust with the on-chain SLAs and staking and how we tried to solve that—keeping service providers accountable to the people that were going to be trustlessly consuming their services—and how we streamline payments through some cryptographic means. And that is directly translating to how we're going to continue to try to help secure infrastructure for the next phase of Web3, which includes agents. Agents are infrastructure and they're going to be on these registries and on our marketplace.
So that's my talk. Thank you so much everybody. d.build is our website if you want to check it out.
Moderator: Thank you EG for this great talk. Now we'll be having a Q&A session. So if you have a question please raise your hand and our volunteer is going to come and give you the microphone. I don't see any hands. I guess we have a hand right there in the back.
Audience Member (Arno from Chile): Hello. Um, Arno from Chile. I used to sell OTT subscription with credit card in the past. Um, and the main issue we had is renewal. Uh, because the credit card could expire. The credit card could be out of money. Um so I guess a wallet cannot expire but uh it can be out of of of money. Uh so how do you handle it with X402?
E.G. Galano: So X402 is usage based... And with Infura we've definitely had that same issue with somebody using a prepaid card or a card that expired. Anybody that's accepted credit card payments has felt that pain. So X402 allows somebody to just have a wallet that pays in crypto for each request. Each request has a denominated value of some amount of like micro USD or something that it's going to do for each request.
And that's where this becomes a limiting factor for businesses to adopt it. Because if I went to you when you were running this business and I said, "Use X402 to accept payment," a lot of users would consider that too high friction. They either don't know how much they actually use... Or they'll say, "I know how much I use, but I have a discount because I committed to a certain amount." Like, that's where X402 kind of falls short right now.
And so we're looking at like is it possible to either extend X402 to support one of the designs that we have which is along the lines of having an NFT or token that's owned for a period of time where somebody has a set price that they issue for that token and it validates a session for a set period of time.
There's other things that people can do, like if we're talking about purely like Web3 mechanics. One of the mechanisms that I've seen that I like is staking a particular token, not charging for it, or not actually like prepaying. There's a difference between prepaying and buying that amount ahead of time versus actually staking the tokens. So say if I told you "stake a thousand of this token and that will ensure that I give you this access at a pay-per-use rate, but if at any point your wallet runs out of funds I will still give you access, but for each day that goes by that that wallet was not brought up to current, then your stake is going to get slashed." Right? And so it's not directly paying or asking somebody to commit and there's like rewards mechanics that help offset that for them.
Our network currently doesn't have something to support that but it's something that I'd want to implement so that this protocol actually works in a traditional like SaaS business context as well.
Moderator: Okay. We won't have any time left for more questions. So please catch him outside in the hall if you have anything.
