AllWalletDevs #038

|2026-02-18| Agenda: #1909| canonical JSON

Transcript

Sam:Alright, I guess we can probably get started. We do have quite a few items on the agenda. I'm not sure…

Sam:who's from which wallet here? I think there are a lot of new names, but

Sam:I will post the recording afterwards, so hopefully we'll get some feedback from everybody. So I guess let's get started with All Wallet Devs number 38.

Sam:Mercy, are you here?

Sam:No? Okay, so we will come back to that one.

Sam:Yeah, I guess let's start with the Structured Data Clear Signing Format, ERC-7730. If you guys are here to give us, like, a summary, that'd be great.

lcastillo:Yeah, I guess that would be me, so…

lcastillo:Hi, everyone. So, very, very happy to be presenting today. I see that Harry has joined also, so I will count on him to back me up when there's any need. Do you know how many, how much time I have to present ERC, roughly? Sure, that's actually appropriate? Okay.

Sam:Yeah.

lcastillo:So, just, just to give you maybe a little bit, a little bit of context, I've got, I've got a couple of slides that I can share that gives, that explains a bit, history and the approach we had for, for the 7730, file, so let me, if I can, let me share… I don't know if I can share my,

lcastillo:If I can share my screen… I'm not sure.

Sam:Yeah, the Zoom bot just joined, so hopefully it'll give me, admin here, and…

Sam:Nope, I guess not. So,

Sam:Do you have a link I might be able to share?

lcastillo:It's, it's actually a PDF, PDF file, so…

lcastillo:Well, that's fine, I can do it without, without the slides, it's okay. So basically, the context of C730, was to, for, for Ledger, hardware wallets, and wallets to start,

lcastillo:trying to solve better the issues of blind signing, so… or do you actually display relevant information to the user when they actually want to approve a transaction on their device?

lcastillo:This is a complicated topic because, typically what we realize as wallet maker is that,

lcastillo:base function call or message call that you make users sign, even if you are equipped with the API of the smartphone track that you're trying to call, is not really human understandable for many different reasons. The first one is that ABIs are very developer-driven.

lcastillo:They are… they look like function calls, rather than mostly user intents, as translated as user intents. And they actually also basically use only the solidity types, which can actually be formatted in many different ways. So, as an example, an integer can be interpreted as a token amount.

lcastillo:or can be a date, can be a block height, or any kind of things that make sense for a smart contract as a parameter. And there's no real information that Wallet can use, apart from the smart contract code itself.

lcastillo:To try and display this information, correctly to end users.

lcastillo:So, this is, this is the crux of the problem that we are trying to solve with the 7730. So, how do we transform a transaction raw data, or a message raw data that we are making a user sign into human-readable intent in the easiest way possible, and the most scalable way possible for our end users? Because,

lcastillo:Just to give you a little bit of context, as Ledger, we introduced roughly a lot of technologies to start doing that, actually, a long time ago, like 3-4 years ago, mostly based on programmatic extensions to our application that we're running on our wallet.

lcastillo:This was a kind of a maintenance nightmare. It required, basically, dApps developer to understand C code, to actually extend anything in a relevant way. Very specific to Ledger, so not reusable whatsoever for other wallets. So that's why we started to introduce 7730,

lcastillo:Proposal as a standard.

lcastillo:To have a common approach for, clear signing, any kind of message or transaction, based, based on a few common, common concepts that, that, that we had in mind, that would be able

lcastillo:to be reusable by all wallets, so that DAP only has to write his 7730 file once, and will be clear sign on all the wallets, in a kind of a similar standard way, actually.

lcastillo:So, the base principle, the philosophy behind this, this standout, we have a, we had a few, few, few things in mind when we started pushing the standard. First is that, it's data-driven, so it's actually a metadata file.

lcastillo:Which is, which is appended, kind of appended to the API, so that it complements the API and provides formatting information, to the wallets on, what they should display to the user when they, when the user is interacting with a specific smart contract.

lcastillo:This is the basic idea behind the 7730.

lcastillo:It's presented as a JSON file that I'll be able to share some examples later that contains this metadata. It's data-driven, so I think it's not a programmatic model, it's only providing metadata about how to format each transaction code. There's no logic built in beyond what is specified in the standard itself.

lcastillo:which made it a good support for both hardware wallet and software wallet, given that hardware wallet tends to have far more restriction on the execution capabilities that they have. We wanted a solar that could also be supported by hardware wallets, whatever their form.

lcastillo:So that was a fairly important one for us.

lcastillo:obviously at Ledger, I would say, but definitely that was useful, because nowadays, what we realize is that by being very, very data-driven, it's basically a JSON file, it also plays fairly well with AI tools, and it created a standout that is fairly easily interpreted by, by AI tools and generated or analyzed by AI tools, so, which is

lcastillo:kind of a boon for nowadays, I would say. So, the basic approach of the 7730 file is that, basically, if you…

lcastillo:If you look at some of the examples I can post here on the…

lcastillo:This is a typical… this one is a… this one is the main example that you can find on the… on the… on the ERC GitHub, on the internet.

Sam:You can try sharing your screen again if you want.

lcastillo:You know, that would be… But, try…

Hester Bruikman:Or if you have a PDF folder, you could ping it to me, I might try sharing to me.

lcastillo:Hopefully I can, should be able to see my screen now.

Sam:Yep, we're all good.

lcastillo:Perfect.

lcastillo:So, these are the slides, just an introduction. So, this is what we call, can you see the slides, or do you see the GitHub right now?

Sam:Slides.

lcastillo:Perfect, so… so just to quickly go through the most important points, this is what we call blind signing, so it's users, they… they definitely, sign

lcastillo:Something, but they don't understand whatever they're signing, because it's presented as a hash.

lcastillo:And we want to go, basically, to an interface which looks a bit more like, like, sorry, like this, where, every field is interpreted, sorry, every field is interpreted.

lcastillo:and clear to the user. And as I mentioned, the… sorry, the ABI itself is not enough, because that's the kind of interface you can build with the API itself.

lcastillo:There's a lot of issues, even for the current API to interpret, to interpret the, the parameters as a user, and it's not really that much better than, than, than actually a row hash that you have to sign, because you still have to interpret, as a user, a lot of parameters that are completely,

lcastillo:dependent on the program you're calling, actually, so you have to build in knowledge in that, so…

lcastillo:And as I was saying, these are the requirements we have, we had when we started to introduce that. So, data-driven, so it's basically a metadata file, human-friendly, so it's made to be, read by humans.

lcastillo:With a nice addition that nowadays it's also easily read by AI, so it's pretty, pretty powerful, to, to have kept this requirement all the way through.

lcastillo:It's standardized, so we really wanted something that was not specific to a specific wallet or hardware wallet, and that could be reused by all wallets, so that basically the dApps only have to write the file once and be clear signed on all the wallets. That was very important because

lcastillo:the problem of clear sending is really a problem of scale. To describe correctly all the files out there, you have to have the support of the community and all the dApp makers to describe, to help us describe what's supposed to be displayed to the user.

lcastillo:So really, to build this standard so that we can get, to a scale that is an ATM scale, basically, and not just a couple of wallets trying by themselves to clear sign to buy the UN of… by clear signing, just, whatever they can, actually.

lcastillo:And we also wanted something that was easy to implement, or more… rather than easy to implement, that was,

lcastillo:possible to implement whatever your constraints, including the most, stringent constraints that a wallet could have, like arbor signers that we have at Ager. So, this was some of the requirements we had in mind when we started developing the 7730.

lcastillo:And, how does it work? As we mentioned, basically, you have, you have,

lcastillo:the standard, that is the key component, then you write a JSON file that contains the metadata about the way you want to format your transaction and messages. And this gets inside the public registry, and we are in the process of

lcastillo:transferring this, the ownership of this public registry to the Ethereum Foundation, so once this is done, you will submit, basically, the semantic file to the public registry. And once this is done, this file is actually imported by the wallet.

lcastillo:Verified, and then the wallet can use it to build the user inter… the correct user interface, actually, for that.

lcastillo:And what does it look like? Rather than showing an example, maybe I can… well, let me switch back to the GitHub, it's a bit more clear. This is an example of what a simple ERC307730 files look like. There are three important sections to understand in the 7730. So the context section here.

lcastillo:is really all the binding context of when the 7730 file is applicable. So it gives you, basically, what contract you're trying to interact with.

lcastillo:what are the deployment addresses of this contract in the various chains that are EVM compatible. For a message, it will give you the similar kind of information. You can actually add the name of the contract that you want to pad into. In the V1 of the format, we had also the ABI and the schema of the contract here, but we realized that it was better

lcastillo:So you embed it directly in the…

lcastillo:In the display section, so… so we removed it, and that made the file far easier to… to read and to manipulate, actually, so it's… it's better.

lcastillo:Then we have the metadata section, which contains displayable information by wallets on the target of your interaction, so typical information about which contract you're interacting with, which entity behind the contract you're interacting with.

lcastillo:some additional information that might be useful for users, like a URL they can go to to interact with this contract.

lcastillo:So, a dApp URL, for instance, or any kind of information that the owner of the contract may want to show to the user about them when a user interacts with the contract.

lcastillo:And then the most important section is the display section. So this display section actually contains the core information about the start itself.

lcastillo:Which is, the formatting information about a specific function. So here you have, we explicitly name the function that the formatting information applies to. So here it's a simple transfer function for a NIRS20 token.

lcastillo:You have an intent, which is a verb that represents the intent of the interaction of the user with when they're calling this function. And then you have the field section, which describes how to format each parameter of the call.

lcastillo:And whether you should display it or not as a wallet, actually. So here, you should actually display both parameters. It tells you, okay, the two parameter is actually an address, and you should format it as an address, or as a trusted name, if you have a way to transform the address into a trusted name, which can be an ENS name, for instance, or it can be a local address book for the wallet, if the user has associated this address with a specific name.

lcastillo:on his own. So, any kind of transformation from an address to a name is acceptable, as long.

lcastillo:as a user, or the wallet trust it, actually.

lcastillo:And then the value is actually interpreted as a token amount.

lcastillo:So, that means… that means that basically this integral value is supposed to be converted as a token amount, and by that we mean that actually the wallet should, get the token details from the add to parameter here, so basically the destination of the, the transaction in that case.

lcastillo:Use it to retrieve the ticker information and the decimal that the token is using for its values.

lcastillo:Convert the value using the decimal and display it with as a real value plus a ticker.

lcastillo:So that the user really have a nice experience while they're interacting with this token, and don't have to convert themselves the actual integral in the token value. So this is basically the crux of the standard, it's really there.

lcastillo:So we've kept adding new formatters to tackle new use cases, so every single time we see new use cases.

lcastillo:Then we add new formatters so that we can enrich the standard with new interactions supported by the standard itself. So, for instance, recently, we've, we've added interoperable address, which was another ERC that was introduced.

lcastillo:to standardize the way address cross-chain are formatted as a parameter to a function call, and also the way it's actually displayed. So it was a pretty nice addition to say, okay, we actually… this TEGAR value is actually a cross-chain address, and display it as a cross-chain address, as specified by the other ERC. I think it was 7930, if I remember correctly.

lcastillo:So this is… we keep adding new formatters like that. We are at a point where we believe we've covered quite a few use cases, and we are fairly happy with the current forms, which is why we're calling it a V2, at least a draft V2 ready for public review and getting more comments on it.

lcastillo:What can I say more about the 78730? We've also added a couple of things that makes life easier for the addition of the file itself, so ways to include files or ways to put in command some definition here that makes it a bit easier for an actual developer writing that file to have a more compact

lcastillo:for presentation of the file, so this is all described in the ERC-7730. But again, the intent was really to have a file that, in the end, is fairly human-readable, so this service still looks readable for developers that understand what they do, easy to write for smartphone track developers, and that with what

lcastillo:still interpreted, completely, easily to interpret by wallet, so that they can, take this file and enrich the API of what the user interacts with to actually, display, the interaction in the nicest way possible that they want to target, actually.

lcastillo:So this is, kind of the groups of the 7730, presentation of the standard itself.

lcastillo:Around the standout, there's another big topic we have in the pipe currently, which is the discussion about the way we do the governance of the…

lcastillo:of the registry itself. So, as I mentioned in the slide, basically, the intent is to put all the 7730 files for now in a GitHub repository. Right now, Ledger is hosting this GitHub repository, but in the coming weeks, it should be migrated to an Eternal Foundation GitHub repository.

lcastillo:But a big part of the job of maintaining this GitHub repository is actually checking that the file that goes in the registry actually corresponds to the implementation of the Spartan Track that goes on-chain, actually.

lcastillo:This is very important for the security of the whole ecosystem, and it's… the ultimate line of defense in that case is the wallet itself, and the wallet shouldn't… should actually verify, actually, that everything goes, but as an ecosystem, it's far better if there's a way to actually verify and audit the file that is in joint history itself.

lcastillo:And attached to this registry, trusted information about who has done the audit, what was verified, and maybe, some additional data, so that wallet can take,

lcastillo:a faster decision on trusting a file or not that is in the registry, so this is a big part that is currently under discussion, so I don't think… I think, Eric, you had some proposal on that, to have a…

lcastillo:to have a… Let's say, a cleaner proposal on the way we handle the registry.

lcastillo:when it's migrated to the Ethereum Foundation.

lcastillo:But otherwise, this is the big, big topics. So, 7730 is really about the metadata that enrich your API so that you can convert a transaction or a message into a clear user intent to display to the user.

lcastillo:It's a public draft ready for review by the larger community, so that we have the best standard that we can get out there. And then, in the pipe, we have this governance to discuss, so that we get a system

lcastillo:Which is as decentralized as possible, with as many auditors that can contribute to the reviews, so that you can really scale the data that is covered by this standard.

lcastillo:That's all.

lcastillo:roughly in a, you know, let's say in 20 minutes, that's a very quick presentation of the, of the 7730 and the ongoing work, around it, but.

Sam:Thank you so much for the presentation. That's a really interesting proposal. There are some questions in chat, but in the interest of moving to, the next proposal… the next discussion point, I'm going to hand the floor off to Mercy, and,

Sam:get a presentation about RPC endpoint versioning.

Arik:Sam, if we can only ask, like, because, like, I think one of the main purposes of this presentation is two things. One, if you're a wallet, and you're thinking, what does it mean for me, should I integrate this? How?

Arik:talk to one of us, right? To Loren, Hester, me, somebody, or just post in, like, the Nexus group or one of the other ones, and reach out, and we're happy to do more specific sessions with wallets and, like, protocols that want to use this, right? So I think this is really, really important.

Arik:And if you have feedback on the ERC, where we finished a draft, but we're happy to take more feedbacks, so this is really important for us as well. Thank you.

Sam:Great, thanks so much. Mercy.

Mercy Boma Naps-Nkari:Hello, Sam, thank you. Good evening, everyone. I don't really have, like, a presentation per se, I just wanted to get more input on this. So, the RPC team is trying to, like, explore endpoint-level versioning for JSON RPC.

Mercy Boma Naps-Nkari:API, so… and we would really love to get input from wallet devs and users before we finalize what, the V1 looks like. So, I…

Mercy Boma Naps-Nkari:I will share its magician link, so that to get more points in case, maybe, if something comes in my data. So, the thing is that idea, I wanted… we wanted to ask if there are specific methods or response fields where that backward compatibility is critical for wallet devs.

Mercy Boma Naps-Nkari:Or any pain points when the spec changes that we should be aware of, so that we don't…

Mercy Boma Naps-Nkari:Do something that will break, at some point for the real users of the…

Mercy Boma Naps-Nkari:At the endpoint. So, before we finalized version 1,

Mercy Boma Naps-Nkari:And we would want to get this input first, so that we will know what to…

Mercy Boma Naps-Nkari:include in version 1, and then know how to, like, progressively, take up from there. I don't know if what I'm saying is…

Mercy Boma Naps-Nkari:Making sense at all?

Sam:I think so. So you're, working on adding versioning to certain Ethereum RPC endpoints, and oh, you're still sharing your screen, by the way.

Sam:And you want feedback on how that gets shaped?

Mercy Boma Naps-Nkari:Yes, let me share the, link… the PR links to get more context.

Arik:I pinged Lauren a couple of times, but, like, if you can stop his screen sharing, maybe that's also a good idea.

Sam:No, I'm not, I'm technically not… no, there we go. Okay.

Sam:Awesome. Well, thank you, Mercy.

Sam:Yeah, if anybody has any feedback, please leave a comment on the discussion thread and PR that's gonna get posted. There we go.

Sam:If anybody has any comments now that they'd like to discuss about it, we have a bit of time. Otherwise, we'll move on to the next discussion point.

Mercy Boma Naps-Nkari:Okay, sorry, I also want to include… maybe I can share, like, a calling for the RPC in case something comes in mind, because the idea is to get, to address how the, breaking change… how it's been handled currently. If…

Mercy Boma Naps-Nkari:That is a pain point for wallet developers, and if there's something we need to keep in mind before making this, shipping this endpoint versioning.

Mercy Boma Naps-Nkari:So that it will be useful for…

Mercy Boma Naps-Nkari:your workflows, and it doesn't, like, unnecessarily add a sort of complexity to what we have already. So if it is something that is important or useful, we would like to get an input, and then if it's a pain point or something, maybe you feel like, okay, this needs to be corrected, or there's something

Mercy Boma Naps-Nkari:that needs to change in the RPC spec, for example. Also, this is, like,

Mercy Boma Naps-Nkari:an open floor discussion in general, so… because at the end of the day, wallet devs are the main users of our PC endpoint, so…

Sam:Alright, well, thank you so much.

Sam:Moving on to the next discussion point, we have another clear signing, proposal Yeah.

Sam:I unfortunately don't remember who was supposed to present this, but if you're here, please take over and, tell us a little bit about your proposal.

Kirill Pimenov:It's me and also Naila on the call, he probably would need screen sharing permissions. Yeah, bye. So, I swear, it wasn't scheduled for us to be on the same call as Laurent, but I'm really grateful for both his work and, like, setting the stage for this.

Kirill Pimenov:Because, like, in my team, we've been using with a very related problem, like, not exactly the same, but closely related. And, like, yeah, with a little bit of a support from Ethereum Foundation, we now can prepare some early, early draft of our funding. We're not even, like.

Kirill Pimenov:draft of ERC stage. But, yeah. If you go to the root of it, I would, like.

Kirill Pimenov:Our problem is that I'm stupid and stubborn, and because of that, I want to give developers a way to specify how the contracts should be represented in the hardware wallets.

Kirill Pimenov:And to add insult to injury, the hardware wallet I have in mind is this thing with a ridiculously low bandwidth, both on input and output, which is a very different, like, security model from Ledger, and a different set of trade-offs needs to be done. And so, yeah, like.

Kirill Pimenov:We want users To be able to see what they sign.

Kirill Pimenov:And we want users to be able to see what they sign, even if that's a very, very fresh, I don't know, some sort of a DEGAN token swap thing, which launched in the last 24 hours, and definitely, like, it's not going to be merged in any centralized registries, even if it's legit, but that's questionable.

Kirill Pimenov:So we want that to work in a developer during semantics, without central repository of tools which verifies it after them.

Kirill Pimenov:We want that to work without, like.

Kirill Pimenov:real-time dependencies, this thing doesn't have a full Ethereum state, even unless it has access to the GitHub with the latest JSON definitions, and those constant firmware updates. They are not the sweetest point of Ledger, but for us, with an NFC, like, bandwidth to our device, we just can't have it.

Kirill Pimenov:So, it shouldn't have, like, any pull dependencies, no real-time communication. It should be, like, one-way push only for this specific call.

Kirill Pimenov:And, like, yeah, I don't want to be a trust in the period. I don't want to hold the keys to the castle and tell that, oh, this contract gets clear signing, this doesn't get clear signing. I ideally want that to be the contract author's.

Kirill Pimenov:And, at the same time, I want to prevent my users from phishing. So, like, I don't want a new, like, address to be, like, presenting itself as a USDT and then defaulting by customers. Quite a lot of, like, you know, contradictory requirements we have there.

Kirill Pimenov:Oh, and of course, we want to have composability, like, since we are talking about, like, push semantics and developer, like, driven work, and so on.

Kirill Pimenov:I want that to be wrappable in a multi-sync call from Magnosis Safe.

Kirill Pimenov:diagnosis safe or anything down the chain, to have to add additional wrappers for my hardware wallet node to have interpreted, and show it, hi, that's a multi-seq call 1 out of 3, which is wrapping this particular transaction to this new, like, ShibuSwap thing they just deployed.

Kirill Pimenov:So, I want…

Kirill Pimenov:The… what we see on the screen, or any screen, like, any hardware wallet, maybe, software wallets.

Kirill Pimenov:to be the law. I want us to cryptographically be bound to that law, and we designed

Kirill Pimenov:with a very different set of requirements, I think, which hopefully extends 7730 with the features which are required to make that possible. Not without its trade-offs, but we will get there in due time.

Kirill Pimenov:So, our first and very basic important assumption is, like.

Kirill Pimenov:it would… everything would work better if we split explicitly social layer and protocol layer. So, like, social is, like, the who, the, like, oh, I don't want that, like, new smart contract to look as its legitimate USDC. And we sort of solved that by talking lists already.

Kirill Pimenov:And anyone can publish such a list, like, let's do contracts lists. Let's extend that to somehow verify the identities by parties you or anyone a developer trusts, and have a, like.

Kirill Pimenov:wallet-level definition for any address, even the contract, is it a well-known contract, who owns it, and so on.

Kirill Pimenov:And the second, let's extend that with ability of a contract author to specify a display format. It is very, very closely related to 7730, but we would twist that our

Kirill Pimenov:way interpreting that format, interpreting that, how to parse that API,

Kirill Pimenov:is, like, very friendly to both push-based and composable ways of expressing it. So we want dump to tell to the wallet as an additional array, hey, that is the extended info you need… you can use to show on screen the human reasonable parsing.

Kirill Pimenov:And then, like, the wallet will maybe, like, send it to the, like, signer, so, like, maybe it's a nose is safe, which sends it to the, Ledger Live, and the Ledger Live

Kirill Pimenov:like, sends it to the actual hardware device. Or, like, using WalletConnect, you send it to the mobile companion of this thing, and then you put this thing behind your phone's NFC, and it also gets pushed.

Kirill Pimenov:And every layer in that.

Kirill Pimenov:J would just extend the display array, adding an additional, like, representative arrays which help you thematically interpret the APIs. I've seen that question in the Q&A, and I would very briefly address. The problem with APIs in Ethereum, as it stands, is they are not, like.

Kirill Pimenov:it requires some data which is not on-chain to parse what it means. It is not semantically unambiguous, and that can be used, like, against bullet users.

Kirill Pimenov:In very different ways, but, like, the stupidest way is, oh, there are different tokens, and they have different decimals, and if you swap one for another, and your wallet doesn't know where the decimal is, there is nothing in the EBI call which will tell you if you're swapping 1 or 100 of that token, and if you are presenting that in a human form.

Kirill Pimenov:You will fail.

Kirill Pimenov:So,

Kirill Pimenov:we pass that through DAP, through the wallet, all the layers, to the actual, like, signing device. I'm thinking about hardware wallet, but once again, your MetaMask on the smartphone is exactly the same.

Kirill Pimenov:You use that additional, like, metadata which we pushed with, call to represent that on screen for your user.

Kirill Pimenov:nice thing which we have sort of kept in mind is that it might have, like, different localities, like, having Chinese interpretations for the fields might be useful, additional to, like, having English language ones. And then you cryptographically commit

Kirill Pimenov:to what you've just used to show. And with that, you are avoiding all those attacks with, like, developers or someone presenting themselves as developers.

Kirill Pimenov:pushing a falsified metadata to your hardware wallet, so you're signing not what actually happens on-chain. We've all seen those hacks happening, so this is a legitimate vector of attack.

Kirill Pimenov:And… Then… you sign that by effectively having a EIP712

Kirill Pimenov:hash structs… hashing of what you use to display, like, all those arrays of meta info for the calls, and instruct… which instructs you wanted how to parse.

Kirill Pimenov:And then you effectively wrap your call data with an additional

Kirill Pimenov:Clear call, on-chain call, and this is one of the important trade-offs we are currently talking about.

Kirill Pimenov:So, you have a clear call, which, like, accepts display hash as the first parameter, and call data as a second parameter. And it's a very, very tiny ship, and our benchmark is about, like, 7,000 to 8,000 gas units.

Kirill Pimenov:And what it does, it just compares the display hash with what it has hard-coded in the contract, and it fails. If that is mismatched, that means that you've been misled by whoever sent you that meta info, and your transaction is

Kirill Pimenov:drawn based on wrong assumptions, it shouldn't never be accepted by chain. This is how we avoid that single point of failure. And, yeah, if clear call passes, then we are good. And, nice thing about that, it's completely stateless and completely composable.

Kirill Pimenov:Because, like, different layers of that display logic, they can be assembled all together.

Kirill Pimenov:And then, another important part is, like, how do we get from here to there? Because, like, obviously that requires an on-chain changes, and that's a big ask, and we cannot just move the whole Ethereum ecosystem.

Kirill Pimenov:So, especially for the things like Uniswap, like Uniswap v2 is not upgradable, it's still being used. If it's… if you cannot see it on screen in a human-readable form, okay, like, that was for nothing, because the goal is to never have to deal with, like, signing those ungradable hashes anymore.

Kirill Pimenov:So… We…

Kirill Pimenov:Introduce, like, interlinkage between the first thing, like the contract lists, and our display format, in the sense that to be accepted to the contract list, you need to verify your identity and somehow pass the, like, basic checks.

Kirill Pimenov:And then you can attach those, display hashes to that contract list, which is…

Kirill Pimenov:hopefully not update very frequently. And on another side, like, if you're a new contract, of course, you might be able to deliver a contract which has that additional clear call method, which will just enable everything for you magically.

Kirill Pimenov:And there is the middle ground, like, we don't…

Kirill Pimenov:like, we want that to be somehow, like, managed on-chain, so, like, there might be a DAO which manages the mapping being this address and this selector maps to that hash data, and those would be just, like, wrapped in either, like, smart wallet call, or just a flashbot-like assumption. So, like, here is a, like, actual call, and here is an assumption by it, and we rely on the flashbots to make sure that externally

Kirill Pimenov:account also get the pre-flight checks before sending it.

Kirill Pimenov:And, that's sort of it. So, like, our trade-offs are… it either requires a contract change, so, like, extending something like 7730 with additional social layer of, like, hey, this is the source of a hash data that might be on-chain or might not be.

Kirill Pimenov:then we have a gas overhead. It is not free.

Kirill Pimenov:like, we commit and we make a chain check, an additional check, that's just a couple of S stores, that's a… like, we have benchmarks for that, it's 8,000 gas overhead in the current limitation, might be even tighter, but it is still an overhead.

Kirill Pimenov:And, like, yeah, the last one is the local adoption, and this is why we are on this call, and we really want any feedback which would make that adoption easier.

Kirill Pimenov:And to prove that it's not just, like, a figment of aligned imagination, I would like to give, like.

Kirill Pimenov:driver's seat to Nail, who did the most of the actual work, and I just, like, was, you know, running around during this, and Nael will show us, hopefully, the full cycle of adapt

Kirill Pimenov:sending its metadata to the hardware wallet through the, like, wallet adapter, and then we sign and we send it back on-chain. We use a simulated Uniswap, I think, for that demo, if we are ready with that.

Kirill Pimenov:And, like, that is it. Yeah.

Kirill Pimenov:Maybe we can see you, but not hear you. Okay. Awesome, thank you.

Nail:Unknown.

Nail:My name is Ned.

Nail:I'm from, compel. We're working on Kalakstanine architecture, and I would like to demonstrate to you

Nail:how it may work. This app is based on a scaffold, Oath?

Nail:I… edit the… installation to contact with the career call support, and I'd like to…

Nail:Demonstrate at first how it may work even in your browser, or

Nail:Hot waters, because, actually, there's no…

Nail:restrictions, if it's hardware wallet or mobile wallet.

Nail:On your signals?

Nail:So we just… it's installed version 2.

Nail:We… let's do a swap.

Nail:Right now, we just show this notification, because it's our key is stored in browser. We can see one loading

Nail:It just, oh, we're…

Nail:requirements… requirements that we want to do, because we don't want dab to hide that…

Nail:some value was set in a theorem value of transactions, so… If it's there.

Nail:If it's zero, then… we don't show this. And here we can… we can see…

Nail:It feels kind of in the same way as, 7732?

Nail:Have a little less.

Nail:Yep.

Nail:So, it's… it demonstrates that it's possible to work Is this it?

Nail:it… in Brause, implemented,

Nail:REST library, and ported it to browser, to Android, and hardware wallet. And next,

Nail:I would like to show you a demonstration of

Nail:Android, will it connect it with our compiler? How do I want it?

Nail:Please.

Nail:I need… I need to… One time, to SH camera.

Nail:Here?

Nail:Excuse me?

Nail:Let's see…

Nail:Android device, this is the same dub?

Nail:the defend the… And… desktop.

Nail:I… before… before I… I had my wallet, Android with…

Nail:what it can be done, and I'd like to send it, introduction?

Nail:Now we can see that the transaction is passed and displayed on mobile mode, the same way

Nail:Yes, it… in browser. Right now, it uses special native use, so it's not text-based, and this time and states how this library

Nail:Can be integrated into native.

Nail:Mobile… wallets.

Nail:With native views.

Nail:Now, we click Confirm.

Nail:And send it to Compeller.

Nail:Let's try one more time, because sometimes NFC… Does intercept.

Nail:Let's see the new C brickets.

Nail:Yeah.

Nail:Let's see what we have on Compella.

Nail:basically, it shows… it shows, transaction information, so for F tokens, and all the data that is so…

Nail:On mobile, and… this scope.

Nail:I don't need to send, actually what…

Nail:To compare it one more time, because I disconnected it, and you see, and… But…

Kirill Pimenov:I want to highlight that there is no

Kirill Pimenov:custom parsing transaction code on the Campella, apart from implementing this RFC. So everything we see about, like, which tokens get sent to which addresses, this call sends wheel, ETH, and so on, those are all part of the spec. They are not hard-coded pre-existing knowledge.

Nail:Let's click Approve.

Nail:Mount Cho se… transaction encoded.

Nail:Well, that's good.

Nail:Yeah, and, has action sent?

Nail:Op, and reduction sent.

Nail:And billing's updated, you can see, almost.

Nail:0.7.

Nail:Yeah, so I wanted to… I will say, basically, our approach works well on the web, on mobile, and on…

Nail:hardware orders, so… Yeah.

Nail:Everyone can benefit from this architecture.

Nail:Thank you.

Kirill Pimenov:Yeah, thank you. Like, just to reiterate about, like, how this is, like, a full cycle, if you are a developer of the wallet.

Kirill Pimenov:you implement the display format parser. Like, maybe you base it on the 7730 work, maybe you do that, like, aside of it, but…

Kirill Pimenov:schema is published, like, Rust reference implementation exists, you just do something like that. And you start with, like.

Kirill Pimenov:well-known token lists extended to the well-known contract lists, and you get all those features, like those token IDs in the signing pop-up on the Nain's mobile phone. It wasn't hard-coded, it is just, like, in a list of the well-known tokens with their identities.

Kirill Pimenov:If you adopt dev, like, well, you start attaching

Kirill Pimenov:display, like, array to the same transaction call to the wallet when you talk to the Ethereum wallet.

Kirill Pimenov:For legacy contracts, that will be informational, but, like, if you are a new contract, like, do the clear call.

Kirill Pimenov:If you're a smart contract dev, do a clear call if you have existing contracts, then, like, work on getting that to the contract lists, and, like, somehow publishing your hash for display, and, like, the

Kirill Pimenov:full contents.

Kirill Pimenov:And for the ecosystem, like, yeah, I wish that would be, like, more work on figuring out how we control those registries.

Kirill Pimenov:And, like, how can we transition from, oh, that's something on Git to something… oh, that's something on-chain we can then leverage on the next stage of this plan, where we can do the smart accounts, wrapping the actual, like, calls in a clear call

Kirill Pimenov:Addendums, or having those, like, flashboard task approaches, where even the externally owned accounts can benefit from this.

Kirill Pimenov:Without relying on, just…

Kirill Pimenov:known parties, and instead of that, meeting to the hashes on chain. So, yeah, I want every feedback we can get.

Kirill Pimenov:From the ecosystem. I want that to be ergonomical, I want that to be useful, and I want Slovakia to

Kirill Pimenov:start…

Kirill Pimenov:moving in the direction where we have a very clear representation for our users what they sign, because, yeah, I'm really not happy with the situation we are in right now. Like, everyone is learning how to sign those hashes, and in the light of every, like.

Kirill Pimenov:livid user who is doing more than just sending USDC once in a while. That's a fact of their reality. They cannot fully trust their hardware wallet screens.

Sam:Awesome. Thank you so much for, coming out and presenting.

Sam:Again, in the interest of time, I think we'll move ahead to the next point, and we'll do asynchronous questions on the Discord server or the Ethereum Wallet Nexus Telegram.

Sam:Yeah, and with that, I'll hand it over to the last point, which is universal enshrined encrypted Mempools.

Loring:Hi, everyone. My name's Loring, I'm from BrainBot, one of the core contributors to Shudder, which recently proposed EIP A105 as a potential Hegota headliner, and my colleague, Yannick.

Loring:We'll be going into some technical details about 8105, and then we would love to get feedback from all of the wallet developers.

Jannik Luhn:Yeah, thank you, Loring, and hello from my side as well. My name is Yannick,

Jannik Luhn:So, with EIP8105, what we want to do is add an encrypted mempool to Ethereum, with the goal of protecting users from front-running and sandwiching attacks, even if they use the public mempool.

Jannik Luhn:Which we think is very valuable, because, users will not have to rely on private inputs anymore, or trusted builders.

Jannik Luhn:For the security of their transactions, which is good for the protocol, in terms of decentralization and neutrality and censorship resistance and,

Jannik Luhn:Or these properties.

Jannik Luhn:How it works on a high level is that we add a new role to the protocol called a key provider, and their job is, on the one hand, to provide encryption keys to users so that they can use those to encrypt their transactions with them.

Jannik Luhn:And, on the other hand, provide, when needed, the corresponding decryption keys to the protocol, so that the protocol can then decrypt and execute those transactions.

Jannik Luhn:Encrypted transactions will consist of two parts. First, the encrypted payload, that is the actual transaction that the user wants to be executed, wants to have executed, and then around that, this is wrapped in an envelope, which is plain text and handles the gas payment.

Jannik Luhn:And they get executed in two steps. First, in the block in which the encrypted transaction is included.

Jannik Luhn:this, the encrypted, the plain text pipe will be executed, so the gas payment, and in a way, this schedules then the decrypted transactions to be executed in the next block. Basically, when a key provider sees the executed envelope, they will then provide the,

Jannik Luhn:Decryption key between the two blocks, and in the next block, we can decrypt and execute.

Jannik Luhn:This is basically it. From a wallet point of view, I think, what has to be done is, first of all, they need to, or you guys need to enable users to choose one of these key providers, or choose for them. I think that should be very similar to how a RPC provider is chosen today.

Jannik Luhn:Then they need to encrypt the transaction, which is something that will be dependent on the, on the key provider, that might be,

Jannik Luhn:So there might be some SDK that the key provider provides, or an API, maybe, but it's not specified in the protocol.

Jannik Luhn:then the wallet has to do the… this two-step signing process, basically encrypt, or sign, encrypt, and sign again the envelope, and then when you send the transaction, you have to watch for basically two events. One, the transaction being included, and the gas payment being handled, and then in the next block, the actual execution.

Jannik Luhn:Yeah, I think that's mostly it.

Jannik Luhn:Lauren, you want to say a bit more?

Loring:I think that's a great introduction,

Loring:We have been speaking with the client teams about how to implement this and been getting wonderful feedback. We also recognize that EIP 8105, once implemented, would impact wallets in a range of different ways.

Loring:From, potentially changing revenue models, to…

Loring:new UX flows, as Yannick mentioned, and so we are excited to make as many connections as possible with different wallets, collect your feedback, your suggestions for improvement, your questions, so that we can incorporate that

Loring:into the EIP itself, and make sure that once it is implemented, that it is something which wallets will embrace and,

Loring:actively support.

Loring:maybe… yeah, I'll leave it there, and if there are questions, and we have time, we can do it on the call, or please reach out to me in the Discord or on Telegram. I'd love to chat with you one-on-one.

Sam:Awesome, thank you so much for taking the time to come out and talk about your EIP.

Sam:I guess, we have 9 minutes left. If anybody wants to chat about anything, feel free. Otherwise, we can end it here.

Sam:Great. Well, let's call it here. I'll upload the recording to the Discord server, and

Sam:If anybody has anything to talk about, let me know, and we'll schedule a meeting for next month.

Sam:Take care, everyone.

Mercy Boma Naps-Nkari:Bye.

Chat Logs

Sam:https://eips.ethereum.org/EIPS/eip-7730

lcastillo:https://github.com/ethereum/ERCs/blob/master/assets/erc-7730/example-main.json

Sam:How are params names assigned? Would something like "erc7730:tokenPath" be a valid name? How about format? Would an ordered array be better than a single string, where the wallet picks the first format it recognizes?

patrick:A question of mine for later… feel free to ignore for now. So ABIs aren’t enough because why? I don’t fully understand the logic there. Is it because we have to be sure the ABI is correct? Using your proposed solution is mainly just saying “this is the correct ABI for X contract, and here is how you read the parameters”… yes? Like if a malicious token had a “transfer(address to, uint256 amount)”, but it actually removed tokens from the address to , your solution would have those developers would just update the intent field of the json. Do I have that right? I think I talked myself into remembering why this proposal is good. But the “ABIs can’t be trusted” feels a little weak, just more like “ABIs are hard to read” feels more correct no?

Hester Bruikman:Thanks for presenting this work Laurent!

Mercy Boma Naps-Nkari:https://github.com/ethereum/execution-apis/pull/704

lcastillo:@Sam params are assigned in the function name itself, which is in the form of a human readable ABI, which makes parameters names unambiguous. A parameter path like "#.tokenPath" would be valid if tokanPath appears as a parameter name in the human readbale ABI

lcastillo:For formats we never really found a use case in which multiple formats would make sense for a single parameter, but if we ever see this case it would be a possible addition

Sam:Replying to "@Sam params are a..." I'll continue on the discussion thread

lcastillo:@patrick indeed the issue to solve is more ABI is insufficient to represent the data to the user, more than untrusted. In fact 7730 itself doesn't solve the trust issue, a rogue contract could easily misrepresent its parameters. Which is why the governance topic with a way to audit 7730 files vs contract implementation is super important for us

Nicolas Consigny:Is there a link for both the proposal and for the hardware device presented ? This is https://gist.github.com/nailkhaf/d81c73327fefdb76fdad847035ddbc82#file-architecture-overview-md right ?

Kirill Pimenov:We've just made the whole repo public: https://github.com/Kalapaja/clear-signing

Kirill Pimenov:Gist above is correct, but is more of a "one-pager"

Nicolas Consigny:Nice demo, congrats !

Hester Bruikman:Impressive live demo

Sam:+1

Loring:EIP-8105 (Universal Enshrined Encrypted Mempool) https://eips.ethereum.org/EIPS/eip-8105

Mercy Boma Naps-Nkari:👋 We've opened an EthMagicians thread on repo & endpoint-level versioning for the JSON-RPC API. If you build on or interact with the API, we'd love your input before we finalize v1 check it out and share your thoughts! https://ethereum-magicians.org/t/repo-endpoint-level-versioning-for-the-json-rpc-api-seeking-community/27765?u=bomanaps thank you

Loring:I’m at @LoringHarkness on Telegram

lcastillo:Thanks everyone!

Hester Bruikman:Thanks all!

Loring:Thank you all!

Nail:Thanks!

patrick:Thanks all

Summary

13 highlights · 3 action itemsExperimental

erc7730 structured data signing

ERC-7730 draft V2 ready for public review; JSON metadata enriches ABI for human-readable transaction display00:09:30
7730 file has three sections: context (contract binding), metadata (contract info), display (formatting rules)00:18:27
Registry governance under discussion; migrating from Ledger GitHub to Ethereum Foundation soon00:24:41
Audit/verification system for 7730 files needed to prevent malicious contract misrepresentation00:25:01

clear signing proposal

Kalapaja proposes on-chain clear signing with cryptographic commitment to display metadata00:32:10
Solution uses 'clear call' wrapper (~7-8k gas overhead) validating display hash on-chain00:36:30
Push-based semantics work without real-time dependencies; supports offline hardware wallets00:38:50
Composable design enables multi-sig wrappers without additional hardware wallet integration00:42:16
Live demo shown: dApp→mobile wallet→hardware device via NFC with native view rendering00:43:30

rpc versioning

RPC team exploring endpoint-level versioning; seeking wallet feedback on backward compatibility requirements00:27:54

encrypted mempool

EIP-8105 proposed as Hegotá headliner: encrypted mempool to prevent front-running via key providers00:54:05
Two-step execution: gas payment in block N, decryption and execution in N+100:55:26
Wallet changes needed: key provider selection, encryption flow, double signing, two-block confirmation tracking00:56:06

Action Items

Wallet developers: Provide feedback on ERC-7730 draft V2 in discussion thread or Nexus group00:26:46
Wallet developers and RPC consumers: Review RPC versioning PRs and provide feedback on backward compatibility pain points00:29:49
Wallet developers: Review EIP-8105 and provide wallet integration feedback to Shutter team00:57:05