SCI: Enhancing Web3 Security Through Smart Contract Verification

Transcript

[Music] Hello. Hello. Um, so hi. We're here today to talk about SEI, a protocol for safer smart contract interactions. I'm Austin Labaro. Uh, I'm I work at Mimik. We have a talk in like an hour. I encourage you to go to see it. But uh in my free time with some friends, we developed this protocol. But before talking about like the solution and what we build, uh maybe let's talk about the problem first. So compromised front ends

can redirect users to malicious smart contracts leading to wallet fund losses. Basically, this is a fancy way of saying that you interact with a compromised front end, a malicious front end. Uh you did everything correct. You enter the URL, you go to let's say curve unis swap, but because of they had been hacked due to DNS hijacking or maybe supply chain attack. Um, you interact with that smart contract that you weren't intended to, you sign a transaction that instead of swapping, you allow a drainer smart contract to uh get control of all your funds. Um, so a little bit of the size of the problem.

um $300 million uh dollars were lost in scams in two uh in 2023. Basically half of that were lost due to domain hijacking. So this problem that we're talking uh in 2024 300 millions were lost only across EVM chains and like four major uh crypto platforms were hacked. Uh so this is a real uh problem. uh most more recently curve was hacked uh due to this very problem. Uh their domain um was hacked and compromised. So when you interacted with curve instead of giving uh permission allowance to like the curve

smart contract, it was another smart contract that basically uh got control of all your funds. So let's talk a little bit now that we know it's like a real problem that user are facing. Uh let's talk a little bit about the solution. So we introduce a decentralized verification protocol where uh owners can decide which smart contracts are allowed to interact with their users. So how this looks basically when the wallet uh or plug-in or whatever you're building wants to send a a transaction it gets the domain and say okay it's this smart contract verified for this uh domain and you talk to our smart

contract that it's going to return true or false. You have a little bit of uh we build like a metamas uh snap and you can see how it works there. Basically, it says, "Hey, this contract is verified. You're interacting with Rocketpool uh in this chain in this chain uh basically Ethereum with this contract." And this was when the the smart contract was registry registered in in our protocol. In reality, it looks a little bit more like this. So basically we build like a a smart contract the SEI smart contract that it has some utils but you can interact directly with the protocol the registry and the verifier they are immutable contracts. Uh and basically what you do is you get the first you

look for in the registry. Okay, give me the verifier for this owner and then you look for uh like if it that smart contract in that chain is verified for that website and it's going to return basically true or false. Why we build it like that? This is a little bit more about like the registry and the verifier because uh having uh the verifier separate you can create custom logic because they are smart contracts. So it depends in each use case what you want to build. So I as a DAP owner if I have like a really complex use case maybe for example in unis swap you can verify like if that uh pool like that smart contract it comes from a unis swap pool and you

can look for it on chain. So basically how it work it's the registry as you can see here it has like the domain the owner and it a pointer to the verifier and then uh the verifier we build like the public list verifier that it's like an easy verifier where you just list okay all these contracts are allowed to interact with this uh domain uh but you can build also a custom verifier like in this example for other more more complex use cases. So how do we know who is the owner of a domain? How do we know that on chain? We build what we call registars. Basically registars are smart contracts that are

allowed in the registry. Uh and these registars they have logic on how to know who is the owner of a domain and we can build different um rules for this. Uh we build the ENS registister basically. I don't know if you know but you can like uh get uh an ENS of your domain. So if you are the owner of that domain ENS can check that over DNS over HTTP uh with some records and then it got it gives you like an an ENS. So we built an ENS register that checks if the wallet uh that wants to register the domain within our protocol in fact holds uh the ENS for that.

So basically this this is a look of our architecture because ENS it's on Ethereum but we don't want every time you register like um basically smart contracts in in our uh in your verifier in every public list verifier so we deploy them on optimism so it's cheaper um so basically we use the ENS registister on Ethereum that we built and deploy we use the cross domain messenger from the super chain to talk to our registry uh in optimism.

Um are there any other like solutions out there? Yes, there are. I believe that they are not really good. For example, this one it's if you want to stake 32 ETH that it's a lot of money uh in the deposit contract. They have like a popup saying like you can go to this and we can read you out loud like the the the address that you are going to send the funds to and you have to check in your like MetaMask or whatever thing you are using ledger if that like like digit by digit if that corresponds to the smart contract you are going to interact to. So it's a solution yes but I don't think it's has good UX

especially like you are sending 32 E or more um and then uh you can there's other solutions that maybe can use uh DNS txt record. So if you're a domain you can put like a list okay in my like uh DNS in the tx txt record these are all the contracts that are allowed to interact with my domain. You could do that and you can verify over DNS over HTTP. But there's some problems with this. One is that if they hijack your DNS, they can also change this list. So it's like uh you're not adding extra security with our solution because this is a like a smart contract that has a owner that

it's a wallet. they should they will have to hack like the DNS and your wallet to be able to um change our in our protocol the contracts and also this relies on a centralized service like Cloudflare or other centralized service that they do DNS over HTTP to get that information they can withhold that information they can even change it or they have can have the downtime because we are all onchain you can have your own RPC you don't have to trust us. Uh you can check everything with your own RPC if you want or infura or get a bunch of RPCs uh to get to consensus. So it's really flexible what you can do.

Um and a little bit of what is the user experience using like we build a metamas plug-in but it's uh you can do like a plug-in in chrome you can this can be added to wallets as a as another measure of uh safeguard so for example in this one meta mask again it's a little bit of the previous example you're staking uh with rocket pool uh you're going to send the transaction from this wallet to this deposit contract I don't know even like if this deposit contract is the one from RocketPool and I shouldn't know. Um so what we did with the plugin if you see there it says inside from SEI and it says if the contract is verified or not

so for stake.rocketpool.net that contract it's verified. So I know that I'm interacting with a contract that like the ones that build this wants me to interact and it's not like a malicious smart contract. So I click I see all the insights and I I can click confirm and it's going to be good. And for example with curve we tried it out when it was hacked and it worked. Uh basically um you enter the in the curve's uh UI and it say hey be careful this contract it's not allowed to interact with this domain. So you know that something is wrong and you can check maybe Twitter or whatever are your

sources. So this solution it's a little bit more proactive than being reactive. Like most solutions now it's like posting on Twitter, hey we got hacked and it's more reactive and you are hoping that the users find out before interacting with your domain. Uh with this you verify it beforehand and if you got hacked or something goes wrong you know that your users are safe uh using our uh solution. So yeah uh this is a public a public good uh we do it in the free time. We invite like developers auditors whoever wants to build this uh and continue building it or use it uh to talk to me and we hope to make crypto safer for

everyone. This is the team uh we're for. Um and yeah, thank you very much. If there's any question, any question or okay, if you want to talk also, I'm going to be outside. So, thank you. [Applause] [Music]