We are ready for our last talk before lunch. So, without further ado, I'd like to bring on Shady to talk about how we can change the wallet worlds and make better infrastructure choices to just solve the problems of needing multiple wallets. So, without further ado, please welcome him on stage. Excuse me. Hey, good afternoon, everybody.
Uh great to see see everybody in the audience here. I guess you must not be too hungry. You must have had a really big breakfast. I mean, uh lunch is just uh outside waiting for you. Uh hi, everyone.
My name is Shady El Damati. I'm one of the co-founders at Holonym. And uh we're building a tech stack for for humans called human.tech. So, we're we're at a builder conference today.
And what I want to talk about today is something that I think a lot of us are grasping with, uh trying to understand. And that is uh how is how is how is autonomous software going to change the world, right? We're we're having autonomous software do more economic work for us. So, what happens when economically productive software begins eating the world? Now, the prediction I want to make here is that within the next 9 months, the wallet as we know it is going to be dead.
We're not going to have these point-and-click interfaces. It's going to look like something completely different because the cost for creating software is approaching zero. And the primary user interface, the home page that users might go to for interacting with software, is going to change. So, yeah, I'll tell you what I exactly what I mean about that. But, I think it would be good to get an idea of uh who's in the audience.
So, who who here is actively using AI on a day-to-day basis, please raise your hand. Okay, yeah, that's like unanimous except the AV team. I don't think the AV team's using it. But okay, and then who here is experimenting with tools like open clawed or Hermes to run agents? Wow.
Okay, wow, that's like a really big amount. I feel like this number grows every day. I just started actually running my own Hermes agent as well. And it's it's it's a paradigm shift. It changes kind of how you think about how you think about just interacting with software in general and what your day-to-day looks like and you know, you tend to forget about things like meals and and taking a shower and your agents are always there waiting for you to to to be their parents.
But one of the kind of major challenges if you're experimenting with these types of systems is what do you do with the secrets that you need for your agents to actually behave autonomously? Right? If you want your agent to auto deploy servers. If you want it to auto deploy apps and completely own the CICD pipeline with you just in the loop when needed, it's it's a bit of a it's tough, right? You have this dot env file.
You drop the private keys in the dot env file. You drop your API access keys, your personal access tokens. And you pray to God that you know, it doesn't get prompt injected or doesn't accidentally leak the dot env file. So I don't think I'm alone in this. I would love to know by a show of hands, who here would actually give an agent your private key for a production use case?
One person. I need to talk to you afterwards. I'd love to hear exactly what your setup looks like. But yeah, we we probably should not be giving AI agents our secrets and if if there are use cases for this, I'd be curious to learn more about them. This is I think one of the biggest blockers for many builders and kind of the if there is going to be a transport transformational moment for AI agents in in technology in this next industrial intelligence revolution, we're going to have to get a we're going to have to figure this out.
So, I'm going to I'm going to put this up front. I I think let's start off with what the frame of reference is and then we'll go through why we're thinking about this design philosophy when it comes to software architecture for autonomous software. We need to move away from this idea of agents or even wallets in general acting as containers for assets or agents having authority. And thinking more of wallets as you know, they become kind of something different when you think of wallets as containers for capabilities or assets. And agents are basically just receiving this delegated capability, but never any any authority, right?
They never they never receive that. So, what does that mean? It basically means that because these systems are non-deterministic, right? In nature, it's very important that we have hard guardrails in being able to kind of delimit what sort of behavior they can do. So, for example, when it comes to to DeFi or when it comes to on-chain stuff, it's about say don't spend more than a certain amount in gas.
You know, don't participate in these transactions if you know, MEV if MEV safe routes are not available. You know, perhaps only sign applications from specific sign requests from specific applications only if they meet say so for example, some risk threshold or some list of criteria, right? Say that this application hasn't had an exploit in the last 30 days, then yes, I would like to then you're allowed to find the best routes, whatever that is. Um, so in in all of these cases, what we see is that human approval comes in only when you're you brush against the guardrails. So, the engineer's task then is to really kind of compress capabilities to their minimal attack surface, keeping security in mind.
And this is something maybe you can build through iteration as the production use case becomes more mature and you better understand exactly what the environment is that the agents uh, is kind of participating and behaving in. You build these primitives together and then you can end up with more functional autonomous uh, flows, right? Where you step in at certain points where it's important perhaps to revise the policy to perform uh, specific type of approval uh, etc. So, yeah, the sky is kind of the limit when you think this way and you're not just kind of like recklessly blind, you know, blindly running into uh, yeah, allowing automation to kind of just like, you know, maybe ruin your day. So, yeah, I mean, this is I I I think like, yeah, yeah.
So, this agent security issue really is a design problem, right? It's it's it's a design philosophy problem and it's coming from security as a first principle. So, how do we actually how do we actually approach secret management in a way that allows for these sorts of guardrails to exist? And you know, how is it even possible for anything to to do anything like how is it even possible for an agent to even do anything if it doesn't have access to your .env file?
Like the key has to live somewhere. If it's local, it needs to be read into RAM. So, there's been a a couple different ways to approach this in the industry and I think they're all indicative of uh, how people are starting to think about these problems. There's been exploits, right? There was like a DeFi exploit like a couple weeks ago because an agent leaked a private key and you know, a couple hundred thousand dollars were stolen.
This is only going to increase as things like Claude Atlas are released and more exploits become available and yes, it's going to be a big problem. So, approach number one is YOLO. Give the agent the key. Let's you know, we just want to experiment figure these things out and then perhaps a solution will reveal itself. Maybe agents will just become smarter and we're along for the ride.
Option two is a good option. Option two is you keep the key local. So, tools like for example, Iron Claw written up by Ilya from Near, really great piece of software that runs a separate container for your secrets and keeps that container shielded from the agent and that container is running like on localhost, so it's local. Or open open wallet standard is another great example where you have some seed phrase and with that seed phrase, you drive a key on the fly. Kind of like you know, BIP BIP 32 from Bitcoin.
You you have like you know, root seed phrase, you can then drive a key on any elliptic curve, any blockchain. You only read it in in memory very temporarily to sign the transaction and then you delete it immediately. This is a pretty good approach. This is not bad actually. Now, I'm going to propose a third approach that's even better that I think is even better for a couple different reasons and again, it's a bit of a design trade-off.
So, the better approach is the key doesn't exist at all. How about that? What if the key does not exist at all? What if the key is never reconstructed in in any single place, but rather is able to sign collaboratively. Meaning that you have you can take some some some some primitives from some cryptographic primitives.
You split the key up between say the sovereign share or the individual and a server and you're able to generate signatures on the fly. So there's a couple reasons why you would want to do this. First off keeping the key local limits you to say unless you're running your own RPC on local host as well. Uh You're going to be you know potentially you might be potentially vulnerable for say Oracle attacks, right? If something if there's some slight difference between things come out of sync between what's happening on chain and the state that you've defined on local, you can end up with a an Oracle mismatch, right?
So you your transaction might revert or worst case scenario man in the middle attack or something else, right? So Yeah, there's a couple problems with that and being able to do these things I think live in production I think is really important. So that's 2PC. 2PC is literally MPC, you know, but instead of multi it's two people or two entities that are interacting. On one side you have the clients where you can derive your key share from anything really like it could be for example it could be like you know if you wanted like a face scan, right?
You could have something tied to your biometrics if you if you want to get fancy or if you just want to keep it simple you could do a say like a phone number sign up or email sign up. You OPRF it add some entropy to it and now you have a really strong key. Now the problem with that though and the problem with most seed phrase based private key solutions is that if you lose the device, you lose access to the key. If you get malware on the device, you lose control of the key and the assets are zeroed out and you're wrecked. So starting from this primitive why not then have a second key share?
The second key share can then exist in another client, like a server, it could be enclave, it could be a network, it could potentially be a network like a threshold network like Lit or Ica. And when you want to actually perform a transaction, you take these two keys and you effectively multiply them together on the fly to generate the signature. Uh having it in the server is really powerful because now you can have runtime policies on the enclave or the network. For example, you can set all of these different guardrails in place, you can have them adaptive, right? With real-time information.
The policy itself can be an agent that lives within the network or the enclave. Uh and then you can spin multiple versions of these up, right? You can you know, you're not tied to one production setup for for this type of architecture. So, this this is the way forward and in in our in our mind, um we think that to really see uh autonomous software really reap the benefits of what's possible, we need to have effective secrets management and the most elegant solution that we've been able to find over the past 2 years of working on this problem is uh is is this 2PC architecture. So, yeah, okay.
So, what happens then, all right? If we adopt this 2PC architecture, what kind of automations can we see? Uh the idea here is that this stuff is happening really fast. Uh so, within the next year, you might actually, you know, instead of opening up MetaMask and then connecting to Aave and then loading up your safe multi-sig and then drinking your coffee and getting ready for the onslaught of 20 approvals and transactions that you have to sign and execute and confirm, uh you open up a natural language prompt. You open up your natural language prompt, you say, "Hey, good morning, Claude.
Uh it's a great day to rebalance my Aave portfolio. I want to get the best yield because it looks like some of the it looks like the collateral has changed. So how about this? You can swap up to $500 of my balance in Ave. And I don't want you to spend more than $10 in gas fees.
And then you have a 5-minute permission token that lets you execute this this string of transactions. So effectively what you're doing is in a single prompt, you're producing a signature with guardrails that lets you execute execute a very complicated set of transactions or intense with one single keystroke, right? Or a couple a couple keystrokes. So this is kind of the future we see I think at least in the immediate term where a lot of the wallet interfaces just starts dissolving into the background. It becomes pure infrastructure.
And the UI becomes something a little bit different. It's possible that there might be even further disruptions. I don't think this is the end-all-be-all for how we think about the future of front end for for for consumer-facing applications. I think now that the cost of software is coming down to zero, it's very possible that front ends might be constructed on the fly for customer segments to create personalized experiences that, you know, are tied to perhaps their their preferences, their history, or whatever profile they might have with the service they're interacting with. And in that case, like you know, it's yeah, that's kind of mind-blowing if you start thinking about the consequences of that.
So yes, so 2PC is live today for builders to interact with and start messing around and trying it out with for all you open cloud users. It's WAP for agents or agentic WAP. Super easy to use. Uh you know, we're looking at creating an SDK as well if the need is there for that, but you just do an NPM import of the package. You create uh, a wallet for your agents by creating a password.
And, uh, yeah, and then you can set policies. You can tell it exactly what it can or can't do. You can set up 2FA so that you receive a Telegram or Signal message whenever you you want to be included in the loop or when you run up against the guardrails. And then the cool thing is there is a front-end application you can go to and then log into the wallet. So, for example, if you wanted to set up uh, a wallet for your Ave rebalancing, you could say, you know, uh, shotti plus agent@gmail.
com. Uh, and then you create create the wallet for the agent. And then you go to wop.xyz, you know, have it run off. And then you can actually watch the balance and the transactions appear in run time uh, in real time.
So, you can kind of sit in front of it and and and watch the wallet do its thing and even intervene uh, or update the policies or you know, you know, even like uh, submit asynchronous transactions at the same time. So, it's kind of fun uh, it's it's it's to see what you can do with that. Let's see. Uh, I guess the other important thing here is that the wallet is chain agnostic. Uh, so 2PC, the cool thing about it is it can you can produce these signatures on any elliptic curve.
Doesn't really matter what chain you're working with. Uh, it can be supported. Uh, just reach out if that's if there's something that you need that we don't currently support. Yeah, so I mean this is what we do, right? Uh, we're really concerned with where autonomous software is going today.
I think there's not enough thought being given what happens when what happens when we really abstract humans away so far uh, and the kind of consequences that emerge from that. So, human.tech really, it's just an infrastructure for keeping these humans in the loop. Uh, and we do that in two ways. If you're familiar with uh, Gitcoin passport, that's us.
Um, you know, we to keep the humans in the loop, you need to identify who the humans are. So, we do proof of personhood. We have something like 2 and 1/2 million users, 50 million credentials have been created specifically just for proof of personhood. Been doing this since 2022 protecting quadratic funding rounds and a bunch of other stuff, right? And the other the other missing component that we felt we had to I think like that we felt really uniquely positioned to put out there is um this 2BC architecture.
So, being able to give you humans control, right? Identify the humans then give them the ability to exert control and protect their authority over the autonomous software that acts on their behalf. And that's what Wallet as a Protocol was built for. So, yeah. I mean, what more is there to be said?
If you're working on any project in the hackathon, we have a booth. We'll be here all day. Even if you know, maybe you don't finish your project today, come get our contact information. We're happy to work together with you. We're actively building out recipes for different types of use cases for automated prediction markets for uh you know, there's one fun one where it's like a a jukebox where you can pay an agent in crypto to ask it to play a certain song or yeah, if you're working on something fun, come stop by.
I would love to hear what you're thinking about. And yeah, there's a lot of unsolved problems here as well. It's a very still I think like under specified problem space. Agentic space is just beginning and you know, if we believe kind of the trend and the and the momentum that's picking up, maybe by the end of the year, some of the crazy ones are like 90% of crypto transactions are all going to be agent based first. Humans are going to start forming very very very little of the transaction volume.
Um so, yeah. If you're building along these lines, let us know and that's that concludes my spiel for today. Thank you so much.
Woo!
Automatic transcript — names and jargon may be misspelled.