ERC-8095 bringing trust in DEFI contract addresses

EthCC[9] · 30 Mar 2026 · 21:44

José Luu presents ERC-8095 as an administered on-chain whitelist of DeFi contract addresses. The presentation examines authority-led vetting as a way to help users authenticate the contracts they interact with.

Speakers

Topics

From EthCC[9], hosted by Ethereum France.

Transcript

1 2 Okay. Hi everyone. >> [snorts] >> I'm glad to be here with you to present the ERC 1895. Um How did this ERC came to life? It was It's a result of a hackathon uh which was organized by Banque de France. Uh the purpose of the hackathon was to uh uh protect users against uh scams with uh smart contracts.

Uh Most likely, I think they were envisioned a >> [snorts] >> to be some sort of a uh do your own research uh with AI or some algorithm, something like that. We did things We did it differently. And uh we won the hackathon. So, we were a team of uh a few people from uh Banque Populaire Caisse d'Epargne. And uh what happened is that 6 months later uh Banque de France told us, "Ah, okay. Your ID uh your ID was good and we've used it uh on our experimental blockchain uh internally to keep track of the smart

contract." Um because author authors of the smart contract would disappear. Uh the purpose of the smart contract documentation were dissociated with the address and all all sorts of thing and there was a proliferation of smart contract everywhere in their internal blockchain. Uh so, that solved their problem. And so, we we teamed together with uh Banque de France to elaborate this uh ERC uh for the the greater purpose of uh our ecosystem.

Uh so, what happened >> [snorts] >> when you want to to deal with uh when you want to do uh DeFi, you you want to deal with something on the blockchain, you you want to transact with the smart contract of the blockchain, well, the usual answer is uh okay, uh over there do your own research. Uh And that means, "Okay, we do your own research." What What is this address I'm sending money to? So, that's that's uh that's our purpose. Okay? And through through a mechanism which is uh the purpose of ERC uh

1895 uh we're going to uh somehow somehow exhibit uh the good contracts, the good addresses. Um Um Therefore, users would be uh would be able to trust those addresses. So, how does that work? Sorry. Okay. Uh the ERC uh 1895 is issued by some trusted authorities or uh supervisor or uh

some somebody uh users can trust. Okay? They So, they deploy the smart contract and then they have to have a vetting process to register uh actors of the ecosystems. Those actors would then uh uh deploy smart contract and register them in the 1895 smart contract. Okay? So, it is a an on-chain directory of smart contracts.

Okay? Um Once an actor is registered it can itself manages manage what we've called a a reference. A reference is not only an address, but it's also uh a pointer to a URI >> [snorts] >> uh that is describing uh what this contract is doing and uh uh describing the status of the contract uh whether it's active or it's been uh canceled or it's been replaced by something else.

Um So um so, once a an actor is registered he manages himself uh his references. Okay, so, it's a it's a distributed mechanism. So, how does How does that work as seen from the user? >> [snorts] >> As you know, when you're uh doing some transaction, you you want to do some uh uh uh DeFi uh submitting your money to DeFi or you want to

to buy an NFT or something you deal with the UI of the supplier. Okay? >> [snorts] >> Um The UI after after you have uh uh told the UI all the terms of the transaction of the transaction is going to make the transaction and submit it to your wallet. Okay? Um Then with the ERC 1895 the wallet queries all the directories it knows about and look for this address. Okay?

Uh so, it iterates through all the ERC 1895 it knows. And if the address is found uh it tells the user, "Okay, it's verified." Otherwise, say, "Okay, I don't know this address." Okay? Um So, the trusted status then uh is shown to the user. The user then signs uh the transaction and the transaction goes on-chain.

Now um to illustrate to illustrate and try it out we've done a MetaMask integration. Uh The Met- We've done a MetaMask add-on. They they called it snap. A snap is a MetaMask add-on. And uh within MetaMask, there are a number of hooks. Uh You can tell MetaMask to call you call the snap uh when something happens within MetaMask.

So, we've hooked the uh before signing hook. Okay? So, before signing uh our snap is called and our snap through another uh blockchain connection verifies all the uh ERC 1895 it knows and looks if the address uh the transaction is going to is known.

Okay? When it's not known uh we have some red red sign showing the user "Okay it's uh it's unknown." And if it's found then there is a green mark and it it tells you, "Okay this um this uh address has been found in such uh directory and is the responsibility of such uh actor which I've called uh referent on the on the slide before. And uh there are uh live URL links where you can click

and check um the deployer of of the um 1895 smart contract or the deployer of the smart contract you're going to interact with. Okay? Which is a registrant. So, that's that's how it works. Um The deployers they they are uh recognized They should be recognized authorities.

They could be big actors. So, who are you going to to trust? Big actors like maybe Coinbase or you know, big platforms. You may trust uh you may trust OpenSea, for instance. You may trust big names. Uh of course, uh you may trust your bank if your bank is one of the uh actor and uh has organized uh to deploy such a smart contract. And also, you may trust your country regulator. Okay, in France is the it is the ACPR.

It delivers the Mika license. Currently, the Mika license licenses they are registered on the website of the ACPR, but it's not on chain. And and you don't know you have the name of the companies, but you don't know which smart contract they are responsible of on the blockchain. Okay? So, this solves this disconnection between the two worlds, between the regulation that exposes only on web and the blockchain.

So, there is still a a loophole because someone can can deploy an ERC 1895 on the blockchain and claim a claim it's a it's a genuine one. Okay? Also we it's a little bit like well How we see the future, how we see the evolution of this.

It's a little bit like you know, when you deploy a web browser on your workstation it comes preloaded with the root certificates. So, we expect that smart extension of of wallets come with pre preassigned addresses of the the such a a 1895 smart contracts. Okay? Very similar.

Okay, the loophole now. And and how we do we close the loophole? Uh every 1895 smart contract has a um a get contract URI. So, that means the URI of the smart contract itself points to the website of the supervisory advisor entity which has deployed the smart contract. And in turn, there is metadata on the web page which points back to the address. This is how you can check the

authenticity of the smart contract. And we request that actors who have deployed their own contract do the same. This way at each level, you can verify the authenticity. And this is it. I will take question if there are things unclear, but if you have comments or criticisms or whatever please give them in writing to this address which goes to the comment page on the Ethereum Magicians

which I will answer and that will help the this standard progress and become known. There is also a reference implementation which is very small. So, we we have chosen to do a very minimal standard you know, like the ERC 20s that there are a few only a few calls it we have in the standard there is a there is a paragraph with options security options and so we've

it can be expanded to whatever functionality you you need. And one of the one of the capability we envision is that as I said the reference that is a smart contract address they have a status means alive or cancelled. And one of the options would be to historize that is to get an audit trail of the status change.

So, that one can look at the current status and see when it has changed. But there there are many and it's up to to whoever needs to implement. Okay. No questions if you have. One question. Thank you. I have a question and who will be like the trusted verifiers for this whitelist? Like who will like make sure these public addresses are like trustworthy or you know, whitelisted. Okay. So, this is really a supervisor duty.

And the supervisor would be So, we I was thinking about the regulatory authorities. The regulatory authorities they have a vetting process which is documented and very strict. If you've tried to apply to for a Mika license and you you know that it's a very thorough and you're you're inspected all your information system, all your processes, your compliance is inspected. Of course, the the vetting process is part of the trust you can give to the whole thing. And the vetting process

has to be defined on the supervisor website for instance. So, how do I how do I vet the registrants? And that's that's as important as being a big name. As you as you said about supervisor, right? So, isn't it kind of a centralized system? Like moving away from decentralization because not everyone can like basically know see okay, is this verify is this secure or not?

Smart contracts like isn't this kind of a centralized this approach? Okay, it's it is semi-centralized. Okay? There can be many such contracts as many as people who feel empowered to organize their own ecosystem. Okay? Once you are a registrant once you are a registrant in the smart contract you manage yourself your references.

That is the supervi the supervisor is not going to you don't have to go through the supervisor. In in that way, it is decentralized. That is once once you are in okay, you manage your own smart contract. And it's the supervisor is supposedly trusting you because it's for your customers. Okay? Another And what about some contacts like vet contract which is not you know, like which is not belongs to any protocol like Uniswap or anything?

No the the addresses they are they don't be they they could point to also to EOA addresses. Okay, external external owned addresses. For instance, it could be a a remittance address for a for an exchange. Okay? That is if you or or a payment address to some bank or whatever. Okay? So, it's not tied to any protocol. It's just addresses.

One question in front. And today do you have like big registrants like Aave, Uniswap that have built this reference? Cuz I see a lot of use cases that could help the industry. >> right now we have we have no one. >> [laughter] >> So, so this this standard is to be promoted and used by whoever needs it or wants it. Is there anything in your standard relating to having proxy addresses?

Like can you point to a proxy address and do you see any sort of issues with just having like >> I don't see any issue on that. Okay, you you have to if it's a proxy and you the intent is to to be able to change code, okay. Uh we have we have envisioned a a version number on the reference. So for your users, you can increment the version number.

All right, thank you. Um hello. I know BPCE is a banking group. Yes. Um do you look forward to integrating this into your your own banking infrastructure? How do you monet- mon- monetize this product? Uh so right right now it's not integrated. It it it could be. But uh it's uh they're busy doing uh other things, but it could well be.

>> [laughter] >> Okay, who are your target who are your target clients then? Sorry? Who are your target clients? How do you monetize >> They're Well, they're they're not client. It's uh you know, the target uh users uh we're targeting the supervising authorities, somebody well known and who has, as we said, a strong vetting process. Uh so that people uh users trust the whole thing. I'm good.

Okay. >> [applause] >> Well, well, well.