Trust, Discovery & Autonomy in the Age of Agentic AI

Transcript

All right, here we go. Hi everybody. My name is EJ Galano and I work at Infura. Um, uh, 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 web 3 in 200 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-s 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. Um if you use Infura, you're very um 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 web 3 evolves. And that's what I'm supposed to be talking to you about today is we're here at the agent uh agent zero conference talking about how agents are the infrastructure that's now

enabling a lot of new activity on web 3 and what is it that RPC and Ethereum uh service providers have to do with that. There's a lot of primitives that were built over the last 10 years of Ethereum. Uh look at all of the new products that are built. all of the uh things that stable coin innovation has pushed forward in mainstream adoption. It wasn't just uh 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 like UX problems, uh different EIPs and ERC's, all of this stuff. uh

built different primitives that now power defy as we can actually use it today. So having a mobile app where you can earn 10% APY is like a a very nice and simple concept. But the thing that actually powers that was built over the last 10 years of some of these uh things that you saw that maybe still exist, some of them don't. But there were a lot of lessons learned. Uh there's a lot of projects out there like bass that are getting huge adoption in the mainstream and bass is built as an optack chain. So optimistic roll-ups helped power that and optimistic roll-ups came from the plasma group research or 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 like what things are worthwhile content and then somebody curating that content and making it more digestible for the consumer. uh a marketplace. Uh app stores, those are another example of that of somebody going out there and curating all of the things that are exploding in a new technical environment, uh 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 like 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 ver verifiability that it was actually done. There's a lot of uh nuance in that problem. A lot of different angles that people are taking like verifiable AI reproducible res uh results running um agents and uh AI

infrastructure in a TE or some other type of trusted environment. We on the Infura side started with X42 as a way to get receipts for API payments. That was our very simple use case that we that started to introduce us into how we start to provide receipts for things that we're doing in uh our line of business. We provide an API. How do we actually accept payment for it? This uh 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 um 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 because you needed to find if there's a new OP stack chain that launched this week, if there's uh some new layer 1 that's launching next week, who's the provider

that you're going to interact with, does your current provider provide that service? X42 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 uh development. It was part of our transition from Infura being a centralized SAS into what I now work on full-time which is our decentralized protocol called Den. It stands for the decentralized infrastructure network. And I'll get into the high level of what that is as a

protocol in a bit. But that's sort of the background of why we're here talking about agents and how Infura factors into that. A lot of the problems that we have been solving in trying to turn Infura into a decentralized protocol are very much translated into the problems that we're seeing as people are discovering and accessing MCP APIs and agents. How do you verify the reputation of these things? Ensure a quality of service etc. This is our highle architecture of how the Den protocol works. AI agents, DAPs, 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 web 3 applications on and what's the difference between a web 3 application and uh traditional web 2 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 it 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 uh meeting a minimum level of quality and um what capabilities they have is uh a watcher system that we have a watchtowwer 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 X42 that I just mentioned. Lastly, we have a staking layer implemented as an IGEN layer AVS so that we're not requiring some new token to stake to join the

network and secure the network. It's reststake like ETH like Lido staked ETH securing our operators to provide new services on the marketplace. So, if you're an API provider or um somebody that created a new service, you stake ETH, run this operator um 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 onchain SLAs's. How do you like 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 Den ensures that there is an onchain 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 a onchain bond that's going to enforce that. Our watchers currently are uh supporting us through checking all of our RPC endpoints, doing things like checking latency, ch uh checking which regions of the world they're uh infrastructure is actually uh hosted in. Uh it checks

consistency across chain data. Uh making sure that there's no inconsistencies in the latest information. 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 it was easily extensible because it's a um 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 X42 and agencies discoverability. Tomorrow we'll be speaking at the trustless agents day talking about our participation in the

ERC 80004 specification. If you're not familiar with that, it's the specification about having an onchain registry for AI agents. So, you can see why we started to look very closely at this problem and work with the the folks that were behind that ERC because we were building an onchain registry for services. And as we started to look at our design versus the design for ERC804, we were both kind of uh overlapping in terms of what we were building. I had been pitching Den as this is an uh onchain service registry. But what ultimately is the difference between an onchain service uh 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 80004 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 um periodically check health and how you report that information and how you score it. uh when we tried to apply a lot of the algorithms that we had for scoring infrastructure to agents, it it was very clear that this was something that could immediately provide value and why we started to work with integrating

with 80004 so that we can help attest to the quality of information that's on this registry. So here's an example a query of like at a high level of how you could expect to interact with a protocol like this. It's not just point look at 804 what's on this registry and start to consume it but at a protocol level find me a service that gives me these characteristics and you define your filters how much you want to pay uh what regions those services are deployed in what the um or uh anything else like the uptime guarantees that they provide through the SLA agreement that exists on chain.

This is where the evolution of businesses in web 3 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 like 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. Um, I used to use um 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 the software and your license was tied to if you wanted to run this on like a four core or an eight core machine. SAS is the uh evolution of that business model that was enabled by cloud. Cloud was the technology. SAS 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 Infira run a SAS company. We didn't give you a node software and say we'll charge you $1,000 per core. A2A ERC804 X4 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 SAS 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 use utilize this new channel. Whether it's a user interacting with a wallet and the wallet has an agentic interface built into it. People are actually using these platforms that are going to be deploying their own agents or it's just DAPs that are augmenting their capabilities through AI features and data and capabilities. All of that's going to flow um through to access

existing services uh uh new MCP APIs and new models that come out over time. It's going to continue to evolve and we don't really know where it's going to lead, but starting at what's solving the near-term problems, which is the discoverability and payments is where we've started with participating in X42 and 804. So agents are going to be one of your new customers. Like how is your current business or product uh evolving and keeping up with that to be able to serve that? Um as a developer shop like Infura, it started with being able to support uh an MCP context for our uh 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. um how digestible is your API? Uh 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 our problems with discoverability through an on-chain registry, the trust with the onchain SLAs's and staking and how we tried to solve that. um 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 um going to continue to try to help secure infrastructure for the next phase of web 3, which uh includes agents. Agents are infrastructure and they're going to be on this reg or these

registries and on our marketplace. So that's my talk. Thank you so much everybody. Uh d.build is our website if you want to check it out. Um you can follow us on Twitter. We did a uh launch of our AVS earlier this week on Monday. So as of this week our AVS is live. People can run operators. People can stake to secure the network and reach out to us if there's any new specifications especially that you're interested in collaborating on. My my belief is that X402 is a great way for us to get uh adoption near-term. There's extensions to that as a protocol specification for payments that would enable other business use cases like

monthly subscriptions or some sort of like bulk discount for services that's currently not captured by that spec. There might be another specification that you know about that would be interesting for us as a marketplace. We're not prescriptive on how somebody accepts payment. Accept payment in any token that a service wants to accept payment in. Uh use any way of uh accepting payment. It could be a streaming protocol that we integrate. It could be another way of uh doing things through an NFT that you purchase that gives you access to a service. Um we'd be happy with working with anyone interested in integrating with the protocol. Thank you.

[applause] Thank you Galono for this great talk. U 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. 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 X40? So X42 is usage based and that's what I'm talking about with uh and with Infere 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 X42 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 X42 to accept payment," a lot of users would consider that too high friction. They either don't know how much they actually use because they'll say, "I don't know. I pay $30 a month." Like, I don't know how much I 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 X42 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 um a NFT or token that's owned for uh 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. Um on X42, I think the thing we were looking at is using it as being a being able to open and close a session and then charge over the duration of the session. Um but there's other proposals of how X42 can do something similar to what you're saying about um running out of funds on like a or a credit card being declined.

There's other things that people can do like if we're talking about purely like web 3 mechanics. One of the mechanisms that I've seen that I like is um staking a particular token, not charging for it uh or not actually like prepaying. There's a difference between prepaying and buying that amount uh 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 but uh at a pay-per-use rate but if um 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 you it's not directly paying or asking asking somebody to commit and there's like rewards mechanics that help offset that for them and uh there's no specific design for that right now. Our network currently doesn't have something to support that but it's something that would want I'd want to implement so that this protocol actually works in a traditional like SAS business context as well. >> Okay. Uh we won't have any time left for more questions. So please uh catch him outside in the hall if you if anything.