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

Hello, everyone. Can you hear me well? Okay. I'm going to be moderating here. My name is Valery.

I am the CTO of 1KX, which is a crypto-native 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 lots of discussions about how to do it better. And 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 perspective of the company.

And today, I will be talking about the co-signer. So, yeah, it reflects on what the panel is about, which is security and signing transactions and understanding transactions called data. Andrei? Hi, all. Nice to be here.

My name is Andrei, and I'm heading product at HyperNative. HyperNative is a web-free security company, and we secure the entire lifecycle from prior to the transaction, during the transaction, and, of course, on-chain monitoring in real-time. So, this is a very exciting panel to join on how to secure transactions in all this lifecycle. Hi, everyone. My name is Charles Guillemet.

I'm CEO at Ledger. My background is cryptography and security, and I joined the company in 2017. I guess, like, everyone is aware of what is Ledger. Do you raise your hand if you own a Ledger device? So, yes, this company, we are doing these Ledger devices.

We also have Ledger Live, which is the company app, and we also have an offering for B2B, for enterprise, in order to manage their funds securely and also apply governance on top of it. This is me in a nutshell. Hi, my name is Alex. I'm co-founder of Gnosis Guild. We're developing Zodiac OS, which is an institutional-grade platform for managing digital assets on-chain, and Enclave, which is a protocol for confidential computation.

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. Last year, Radian Capital, and of course, this year, the Bybit hack. 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 the threats were hidden in the data, and being able to read cold data is not something you can do 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 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 transactions or hacks like the Bybit or the Radian, but transactions you sign every day.

So, it's very important to develop new tools and distribute them, like the co-signer that we are building, to enable verification in that transaction cold data. Enable end users who are not that much technical to be able to verify the sanity of a transaction and be protected against sophisticated attacks that they cannot see. So, I believe that being protected against those, even attacks that you cannot prevent because, of course, you cannot prevent all type of attacks, but being proactive and having modules like the co-signer can definitely make a big change in the ecosystem right now. So, to recap, you're saying that the co-signer module basically makes the whole verification easier, and by that, everything is kind of more secure. That's it.

The co-signer basically acts for the end user, so it eases a lot of pain from the end user, not only big organizations like Bybit or Radian, 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, 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 off you by validating not only complex parameters inside the transactions, but all the actors, and also we can enforce policy organizations for tailor-made. Thank you, Mazo. I believe that HyperNative will also handle this, but maybe a little bit different angle.

Yes, that's interesting. I think that, of course, we all became aware or more aware after those hacks, and I think that besides the hacks themselves, it is important to understand the risks that the various types of customers face when interacting with their 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 Karpatsky or Galaxy or others who will have a specific set of needs in their capacity as asset managers, while protocols, and again, we work with Morpho, Balancer, Chainlink, and others, have significantly different needs. They not only manage their treasures, but they actually have wallets that perform 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, 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 is 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. Our Guardian product employs the 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 they may have done or risks that they may not even be aware of by technical controls that is enforced on the wallet itself. So, this is the way we approach it, but there are other solutions as well. Great.

So, basically, you have diversified, like how I understand this, the various types of clients have different methods, depending on their profile, and the policy allows you to flexibly configure that? Yes, I would say that some of those needs are prevalent to all customer types, right? So, everyone wants to avoid fraud and phishing and hacking exploits and transferring excessive funds, your entire treasury to, or bridge risk, for example, right? If you interact with a bridge and you send it to some other address on the other chain, then it's something that you would like to avoid, but there are a lot of specific invariants, 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 has Ledger learned from the hacks? So, for me, I have like two main takeaways for this specific story, Radiant, Bybit, but there were other stories last year. And the two takeaways are the following. So, first of all, if you are like a financial institution, like a big organization with a lot of funds, there exists today like a financial grade type of security solution.

At Ledger, we have one of them, which is called the Ledger Vault, and this solution is leveraging like hardware technology. And this is 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. The secrets are completely like offline inside the enclave in the HSM. And the organization is able to define who has access to which account, what are the policies.

Also, it's possible to revoke a signer. Like anything is possible when it comes to defining the framework. So, the organization will define that for this specific account, this list of people can access to it. They can send transactions to only this specific address. This is the whitelist.

If they want to spend above a certain threshold, then they will have to gather three approvals out of five. And if it's about like 100 Bitcoin a day, then they will need to gather the approval of the CFO. This kind of rules can be implemented within our solution. We are leveraging HSM. That is in charge of verifying those policies.

And if they are not met, like the secrets cannot be touched. This is how it works. On the user side, they are given like a personal security device. We are giving them like a specific version of the ledger specs. And on this device, they will be able to change the policy to review the transaction they need to approve.

And we are using like a secure channel to authenticate the users with the platform. So, this is really what it is about for enterprise. 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 institutions. And I think this is very different from what Safe is offering. Safe is a great product, but I don't feel this is what financial institutions need because they will need like insurance. They will need compliance. They will need to make a deal with a company at the end.

And I feel this is my first takeaway. So, ledger vault is one of them. But there are also like other type of solution for B2B. Anchorage is one of them. Copper is one of them.

Fireblocks. There are a few of them. Back in the day, there was no solution. But now, there is such offering. And you can't manage 1.

4 billion on retail type of devices with free software that you find on the internet. I don't think this is a reasonable statement to do so. So, that will be my first takeaway. Financial institutions must use enterprise-grade security product. And the second takeaway is about clear signing.

When you are using a ledger device or a hardware wallet in general, what you want to fulfill is like three different properties. The first one is to generate your secret inside an enclave. An enclave is something completely offline 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 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. When we started ledger, the first device was the NanoS. And already you had a screen. And we were supporting Bitcoin transaction.

And clear signing on Bitcoin is pretty simple. You just send and receive. And it's about 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 new blockchain where you are interacting with smart contract, smart contract can be arbitrarily complex. And for a device that is completely disconnected from the internet, it's pretty complex. It's impossible to understand what is behind this cold data. So, in order to solve this problem, what we did is creating an ERC, the ERC 7730, where we essentially ask all the DAPs in the ecosystem to explain us how their smart contract is working. In more technical details, we are asking them to create a JSON file that describes what are the name of the method, what are the relevant parameter, what are the type of these parameters.

And we are giving this JSON file to the device along with the whole transaction to be signed so that the device is able to properly pass this transaction. And if you have like all of this on the device, the device is able to pass the transaction and to show to the user what kind of transaction it is signing. So, you are interacting with any swap and you are about to swap this amount of ETH against this amount of USDT. The field is this. Are you okay to sign this transaction or not?

And then you can consent. And here you have like end-to-end security when it comes to signing initial transaction. The other feature that we recently implement is a transaction check on device. So, you probably know like a blockade offering or cyber offering. What they are doing is basically, in particular, we are doing plenty of other things, but what they are doing is assessing the risk for a specific transaction.

But one of the problem is that 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 BybitHack and RadiantHack, by the way. They simply swapped the transaction at the very last time so that the 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 a blockade, fibers, and others so that they run their check.

They do like a risk assessment for this specific transaction and then the device is receiving the whole transaction to be signed along with the risk assessment. And on device, it's displayed the risk associated to this specific transaction. So, it can be a critical threat, it can be like a risk 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 was a critical threat, you can sign this specific transaction.

So, that it completely mitigates 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 the way we are solving this problem. Just to finish with clear signing, so I mentioned we have this ERC-7730 that is a standard that anyone can use. However, when it comes to signing more complex transactions, especially safe where you have proxies and nested transactions inside the cold data, it's a little bit more complex to do it. And if you want a quick announcement, we are working on supporting properly a safe transaction so that on device, you will be able to completely understand what's inside the transaction and that you are interacting richly inside your safe wallet.

It will be properly displayed on the hardware wallet itself. Thank you, Charles. Yeah, I mean to recap, Charles just answered multiple topics in this panel and I'm grateful for this. 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 our participants because these are super important.

This is like what's coming next. Sure, yeah. Yeah, I think we learned a lot from those hacks. I think an interesting thing about them was they were both routine transactions that the teams were making. So they were pretty much everyday operations that were common for Bybit.

It was transferring between a hot wallet and a cold wallet, pretty routine stuff. And with that, it's pretty easy to scope out and for those specific transactions. So we developed the Zodiac roles module, which extends safe to create very specific permissions and granular scoping that you can set. And with that, they could have just created a permission that would allow them to transfer between these two wallets with just one sign or even an intern could have done that. It would have been very low risk because the worst that can happen is you just have your assets in another account and can transfer back.

So yeah, we're leaning into permissions and scoping. I think that signing should really only be used for in very rare cases. For the most majority of things that we're doing on-chain, they're repetitive transactions or operations that people repeat in their workflows. And signing is kind of a major open-ended transaction that should only be reserved for upgrading your account or very significant changes with high auditing, high security. Yeah, thanks.

That's a very important insight here because of this repetitiveness of transactions and operations. And we at 1CAX 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 awesome. Thank you. We can go to the next topic and that's actually the topic of specifically verification of what transactions mean and then the transactions hashes.

And we definitely know how to do this with Ledger now because there's so many details about that. And for me, for example, 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 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 how we solve the problem is with the co-signer.

So co-signer is an additional signer that you can integrate in any MPC like Space or Fireblocks. And it solves two problems. 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. It eases the problem because the co-signer acts as either a required or an additional signer and it receives the actual transaction. So it will have prevented the Bybit hack because our system would have validated that transaction and detected it will have been malicious and blocked it.

And more specifically, like we offer two different products for decoding code data. We offer our APIs, which enable simulation and validation to offer the end user a clear vision on what's happening in the transaction. And 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, thanks to our very wide data source from the ecosystem and a team that gathers information on a daily basis. So we are updated every hour on new threats and malicious addresses that are by a signer.

And it eases a lot of problems and a lot of pain points from the customers who don't want to bother too much decoding themselves the transactions. What's the false negatives and false positives? What are the numbers? Like below 1% for false negatives. And false positives usually get resolved in a very short amount of time, because we only have false positives for fresh new organizations, so unregistered organizations or anonymous EOAs, and usually the procedure is that the organization contacts us because we show usually a button or a form to contact us and we resolve the matter in a matter of like minutes, if not hours.

So that's our power and in terms of false negatives, we can keep the false negatives numbers so low, because the amount of data we gather from the network and from 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 hypernetics. Yeah. So... And hashes and everything. Yeah.

I think that the interpretation is really an important aspect here and understanding in layman terms, right? Or I wouldn't say layman, right? There are professionals in their own field, the traders and analysts who are not technical and can 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... Even for the technical people who are able to review traces and so on.

We are all people, right? So we want something that is much more reliable and not on whether we had our coffee in the morning and looking well at the traces. So I think that it is important to employ solutions that have proven themselves in the past, right? So we employ machine learning and behavioral analytics and multiple techniques that have successfully found the Texas fraud and phishing. We have the unique models for that, hacks and exploits and so on.

So you want to introduce that even for a technical person, 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 the 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 lifecycle, right? So prior to the transaction, how do I investigate and research the contract 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 on-chain monitoring. In real time, I establish the position on Morpho, I establish the position on Aave, I transfer funds and so on. I have assets on-chain, I have a multi-fig, is something happening to them? Are they being subjected to attacks now?

And whether there's automated response configured, right? Which many of our customers employ automated responses to pause protocols, to move funds and run positions and so on. So it's not just at the point when I initiate a transaction, how do I avoid risks? It's seeing my entire web suite activities, right? In one comprehensive phase suite and understanding, okay, I'm covering all my bases here in a platform that can interact throughout the different steps.

So that sounds like there's a lot of ML inputs and analytics that allow us to kind of predict what's going to happen in combination with the rules 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 phishing and hacks and exploits and the behavioral analytics and so on. And now you apply those detections, right, and this insight from the multiple engines to the various steps in your life cycle to ensure that you are protected throughout your activities. Thank you.

Okay. Yeah, Charles. I was assuming you told the story, but yeah, please add whatever. Oh, definitely. So to your point, we can't expect that users will understand hashes, like no one understands hashes.

And it's a very big problem that we, us as an industry, accepted that it's okay to sign blind, signing hashes. It's a big problem, and this is how Bybit and plenty of users are losing money every day. So you were mentioning technical people, but even so, most of users won't ever be able to recreate the whole 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 won't happen.

This is the first thing. The second thing is even for technical people. You are doing this like once, twice, several times, and at some point you are getting bored and you are doing this very quickly, and then you will sign a malicious transaction at some point. So those are not solutions, and we must all agree on this. And the way we are solving this is really by two different ways.

The first way is clear signing, providing the users with the understanding of what it is about to sign. And the second one is a transaction check on device. Just to give a very high-level view of the success for this feature, we launched it, I think, on March. It's only available on Flex and Stack, so our newer devices, and only in one month we simply saved 18 million. So this is what we are talking about, and this number will compound over time, and this is millions that are saved for the whole ecosystem.

And when we are saving millions, this is for everyone, because if our ecosystem is only about hacks and everything, we won't create trust. So we need to work collectively in creating trust in the ecosystem. In the interest of time, we need to move on. But who in the audience thinks that blind signing needs to die? Let's kill it.

Let's just get rid of blind signing. Let's kill it. And, yeah, Zodiac. Does Zodiac help ensure that you know what's actually in the transaction and the integrity of them? Somewhat.

I think, yeah, we take a little bit of a different approach. I think I agree with Charles. We should not expect the end user to be decoding call data and transaction simulations and a wall of bytecode and everything. So we take a more preventative approach where we have people set up the proper account structure and roles on those accounts so that you don't need to know as much what you're signing. The permissions are set up for you ahead of time so that you can only sign things that you want to sign.

So it's a little bit of coming at it from the other angle. Yeah. Okay. So to recap this whole verification topic, we have every participant on the panel having their own products and their own ways of actually solving the same problem. So 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. When I do my personal transactions, I quite often originate them. I use hardware wallets, but I originate them from the laptop, which I use for other things, for work. I find sometimes that, okay, I actually ran NPM something on it, and now I'm about to initiate a transaction on 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 what are the opinions here? Maybe we'll start from that side. Sure.

Yeah, I think probably the best case is not to use the same devices. But I think for most people, they end up using the same devices. I do use my work laptop for signing transactions that are fairly high value. And yeah, I think ideally scoping the permissions is the way to go 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 do that for my personal, especially low-value transactions. I'm accepting this. Is there any other way, Charles? Don't feel bad about that, because your security setup should never rely on the security of your laptop or your mobile. If it's the case, you have a security problem.

So if you are using like a hardware wallet, a ledger device, and you are verifying on devices, you can have like multiple malware on your computer, on your mobile phone and everything. If you are able to verify on device the transaction you are signing, you are safe. If you don't share your 24 hours with anyone, if you don't put your 24 hours on your computer, you are safe. So again, I'm not saying that your computer should be plenty of malware. It's always good to have a good OPSEC.

But your crypto, the security setup for your crypto, should not rely in any way on the security of your laptop and or the security of your mobile phone, because those devices are simply not secure. Any other opinion here? I think that it's important. So I've been dealing with cybersecurity for over 20 years now in various capacities, in Web3 for the last seven of them. And I think that the sort of actors that we are concerned about here, they are very advanced and sophisticated, right?

So we see them... Let's take the DPRK, right? Everybody's talking about them. But I'll just say that the techniques that they employ are often then copied to others. But they will employ malicious PDFs, right, to compromise machines, and they will invest into compromising entire infrastructures, like with Ronin or with the Bybit hack, right?

Or they will sometimes infiltrate with their own IT workers, right? We handle several such cases where the entire IT team of the... All the devs of the protocol were actually North Koreans. But we have other concerns as well, right? For fraud and phishing, right?

Inducing customers to transfer funds to them, thinking that they are actually interacting with the different dApps, cams, drainers, big butchering schemes, right, where you get some investment back. 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 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 companies like HyperNative, right, are providing these detections and to you at the point of signing, saying, even if you think this is a legitimate transaction, don't proceed with it. So 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 to help you ensure... As our customers say, we sleep better, right? Right.

When you have such a... Right. Definitely sleep. We need to work on sleep. That's what'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 signing transactions. That's not how we are going to onboard the next billion people. It's not acceptable.

And we need to sleep better at least. And we need to stay safe when signing transactions, even if we aren't able to understand those transactions. 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. 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 transaction used by phishing scammers to trick users into losing funds. So not just displaying to the user what they are signing is enough to save them from the scams. You need someone also who validates those.

You need someone who preemptively 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 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 are going to sign a malicious transaction anyways. It is going to happen. We don't want that to happen.

We don't want that to happen to big organizations, but also to daily businesses who do transactions on-chain every day. We don't want errors in the way. That's why we handle the validation. And we can enforce 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 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 find that transaction anyways. So there is always ways to bypass it. To wrap it up, basically, we are all agreeing that we are kind of mostly accepting this risk of the signing environment.

Maybe except for some outrageous cases. Recently, 1KX, we published this document, Multisig OPSEC. If you just Google Multisig OPSEC, you'll find it definitely. MyTowerDevOps published it. And that was one of the points.

And another point in that document was diversity of signing devices. Like, if Ledger gets hacked through whatever vector, maybe some of the signers on the page should be using different devices. And maybe Charles, you can start commenting on that. On this, I understand the rationale for saying diversity could mitigate more risk. One of the problems is that there is not so many devices on the field where you have high level of security, where you have the support of safe, where you can do clear signing, this kind of thing.

So it really depends on your setup. It really depends on your security constraints, on your threat model. Personally, I only use Ledger devices even in a Multisig setup because I feel this is the best-in-class security that you can have. And the risk that you would mitigate by using another type of device are not worth what you lose in terms of security with using these devices. Thank you.

We have three minutes left. Does the audience have questions? Yes, please. I have a question first. Okay, I have a question mainly to Ledger, but maybe I'll ask you from shipping.

So 7.7.30 has this requirement that basically all of the developers in the world open a PR against the Ledger repo, and then you then curate that to get metadata about the contract. Is the reason why Ledger, 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 ABI that would already give you at least the function name and the parameters? Very good question.

The problem with ABI is that they are very high-level, and sometimes the name of the method is not clear. Also, you don't have types. So ABI is more than nothing. It's better than nothing. But 7.

7.30 is far better than only ABI. When it comes to the registry itself, so we created the standard, and we would like to decentralize the registry. We asked the Ethereum Foundation to do it, by the way. For now, they didn't accept, as you know, but we are very happy to decentralize the registry.

What will be centralized on the Ledger side is the curation of the registry. We will only sign the metadata file that we trust, that we verified, but the registry itself and the ERC 7.7.30 are completely open-source, and they are public goods. Thank you.

Hi. I'm super impressed with the developments that have been going on and how you're handling the topic of client signing. I have a philosophical question, though, which is regarding the level of abstraction with which we represent the wallet. So we give the task of creating the transaction, and then we have a very low-level interface at the standardized level to which the wallet, 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 the intent of the end user and start giving the task to the wallet to actually create the transaction from the intent that it has received from the wallet?

It's a very good question. On a completely general standpoint, it's impossible to do everything on the device that is completely disconnected with only a description language model. This is not possible. However, we can go very far already, and this is also why we think it's complementary with this transaction check type of solution with Blockhead or Fiverr or Tenderly on device. So I think this is complementary.

However, I don't think we should rely on the user itself to verify the transaction. This won't happen, and this is the job of wallet, but also dApps, 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 is able to understand what he finds. To your point about intent, we have talked a lot in the ecosystem about creating an intent-based type of transaction. The problem is how we do that properly, because you would like to have something very high level so that the user can completely understand the intent. However, behind the woods, what is actually running on-chain is not that simple, and it's difficult to have a one-to-one matching between the high-level intent language that we would create with what is actually happening on-chain.

So this is one of the challenges that we have collectively in the future. Sometimes I discuss with different people who think that AI could solve this problem, but the problem is that the language is ambiguous. So this is not a simple problem, but this is a problem that needs to be tackled if we want to do very, very complex interaction directly on-chain. Thank you very much. I think there are more questions.

I want to give the floor to some of the participants for closing comments, and then maybe if there is another question. Andrei? Sure. So first of all, it was a very interesting panel, so I want to thank all of you. I think that 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 users are trying to do things, right? And one of the things that we heard repeatedly throughout the last years of our engagement, and specifically the last few months, is that they are hesitant about doing things in Web3 because they are concerned about risk, right? So there is this very nice metaphor that I heard a long time ago about cybersecurity, that why do race cars have such good brakes? To go faster.

To go faster, exactly, right? So this is the same concern that we repeatedly hear from users, that they want to do more in Web3 and they are constantly concerned about risk. And the more we can obstruct 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 major parts will be obstructed away from them, the more users will be using Web3 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, but thank you.