DAPPCON 2025: Know What You Sign- Robust Tooling for Security and Verifying Signatures

Transcript

Hello everyone. Can you hear me? Well, okay. I'm going to be moderating here. My name is Valerie. I am the CTO of 1KX, which is a cryptonative VC fund. We are both investors of SAFE and we are using it intensely. And the problem of how we verify what we're doing and how we make sure what we sign it comes up almost every day. And we have a lot of discussions about how to do it better and like there's so many open questions and I'm excited that we have this panel of we are lucky to have this panel of experts here and let me just have them introduce themselves before we go into

the details. Hi everyone, I'm Tomaso from blockade. I'm a security researcher. So I handle the security uh as perspective of the company and today I will be talking about the cosigner. So yeah it reflects on what the panel is about which is security and signing transactions and understanding transactions called data. Okay. Andre hi all nice to be here. Um my name is Andre and I'm heading product at hypern.

Hypernative is a web3 security company and we secure the entire life cycle from prior to the transaction during the transaction and of course onchain monitoring in real time. So this is a very exciting panel to join on how to secure transactions in all this life cycle. Hi everyone, my name is Charles G. I'm CTO at Ledger. uh my background is uh cryptography and and security and I joined the company in uh 2017. I guess like everywhere everywhere everyone is aware of what is ledger. Do you raise your hand if you own a ledger device?

So yes, this is this company we are we are doing this ledger devices. Uh we also have Ledger live which is the companion app and we also have an offering for uh B2B for uh enterprise in order to manage their funds uh securely uh and also apply governance on top of it. This is this is me in a nutshell. Uh hi my name is Alex. I'm co-founder of Nosis Guild. Um we're developing Zodiac OS which is a institutional-grade platform for managing digital assets on chain. Um and Enclave which is a protocol for confidential computation.

Uh yeah happy to be here. Awesome. So the first topic that I want to talk about is obviously the topic that was the most salient this year and this is the various hacks that we've seen and last year Radiant Capital and of course this year the Bybit hack. Uh I'm curious about the perspective of all our panelists on this issue and what we learned from it and how do we prevent similar hacks in the future. Those hacks were lethal and very sophisticated also to experienced users because uh the threats were hidden in the data and being able to read cold data is not

something you can do uh in a couple minutes or something you can do without specific tools. So here comes the first problem and even if you are a security expert like I cannot read cold data with ju just just by reading it. I need tools. I need to be prepared. So that's a great challenge of the ecosystem right now, which is signing things you do not understand. And that not just applies to malicious transaction or hacks like the bybit or the radiant, but uh transactions you sign every day. So uh it's very important to develop new tools and distribute them uh like the cosigner that we are building uh to enable

uh like verification in that transaction called data uh enable end users who are not that much technical to be able to verify uh the sanity of a transaction and be protected against sophisticated attacks that they cannot see. So I believe that being protected against those uh even attacks that you cannot uh prevent because of course you cannot prevent all type of attacks but being proactive and having modules like the cosigner can definitely make a big change in the ecosystem right now. So to recap, you're saying that the cosigner module basically makes the whole

verification easier and by that everything is kind of more secure. That's it. The cosigner basically acts uh for the end user. So it eases a lot of pain from the end user uh not only big organizations like you know buy bit or radiant but also smaller organizations that do a lot of transactions every day on chain. Let's say you have to manage a lot of positions on chain. Of course, uh you will be doing many transactions and you cannot validate manually all those transactions. So we can do that for you and we can ease that pain of you by validating not only complex parameters inside the transactions but all the

actors and also we can enforce policy organizations uh for tailor made. Yeah, thank you Tomaso. I believe the hyper native will also handle this but maybe a little bit different angle. Yeah, that's an interesting. I think that um of course we all became aware or more aware after those hacks. Um I think that besides the hacks themselves, it is important to understand the risks that the various types of customers face in interacting with their um wallets whether they're by the way safe or other wallets and those needs differ significantly. We have hundreds of customers from asset managers like uh Karpatki or Galaxy or others who will have specific set of

needs in their capacity as asset managers. While protocols in the game we work with Morpho, balancer, chain link and others have significantly different needs. They not only manage their treasuries but they actually have wallets that perform operational operations on their contracts, right? And the concerns are different. So it's very important to have granular policies that provide both visibility into what is the action that is going to be executed as well as control to prevent unwanted actions. So uh Tomas mentioned here being able to understand to have visibility into the transaction right and to understand even for non-technical people what it is that you are going to execute and get a recommendation that

will not only say there is risk or there is no risk but also what is the impact right I'm going to execute this function there's going to be this change in balances and so on and the next step besides interpretation is the fact that you need to enforce the solution so there are multiple approaches here we um our guardian uh product employs the a safeguard module and the way that we do that is that we actually analyze the transaction in real time as it is initiated and if it passes all the checks it will be allowed to proceed and if not it will be reverted right so we protect the user from mistakes that uh they may have done or risks that they may not even be aware of by technical

controls that is enforced on the wallet itself Um so this is the way we approach it but there are other solutions as well. Great. So basically you have diversified in my like how I understand this uh the various types of clients have uh different methods uh depending on their profile and the policy allows you to flexibly configure that. Yes, I would say that they have some of some of those needs are prevalent through all customer types, right? So everyone wants to avoid fraud and fishing and hacks and exploits and um transferring excessive funds right your entire treasury to or bridge risks for example right um if you

interact with a bridge and you send it to some other u other address on the other chains and it's something that you would like to avoid but there are a lot of specific invarants specific concerns per customer type per the sort of activity and the use cases they engage with that they need the capability to tailor the policy to their specific needs perhaps different teams within the same customer and this is how we approach the solution by enabling our customers this granular policy configuration. Great. So what does ledger what what has ledger learned from the hacks? Um so for for me I have like two main uh takeaways for for this specific stories radiant by bit but

there were there were other story um last year and and the two two takeaways are are the following. So first of all if you are like a financial institution like a big organization with a lot of funds uh there exist today like financial financial grade type of security solution. At Ledger, we have one of them which is called the the Ledger vault. And this solution is leveraging like hardware technology and this is the the type of solution that you can find in banks. We are using HSM on one side and personal security device on the other side. uh the secret are completely um like offline inside the enclave in the HSM and the organization is able to define who has access to uh

to which account what are the policy also it's possible to revoke um a signer like anything is possible when it comes to defining the defining the the framework so the organization will define that for this specific account this list of people can access to it they can send transaction to only this specific address. This is the white list. Uh if they want to to spend like above a certain threshold, then they will have to gather three approvals out of five. And if it's above like 100 bitcoin a day, then they will need to gather like the approval of the CFO.

Like these kind of rules can be implemented within our solution. We are leveraging HSM. That means that the HSM itself is in charge of verifying the policies and if they are not met like the secret cannot be touched. This is how it works. On the user side, they are given like a personal security device. uh we are giving them like a specific version of the ledger stacks and on this device they will be able to change the policy to review uh the transaction they need to approve and we are using like a secure channel to authenticate the users uh with uh the platform. So this is really um what it is about for enterprise. uh there is also like associated SLA there are also like

compliance there is also insurance and this is the type of solution that is required by like big financial institution and and I think I think this is a this is very different from what safe is offering safe is a great product but I I don't feel it's um this is the this is what financial institution needs because they will need like insurance they will need compliance they will need they will need to uh to make a deal with a at the end and um and and I I feel this is a this is my first takeaway. So ledger vault is is one of them there but there are also like other type of solution uh for B2B encourage is one of them copper is one of them firelocks there there are a few of them back in

the days there were there was no solution but now there is such offering and and you can't you can't manage 1.4 four billions on like on on um retail type type of devices with free software that that you find on on the internet. I I don't think this is a reasonable uh statement to to do so. So that will be my first takeaway. Financial institution must use enterprisegrade security product and the second uh takeaway is uh is is about clear signing. Um when when you are using a ledger device uh or a hardware wallet in general uh what you want to fulfill is like three different

properties. The first one is to generate your secret uh inside an enclave. An enclave is something that is completely offline and uh and where you have like strong security properties even against an attacker with physical access. So secret must be generated inside the enclave. The cryptography must be implemented inside the enclave so that the secret don't have to leave uh this enclave. And finally, you need to have a trusted display. You need to have a way to understand what kind of transaction you are signing. Um when we started Ledger, the the first device was the NOS and already you had a screen and uh we we are supporting bitcoin transaction and clear signing on bitcoin is pretty

simple. you just send and receive and it's about like verifying that you are sending 0.1 bitcoin to this specific address and all of this is very well supported. However, when it comes to uh like new blockchain where you are interacting with smart contract, smart contract can be like arbitrarily complex and for device that is completely disconnected from the internet. It's pretty complex. It's impossible to uh understand what what is behind this called data. So in order to solve this problem uh what we did is creating an ERC the ERC 7730 uh where we essentially ask all the DAP in the ecosystem to uh explain us how their smart contract is working. Um in more technical details we

are we are asking them to create a JSON file that describe uh what are the name of the method what are the relevant parameter what are the type of this parameters and we are giving this JSON file to the device along with the row transaction to be signed so that the device is able to properly parse this transaction and if you have like all of this on the device the device is able to parse the transaction and to show to the user what kind of transaction is signing. So you are interacting with uni swap and you are about to swap this amount of it against this amount of USDT. The fees is this. Do you okay to sign this transaction or not? And then uh you can consent. And here you have

like end to end security uh when it comes to uh signing um unis swap transaction. The the other um um the other feature that we recently uh implement is uh transaction check on device. So you probably know like a blockhead offering or cyers offering what they what they are doing is basically uh in particular we are doing plenty of other things but what they are doing is assessing the risk for a specific transaction. Uh but one of the problem is like what happens if the transaction you are simulating the transaction you are assessing is different from the one that you are signing and this is what happened in by bit hack and ladant hack by the way they they simply swap the transaction at the

very last time so that the the hardware wallet is signing something different. So in order to solve this specific problem what we are doing is pretty simple right before when the transaction is crafted this transaction is sent to blockhead cyers and others uh so that they uh run their check they do like risk assessment for this specific transaction and then the device is receiving the row transaction to be signed along with the risk assessment and on device uh it's displayed the risk associated to this specific uh transaction. So it can be a critical threat could be like a risk detect detected or no risk detected and then as a user you decide if you want to sign

this specific transaction or not. Even if there is a critical threat you can sign this specific transaction so that it completely mitigates uh the risk where you have a malware on your computer that makes you think that you are signing this transaction while you are signing another transaction. So this is this is the way we are uh solving this uh problem. Just to finish with clear signing uh so as I mentioned we have this uh ERC 7730 um that is standard that anyone can use. Um however when it comes to uh signing more complex transaction especially save transaction where you have like proxies and nested transaction inside the gold data it's a little bit more complex to

do it. And um and if you want a quick announcement, we are working on um uh supporting properly like safe transaction so that on device uh you will be able to completely understand what's inside the transaction and that you are interacting with unis swap inside your safe wallet. It will it will be uh properly displayed uh on the on the hardware wallet itself. Nice. Thank you, Charles. Um yeah, I mean to recap, Charles just answered multiple topics in this panel and I'm grateful for this is like a very coherent story. I want to give floor to Alex to kind of also share what they learned from this and then we'll return to these topics with other participants because these are super important. This is like what's coming

next. Sure. Yeah. Um yeah, I think we we learned a lot from those hacks. Um I think an interesting thing about them was they were both uh routine transactions that the teams were making. So they were pretty much everyday operations that were common. Um for by bit it was transferring between a hot wallet and a cold wallet. Um pretty routine stuff. And with that it's pretty easy to to scope out and create permissions for those specific transactions. Um so we've developed the Zodiac rules module which extends safe to create very specific per uh permissions and granular scoping that

you can set. Um and with that they could have just yeah created a permission that would allow them to transfer between these two wallets um with just one signer even or an intern could have done that. would have been very um yeah, low risk because the worst that can happen is you just have your assets in another account and can transfer it back. Um so yeah, we're leaning into permissions and scoping. Um I think that signing should really only be used for in very rare cases. Um for the most majority of things that people are doing on chain,

they're repetitive transactions. They're operations that um people yeah repeat in their workflows. And signing is kind of a major open-ended transaction that should only be reserved for uh upgrading your account or like very significant changes with high auditing, high security. Yeah. Thanks. That's a very important insight here because of like this repetitiveness of transactions and uh operations and like we at 1KX definitely feel this that we need to streamline the operations on the one hand and not drop security a single bit on the other hand.

So that's that's awesome. Thank you. We can go to the next topic and that's actually the topic of like how like specifically verification of what transactions mean and then the transactions hashes. We definitely know how to do this with Ledger now because it's like there's so many details about that. Uh and like for me for example I was uh I'm I'm deep in VM internals since a long time. So for me looking at the tenderly trace is fine. It's natural. It's okay. But I'm honestly terrified when I think that users need to do this. And definitely like Tamasa can tell more about this. That's a big

problem. And if you are looking at very complex transactions, it can get very hard to look at traces in tenderly. And that's uh how we solve that problem is with the cosigner. So cosigner is an additional signer that you can um integrate in any MPC like safe or firebox and it solves two problems. Uh one is the bybit style hack where the transaction that you're seeing on the safe UI is not the one that you're signing. Uh it teases this problem because uh the cosigner acts at as either a required or an additional signer and it receives the actual

transaction. So it would have prevented the by bit hack because our system would have validated that transaction and detected it would have been malicious and blocked it and more specifically like uh we offer two different products for uh decoding cold data. We offer our APIs which enable simulation and validation to offer the end user uh a clear vision on what's happening in the transaction. uh not only what's happening, what are the outcomes and a verdict on the addresses involved in the transactions and we do that with a very low rate of false negatives uh thanks to

our very wide uh data source uh from the ecosystem and a team that gathers informations on a daily basis. So we are updated every hour on new threats and malicious addresses that are coming into the chain and uh we also as I said offer the the co-signer which is uh a managed by us signer and it teases a lot of problems and a lot of pain points from the customers who uh don't want to bother too much uh decoding themselves the transactions. What's the false negatives and false positives?

What are the numbers? Oh, like below 1% for false negatives and false positives usually gets resolved in a very short amount of time because we only have false positives for fresh new organizations. So, uh unregistered organizations or um anonymous EOAS and usually uh the procedure is that the organization contacts us because we show uh usually a button or a form to contact us and we resolve the matter in a matter of like minutes if not hour. So that's our power. And in terms of false negatives, we can keep the false negatives numbers so low because uh the

amount of data we gather from the network and from uh private networks is very wide. So that's our strength. Okay, I get that. Thank you. And moving on, so verification of what transactions mean in hyper native. Yeah, so and hashes and everything validity, right? I think that the interpretation is really an important aspect here and um understanding in layman terms right or I wouldn't say layman right they are professionals in their own field but traders and analysts who are not technical and uh can't treat perhaps tenderly but they really understand what it is that they're about to do and there is a concern here not just about um even for the technical people who are able to

uh review traces and so on we are all people right so um We want something that is much more reliable and not on whether we had our coffee in the morning and uh um are looking well at the traces. So I think that it is important to employ um solutions that have proven themselves in the past. Right? So we employ machine learning and behavioral analytics and uh multiple uh um multiple techniques that have successfully found detected fraud and fishing. We have unique models for that hacks and exploits and so on. So that you want to introduce that even for a technical persons but definitely for the non-technical person to tell them even if it appears fine to you we think that

there is risk inherent in this and the other component here is I think that customers at least the customers that we talk to are looking for a comprehensive solution. So it's not just at the point when I initiate a transaction let me know whether there is any risk associated with it. We approach our engagements with our customers throughout the entire life cycle. Right? So prior to the transactions, how do I investigate and research the contracts and the counterparties that I'm going to interact with? How do I when I initiate a transaction, how do I assess it, get a recommendation, enforce an automated recommendation? And of course, a very important aspect is continuous onchain monitoring in real time. I established a position on moro. I established a

position on NA. I transferred funds and so on. I have assets on chain. I have a multisig. Is something happening to them? Are they being subjected to attack now? And whether there's automated response configured, right? Which many of our customers employ automated responses to pause protocols to move funds unwind positions and so on. So it's not just at the point where I initiate a transaction, how do I uh avoid risks? It's seeing my entire web three um activities right in one comprehensive suite and understanding okay I'm covering all my bases here in platforms that can interact throughout the uh different steps. So that sounds

like there's a lot of uh ML inputs and analytics that allow us to kind of predict what's going to happen and in combination with rules uh that allow you to basically have this full coverage. Yeah. So I think the way I like to present it is that we are looking at prior to transaction, during a transaction initiation and after transaction when I have assets on chain and we have multiple engines. So we have fraud and fishing and hacks and exploits and the behavioral analytics and so on. And now you apply those detections right and this insight um from the multiple engines to the various steps in your life cycle to ensure that you are protected throughout your activities.

Thank you. Okay. Um yeah Charles uh I was assuming you told the story but yeah please add whatever. No no definitely. Um so to your point we we can't expect that users uh will understand hashes like no one understand hashes and it's a very big problem that we us as an industry accepted that it's okay to sign blind signing uh hashes it's it's a big problem and this is how by bit and and plenty of users are losing money every day. Uh so you you were mentioning like technical people but even so most of users won't ever be able to like recreate the row transaction put it on tenderly understand the trace

compare the hash the hashes most people can't do that and we can't expect them to teach them this kind of thing this not this won't going to happen this is the first thing the second thing is even for technical people you are doing this like once twice uh several times and at some at some point you you are getting bored and you are doing this very quickly and then you will sign a malicious transaction at some point. So there's are not solution and we we must all agree on this and the the way we are solving this is really uh by two different ways. The the first way is clear signing uh providing the users with uh the understanding of what is about to sign and the second one is transaction check on device. Um just to

give a very high level uh view of um the success for this this feature we launched it I think on on March it's only available on flex and stack so our newer devices and only in one month we simply saved 18 millions so this is what we are talking about and uh this this uh number will compound over time uh and this is millions that are saved for the whole ecosystem and when we are saving saving millions this is for everyone because um if uh our ecosystem is uh is only about hacks and everything we we won't create trust. So we need to work collectively uh in in creating trust in the ecosystem. So in the interest of

time we need to um move on. Uh but who in the audience thinks that blind signing needs to die? Okay, let's kill it. Let's let's just get rid of blind signing. Let's kill it definitely. Um, and yeah, Zodiac, does Zodiac help ensure that you know what's actually in the transaction and the integrity of them? Somewhat. I think um, yeah, we take a little bit of a different approach. I think we I agree with Charles. We should not expect the end user to be decoding call data and uh, transaction simulations and a wall of bite code and everything. Um, so we take

a more preventative approach where we have people set up the proper account structure and roles on those accounts. Um, so that you don't need to know as much what you're signing. Um, the permissions are set up for you ahead of time so that you can only sign things that you want to sign. Um, so it's a little bit of the coming at it from the other angle. Yeah. Okay. So to recap this whole verification topic, we have like every participant on the panel having their own products and their own ways of actually solving the same problem. So you know uh it's not like we don't have options. We have many options right now.

And then I would like to bring up another topic like when I do my personal transactions I quite often originate them like I use hardware wallets but I originate them from the laptop which which I use for other things uh for work. I find sometimes that okay, you know, I actually ran npm something on it and now I'm about to initiate transaction this laptop. I'm like I'm a little bit okay if it's low value then I'm okay but I'm always concerned that I probably shouldn't be using this laptop at all and uh what are the opinions here? Maybe we'll start from that side from Sure. Um yeah, I think probably the

best case is not to use the same devices and um but I think for most people they end up using the same devices. I do for use my work laptop for signing transactions that are fairly high value. Um and yeah, I think ideally scoping the permissions is the way to go with um so that there's not as high of a risk with the signing process itself. So you're saying we're basically accepting this risk. I I do that for my personal especially lower value transactions. I'm accepting this. Is there any other way

Charles? Um, don't feel bad about that because your your security setup should never rely on the security of your laptop or your mobile. If if it's the case, you have a security problem. And as long as long as so if you are using like a hardware wallet, a ledger device and you have you are verifying on screen what you are signing, you can trust this. You you can have like multiple malware on your computer, on your mobile phone and and everything. If you are able to verify on device the transaction you are signing, you are safe. If you don't share your 24words with anyone, if you don't put your 24word on your computer, you are safe. So at the end, I I'm not saying

that your uh your computer should be plenty of malware. Uh it's always good to have a good opac but your crypto the security setup for your crypto should not rely in any way on the security of your laptop and or andor the security of your mobile phone because this device are simply not secure any other opinion here yeah I think that it's important so I've been dealing with cyber security for over 20 years now in various capacities in the web three for the last seven of them and I think that the sort of u actors that we are concerned about here um they are very advanced and sophisticated right so we see them let's take DPRK right everybody

is talking about them but I'll just um say that the techniques that they employ are often then copied um to other but they will employ u malicious PDFs right to compromise machines and they will uh invest into compromise entire infrastructures like with Ronin or with the by bit hack right or they will sometimes it's in in infiltrate with their own uh IT workers right we handle several such cases where the entire IT team of the like all the devs of the protocol were actually uh North Koreans um but we have other concerns as well like proper fraud and fishing right uh um inducing customers to transfer funds

uh to them thinking that they are actually interacting with the different dabs, scams, drainers, uh pig butchering schemes, right? Where you get some investment back. Um there is the technology is there, right? But you need tools that will tell you more than just what it is that you are signing. You need tools that are operating out there in the world, aware of the risks, understand what is happening, right? and can bring all these insights to you because you cannot be inspected expected on a single person level who is signing or a team who is signing to understand all the risks that are happening out there and that's why um companies like hypernative right are providing this

detections and this risks to you at the point of signing saying you even if you think this is a legitimate transaction don't proceed with it or at least pay attention to these aspects of it and decide whether to proceed And I think that we all need someone like a trustworthy, right? Someone you can rely on to hold your hand and help you ensure as our customers say we sleep better, right? Right. When you have such a definitely definitely sleep, we need to work on sleep and that's that's helping and maybe blockade is also helping us sleep better. Yeah, I agree 100% with what the guys have said like no one should have an additional computer just for sending transaction.

That's not how we are going to on board the next billion people. It it's not acceptable and we need to sleep better sleeps and we need to stay safe when signing transactions even if we aren't able to understand those transactions. Um and that not just comes to a point where you are reading what's happening on the transaction because let's pick our advanced transactions like a permit. uh we are not expecting all users to understand what a permit is. So we are showing hey this is a permit. Do you want to sign this? Maybe a user doesn't know what that is and that's a a transaction used by fishing scammers to

trick users into losing funds. So not just displaying to the user what they're signing is enough to save them from the scams. You need someone also who validates those. you need someone who preemptively uh blocks you from signing those and that's our main concern right now and that's why we built the cosigner which prevents you from signing anything that is malicious not only warns you it prevents you and this can be of course tailor made to any kind of organization uh with specific rules but we want to make sure that there is no room for error because if you leave room for error the end user is going to make a

mistake anyways. They're going to sign a malicious transaction anyways. It's it is going to happen. We don't want that to happen. We don't want that to happen to big organization but also to daily businesses who do transactions on chain every day. We don't want errors uh in the way. That's why we handle the validation and we can enforce the blocking a transaction for a user with reasons. So the user will get to see why the transaction is blocked and they can enforce policies around that. So they can uh either set it up in a way that they can bypass it. So we're not letting false positives block you from signing your transactions if you really want to

sign that transaction anyways. So there is always ways to bypass it. But to wrap it up. So basically we are all agreeing that we are kind of mostly accepting this risk of the signing environments maybe except for some outrageous cases. I mean recently 1KX we published uh this document multisig opsec uh if you just Google multisigsec you'll find it definitely Mike our devops published it and that was one of the points and another point in that document was uh diversity of signing devices like if ledger gets hacked uh through whatever vector like maybe some of the signers on

the safe should be using different uh devices And maybe Charles you can start commenting on that. Uh on on this I I understand the the rational for saying like diversity could mitigate like more more risk. Um one of the problem is that that there is no not so many devices on the field where you have like high level of security where you have like the support of safe where you where you can do like clear signing this kind of thing. So it really depends on your setup. It really depends on your uh security constraint on your threat model. Uh personally I only use ledger devices even in a multisc setup because I I feel this is the this is the bestin-class uh security that you can

have and and the risk that you would mitigate uh by using another type of uh device are not worth uh what you lose uh in terms of security with using these devices. Thank you. Um we have 3 minutes left. Uh should does the audience have questions? Yes, please. I have a question for Okay. I have a question mainly for Ledger, but maybe other people can chip in. Um so 7730 H has this requirement that basically all of the D developers in the world open a PR against the Ledger repo and then that you then curate that um to get metadata about the contracts. Um, is

there a reason why ledger in the case I know why you want that but in the case that you can't get all that information is there a reason not to use the AI that would already give like at least the function name and the the parameters. Very good question. Uh the problem with AI is that they they are very high level and sometimes the methods are not the name of the method is not clear also you don't have types. Uh so ABI is more than nothing is better than nothing but 7730 is far better than only uh ABI. Uh when it comes to the registry itself so we created the standard and we would like to decentralize decentralize the the registry. We ask to the Ethereum Foundation to do it by the way for now

they didn't accept as you know but we we are very happy to decentralizing the the registry. What will be centralized on the ledger side is the curation of the registry. We we we will only sign the metadata file that we trust that we verified but the registry itself and the ESG7730 are like completely open source and they are public goods. Thank you. Yeah. Hi. Um I'm super super impressed with the with the developments that have been going on and how handling the topic of of blind signing. I have a philosophical question though which is regarding the level of

abstraction that with which we represent a wallet. Right? So we give the DAP the the task of creating the transaction and then we have a very low level interface at the standardized level to which the wallet uh you know on the way that we interact with the wallet. How far can we go with this and when do we start from your perspective thinking about intents of the end user and start giving the task to the wallet to actually creating the transaction from the intent that it has received from the uh it's a it's a very good question like on the completely um general standpoint it's impossible to do everything on on the device that is completely disconnected with only uh like a description language

model. This is not possible. uh however we we can go very far already and this is also why we think it's complimentary with this transaction check uh type of solution with blockhead or cyver or tenderly on device so I think we all this is complimentary uh however I don't think we should rely on the on the on the user itself to verify transaction this this won't happen and and we this is the job of wallets but also dabs maybe also blockchain to make sure that we are able to make the abstraction and the user experience as simple as possible so that the user uh is able to uh to to understand what signs to your

point to your point about intent. Uh we have like talked a lot in the ecosystem about like creating like intent intent based type of transaction. Um the problem is like how we do do that like properly because you would like to have like something very high level so that the the user like completely understand his intent. However, behind the hood uh what's what is actually running on chain uh is not that simple and it's difficult to have like a a one one matching between the high level intent language that that we that we would create with what is actually happening on chain. So this is one of the challenge that we that we have collectively in the future and sometimes I'm I I discussed with different people who

thinks that AI could solve uh this problem but the problem is like the language is ambiguous. Uh so this is not this not a simple problem but this is a problem that needs to be tackled if we want to do like very very complex uh interaction directly on chain. Yes. Thank you very much. I think um there's more questions is I want to give floor to some of the participants to for closing comments and then maybe if there's another question um Andre sure so first of all it was a very interesting panel so I wanted to thank all of you and I think that uh it is important to understand we discussed a lot about risks right this is the focus of this panel and so on but I want us to

remember that in the end the customer the users are trying to do things right and one of the things that we heard heard repeatedly throughout the the last uh um the the years of our engagement and specifically the last few months is that they are hesitant about doing things uh in web 3 because they're concerned about risk. Right? So there's this very nice metaphor that I heard a long time ago about cyber security is that why do race cars have such good brakes? Okay. To go faster. To go faster. Exactly. Right. So this is the same concerns that we repeatedly hear from uh users that they want to do more in web 3 and they are constantly concerned about uh um risks and the way that the more we can abstract the risks

away and provide them with the trust that what they are doing will be risk-free or they will only need to apply some level of intelligence and decision- making to their transactions but the ma the major part will be abstracted away from them. The more users will be um using web 3 and the more the entire ecosystem will grow which we all hope for. Thank you and that concludes the panel. We could talk about another hour, I feel.