Restaking Panel

ETHDubai 2025 · 29 Apr 2025 · 31:16

A panel discussion on restaking at ETHDubai.

Speakers

Topics

From ETHDubai 2025, hosted by DeFi Dubai.

Transcript

Hey guys, uh good afternoon uh everyone. I am Duv. I'm co-founder and CTO of Catalysis and I'll be moderating this resting panel. Let's get started. So let's start with quick intros. And uh I'm Nick. Uh I'm one of the founders at Melo and we're building the institutional vault infrastructure and we're also working with restaking. Hi, my name is Philip. I'm a lead contributor at Inception LRT. We are a metal provider on top of Symbotic and Egan layer.

Hi, I'm Phil Vogle, founder of Cork Protocol. We're building a protocol to allow anyone to price, trade, and hedge risks on chain starting with pegged assets like LRTs and stable coins. Hi, I'm Lauren. I'm from Emily Capital. Uh we are a liquid fund acting in D5 blockchain for since 2020 and working with uh all the partners and protocols at this stage. Hey, my name is Ilgis. Uh I'm from Gearbox Protocol. Gearbox is lending protocol. So actually we on board a lot of LRTs uh for leveraging and different use cases.

Awesome. like beautiful people in the panel and I would like you guys to have spicy takes in this panel like this is mandatory. So let's get started. So uh as we all know uh slashing is live on symbiotic and layer both on mainet. How you how are you guys currently evaluating also uh on our end basically we we have curated model in the system and we don't assess the risk on our ends we delegate

this to curators and I think it's the best approach because you will have multiple different approaches to risk management you'll have different risk profiles and uh also I think that uh it's important to understand that risk takingaking is basically uh it's it's insurance mechanism depending on slashing implementation but in the most simple case where you have just uh slashing with burner uh then uh it's something that punishes the entity in other case if it's slashing with a redistribution it's it's exactly insurance so uh in this case you need to like keep very low corl relation between uh uh the the risk profiles and uh we're also going to provide more data to make

decisions for LPs when they get into the vaults and uh also uh provide more infrastructure for risk management for curators. We recently launched some things around interfaces for curation and uh I think this is something that's important to have in the in the ecosystem and uh yeah and I think no uh restaking protocol can work without curation these days. So inception has a similar approach where we're not a protocol curator. So we delegate curation to um independent creators um such as risk managers or liquid funds that will like to to be uh curators. Uh one thing that I I guess we we offer uh on top of that

is that we work with multiple curators. So you benefit also for some level of diversification of the slashing risk and we actually also work with trusted creators that we know have onchain risk mitigation mechanisms that you know might eventually pull out the capital if there is a slashing event that occurs to avoid correlation slashing risk and that kind of stuff. Um so so there is a bit of enhanced benefits I think to work with multiple um created vaults instead of only one um if it is um you know carefully uh selected let's say by by the DAO of our protocol when when it becomes live.

So we're actually building out the market infrastructure to allow market participants to price the risk of slashing. And so that can come in a lot of different forms. In our initial implementation, right now we have DEG swaps which allow the market to price the risk of a DPEG on a pegged asset. So you can take an LRT or a vault or any sort of any token you want and create a market where you're actually pricing the risk of a DPEG which could come from a slashing event. As we move forward and and down our technical roadmap, we actually plan to have the ability to price specific slashing events on an ABS or a network. And that will allow the market to continuously price and update what the costs are for ensuring that risk and actually allow the the market to price, trade, and hedge it.

Okay. Uh well as a curator and to add something smart that already been said uh first yeah like Nick said uh slashing in race taking is the is a is a function okay that someone trigger okay and you have either a punitive event as Nick said so one or a certain number of your 32 Ethereum get burnt or as Nick said could be redistributed. So here we can think of uh insurance as already said.

So the in staking long time ago when it was just lido you know or the vanilla staking the risk of slashing came from the not validator uh because they were either not you know like synchronized or they have like a downtime or they were simply like mischievous. You know on the risk takingaking side the risk does not come from really the node operator but the AS or the SSN itself or to be more specific. The risk come from the way the middleware is designed. The the AVS middleware is designed. So how do you trigger uh a slashing? Who has the right to trigger it? Who has the right to veto

it? Is it a direct slashing? Does it have a resolver committee behind? uh do you have 24 hours veto etc. So us as a curator uh to sum up is uh we look at the quality of the middleware of each underlying as we secure and we make sure of the responsiveness the communication between the n validator the curator and the ssn itself. uh I think it has been said like earlier on the slashing is not something someone wants to you know rock ppull us. It's mostly of the time an issue of communication or or parameters.

Um so at this stage it's so experimental uh we all working actually one by one because each slashing mechanism is unique to its ABS. Some AS doesn't even have slashing like ENDA will never have any punishment slashing. Some however does. So that's why it's very hard right now uh to synthetize uh how to price the risk of slashing because they're all pretty different. Yeah. And to finish here, I mean, not validator knows a lot about the slashing risk. Yeah, I think at the end of the day, each individual ABS or network is going to have to have its own level of looking at how you price the risk because it's so could potentially

be so different and also what happens to the slash at that time is just the spectrum is huge. I guess in in lending markets it's a bit different angle uh for looking at session uh as uh for back assets mostly in lending markets use this uh fundamental or exchange oracles which actually checks uh how much underlying has uh asset actually and this underlying could be changed in in case of flashing. So crucial part for us is withdrawal period. Uh so that in case of different stinging uh things if they happens uh liquidators should be able to withdraw

position so how much it cost for them how uh much time it takes for them that's crucial part for us from lending perspective. Yeah, I would uh also add one more thing that uh right now we we were speaking mostly about the risks from the LP side but at the same at the same time there are risks uh on the side of ABS or shared security network in terms of which other networks are utilizing the capital together with you because if there will be significant slashing event coming from other network then your security will also get affected and it's also important to choose the capital providers and vaults and curators from the side network not just from the side of LP.

Amazing. I have multiple follow-up questions. So, let's start one. If you had to choose one, will you burn these slashed assets or redist redistributed? I will definitely redistribute because uh if you can redistribute, you can also burn. And uh uh but uh jokes aside uh I think it's just a more powerful concept and uh in this case you can build more things uh that will work with traditional finance and uh you can uh get much broader use cases with the insurance repo whatever and uh in this case it's uh it's something that covers much more capital.

Yeah, I don't have necessarily a super strong opinion about that. I think about the risk of uh or the concern of redistribution is not knowing how exactly it will be redistributed in case of a slashing event because if it's some small group member or some concentrated voters on some DAO that are going to decide about how this is going to be distributed then how do you price the risk of slashing if you don't know what the tokens will be how how it will be handled after the slashing. So I think there is this uh part of uncertainty that yeah makes me not have a strong preference for both uh you know options unless if we dig a bit deeper.

I think it really varies, right? The use cases for ABS's and networks is enormous. And so what the actual use case of the slashing is is also going to be really varied. And I think also one of the things that needs to be considered is if you're thinking about redistribution, who are you redistributing it to? And is it actually someone who is affected by the event? again depending on the network design or the AS design. But one of the challenges that you have is that let's say you're uh securing an oracle and the oracle does something incorrect and there are downstream effects of that. How do you actually get the redistribution to them?

And is that redistribution anywhere near enough to cover the potential effects? Yeah, but uh I think also with the burning it's it's another way of redistributing because because it indirectly affects the price of the asset and in this case it's also redistribution but in a different form. So it's it's the way to red distribute to everyone who owns this asset. Certainly. But I think what like the let's say it actually causes liquidations to take place downstream because the oracle gave you a wrong price data, right? And then it turns out oh that price data was wrong. We wanted to redistribute to the people who got liquidated. Is that if they do like if you're just burning it, you're sort of helping everyone, right? Not necessarily helping those specific people who were affected. But also like is there enough

of a redistribution even if you were able to target them and say you were the ones who were affected by this here we have this stake it's you know x number of ETH or whatever that actually goes back to them but no they lost 10 times that how do you actually compensate them for the fact that they didn't do anything wrong that should have gotten them liquidated I don't think yeah I mean it's so early and right now I was listening you talking it's like okay so you have one alert Okay, that secured 10 as let's say then one as have a successful slashing. So out of the I don't know 32 if let's say we lose one. What will be the price of the LRT?

Uh I mean this V or Oracle as you said it will not be too difficult. I think the issue is not to price the LRT in a secondary market. No, no, the issue is how do you price the the LRT at the primary market at the vault once you have a once you have an event of slashing that occurs so far so good no slashing occurred primev I think is already activated uh avda is activated but doesn't have any slashing per se so we are really at the beginning of a big journey here I mean you're already starting to see some network and ABS designs that are intended to have a slashing, right? I've

seen some design proposals where they're actually used to ensure rein reinsurance stakes. And so if money, cap money is coming up. Yeah. I mean, I think so if there is actually in those events, you're going to have slashing. It's going to occur and there's going to be like an actuary model that says this amount of it is actually intended to be slashed. And then I think you have a really interesting question of if you have an LRT that's uh allocating to that, how do they price themselves? Because at the end of the day, in the secondary market, fine, you're right. Exactly. It'll take care of itself. But in the primary market now, they've been slashed, right? And they were they know they were going to be slashed. And so is there a way to build buffers and build other things such that that slash is

almost accounted for. And so it's like we know that on this particular allocation, we anticipate 4% being slashed in a year, but we're being paid 8%. And so therefore, we have a way of like compensating for that. So as long as we're being slashed at the amount that we think, it's always going to work out. It's if we get slashed more than that. But now you have another problem. And and as Nick mentioned is that sometimes you can again you can secure 10 as with one Ethereum. So if one of yours gets slashed okay what's happened to the security of the nine others remaining as this is really a question would like to answer. I mean I don't have the answer now but gauntlet did some

analysis about that using some minimax model which I think pretty smart even though they are my competitor but I'm happy to to say awesome. So uh let's take a case study of uh proof ofstake networks. Historically proof ofstake networks have seen slashing due to misconfigurations bugs in client configurations but not actual malicious behavior. What do you think of misconfigurations across these different also? Yeah, I think uh like it's uh it's also something uh in uh in the angle of uh

risk and yield profile because the the higher the risk the higher the yield. If we look into Ethereum network then uh in 2024 uh it was about 68 ETH burnt during the whole year. It's it's a very small number compared to the the amount of ETH that was staked and um uh and the risk is super low. Uh in case of AVSS the risk is of of course much higher and uh there's different implementations for slashing and uh different implementations of AVSS. uh but uh at the same time uh there are things like resolving committees which can mitigate the uh at least some things where the there is some errors in terms of the code or some malicious misbehavior from

the hackers or something like this not not from the side of uh designed mechanism. Um so I think that uh all the u launches that uh activate slashing they should have uh the resolving committee uh on the first stage or something like this implemented uh and integrated uh because u uh it's it's something that's very new and we need some reputable uh entities that will like at least uh look into what's happening when there is the first slashing events coming and after that uh it can be just removed as soon as we make sure that everything works fine.

Yeah, I think in terms of slashing there is one part that is potentially different uh between proof ofstake networks and uh shared security um is the potential risk of correlation slashing. So there are c certain type of slashes that will remain isolated in a specific um SSN or or network but there are other type of slashes that might eventually have a causality that might trigger other slashes in other networks. So understanding that slashing correlation is something that is still very very early. We don't really know you know how it's going to uh to happen. Um there are some creators that have those onchain monitoring tools with hooks that will

trigger out the the liquidity if there is such an event occurring but I feel like there is still a lot of uncertainty and that's probably the the main difference with proof ofstake networks and shared security networks. Yeah, I think that's exactly right. you know, especially when you're thinking about one single stake securing 10 AS networks that potentially if one server goes down or has an issue and all of a sudden all 10 of those are slashing against the the same stake, what does that do? We don't know, right? And I think that's going to be a really interesting thing to see how the market ultimately prices those risks and actually looks to prevent them from happening. Um, we have a lot of track record and history on Ethereum and other large proof ofstake network slashing. we

have zero history on ABS as a network. So I think it's going to be a long time before we actually know exactly how this is going to work out. I think it's uh it's also important that uh there's another layer of risks in this case because if uh if there is slashing event uh in in the ABS that will slash some assets in uh in the vault or LRT in this case it also affects the secondary market and there could be cascade liquidations on the Linux markets and more things that will get affected in the DeFi ecosystem. Yeah, that's also that's fascinating because it it could end up being that you have temporary like DPEG events that end up being caused by a slash event that's actually very very small, but because everyone doesn't know what it means at the

beginning, everyone sells in the secondary market, it causes mass liquidations and then 20 minutes later prices back up to like you know being off by 10 basis points. I have one point like uh us MV Capital we don't put direct slashing we put resolver committee 24 why Nick did you say once everything is stable let's put out the resolver committee and do direct slashing I'm not sure I will feel always comfortable to to keep direct slashing I love my veto no no I think uh it it makes sense like case by case and uh it it depends on the specific implementation of uh AVSS and it depends on specific risk profile. So probably later at some point

you would have several vaults some vaults with direct slashing some vaults that you will manage with resolving committee depending also on requirements from the side of ABSS. What would be the negative path of running a vault with a veto with a vet still there are some trust assumptions uh on the on the side of committee. So uh sometimes if you want uh very strong trust assumptions and uh you're very confident in terms of the implementation then in this case most likely you won't uh have the the weather committee but these are ever evolving software and how will you remove resolving community and enable direct slashing because these

are evolving. Yeah, but it's uh it's something that can be configured on the on the level of the vaults. So it's uh it's the case where uh it can be decided later and you start with the veta and then you remove it. Yeah, makes sense. Some walls having direct slashing and some with resolver committees. Makes sense. Makes sense. Uh I want to divert this uh panel to node operator selection as Walt curators and LRTs. How do you guys select node operators for these these ABSS? How do you assess node operators for a specific ABS?

Yeah, on uh on our end as a protocol, we we work with all the major node operators and uh I think it's it's already dozens of node operators in our ecosystem and uh curators free to ch are free to choose and work with any node operators. They can also bring more new node operators in into the system. Uh and uh also we we have uh two types of vaults in this uh in that sense. We have vaults that uh work with multiple node operators and we have node operator specific vaults and uh in most cases they're also uh the node operators are working with uh our curators to manage the vault and uh it's uh the way for them to work directly with avs and uh uh

and keep more business on that side and uh at the same time uh it gives them more flexibility in terms of risk management and curators help a lot because it's uh basically business of curator to manage the risk and node operator provides all the infrastructure. So as mentioned before on inception level we work with the curators the curators select the node operators in the networks. However to be able to select the curators we need to understand what type of curation they're doing. So we we we built a a resticking explorer for us mainly for internal you know purposes because we we kind of need to understand what is the network exposure of the creator. Are they working with multiple node operators?

Are they working with the same node operators on all the networks or do they try to have different selection uh of node operators depending on the network to try to mitigate potential correlation slashing. Not all node operators will be equally performant as well. So there might be node operators that are very performant on some SSN and and others that are less performant on others. Um does the node operator have a lot of concentration in a specific SSN network which might cause some centralization concerns on some networks or not. So that's obviously the job of the creator, but for us delegating capital to multiple curators, we need to understand what is the curation type that they're doing and then provide additional

diversification. At a fundamental level, we're just trying to build at Cork the infrastructure that allows all of these different things to be priced. And so if you have a vault that's allocating to specific node operators, you can actually price that node operator's risk. If you're allocating to a group of AS's or an LRT, you can price it at each individual level and just give the market the tool set to actually start to create um risk markets for this. And then ultimately that can get packaged into things that look much more like traditional uh financial structured products that provide reinsurance and different levels of capital with trunching and all sorts of other fun stuff. But sort of has to start at this like core fundamental level at first.

um as a as a curator the way we select the not valid data. So yeah there is the concept then there is the the practicality. Um so you have around 80 85 node operator I think that are listed more or less on symbiotic. Uh six months ago there were a number of 30. So us we are not n validator but we have to delegate to them. So I needed to talk to lot of nooperator during those last six months. So first I looked at cohort zero which is the not validator that was in the test net of symbiotic. You know all them. You have P2P Lugan Corisard um DSRV N infra I need to name more

otherwise they will think I do some uh and Bloxcape u etc. You have a lot. Okay. And so at the beginning is to work with the one that has been the closest to symbiotic uh team. I think in the future more and more on that validator will come but I think they will their knowledge will be a little bit lower than the one that is working on risk takingaking right now. Um what happened with the not valid data? How do we select them is uh okay so everything that what you mentioned so the historical data the track record how many slashing did they did they occur during POS and then basically we we study uh not validator one by one uh by

giving a use case of SSN and then depending on the answer of each not validator first we have a good overview of what not validator think then we start picking which one has been the the most thorough thorough on the analysis. I think in the future you will have theatic meaning that some not validator will become expert into one family of ABS. Right now it's so small that there is only like 10 20 uh SSN so that every big not validator can for now acknowledge each of them. Yeah. So just a shortcut to answer is we work with the not validator that have the that has been the most proactive in risk takingaking layer and symbiotic so far.

uh for learning markets I guess we don't work uh directly with node operators uh so don't need to choose them but actually it's another dimension of data to assess risks of underlying alerts yeah so when we check in different alerts what kind of not apparatus they are working on and uh yeah uh data on like uh even for validation of different services I guess it's also like valuable data to understand the risk because it could control show the uh how much uh technical team how they good on devops and etc. Yeah. So awesome. Sounds good. I think we have a lot of node operators and they have very

good expertise in validating these networks and AVs and we are well equipped and we are still early. We need to figure out uh how node operators work. So yeah, uh if you guys had to choose one, maximize the number of AVs or doubling down to maximize yield of one AS what would you choose? I would maximize the number because uh this uh gives you more diverse risk profile and uh I think it's it's the only way to to work with the with the risk management with the AVSS.

Yes, same. I will also diversify You can sense us here I guess. Same same because it's cumulative. Why why do you want to double down on one since actually you can secure two at the same time? So the deal is cumulative. So we are still digent industry. So we need to choose every index. Yeah. Yeah. This is a dig industry but keep the correlation low. Yes, you need to keep the correlation low. or just keep praying or just keep find another way to hedge out the risk.

Maybe let me turn the question a little bit. So in resticking you have that concept of sticking ratio, right? Where where you have let's say a million 10 networks. So do you want to provide 10 times a million and and providing 10 million economic security meaning that you're staking restaking ratio is like 10x. So will will you maximize the staking ratio or is there any reason why you will not like to maximize the staking ratio as a curator? I'm happy to maximalize it until slashing is live.

Yeah. Then I think it ends up starting to look like something like an efficient frontier where you have what is the actual like risk adjusted return that you're providing where if you could actually end up getting slashed massively where everything goes to zero because of the way that you're set up. What is the return that you're getting for that? Yeah. Yeah. The tricky part about risk adjusted returns is in TRA 5 we have the concept of volatility slashing has in itself no volatility. It has maybe a value at risk. what is the maximum loss that you can get right what is the probability you can actually get that maximum loss or not so yeah yeah yeah looks like an efficient frontier it's I mean the there's like all sorts of new concepts that are being developed

here that have no exact corlary in traditional finance but the way in which you can actually try to mitigate and price and hedge the risks of them do have corlaries I guess right now is number of haves is too low. It's kind of like a credit portfolio. If you try to understand risk of giving credit for some specific person, we can't do that. But if there is like thousands, tous thousands of similar people with similar profile in that case you can assess the risk and build some scoring model etc. So it's too early. We need more aes okay we need more absises.

Okay, I won't take too long and let's take one last question. Uh, quick prediction. What will be the biggest headline in the next 12 months in the reing ecosystem? I think it's the first slashing. It's It's easy. I was about to say the same actually. Yeah, I think there was like a huge headline when Lido experienced its first slashing event, right? Right. And so when I think when an LRT has an event where or anything has an event where there's an actual slashing event that is real and substantial, not just like, oh yeah, one ETH was slashed and it's covered by a, you know, a buffer fund.

When it actually affects the price of something, that's when you're going to see a real headline. Yeah. Lido V3. So August 2025, Lido V3, it's going to be big, I think. And Catalyis release going to be big. Yeah. Catalyst for the win. MoreSS. MoreSS. Yeah, we need more. More ideas. Agree. Okay. Thank you all. Thank you to all the panelists here. And yeah, resting is the future, but it needs to be built right. And all of us are here to do it. Thank you.

[Applause]