On October 20, dYdX Foundation hosted a discussion with Xenophon Labs on Twitter Spaces regarding their proposal to effectively wind down the safety staking module by:

1. Setting rewards for stkDYDX to 0, and
2. Reducing the blackout window to 3 days.

We have included the AMA audio file and a redacted transcript below.

Cliffton (dYdX Foundation):

Good morning, good afternoon, and good evening everyone. Thanks for taking the time to join this Twitter Spaces with Max Holloway from Xenophon Labs.

In terms of agenda, Max will walk through his research and proposal on the dYdX community forums to explain why he thinks the safety staking module should be wound down. So we'll get him to introduce himself, understand what Xenophon Lab does, walk through some of the grants that Xenophon Labs has been working on, and deep dive on this proposal.

So, we do have some pre-populated questions and then I'll open the floor up to the dYdX community to ask some questions as well.

Max, could you just give a quick introduction about yourself, Xenophon Labs, and what you guys have been up to?

Max (Xenophon Labs):

Thanks for having me on!

I'm Max Holloway. I run Xenophon Labs, which is a small, high-conviction research firm and we mostly focus on technical research problems for Web3 organizations. If you've been in the dYdX community for a while, you may have seen us around, we've been here for almost a full year doing work with dYdX. We were part of the very first round of the dYdX grants program and we've been active contributors ever since.

We're doing our best to bring high-context community contributions to the dYdX protocol. Some of our work has included the development of trading tools, exchange risk modelling research on the trader rewards mechanism, and research on the liquidity staking module.

Most recently, as with this proposal, research on the safety staking module. I've had the pleasure of working with some awesome collaborators as well. So it isn't just me working on this stuff and I encourage anyone who wants to dig deeply into any of this research to read the actual papers that we publish along with the forum posts because they go into a lot more detail, then we will be able to get into on this Twitter Spaces.

Cliffton (dYdX Foundation):

Nice, thanks for the TLDR. It would be super helpful if you can walk through at a high level what you're proposing because I don't think everyone has had the time or opportunity to review what you've posted on the forums as well as review the paper that you guys have created as well. So could you give a high-level overview of what you're proposing on the farms?

Max (Xenophon Labs):

I can take a couple of minutes to explain this because there are a couple of moving pieces.

So, there's a safety staking module on dYdX, which is a pool of $DYDX tokens, which are meant to be used in the case of a shortfall event on the exchange. Examples of shortfall events might be if there was an exploit that led to a lot of the user funds being taken out of the exchange, then there are these, I guess procedures or these processes in place through which the protocol would be able to make users whole again.

One of them is the safety staking module. So you can think of it kind of like an insurance fund where if something bad happens then all the funds and that insurance fund could be used to pay back depositors into the exchange.

In exchange for the risk that people take when depositing into this insurance fund because whenever they deposit there's a chance that they'll get slashed, so to speak. And if there were a shortfall event to compensate them for this risk that they're taking and also the cost of their capital, the $DYDX, I guess there are $DYDX token emissions that go towards paying folks basically to put their $DYDX into the safety staking module.

So I'm sure we can link to more specific docs on the safety staking module, but I guess I'll move on from just what that is. In our research, we looked into what the safety staking module is and how well it satisfies the goals that are laid out for it.

There are two main goals for the safety staking module. One of them is that we want to align the insurers of the protocol with the protocol itself, which is something that you can do with the $DYDX token, whenever people deposit their token, they may make governance decisions that since they have a lot of skin in the game, they may make governance decisions that prioritize security and wellbeing of the exchange. So that's one of the perks.

But the main perk of the safety staking module is that it's supposed to provide insurance in the case of a shortfall event. So, in our research, we looked at these two goals and asked how well the safety staking module as it stands today achieving these two goals. So starting with the first reason, that alignment between insurers of the protocol and the protocol itself, we found that there actually are conflicts that can arise whenever you are providing $DYDX token, and also voting on governance decisions because you retain your voting power when you stake in the safety staking module.

So there's a chance that if something went up for a vote for the safety staking module to be slashed, a lot of $DYDX in there that people may not want to have slashed. So that's one of the objectives of the safety staking module we felt was pretty dubiously being satisfied if $DYDX were where the asset that was being staked.

More importantly, we looked at how well the safety staking module was achieving that second goal of ensuring in the case of a shortfall event, and here's where we defined a term called insurance power, which is the realistic amount of value that the safety staking module would have at the time that it would be used. So in the case where there was massive turmoil on the exchange and you needed to resort to something like a safety staking module to pay back protocol debts, it's most likely not the right time to be paying people in $DYDX token, right? There are several historical events after exploits where when you look at the value of a token, it goes down quite a bit and it's perhaps the worst time possible time to sell it to try to pay off debts of the protocol.

So, we found that what we call this insurance power, the realistic amount, you'd be able to sell this $DYDX for to pay back depositors in the exchange, it's severely lower than the nominal value of the $DYDX that's currently in that module. And we found this particularly concerning. With this in mind, we looked at both the objectives of the safety staking module and said, "Okay, neither of these is being satisfied super well in our opinion. So, how would we change how the safety staking module works to make it more compatible with these goals?”

What we arrived at were several different possible solutions. One of those solutions would be to replace the $DYDX in the safety staking module with $USDC and instead, you just have a $USDC-based insurance fund for back-stopping the protocol in the case of a shortfall event. So that's one of the options.

The other option is to use Balancer where you could create a Balancer pool that has some combination of let's say $USDC and $DYDX and then people would stake that liquidity, that Balancer LP token into the safety staking module. This method produces several benefits which are outlined in the research paper. I encourage people to read more into it in the actual paper.

The final possible avenue going forward that we set is maybe it's just best in the short term to get rid of the emissions that are going to this safety staking module in the first place.

Whilst long term we think that insurance is a very important piece of the protocol, I think it's great for user experience to know that their funds are being insured right now. It's not going to be possible to implement any of these ideas that we had such as the Balancer idea or the $USDC-based idea.

Right now, it may just be best that we get rid of the emissions that are going towards the safety staking module because, as we argue, it's not a particularly useful place, it's not a very useful way of spending $DYDX.

Cliffton (dYdX Foundation):

Got you. Thanks. That's super helpful. I guess we can start with a few questions, so feel free to request to speak and I'll bring you guys up to ask your questions to Max.

First question: you mentioned that the safety module is like an insurance pool for the protocol in event of a black swan event. Currently, the safety module sits at 37M $DYDX stake and our TVL is roughly $367 million.

So it's roughly 10% of the total TVL. It seems like the protocol doesn't necessarily meet its insurance pool to be equal to the entire value of the TVL and perhaps we should be looking at a third-party insurance solution, which would make more sense than self-insurance because it's going to be far more capital-efficient. So what are your thoughts on that? Should we be looking at other insurance providers like Nexus Mutual for example, instead of doing it internally?

Max (Xenophon Labs):

I think that's a wonderful question, and I just completely agree that would be a lot better than self-hosting this. One benefit of doing it on our own is that we don't need to pay a fee to a third party.

However, I will say a lot of the cost of this, running this module is paying for people's cost of capital, right? They are taking their money and they need to put it into this module and they don't have other things that they can do with it.

In the case of a mutual or an insurance fund that can cross-insure across several different, among several different customers, then that is a lot more capital-efficient as you mentioned. And so the question is just like, "Okay, why aren't we doing this right now?" Well, it comes down to the existing insurance providers. I can see two ways of going about this and we didn't find a good way, a good practical solution for this.

One of the ways that you could go about this, as you mentioned, is something like Nexus Mutual. However, if you look at the overall liabilities of dYdX, Nexus Mutual is significantly smaller, so you can imagine ensuring some portion of the deposits that are in dYdX, however, you wouldn't be able to come anywhere near the total amount of deposits.

So we didn't think that it was a very scalable solution. Don't quote me on this, but I last looked, Nexus Mutual was sitting around maybe a $100 million TVL. And so if we were to even insure a third, or a fourth, I guess, of the dYdX protocol with Nexus, we would be doubling the size of their TVL or their outstanding notional.

So it's something that we would maybe be too big to do in a meaningful way and obviously, it would destroy the benefits of their cross-insurance because if half of their risk was on a particular protocol, their whole idea of doing a capital-efficient mutual evaporates because they have so much risk concerning one customer.

So does that make sense? I think it's more of a practical question, how would we practically do this? I think that's the bigger concern than me having an issue with the in-theory idea of using a third-party service provider for this.

Cliffton (dYdX Foundation):

Thanks for pointing it out. I just looked at it quickly. And Nexus Mutual's total TVL stands at $180 million, so you're right. It's going to just complete their risks on this one protocol. Cool. So TokenFI has requested to ask a question.

Jason (Blockchain at Columbia):

I have a question about eliminating the safety staking pool, as you mentioned. How risky is that to not have a staking pool?

Is there any timeline in mind for how long the protocol won't have it? And yeah, I'm just curious about the risk you think is being taken on, versus having a poor staking pool, poor insurance versus no insurance at all.

Max (Xenophon Labs):

Even if the insurance power of the staking pool is much lower than its nominal value right now,  it's still not zero. The question is just should we be paying that much for what we're getting?

I don't know exactly how to go about it, right, because I would have to put some probability or some estimate on the probability of the protocol being exploited or having a shortfall event for larger than the amount that could be covered.

I think, right now, dYdX Trading Inc. uses the liquidation fund. Whenever they perform a liquidation, they use the, I suppose the profits that they get from those liquidations for their version of an insurance pool. And it has I think somewhere around 17 million or 18 million $USDC in it currently.

So for small exploits or small shortfall events, that should be ample to cover for it. And then in addition to that, governance has additional means to cover any issues. Of course, that would need to be decided by governance. And so I'm not claiming that those funds necessarily would be used, but yeah, so that's the idea. I don't know if you have any more questions.

Jason (Blockchain at Columbia):

That makes sense. You briefly mentioned 18 million $DYDX or $USDC for a small shortfall event. Do you have a number in mind for what would be a good insurance fund for a larger shortfall event? What the goal is in the future?

Max (Xenophon Labs):

Honestly, no, because it's a pretty challenging problem to estimate the distribution of possible attacks. And we didn't want to put numbers on that because we couldn't come up with any really good methodology for doing so.

I think what would be nice is if there was an external service provider that was able to insure a very substantial amount of the protocol or to look for other solutions via mechanism design. Other decisions could be made at the protocol level such as limiting how much can be withdrawn per time or putting caps on that. I mean, a lot of that would come at the expensive user experience, so I'm not recommending that, necessarily.

But there are several ways that you could limit the bleeding, so to speak, in a shortfall event. And that would allow us to put tighter bounds on how large a shortfall event would be.

But no, the best methodology that I could give you right now for how much we should insure would be like, well, if it's cheap enough and it's not that risky to have funds on dYdX, then why don't we try to insure as much as possible up to the TVL. But yeah, this is as much... It requires some estimation and we didn't provide any methodology for doing that well.

Cliffton (dYdX Foundation):

Cool, thanks for the question. So we have another question here - what are your exact recommendations on the replacement of the current safety sticking module? I know you briefly talked about having a Balancer pool or creating a $USDC safety staking pool, but can you just talk through the four recommendations that you put up? What are some of the pros and cons of each?

Max (Xenophon Labs):

Yeah, sure. So I'm happy to start with the $USDC safety staking module.

So the $USDC safety staking module would have the benefit of matching the exact liabilities of the exchange. So presumably if the exchange is still using $USDC as its collateral, as basically as it's the collateral asset that traders use in their margin accounts if it continued to use $USDC, then having a token that matches the liability of the exchange is a pretty clean solution for what you should use as the staking asset, right? Because whenever you do that, you're no longer required to estimate the conversion that it would take to make folks whole again in the case of a shortfall event. So I think that that's a pretty powerful and clean solution.

And again, as I said, we also considered the Balancer case in which if folks who were depositing into the safety staking pool wanted to also earn liquidity provider fees, for instance, that's something that you wouldn't be able to do if you were just putting $USDC into the pool.

And so if we are concerned about capital efficiency, we could start looking into things like Balancer. Another nice benefit of putting in a $DYDX/$USDC/Balancer LP token is also that you're able to retain some exposure to $DYDX. So this was seen personally as a compromise between what we have today, which is a fully $DYDX safety staking module, and what in the fully $USDC safety staking module, that was also proposed as a potential solution. You could imagine the Balancer pool achieving this trade-off where you have some $DYDX you have some $USDC, and the added benefit is that you're also able to earn fees from it. So that was our thinking with the Balancer one.

In sum, those are the main two solutions that we seriously considered for going forward for the safety staking pool.

Cliffton (dYdX Foundation):

Got it. Thanks, Max. I encourage everyone to go onto the forums and review the paper that Xenophon Labs has written.

Going back to the proposal, what you're proposing right now is to wind down the safety module, correct? Are you intending to remove this pool in its entirety or are you looking to just stop the emissions right now?

Max (Xenophon Labs):

Yeah, so that's a really important question. So, for anyone interested in the implementation of this, it's extremely simple.

So since it's a smart contract, it is immutable and it's not a good idea. I think even if we could, it's not a good idea to fully destroy that smart contract. Instead, we're planning to stop forwarding token emissions to the stakers in that pool.

Cliffton (dYdX Foundation):

Got it. Yeah, I think a few community members have expressed their concerns that it's going to be extremely risky, to remove the safety pool in its entirety. I guess the last question on my side is, do you think there are any implications to V4 if we wind down the safety sticking module right now?

Max (Xenophon Labs):

It seems pretty separate. I mean, of course, the amount of, I guess looking from the liabilities of the protocol, I don't know how the total outstanding amount of deposits will change going to V4. I don't know if there were going to be more or fewer assets on the exchange, but there's nothing really obvious that I see that means that we should wait to do this until V4. I haven't seen any super hard connection there.

Cliffton (dYdX Foundation):

Gotcha. Thanks. Cool. All right. If anyone else has any questions, feel free to request to speak and I'll bring you up on stage.

James (dYdX Foundation):

Max, thanks for coming on. It's good to have you here and thanks for all the great work you've done in grants V1 and V1.5 so far.

Just a quick one just to allow me to understand it a little bit better. Obviously, with dYdX Trading Inc. and V4 coming up, there's still some discussion around tokenomics changes. There are several posts on Commonwealth recently. I know the dYdX Trading Inc. and you are looking into tokenomics. Are these proposed changes translatable or will this require in-depth research coming around Q2 next year?

Max (Xenophon Labs):

I think that's a good question. I think it's similar to the last question unless I'm understanding wrong. I think that this is mostly separable from V4, right? The interesting components of V4, right? It is on an app chain, with all the new tech and infra behind the scenes. I think that this is fairly separate. So I mean, I can speak honestly on my end. I don't think this is going to create any more work for Xenophon Labs.

I think, if anything, it's going to create less work for us going forward. If we were to get rid of the safety staking module, we wouldn't have to worry about doing any more research on it. And so I don't foresee us doing any more work on this concerning our token design grant either. Yeah, let me know. I don't know if I quite answered your question, so let me know if you have any other components of it.

James (dYdX Foundation):

No, that makes sense. Thanks for that Max.

Cliffton (dYdX Foundation):

If you guys have any questions for Max, feel free to request to speak and I'll bring you up on stage. We have TokenFi with another question.

Jason (Blockchain at Columbia):

I have another quick question.

I think getting rid of insurance completely and getting rid of the safety module, for the time being, seems concerning. Have you thought about lowering the APR so we're not paying as much, at the same time we still do have a safety module in a place where people will be earning some yield for their $DYDX?

Max (Xenophon Labs):

Yeah. Do you want me to focus on giving people yield on their $DYDX, or do you want me to focus on the insurance power?

Jason (Blockchain at Columbia):

The insurance power.

Max (Xenophon Labs):

I'll ignore the part about yield on their $DYDX. For insurance power, there is still some between $17-$18 million in $USDC that could be paid for a shortfall event at the drop of a hat. There's a fund specifically for that. After that, there are still a lot of tokens that could be contributed, perhaps from the treasury, in the case of a shortfall event.

Yes, there will be less insurance power for the protocol is the short answer, but I don't agree that it's going to go to zero. There's still at least going to be between $17-$18 million for smaller shortfall events.

Max (Xenophon Labs):

I saw that Chris Blec responded to this tweet, so I was hoping we get him on.

Cliffton (dYdX Foundation):

Okay. Let me check it out quickly.

James (dYdX Foundation):

Max, is anything exciting coming up over the next few months from Xenophon Labs? Are you working on other projects as well? What's going on in your world?

Max (Xenophon Labs):

Yeah, so we're excited. We're working on the $DYDX V4 token design. So that's coming from a community perspective.

Because what happens with the $DYDX token is a community decision going into V4. So yeah, I mean it's going to look like a lot more of the quantitative work that we've done before. Looking into the mechanisms that exist on dYdX today, seeing potential new ones that we could implement going forward, looking into some of the corner cases of what running your own app chain might look like once you move into public and shared infrastructure, rather than centralized hosted stuff, comes with a lot of interesting problems.

So, yeah, we're excited about working on that and thinking about dYdX quite a bit.

Cliffton (dYdX Foundation):

So Max, can you just quickly talk through when you are looking to potentially move this towards a Snapshot poll, and then maybe I can just talk through the community and the audience here on what the process is moving forward?

Max (Xenophon Labs):

Yeah, absolutely. Since I think some people may be tuning in or just starting to think about this proposal now, I'd like to at least give till Friday to wait and see if there's a lot more discussion. And if there isn't much more discussion on it, then I'm looking to bring this to a Snapshot proposal on Monday.

Cliffton (dYdX Foundation):

Before we end the session, I wanted to touch a little bit more about how the implementation would go after the Snapshot.

The Snapshot is going to run for roughly four days, and this is an off-chain vote. Once we get a clear sentiment from the dYdX community on how the vote goes, if the vote supports the winding down of the safety module by reducing or eliminating the emissions rate, Max will need to move this on to an on-chain vote. The on-chain vote would fall under the requirements of the short timelock.

In terms of timing, implementation from start to finish could take as little as 2-3 weeks.

So with that, we can end it. Thanks, Max for again joining and answering all of the questions that the dYdX community asked. Thanks, everyone for tuning in. Again, this entire conversation was recorded, so we will transcribe it and post it on our blog. If you guys have any further questions for Max or the dYdX Foundation team, feel free to visit the forums and post your questions there or DM us on Twitter if that's something that you prefer to do. And with that, I guess we can end off this Twitter Spaces. Again, thanks to everyone for joining, and thanks, Max.

Max (Xenophon Labs):

Thanks, everyone.

Cliffton (dYdX Foundation):

Thanks, everyone. Have a good day!