New Ethereum talks, every Monday. The week's conference uploads by event, in your inbox.

Loading player…

DeFiScan: Verifiable insights into DeFi risks and decentralization - TokenBrice | DeFiCollective

ETH Belgrade CommunityTue, Oct 7, 2025, 12:00 AM

DeFiScan: Verifiable insights into DeFi risks and decentralization - TokenBrice | DeFiCollective

Transcript

Ali himself. [Music] Okay. Okay. Tough crowd. No, we're gonna talk about defi scan for you.

I just wanted to flex my sabion. So in defi, we keep hearing about the same thing where essentially assessing the decentralization stage of a protocol is uh I used to say a full-time job. know that we actually doing it on a daily basis on a lot of protocol. I want to say it's several full-time jobs for several people. Um and it has real challenges.

So I'm just wanted to give you a bit of context with this chart of TVL and you have on there maps the major traumatic event let's say and I think a big reason for the trauma of those events uh especially I mean FTX kind of okay it's centralized exchange everybody knew but uh the USDC deplosion are interesting events because you ask an average middle IQ middle interest D5 people back in the USD mana he would argue with you that it's oh no it's decentralized bro yeah yeah it's interesting blah blah blah they actually thought that they didn't have a resource telling them big red flag no this thing is absolutely stage zero of decentralization of development practice of anything makes zero economic sense they didn't have trusted third party to conduct this kind of reviews and essentially give them the information they could still decide to ignore it but at least they could have had a decent third party resource to assess that now instead they got manipulated by K on Twitter into thinking that this thing was actually sturdy. So similar different situation with USDC, but I think you follow me. So that's how that's how we get to to DeFi scan is essentially we have a big transparency problem in DeFi and that's a bit of a paradox because you know we're all thinking yeah all the data is on chain everybody can check transparency is already there right well it's not that simple to have real transparency you don't just uh uh tell people to look at smart contracts because ah I mean I don't really like those things but like show of hands who in that room actually checked a smart contract to verify the reserve of a protocol or some functions one day in your I got what two hands. Okay, you got the answer as to why we need something like defi scan because nobody is checking the contracts and I don't blame you. I don't even check the contracts myself.

I can't really do that so well. So essentially what we need is we need tools where you have a big proper birdie geek that went to check the contracts for you and then reported against a neutral framework where other birdie geeks can audit his assessment and the normal people can essentially read those assessment make decision based on those assessment because they are peer-reviewed they are neutral and they are fact-based so that is what we are doing at defi scan and domain angle is the decentralization of protocol So you have on screen essentially kind of the main questions that will be answered by a device scan review. So who really operates a protocol? What kind of functions they have? If there is some critical change that can be made, how is it made?

Who made it? What is the delay to react to those changes? Are there any critical dependency of that protocol? Does it mean that if you use that protocol, you're using other protocols or infrastructure without even knowing about it? all these kind of questions that are necessary to to be answered if you want to actually understand the decentralization status of the protocol you're using and by extension the risk you're assuming by interacting with that protocol.

So that's a million-dollar question for us. How much D is in my FI essentially? Uh and that's how we get to defy scan. So D5 scan is essentially first a framework because that was a big question like what is effectively decentralization. Can you put it in in base of criteria to be able to assess all kind of protocol against that framework that took us almost a year to reach a proper framework and it's still continuously improving.

So it's it's a real challenge. Then there is a whole let's say less known me dimension of device scan that is just the tooling and the resources. So we analyze lots of contract. We need to monitor the verification status. We need to understand the permission.

And to do that we've built some tooling. All the tooling is open source. That will be mostly of interest to the developers. But for us it's also important to make it public because that means anyone can replicate or finding if they want to audit uh a device can review essentially. And I guess then the main thing that most of you might be interested into is the website itself defiescan.

info where you go there and you will find those uh assessment the decentralization assessment of various defi protocol. So that's define.info go check it out stamp of approval from the foundation recent grants recipient we are seriously legit. Uh okay so essentially I want to tell you a bit more about the framework and how it work. So we have so far we're following a logic similar to L2 bit.

For those who know about L2 bit they do essentially the same thing but for layer 2s we do it for D5 protocols. So we have a dimension that is just a chain and here essentially we mostly importing data from L2 to assess the decentralization of this chain because that's not our job. The more interesting dimensions are the four others. So upgradability is literally what can change in the protocol the extent of the logic that can be modified by various means and you know it range from absolutely nothing will ever change it's technically impossible to the whole protocol can pretty much be completely changed into something different tomorrow. So the the spectrum here is huge.

Uh kind of link to this upgradability question is a question of the exit window. So okay there are some changes that can be made more or less critical and they can be made by a governance or multisc or whatever but then if a change is made how long do I have to react if I don't like that change that's the exit window uh then you have a dimension of autonomy here the core question is dependencies what does this protocol need to run is it using an oracle is it using other protocol because it's depositing into them and so on so the goal of this one is to help you understand the full risk scope not just the protocol But you know uh if you're on a you're using chain link whether you like it or not all price feed on a are chain link you need to know that and then you need to have some data on chain link to be able to properly access a last one is accessibility and it's essentially your capacity to interact with that protocol even if these official front ends are done without having to go on SS scan because we established 10 minutes ago that nobody goes on scan really. So do you have alternative UI that would allow you to still interact with that protocol if the website is done or if they're being censored by a government or who knows what happened and ideally here we even want to see essentially selfstable front end that ensure that in any situation we can have access to the protocol in a graphical user interface. Uh so this is uh overall the scoring on each of those dimension you will have three grades of rating from a low risk that's green medium in yellow or high in red and it's really about how much can it impact the funds of the user and overall the performance of the protocol. Uh so assessing all those protocols with these five dimensions we get what we call the decentralization stages and it's kind of a global rating of a given protocol.

So we have the first uh minus one/n not defi stage we'll go into that just a bit after but it's literally protocols that don't meet or stage zero requirement. So we consider them not even defi and you will see those requirements in a minute. you won't find it too demanding I think uh so stage zero is essentially full training wheel the thing is on chain you can audit it it has verifiable verified contract and so on but it's essentially full training wheel trust me bro those kind of protocol can pretty much be destroyed completely by a coalition of malicious actors insider most often uh stage one is limited training wheels so here you still have some control mechanism You might have some uh emergency multisig that can do some form of pausing or that has uh an influence over the code changes but uh overall the the total damage that can be done to the protocol is already more conrained and uh the stage two is essentially the bike without training wheels. So here uh most often but I think it's possible even without uh most often there are immutable protocols. So literally no change can be made and uh we don't have a non-immittable protocol in stage two yet I think right uh no we don't but I think it's technically possible but essentially that would mean a lot of actions are taken to protect the users against the governance or whoever is making those change extensive time lock to make sure that people have time to react and so on so let's just zoom a bit on on the stage zero requirements so you know where we're coming from uh as you can see there are a very basic stuff.

So, we want the the protocol to be on an actual blockchain, you know, so we can we can work our magic there. We want the assets also to be on a chain and not in a bank account somewhere or with a custodian or whatsoever. Uh we know how to uh assess reserves in a smart contract. We don't know how to assess the solvability of a bank. That's not our job.

So, that's that's a big one for some protocol. Uh and then the other things are like kind of common courtesy, but they enable analysis. We want those protocols to have a public documentation that is comprehensive and exhaustive. Uh we want source available codebase. So that means you know business licenses are okay but we want to be able to read the code and verified contract for similar reasons because it's cool to be able to read the code but we also need to be sure that the code you're interacting with when you're using that protocol is effectively the code we read and we audited and that's why the verification is for.

So those are stage zero requirements. If a protocol meets them, they can essentially be reviewed through the device kind framework. If they don't, they are non-stage zero non-defi. Um and then we go up the stage of up the requirements with the stage. So um depending of the stage we have different demand essentially, but they're all against this logic of stage zero full training wheel, stage one limited training wheels, stage two no training wheels.

So it's very similar to L2 bit in that sense. Um, so I think one dimension that is particularly interesting and that's why I want to zoom on it now and actually we just uh today we merged uh spark. So I'm missing spark from that picture but you can find it on on defcan.info and spark is a stage zero as well but um yeah I think this is a pretty interesting dimension of defcan where you can see here we have only lending protocols some are CDP other are money market but they all do the same thing. I come here with a collateral I borrow something.

So we on similar use cases again different infrastructure between those CDPs liquidity for instance maker or the money market avi or morpho but for the first time in defi history if I may say say it as such you can actually assess those protocol against one another and you might have seen for instance that compound recently was looking for essentially an infrastructure provider to do um some diplom I don't even remember the chain I think it was polyon or something like that whatever and they went with Moro and people were confused why Moro why not a well I don't know I wasn't in those discussion but with what you're seeing here maybe you have an element of answer um so that's one of the cool dimension of device scan you can compare protocol within a given uh vertical but you can also compare the decentralization of protocols that are not even in the same vertical you can compare unis swap decentralization against a for instance um so just to zoom in in a clean example uh liquidity so this one is pretty interesting because you're with a fully immutable protocol. Uh and so that means in terms of upgradability, well, nothing can be upgraded. So low risk there. Definitely literally risk zero even if we had it. Uh and exit window, well, nothing can be upgraded.

So I don't need to worry about the time I have to react to the changes because there are no changes. So against again low here for the chain, it's only a mainet. That's a lowrisk in no book. Another green um and then the autonomy. This is where it gets a bit more tricky because we're talking of a lending protocol.

So, uh usual suspect for a lending protocol are I need to know the price of the assets people are borrowing against. And in the case of liquidity, uh they get a low because they have a dual oracle structure with a fall by fallback logic between the two. So they manage to avoid having a critical dependency to one oracle thanks to that redundancy and that gives them the low score. And finally in accessibility uh I think we still do not talk about this enough so I'm going to take a minute to give them kudos. Liquidity is literally one of the only protocol in the space that took an active endeavor to maximize the number of front end available on this day.

There is about 50 to 60 different front ends to access liquidity on IPFS on different kinds of technology all around the world and they achieve that by making the code of the front end easily uh implementable by anyone and by having an incentive program for front- end operators. So it's worth the kudos but essentially they get a very nice score in accessibility as well. You don't need to go as far to score a low risk in accessibility. a few front ends and the code for people to run their front end locally is enough. But liquidity really went above and beyond on this one.

So uh a big thing for us is of course the the coverage of device scan. So you might have went on device scan info and you found uh 17 18 protocols there. Now yeah we're getting there but still maybe you don't find your favorite I don't know pendal or lido that you're using but at least you're starting to have the big name now you have unis swap you have a you have maker you have moro more and more are coming. So to this day and this is not accounting for spark we're covering about 35% of the TVL in defi or objective is 90% by the end of the year and at the current pace we are well on track to to reach that point. Don't look at me like that Eve is protocol review at device scan and he's sweating hearing about those coverage objective.

Uh so yeah we actually have 16 or 17 or sorry the slides are a few days old and and we move fast and in terms of team um it's essentially we have two full-time contributors on D5 scan and we have also the D5 collective that is helping out so in total about six seven people involved for the reviews uh the latest one we published that sparked a bit of debate uh was AI in early May and we followed up with the review of Maker and Moro And actually the last on the one here is not laido as I just said it's spark. So now we have a pretty decent lending market coverage. I want to see there oiler and fluid in the next few months. So we have all the big dogs and you can actually understand what's happening on the on the lending front. Uh one thing that is important about us is uh the framework is public, the tooling is public and as much as possible we want pretty much anyone who is capable because it's a technical activity.

We're not going to lie you about this to submit reviews. Those reviews are going to be verified by your team of course but we like to have a collaborative approach as much as possible. And so the reviews that are submitted can either come from the teams themselves that want to do this act of responsible self disclosure about decentralization. Personally I think every team should be wanting to do that and I am a bit shocked that major players are not rushing to order to self report and self-disclose but everybody will form their own opinion on that. Anyway, we've designed the D5 scan so that with their help or without their help, they will be reviewed.

As simple as that. So, we like to do it with the help of the project. If the project is not collaborative, we essentially force review them on our own resources and then reach out to them before publication to give them a chance to respond to the findings. So, everything on define is done with that endeavor. Uh you have the details here.

You'll find it also on defcan.info submit review. You have the same information. But if you're a bit geeky, you can look into it. We also have a bounty program, so you can earn up to $2,000 for uh submitting the review of a protocol.

So definitely worth checking into. Uh yeah, those are the headlines. Uh if you have some question, I think we have some more time. So uh I'll hear from you.

Hey, hey, hey. Thank you for the presentation. Um so basically uh the fundamental fe not feature but specific of the software that software must be upgradable because like time flies no new use cases like happening and so on and you said like that stage two like ideal uh smart like defy application should not be degradable yes by uh logic logical reasons from your personal opinion is there any like chance to find like some kind of serial silver bullet uh to make contract upgradable but also to make it like fully autonomous and so on.

That's a it's a great question. I cannot touch on it at some point where I said currently we do not have a stage two that is not immutable but uh and Eve would confirm that you should chat with him after but in my understanding of our framework it is theoretically possible. It's just no protocol that have governance and can change his score logic went far enough in implementing those safeguards to reach that point. But also you know we tend to make this dotomy between immutable code and oh how do I say agile in an industry where there is a new trend every six months la well you have a very good example of that it's called unis swap made it's version four now all versions were immutable you know they just they ship a new version they migrate people to the new version they do that very well people are not complaining about it I didn't hear so much complain so it works for them and it enables them because you know the counterparty of that is that you weaken the security guarantees of everyone using your protocol at all time just so that the day you need to update you as a dev are a bit more comfortable. Well, no, stop being lazy.

Sorry to be that brand, but I'm more on the angle of make your code immutable and yeah, okay, you might have to migrate your user in two or three years and then why if you have an actual new interesting product to offer them, they will want to migrate anyway.

Yeah, oxy.

Yep. So I'm kind of following up from this question and this more of a subjective I wanted to hear your opinion on this. Um you hear a lot in the space of DeFi this idea of progressive decentralization but I find it curious that like many of the top protocols are from the get-go already wanted to be decentralized while the simpler protocols some of them have been on stage here for years and like without pointing names have seen upgrades that make protocols less decentralized. So I wanted to hear like have you seen examples of progressive decentralization? Do you think it's even possible or it's something that like we just talk about as Scopium?

Great question. Again, uh progressive decentralization is absolute If someone talks about progressive decentralization, you can write them off your book simply because of what Oxy said. I've been in the space seven year. I have yet to find one protocol following on their progressive decentralization promises. The one that is closest to have done it is no shutting down.

That was Reflexive Finance. And the unique thing is they actually came with a timed progressive decentralization road map. So as they launched the first version of the protocol you had like oh in a year this we're giving this part of the infrastructure is becoming autonomous. In two year this part of the infrastructure is controlled by the community and so on. They put strong objective for themselves and they follow through on it.

They didn't find product market fit and now they're shutting down the protocol. What I have found out and there are quite a lot of them are protocol maximally decentralized from day one. So anyone serious about decentralization this is what they're doing. Anyone laughing about decentralization they tell you about decentralization road map. And if they are really like the top of the role players they will tell you about vague decentralization road map without date.

The biggest one in existence is maker. Who remembers the Fenix tense? Ring the bell. Fenix tense. Maker was supposed to be this imbeatable phoenix freed from any dependency of real world asset.

We didn't have a timeline on that. We didn't have technical implementation, technical detail. Those I think that was four years ago the Fenix plan. And when I saw the plan, it started from pigeon. There was a middle step and there was Fenix and I already tweeted maker forever pigeon.

Well, where is maker today? Forever pigeon stance. Pidge instance is total dependency on real world asset and trusted third party. That's the state of maker today and that's why it's a stage zero on defy scan.

When making the stages we have to arbitrarily choose what matters. How is your process trying to find uh validation for the the criteria you have for stages? How did you land on those and how much uh support for those did you find before being comfortable to say that's it?

Yeah. No, that's that's a good question too. It's indeed you know u we are going for quantitative obs onchain observable stuff as much as possible. That means we also have some blind spot. We're honest about it.

For instance, we are really focused on the protocol who changes the protocol permission consequences for the users. But a lot of protocol they have the governance changing those protocols. We assess that part governance we will tell you about the time lock and so on the multis setups that enforce the governance if needs to be. But one blind spot for is we don't look at the governance token distribution. Maybe there is 80% of the voting power in the hand of essentially the same entity and that's a pretty bad thing for decentralization.

So we're not doing that now. But the good news is there are there is a project um name is slipping away from me but you go on the defi collecture. Thank you Eve. Uh yeah. Oh I'm silly.

That's you. Okay. Uh so there are projects doing that and that's really cool and this is more on perspective. You know, we assess decentralizations of protocol and we're happy to give a shot to people assessing on our blinding spot on the sides for us that we're not doing because we want ideally my vision is you know it's not one D5 scan is like 15 DeFi scans three years from now where you have one where you can assess the decentralization of liquid state token for instance you have another doing decentralization of governance assessment you have maybe another going really deep in the governance technical infrastructure and so on and even Once you have all those projects, you can have meta projects kind of collecting the data from all of them. So if you think about stable coins for instance today, you can already do that with several of those uh information service provider as I call them.

So you take like a stable coin like LUSD. You have uh development practice assessment on D5 safety. You have an economic safety rating on bluechip. You have a decentralization assessment on D5 scan. And you have others assessment.

you could essentially score together and have a nice all comprehensive score around that stable coin and I think that's the end game for for this kind of service like D5 scan.

Thank you.

One more question. No. Oh. Oh, yes. Eve,

it's not really

Hello. Okay. It's not really a question, but like if you want to submit the review, yeah, you can reach out to me. Like I'm one of the researchers. I can help you uh to do the technical setup, uh answer questions.

Yeah. Yeah. Yeah. Yeah. Shout out to Eve.

If you have technical questions, you go to him and you can give him a big hug because he's one of the reason uh the speed of reviews on defan uh really spaced up. And uh yeah, thank you, mate. All right, I guess that will be it. Thank you all for your time and see you around if you have more questions on on defense scan.

Automatic transcript — names and jargon may be misspelled.