How Many People Can Rug You? Quantifying Trust in DeFi - Emilien Duc

EthPrague 2026 · 9 May 2026 · 18:30

Emilien Duc asks how many people, in practice, hold enough privileged access to a given DeFi protocol to rug its users, and proposes ways to quantify that concentration of trust. The talk frames rug-pull risk in DeFi as a measurable property of a protocol's access control rather than an unknowable unknown.

Speakers

Topics

From EthPrague 2026, hosted by ETHPrague.

Transcript

Hi everyone. My name is Amelia. I'm very happy to be here. And my talk today is about how many people can rug you. So, not in theory, but like right now with the stablecoins you supply in a DeFi protocol, the ETH you supply on Aave, if a group of humans wants to rug you and take your funds, how many people would it take and how many people would have to agree for that to happen? So, the truth is most people don't have a clue about that question, the answer to that question and for most DeFi protocol, and we're going to look at how we can answer it, why it is actually very hard to answer, and what we can do better

about that. So, that would be boring security talk if I don't talk about recent exploits. That's what people live for. So, 2026 so far has been a year of preventable losses. If we look at three headlines that are interesting recently, just last month, Drift protocol um 285 million loss for because of, you know, it was a huge social engineering hack, but at the end of the day there was access control issues. Um Kelvin that was a cross-chain protocol exploits and terrible security configuration, uh which was preventable.

And then the last one, I wanted three headlines, Wasabi protocol for 6 million, just another admin key that was compromised and then um they could upgrade the protocol, stole all stole all the funds. Um Syndicate is another one that was interesting. It was the key was in a password manager accessible by multiple people and that led to tremendous gain losses. Um the common case in all of those is that this isn't an on-chain smart contract exploit. This is off-chain elements that are preventable, that we can do better.

And um actually 75% of losses last year, according to Hacken, were due to counterparty risk. So, the those are things we can prevent. And most money in DeFi actually today relies on small admin sets of different protocols. So, we're going to look deeper into that. The thesis of this talk, if you want, is that on-chain finance is not DeFi. And decentralized is not binary. It can be measured. We need to measure it. And we need to stop calling DeFi every protocol that holds funds in a smart contract. This is not the case. We need to hold protocols to higher standards.

And for that, we need to measure what do they actually do and how do they protect user funds you from those off-chain uh operators and entities. Um So, let's look into it. Where does the trust hide? If you know DeFi Scan, um you know what starting today we're going to call V1 of DeFi Scan. Um this is um we used to look into five vectors of decentralization. So, I don't know if you can read pretty well, but brace yourself for like a roll back to the old branding for just two slides. Um this is the purple brand. Uh we had five criteria. Um the first one is upgradeability. So, can you upgrade the contracts? Can you change the security

parameters? Could that lead to user losing their funds? Um if you can do that, how much time do I have as a user to react and restore my funds? What's my ability to exit? What's the autonomy? So, does it rely on oracles, of chain entities, operators, cross-chain protocols, accessibility? Does it have multiple independent front ends and providers? If the front end is hijacked, can I still access my funds otherwise? Can I self-host? And then the chain, is the chain itself decentralized? So, we looked at the many different protocols. We looked at into that manually at a fixed point in time.

And um this is kind of the results we came up with. Turns out most of DeFi was not decentralized at all. Um and it is a bit of a problem because it's really easy in the name, decentralized finance. Um In particular, the one we got a lot of pushback for is Aave. It was impossible a year ago for people to think that Aave is still zero. And um well, debatably today that might not be the same pushback. Um but even though it was an unpopular opinion, um the true issue that we ran into is that we looked into that extensively, manually, and we did a lot of research.

So, what we did is we looked at every single entry point and permissioned function in the protocol. We analyzed what could it do on the user funds, what could could it be used maliciously, and what is the impact. And that that is a huge amount of work to do manually. Aave, the Aave ecosystem is like 550 contracts. Uh so, you can imagine that takes weeks to just get a first review. Then you need to actually proofread, uh check if it's accurate, approve it, and then publish.

Um when we did that last year, um about a couple weeks after we published Aave report, they rolled out the umbrella module, which is a whole different risk framework and a whole different set of things that we should look into if we want to update that report. Same thing happened with Lido. They published a They rolled out the dual governance, which is an extremely complicated set of logic that changes the governance and allows users to exit with a better exit window. And in all fairness to them, if we were to update the report right now, as soon as the emergency multi-sig expires, they would probably be stage one.

Um But yeah, the truth of the matter is manual review didn't scale. We needed to do something better about that. Um AI alone isn't enough. AI alone alone is gets a vague idea of the decentralization of a protocol. It is not consistent. It is not It's not reproducible. Uh verifiable not really verifiable. And it hallucinates very well. If it reads in your smart contract code that this is safe, it's going to find every reason to believe it is safe and not actually look at the actions.

Um And that's an issue. Uh because a lot of the time the claims that are made in smart contract comments aren't that true. Um and then we looked into static analysis. We used to use it to detect permission functions and then analyze those manually. Um so what we thought is if we can use static analysis to have all the entry points to the protocol and then all the paths can lead to funds, we can answer those questions automatically. In practice, looking at compiled code static analysis, it gets it it can resolve with deterministically in about 50% of the time because compiled code alone isn't

enough. We need data on chain. Not everything is in the code. Sometimes calls are different. If it makes an external call, Um, it might be an address that you get uh live on chain. It It might be an address that changes every time. And that we we cannot just use static analysis alone. Um, so we needed something better. What we did, um, so to help us with that, we forked the best in the business in term of risk monitoring.

Uh, the gold standard for L2 risk monitoring, I think is that to beat. Uh, they're MIT licensed. Bartek is here. Um, so thank you for that. Um, DeFi, however, is very different from L2 monitoring. DeFi is very different in its own. Um, so L2 Beat alone cannot cover DeFi protocols. We We enhanced it with our knowledge of DeFi to try and make something that can uh be as thorough as possible. And I'm I'm going to walk you through it. Um, I want to give you a little sense of how it gets complicated very easily in DeFi.

This is a dummy example of a DeFi vault, basically. And you have that multi-sig two of three that has three functions to reach a vault. So it can upgrade the vault. That is straightforward. Okay, you can lose user funds if you upgrade the contract. It can set the oracle. And here it already gets a bit more complicated because you need to detect that's the oracle can be set by the admin. And that oracle is being read in the liquid function, which can impact user funds. Okay. And then it can set the loan's value in a separate contract that itself is being read by the vault. So you need to check that that admin controlled variable in a separate contract is being read by the

liquid function, which can impact the funds and impact user funds. Um, and then again, you have external contract to an oracle. The funds themselves don't live in the vault. The funds are allocated in DeFi. So that again, you cannot link easily to to admin rights. And then the funds are most likely USDC, which is a centralized stablecoin. Um So, it's not straightforward. So, this is the methodology. This is our no longer secret sauce. Um We use L2BEAT tools to gather as much data on different protocols as possible.

We discover the whole DeFi protocol ecosystem, all of the contracts, all of the admins, all of the dependencies. Um We use static analysis sliver to uh determine a possible call graph, um which, as I've said before, about 50% of that call graph is deterministic. And then we use probabilities to enhance it. So, using the live on-chain data, we make the best possible guess of resolving the edges that we detect and we're not sure about. Um So, this is still deterministic in it on its own. It's correct in about 95% of cases. For a small protocol, it's 100% correct. For

big protocol like Aave with 550 contracts, it's a bit less than 95%. But, it's still pretty good. What happens is after that, we use AI to we give AI all that context, so it knows all of it. It can no longer make mistake about um call graphs, and it we use it just for two small things. It's determining um if the function on its own impacts the underlying funds. So, the liquidated function does impact it impact them. Uh so, that we automatically classify it, and then we just verify by hand. Um and then we also just link the entry point um which is unknown at the in the static

analysis, with the actual permission owners, which are detected like exposed by L2BEAT discovery usually as well. So, we use AI does the final wiring. We check the results and most of it is actually done with tools that are verifiable and that are reproducible and public as well. So we put those tools together that leads to slightly different risk vectors that we redefine. For example, instead of talking about upgradeability, we want to talk about admin control. This is small you know, wording change. We talk about dependencies, everything that is read from the contract that is external to

the protocol and that can impact the funds. We can actually very quantify it live data on chain. We can say about admins, we can say which admins, which keys can impact which funds and how much, which is great and it's great data to have. Governance, same. The governance contract, how much funds can they impact? So if the governance capture, what are what are the what are the possible consequences? Front end is still something that we curate manually and code is the code is are the contracts verified? This is the only way we can actually analyze the protocol.

And are they audited? This is something we also curate like we scrape and detect automatically so that users can be informed. We also expose display the licenses, which is important for front ends as well so that it's reproducible and accessible. As I've said, everything you see is reproducible and open source. We cover right now we just started rolling out the protocol and we extend. The logic wants that as many protocol we add and the quicker we should be able to add them because the process gets uh better and better every time, but I'm not going to commit to that claim, but we cover about 81 billion of underlying

funds at the moment across 18 protocols. That's 1,150 smart contracts that we track. Um, you might be surprised to learn that this is 154 admins. Um, and uh looking at all the contract updates that have been on those contracts, it's 1,490 uh actual contract upgrades across those protocols. Uh which is huge. You might be surprised of how frequent like a DeFi protocol gets updated. Uh take Aave on its own, for example. Of they've been addressing the KELP DAO situation recently. So, okay, it's not always the case, but this week when we started monitoring Aave,

every single day we detected like a change in Aave that is security-related. Like a multi-sig signer being rotated, the umbrella admin being changed to like a multi-sig, which is huge. And uh that kind of things or like a change in an underlying protocol that is used that is used by Aave. So, as a user, we don't necessarily realize how our counterparty risk is a live situation even after we deploy the funds in a DeFi protocol, and we need to always be aware of that.

It is not 2,500 protocols, but it is one financial system. I think more than ever because we realize 75% of the protocols we've analyzed so far depend on at least one underlying protocol completely or one off-chain entity that can impact the funds. Um, 10 out of 18 protocols depend on Chainlink. And 45% of the entire TVS, so that's about 40 billion of the TVS we've analyzed, is completely impactable by Chainlink. Um, so this is close to half, and I would personally suspect that once we analyze more and more protocols, that ratio would actually be bigger than we

detected it so far. Um So, coming back to our question, how many people can rug you? Or Okay, more fairly, how many people does it take to rug you? Um looking at DeFi right now, honestly, the honest answer is four to five people. I think this is scary. I think this is far too low, and we can do better. Um So how? The three things I want you to take away today. Um Stop using DeFi for any protocol that holds funds on chain, right? We need to have hold them to higher standards. It's about reputation and the future of the DeFi space, right? I think it's totally

fine not to be DeFi. It's fine to be just an on-chain finance, but failure of on-chain centralized entities should not mean failure of DeFi as a space. Uh it's important we distinguish those. Um So, it's important to be informed as user to ask about all five trust vectors when you interact with a protocol. If they cannot answer you, this is a bad sign. Um And also, just help us uh register a review the next 2,480 protocols that we haven't looked into yet. Um we are in the DAO security fund currently on Giveth. There are 7 days remaining.

Uh in all seriousness, that will That will eventually depend to what extent we can scale and cover more protocol in the future. And um And yeah, the conclusion is too many people can rug you. Um so, I think we can change that. V2, or it's hard to It's a bit low, but v2.defiscan.info is the new version. It's where we you can check out our results um in a few hours once I calm down. The This is going to move to our main domain. So, this is going to be defiscan.info. and but for the next few hours you can you can compare V1 and V2. Um do reach out.

This is a Telegram channel. It's DefiScan under the underscore news. Um we're going to publish every day you that you see that we detect a change in a Defi protocol, we're going to warn you in that channel and explain what does it mean, what are the consequences of that change. And um and that's about it. If you're a Defi protocol and you want your users to know about the the counterparty risk they're exposed to in your protocol for transparency, please reach out. If you're a wallet and you want your users to know uh how much counterparty risk they have they're exposed to, do reach out as well. And if you're just interested in counterparty risk going Defi in general, just reach out.

I think that's about it for me. I you we probably have time for a few questions. Um so, thank you for your attention.