AI agents transacting freely, under control

EthCC[8] · 3 Jul 2025 · 20:18

Henri Binsztok proposes separating AI-agent decisions from transaction construction. The presentation discusses a formally specified execution engine intended to constrain errors when agents manage user wallets.

Speakers

Topics

From EthCC[8], hosted by Ethereum France.

Transcript

Okay. So, hi everyone. Uh, my name is Hri Binto and I'm the co-founder at OK Contract and today we going to talk about transacting agents and this is uh this been a hot topic and it's how we let them transact freely but under control. So, this seems to be a contradiction but we will go into that. uh and this is basically how we automate these crypto transactions at the AI agent level uh but without compromising security. So first uh just a few words about the rise of AI agents and it's already a very let's say a big splash.

It's a big market pumping in. There's a ground view research and other analytics firm who predict 50 billion and they may be even underestimating the total markets five years from now because AI agents can solve a lot of problems. They can replace humans uh doing work. Uh but the problem is that there are AI hallucinations, there are errors, there are attacks and they're not going away this year and they're not going away next year and they're going to stay for uh some time. So especially when we think about AI agents that uh do transactions and for instance financial transactions and if we speak about this financial transaction not necessarily

blockchain in fact it's a very big market already but the the main risk is what do we do with these errors with these hallucinations and and and what uh how can we uh prevent basically uh the loss of funds uh in these transactions and this not something that is uh really easy. So let's talk about this uh hallucinations error. So basically the first thing is uh AI models are probabilistic. So even if you reduce what is called the temperature which is let's say the the the genericity of of of the model uh you still have the probability that the

model goes wrong just because of a single word in the input and you just change a word and it becomes a complete different answer and this is the way these models work. uh maybe this is the way some humans work uh as well but we have some error recovery mechanism which may be lacking right now in these AI models and so applicable to transactions and especially onchain transactions it means that the address of the contract that you're calling can be wrong it means that the parameters can be wrong and this is very dangerous because even if you let's say whitelist the contracts that you want to interact to with your AI agent let's say you do this at the ERC C437 session uh key control you restrict you

say only interact with these contract addresses they are very safe I check them etc etc it's completely insufficient because there's a lot of uh defy contracts for instance where you can uh set a parameter to uh send the LP position to another address and if you do that basically your money is gone and each step basically is a risk of error and uh now we estimate that at each step there's a 20% chance that the model will do something wrong uh not what you expect in terms of security or or or just in in terms of safety. So basically if you do compound that on a five-step uh chat which is nothing you have a 30% success rate only and this is extremely

extremely low. So basically it means that most of these AI agent sessions they will fail and it's just uh just a probability. So uh it's funny that for instance even one agent in the virtuals ecosystem which is one of the most wellknown there it's called Luna. They even had to tweet that they themselves are frustrated basically with the recent transactions that they sent. It was tipping uh the agent and there was a lot of reverts. So basically wasting gas, sending transactions for nothing, etc., etc. It's not even a loss, but it's still a problem. There's worse. A second thing are attacks on AI agents. And this is just only the beginning because right now it's very easy to do prompt

injections or other kind of attacks on these AI agents to basically trick them into something. And this is uh for instance AIXBT uh you heard of this probably two months ago got uh raid of 55 ETH uh basically by calling one tool which was already hardcoded. It was only tipping. So the AI agents was uh able to tip someone but someone managed to inject a prompt and uh and send the whole balance to to to their own address as a tip. So it's uh even if you whitelist everything it's not sufficient uh and this is prompt injection could be social engineering as well it's very

easy or or to to take let's say a developer access to some kind of admin function to that agent. So there will be a lot of sophisticated scams and attacks in the years to come and there's no end to that which leads basically to a user trust gap which we have seen for instance in several studies right now if we talk about financial transactions even beyond blockchain only 20% of the people who in charge believe that they can uh trust AI agent to do financial transactions and if we talk to something uh quite related for instance I was in the UK for loans.

Uh 73% of people want a human to decide and definitely not uh an AI agent. Uh and these features will be on chain. We've seen what Robin Hood announced that they they are moving most of their infrastructure on chain in the coming years. So basically this will be on chain. So we need uh guard rails. Most naive approaches uh fall short. So basically what can we do as a naive approach? So the worst thing you can do obviously is to tell the AI agent uh to write some code uh some Python script or whatever and somehow execute it later.

Even if you try to add some guadrails like generating tests as well even if the test pass there's still a lot of ways that it can go wrong. So it's a very naive approach there will be many ways uh to go beyond it. Another way that many projects are are looking into is building manually a catalog of onchain interactions. And uh for instance, they use JavaScript. And because they use JavaScript, they use most often the SDK of each project. And then this grows as a very big repo with thousands of dependencies because for instance, if you use the A SDK and the Uniswap SDK, they both maybe use the same library but not the same version in

their package. JSON etc etc. So you end up with a mess. If you want to support thousand or 10,000 protocols this will be completely unmentable and it will be impossible to secure this and to audit this and to provide security for this. Let's if we switch to another topic uh which is uh not exactly in the same axis but it's giving what for instance what AIXBT does giving the key uh to do transaction directly to the agent. So they say the agent is running on some server that I control. It's under my control. So basically I just uh give it uh the key it could be compromised. And then many people say oh we can use T's as well but it's still a black box the

T's there have been vulnerabilities on the T's themselves. And also if you try to inject and you manage to inject something at the T input depending on what software runs inside the T then you you you can still attack it. What we propose is a solution where completely separate what we call the brain like the decision which we give to the AI agents themselves and the brown the brown is something which is not probabilistic at all it's purely deterministic and this is the way we execute these transactions in a fully deterministic way and this is what I'm going to describe now and which

is basically a way to formally specify the interactions that you do with the blockchain using a new programming language that is purpose built for that especially for statistical uh analyszis and verification. So how our stack works basically there's three component. The first component is we have this language that enables to specify interactions and verify them and we are building a catalog of everything that is legitimate and you can build uh if you want to custom versions of of this catalog. Then we have a purely deterministic interaction builder which check properties of this interaction and that will build it to build the code data. And then we have for instance if

you want to build AI agent uh which is this uh talk about but it's one example of we can do is uh basically specific uh agentic infrastructures like MCP tools for instance that you can embed to create your own AI agent using this stack. So let's talk about uh the catalog uh a bit more. So this catalog basically is not written in JavaScript. It's written in our own scripting language which we call lambdascript. And lambda script is a purely functional programming language. And we made this decision to for instance not use solidity but use another purpose language. So we can do uh formal verification on it. And for instance we have already uh generated coke proofs

which is a formal uh proof assistant to verify that the specification are correct for some properties. Right now we don't have all of them. We already have some of them. And this eliminate eliminates a lot of errors not only the contract addresses but also checking that all the computation all the parameters for this contract are built properly and for instance that includes uh checking the slip page and there's been as well some AI agents who uh were building transaction natively and uh basically because of that uh the sleep page was uh so uh was even missing so basically they got me for for almost all of it. Let's see uh how uh a specification looks like. So now we are

building a developer portal where you can see the specification. So this is for instance for adding liquidity on unis swap. You see you have just a few descriptions here which are the formulas basically the expression in lambdascript of the basically the the interaction that we want to build. So from this transactions and we uh basically have a secure transaction builders which takes the input as a highle input uh and basically compiles the whole interaction checks all the properties on these parameters until we finally build the transactions and the final uh construction that we

have. we can check that it's correct uh versus the specification of the interaction which leads us to now how we use it as an agentic flow. So basically now we are building an agent. What we do is we somehow collect the intent at the AI agent level of what the users want to do. Then we query basically the okay contract catalog to see what kind of specification do we already have that is consistent with the the type of uh intent that uh the users want to do. And here I can add one thing is that this is somehow an open intent architecture because you you may heard there's uh the

intent architecture of course uh which is solved let's say behind closed doors uh by solvers but you often don't have full visibility of the process of the intent resolution here for instance everything can be built client side uh in the in the user browser or in a node you control and you see exactly what specification you choose and how it is built which is the four step like we build it and when it's built then it's ready it's safe and we can execute it on chain one thing uh which matters for these AI agents as well is there's two things when you build an AI agent there's the list of messages the discussion which is

visible to every step of the model like every time you call the model in an AI agent you send the whole history of messages uh that has been in this discussion. What you don't share though is what you can build inside the agent itself. It is a memory and that memory can contain secrets can contain things that the LLM models will not see and but you have tools and the tools can pick whatever they need in that memory so that they can add it to the discussion so that the model can uh make let's say the the best probabilistic decision of of the outcome and I mentioned that uh because for instance the selection of

the transaction the parameters they are in in in memory and in the memory you can do all the deterministic work as opposed to probabilistic work in the agent model. Let's see a demo on how uh transacting uh looks like. So we're not uh it's not a full uh chat product. It's just a it's just a demo. But uh you see basically you're typing okay I want to mint something on optimism. So here uh it's pretty slow. I have some time to talk and I can tell you why because this demo runs fully inside the browser.

There is uh the agent itself is inside the browser. The LLM the model itself is using is running on web GPU inside the browser. So basically this is a fully fully local uh transacting agent which adds let's say a layer of trust that at least you can trust that uh it may do very bad decisions because of the probabilistic outcome but at least it's under your control. So you see here it says okay this is uh what I found in the catalog. So for instance I can mint uh some uh several things. So basically we say okay let's mint the okay logo uh and then it says okay yeah I clicked on the link to see

we can see when it has chosen it you can see the interaction on the okay contract network so you can see the actual contract the actual parameters etc. So we get back to the chat where basically it says okay we're going to mean this are you okay are you willing to proceed. So this fully depends on the demo where basically you can tell uh how much confirmation you want from your user and then you see in the memory here we have uh selected the contract and we have selected the interaction and now this is deterministic and this is what we are going to build in a deterministic way and you can see for instance here the memory. So now it says okay we're going to to call that chain it will cost that

much gas which is now zero rounded because it's even there's right now an optimism there's five zeros in the gas cost he says okay do you really want to do this we say yes note that there are no wallet interactions whatsoever because it's just doing this on the AI agent session key and then it's telling oh but uh and you can see now the transaction is is uh is minted. Uh but you you can think uh but I told you before that uh we shouldn't let the agent have the session key. Okay. So one more thing and I'll end up here. I'm on time. Uh we are doing something else.

We are securing the execution uh of the the interaction in the smart accounts. What do we do is there is one user master key which is kept offchain could be a ledger could be anything. Uh you have an agent session key but we also are building a network which would be a decentralized network that verifies the transactions and we have two fully implementation of this. The okay contract SDK which you find on npm is written in typescript and is evaluating the lambda script etc. building the call data in typescript. We have done a completely independent implementation of

this. It's not even a chpd translate this typescript to go not at all. It's manually re-implemented uh with the best practices in each language and uh for the go node and the okay contract network is completely verifying that the transaction comes from the specification in a fully independent way on completely another codebase. So this is how basically we can build trust on AI agents doing transaction and even beyond that doing any transaction using open standards.

there's no T. There's nothing to hide inside a T. Uh we have uh a path to decentralize everything. And this is why for instance uh probably Vitalik mentioned us as you may know in his talk yesterday. We were in the slide he said basically use IPFS and OK contract. Uh and uh the third thing is uh goes in in the along the same way of decentralization. uh we will make sure that everything we do uh could be censorship resistance and it goes of course with full decentralization and this is our road map. Uh we we're not fully live yet. We're in pre- beta but uh it's coming along the way and we uh hopefully have thought about how we can

secure really how we verify and execute this transaction. So thanks a lot. I think we have maybe two minutes for questions and uh but please follow the links and and follow us uh on Twitter. You know it it matters for for marketing. [Applause] Do we have any questions? You seem very negative on TE's which is an opinion I haven't heard much before.

Is there particular reasons why or any particular exploits? So there were exploits previously with for instance Intel TE's uh and uh there may be others. Uh the other thing is with TE's is uh it's often a black box. You you as a user you don't know what's running inside the T. Most often you you you can't even be sure that it's a T when we tell you oh send your data to this T and never worry about it. Uh and there's a third thing is even if it's a T if there is any vulnerability with the software that runs inside it and if you manage or or you manage to hack and push some uh

let's say uh untested inputs to it maybe you'll have uh one outcome that you basically wasn't planned. Okay. Do you have any other question? Last one. All right, we're out of time. You can talk to me afterwards. Thanks a lot to all of you. Thank you.