# Goodbye YOLO Signing | Kaan Uzdogan (Berlin Ethereum Day, June 2026)

- Speakers: [Kaan Uzdogan](https://streameth.org/speakers/kaan-uzdogan)
- Channel: [Berlin Ethereum Meetup](https://streameth.org/berlin-ethereum-meetup)
- Date: 2026-09-09
- Duration: 21:18
- Watch: https://streameth.org/watch/yt-hM4dKuoDJAY
- YouTube: https://www.youtube.com/watch?v=hM4dKuoDJAY

## Description

Blind signing has long been one of Ethereum’s biggest UX and security problems, without an open solution that could address it at the ecosystem level. With ERC-7730 and the new Clear Signing Working Group, that is finally changing. This talk by Kaan Uzdogan (Sourcify & Argot Collective) explained the blind signing problem, the ideas behind ERC-7730 and its registry setup, and showcased Sourcify’s clear signing SDK, which makes it easier for wallets and apps to add human-readable transactions.

The Berlin Ethereum Day was a one-day event held on June 15, 2026, during the Berlin Blockchain Week, bringing together speakers from the Ethereum Foundation and the broader FOSS, privacy, and security ecosystems to explore the future of Ethereum and self-sovereign technologies - from technical direction and core values to the challenges and opportunities ahead.

Future Meetups and Events: https://www.meetup.com/berlin-ethereum-meetup/

More information on the speakers and the agenda: https://berlinethereumday.com/

## Transcript

My name's Khan. I'm working at Sourceify, which is an Argo Collective project my colleague Jacob talked about. If you don't know, check out Argo at argo.org or watch his talk two talks before three talks before me. But, without further ado, I want to dive into a topic that is quite dear to my heart because this has been a topic that I guess everyone's aware of and everyone has been hurt by this. And we we at Sourceify started working on this quite early four five years ago. Um Sourceify, if you don't know, is a source code verification project. Uh it started within the EF as a Solidity side project and now spun out into Argo with Solidity. We are a non-profit collective. Uh we don't generate any revenue. Uh we run on grants and the team Sourceify team consists of three people. It's me, Manuel, and Marco. And as I said, this topic has been a something we've been thinking about for a long time. Like this is a talk before I joined Sourceify actually from Franci, if you know her. And it has the same title, good boy goodbye YOLO signing. Uh and I also gave this talk four years ago at Devcon to how how to bring human readable transactions. Um but unfortunately, we weren't able to solve it ourselves and we just decided to focus on what we can do best and it was about source code verification, making the source code verification open source, and opening up the data in general. And my talk at the time started as this. So, I the first three four slides will be the same ones that I gave them. So, it's a full circle throwback. So, this is just a normal day in Web3 and we are all seeing these screens uh in our data lives, unfortunately. And this basically is nonsense. Like, you don't know what's going on. You have no idea. Am I doing the right thing? What am I signing up for? What am I What am I giving my money to? And this is basically just saying, "Just shut up and take my money." Like, I have no idea what you're doing. Just take it. And I don't care. And unfortunately, 4 or 5 years later, things haven't been changed yet. And at the end of the day, what we want to see is something on the akin to something on the right, instead of something on the left, which has a lot of ones and zeros that is readable for a machine, into something that is readable for a human, so that you can make sense of it what you're actually signing. And as I said at the time, the problem of blind signing was a huge beast, and we couldn't solve the huge thing ourselves. And we focused on what we do the best. But, things have changed, and things have improved, and the I think we are seeing the light at the end of the tunnel now. It's happens through the clear signing working group that has been recently announced. Um it's been I guess a couple weeks since we announced this. We've been working behind the scenes with different stakeholders, um and recently announced the website, clearsigning.org, about the progress we made and how we can solve this problem. Yeah, as I said, the working group is based on uh an EIP or ERC-7730. This was originally authored by the Ledger team, um and it's a quite comprehensive uh descriptor description of how to do this. And as of now, as of the announcement, the working group was consisting of these critical mass of stakeholders. I say critical mass of stakeholders because as I said at the time ourselves alone were not able to do this, but right now I think we have enough momentum and enough people contributing for this to be a ecosystem-wide solution. So, we have Ledger, Trezor, MetaMask, WalletConnect, Token Ox, Securin, Fireblocks, imToken, Sorcery, as well as Ethereum Foundation's trillion-dollar security team helping steward the whole working group. And the QR code is hosting the registry of descriptors right now. You can check it out. And also shortly on the EIP, it is a it is the 7730 and this can be you can read the IP over here. It's Yeah, it's quite descriptive. But again, why why are we going with this solution? And there's a whole story of other ways to solve blind signing. Um why they wouldn't work, why didn't they did not work, but for me why the ERC-77 works is uh because it's an open standard and it's based on an open registry. And it has enough capability that is enough limited, let's say, because we don't want to have a complete Turing com- Turing complete solution that can be too powerful, that would be also vulnerable. This is more about getting the call data, de- telling the machine how to decode it and showing that. And in the essence, the the the ERC enriches the contract calls with user intent. So, because you have a contract, right? You have the source code and we have the ABI that tells how to interact with this contract. And this descriptor is is a JSON descriptor that comes on top of the whole metadata that we have. As I said, it's an open standard and it's on an open registry that can can can anyone can fork or anyone can open a PR right now. But in the future, we also want this registry to be on chain. And it's it will be based on attestations by auditors. So, once you upload a descriptor, people different stakeholders can review it and say, "Okay, like this is a legit descriptor for for this contract." And the attestations can be weighed can be made through Ethereum attestation service and with off-chain attestations and on-chain revocations. And there's a separate EIP for this. Um yeah, again to why it works, because it's off-chain, it means backwards compatible. So, if we have a solution that's work on-chain, that's for example, if you have a let new language on embedded inside Solidity, that means only the future contracts will be affected, right? So, we need to have something that works backwards compatible. That's why the off-chain part of the registry works. Um it is also expressive, as I said, and it's uh more expressive than ABI decoding and NATSpec. And it gives us special formatting for certain inputs, like you can define tokens, dates, and so on, and you can use the variables within the whole transaction to mention. So, for example, you can say, "I want to mention the two address." Or I want to mention the receiver function arguments. Or you can even define like arbitrary metadata. We will go over these in nice examples. And as I said, like it should not eval expressions, like it should not be a fully powerful um Turing complete uh framework so that we will have the security we have we we will have limited capabilities and also the the the the devices we are dealing with are quite limited, the hardware wallets. So, they are not fully capable machines as well. Um I'll go over an example from the clear signing registry here. This is the Ethereum clear signing registry. And here we have an Ave LPV3 contract. And in this example, the in the beginning of the whole spec, we have the schema mentioning. So, this this this defines how the JSON file is formatted, of course. And then we have the context section. This says, "Okay, what is the contract we're talking about and where are these deployed?" So, this Ave contract is deployed on these chains and on these addresses so that whenever the wallet is pulling up a transaction, it knows which contracts to which contracts we're talking about. And if I can zoom out, a little too much. And then in the metadata section, we have some info about the contract, like who is the owner, some enums that we will mention and the contract name. And I will use this borrowing example to show how the whole thing end-to-end works. So, this is a borrow function and the call data of this function looks something like this. So, you have the function signature for the borrow function and then you have all these parameters that will correspond to each of them. That is quite non-human readable. And yeah, this is the function signature. First, we have an intent. So, we say, "Okay, like, what's the intent of the user?" And we are displaying the intent of the action. So, we say, "Okay, we want to borrow something." And then, next comes the fields. Um the next it will show that the amount to borrow is this much. And then we say, "Okay, like, where do we get this information?" Oh, sorry. What is the format of this amount? And we have declared some certain formats. For example, a token amount, a date. And we say, "Okay, like, the the value you see here, you have to read it as a token." And then, yeah, the the the whole detail of how to format it is in the EIP. For example, the the token amount has a token path, a um chain ID, um and decimals. And so, for example, this would read the decimals from the token and also the symbol itself to show the readable token. So, instead of like 1,000, you can you'll see like um no, not 1,000, but 1 to the sixth. You'll see one die. And so on. So, this says, "Okay." And the path tells where to read this. And it says, "Okay, like, read the amount variable from this function to show the token." And this is always visible. Um yeah, and then, sorry. I'm So, this is the amount. And then, this is the asset. So, this is the contract address that we are dealing with. So, for example, this might be the die die contract address or USDT contract address. And then, we have the interest rate mode uh variable in Aave. And this is a for example, an enum because this can be like zero, one, or 2. Uh and we already defined this in the metadata section. Um I've shown before here. Yeah. We said, "Okay, like if it's zero, it's a non no interest rate mode. One is a duplicated mode, and the second is the variable interest mode. So, in our case, this is a variable interest mode. And then this is what we define here. And finally, the this is the debtor. So, like we say, "Okay, um the label is debtor, so the who is the debtor question? And this time, this is an address name, which means the the value you are dealing with is an address, just for you to know. And we say, "Okay, like for and for this address name, you can assume this is an EOA. And to read this address, you can use your local address book, and you can use ENS, so that you can reverse uh you can use a reverse registry of ENS to show a human readable name. And uh yeah. And in practice, you would have seen something like this before, and with the clear signing, it will look like this. So, you'll say, "Okay, you're interacting with the pool instance. The intent is to borrow this amount of USDT with the variable interest rate, and the debtor is this address ice-win.eth. And then some contract information. So, it's a big info it's a much better relieving way to look at things. Um [snorts] in addition, there are different formats such as uh a call data format that says, "Okay, like the the this might be a nested call, and you have to um you have to decode the calls inside the call, for example. Or in addition, we have the interpolated intent that will give you a full sentence, full string that will say, for instance, subscribe with this much for at least this much minimum received. So, there are other ways to show the human-readable human-readable representation as well. And yeah, this was just an example, and this was an example I got from the clear signing playground we built at Sourceify. So, you can head out, read this QR code, and head out, and check out the examples yourselves. Um the the clear signing playground itself uses the SDK we are building. It's under Sourceify it clear signing, and this is a TypeScript SDK uh aimed for wallets or any applications that want to one-shot integrate this very easily. So, in the end, how it will work is uh you will npm install the package, then you'll just in the format function, you will just provide, okay, like the chain ID and address of the contract. So, imagine like this is your this is inside your wallet code, and once the user pulls up the transaction, you pass which contract it is, and then this would be the call data, and then some other uh options about the format, and this will give you the intent. The fields will be, yeah, each of them label, spender, to value, and also the interpolated intent. So, it's quite easy. Um this is not only for transactions, this is also for um EIP-712 type data messages. The descriptors also cover that. So, I only showed the descriptor for transaction, but there are also descriptors for 712 712 messages. It also supports the library supports also the batch calls right now, um, EIP 5792 batch calls. Um, there is also another library built by Bartek, um, in Rust that also is compatible with Swift and Kotlin, especially for the mobile devices, uh, so that we also have multiple implementations and we can cross-check and uh, use this in all all of our tests. But, this this library mainly is for mobile devices or any Rust or WebAssembly, um, devices, whereas the one we're building is mostly TypeScript. And, yeah, like what besides the SDK for the clear signing, what we do at Sourcify is we do source code verification. Source code verification is the thing you see when you open a contract on an explorer and you see the green check mark, you can read the code, right? We do the same thing, but more open source in a decentralized way. Decentralized in the sense that you can download the whole data set. We believe the data set should be quite accessible and open to everyone. Right now, it's not the case. And, we have over 250 EVM chains. We can support all EVM chains with right now 21 million 31 million contracts. And, yeah, the data set sizes are compressed and uncompressed are like this. We also are, um, empowering behind the scenes the four-byte database, the big largest four-byte database used by most of the tools. We took over openchain.xyz, if you're familiar with that. Um we also pulled up from different four-byte databases to build the largest function signature database. So, the function signatures, if you're unfamiliar with the look looking like this. Um and our verified contracts also keep uh adding adding into this database. We also have an API to verify contracts um to read contracts. For example, if you are using a um if you're building a block explorer, you can use this to fill up the data. If you need ABIs, you can pull them from here. You can also verify on um on Hardhat very easily. Uh by default, it verifies on all verifiers, or you can choose to verify on Sourcify only. And it also is compatible with Foundry. You can verify after deploying, you can verify with this flag. Or you can verify an existing contract with these flags. Um but yeah, um in general, the clear signing itself is already here, so it's already implemented and live on multiple wallets. It's just went live on Ambire. It's already live on Ledger. Uh it's live on WalletConnect. So, it's not just an experiment. It's already on production and it's working. And we are hoping to include more wallets in this picture in in the close time. And this comes with challenges, of course. Um I would say the main bottleneck we're facing right now is the descriptor audits. So, when for each descriptor, we this needs to be like human reviewed one by one because yeah, we need to make sure it's something that works well. Um it might also get some applied added supply chain risk because we are adding up another level on top of the transactions. Um but the adoption is I think so what I how I see is in general like these are technical problems and we can solve the technical problems but the bigger problems are always social and coordination problems. And the bigger problem is getting projects to write these descriptors and wallets to use it. So, we need everyone to help out here. Um and just a note on how the future might be is that how I see the future of these descriptors is that you can you should be able to write similar to Notspec, you should be able to write the descriptor inside the contract in a comment that will give out this descriptor and this will show it on your wallets. So, I like calling this Notspec++. Um yeah, I can talk about this more if you catch me after the talk. But what should you do? What should you do? What's the call to action? If you are a wallet developer, if you have a block explorer, please integrate the clear signing either through the libraries we've built or if you prefer not uh depending on libraries, that's also not too difficult. Please uh just reach out if you need help. Um if you if you're an Ethereum application, please submit your descriptor to the registry uh so that so that your application can be clear signed as well. If you're a user, please demand it from your wallets. Uh please ask them uh to implement this and uh hopefully in the future we will not blindly accept okay, go with blind signing. We will say okay, like in the future in couple years we say do you want to do clear clear signing? You will be like, no, I I don't want to do this. And yeah, in general share the progress, spread the world spread the word and uh hopefully we can make the clear signing the standard. Um so, thank you. Uh you can check out You can follow Sourceify on the left side link and then check out Clear Signing and reach out to me. Yeah. Thank you. >> [applause]