Understanding DePIN Value Flow | Mustafa Qazi - Volt Capital

Okay. All right. Okay. Okay. Good afternoon everyone.

We're back and the first talk after the break is about how to build a deepen protocol and I've got Mustafa here from Volt Capital who is uh doing research engineering at World Capital and he'll be talking to us about deepen protocols today.

All right.

Okay. Good afternoon. So, uh yeah, I'm do research at Vault Capital. Um previously did research on EIP559 at the Ethereum Foundation and then at Sixman Ventures before joining Vault. So um I focus on deepin I focus on how to build better deepen protocols um because I think it's a very underexplored space.

Um, so yeah, let's talk about uh a big question. Is deepen dying? There's been a lot of FUD recently about this. Um, and I think it's based on some of these metrics that you see. You know, like the multiples are pretty crazy.

There's in aggregate $72 million of revenues compared to $10 billion in market cap. The revenues are low. They're not very consistent. They're kind of cyclical. Um, in the case of things like Helium, they happen with kind of centralized partnerships.

So, it's outside of the decentralized models. Um, and a lot of this FUD is just kind of insinuating that maybe this is a speculative bubble. This is not a way to build infrastructure. So, we're gonna kind of hone in on three critiques here. One is that inflationary tokens are not sustainable for building infrastructure.

One is that Deepen is trying to build perpetual motion machines by kind of creating this network effect that will continue to kind of manifest itself and build on itself. And that verification of service when you go decentralized is an unsolved issue. So, in order to better understand that, um, what I'd like to do is kind of zoom back out, talk about production systems, infrastructure systems in general, um, with outside of a deep context, and then think through what happens when you decentralize, um, and what that the challenges are posed to protocol designers. Okay, so let's talk about infrastructure systems. So, uh, this is my framework to kind of think about the primitives of an infrastructure system.

I think there's three inputs. capital which is like the GPUs the sensor whatever the infrastructure is those nodes operational effort so that's maintenance you know provisioning those nodes uh electricity the inputs to run those nodes and then coordination so like routing um you know load balancing quality management pricing all those things are kind of the coordination layer and obviously it all goes towards one output which is service bought by users I think deep pins decentralize the first two inputs so you know instead of me as centralized entity acquiring all this capital. I'm going to decentralize this to other people to bring their own capital and they get a piece of the pie in in in exchange. That's kind of the idea, right? You may think that coordination should also be decentralized if you're talking about deepen, but I think it's different.

Um it's actually everybody's playing in one protocol which is kind of set by a centralized entity. So I don't think that that is a decentralized part of this. That's that's an input that remains somewhat centralized because the protocol designers, it's their task to design a good coordination system so that it actually works. And that's kind of like the point of what we're talking about today. So, as a thought experiment, pretend you're in a pretty deepin world and you have this idea, you're you know, you want to be a founder that you're going to build a competitor to Google Maps because the traffic data is just not accurate enough.

So, your idea is what if we crowdsource people to bring in sensors, right? you can set up a sensor on your street or a highway near you or something. I don't know how safe that is, but in a way where we can get real-time accuracy. Um, this is kind of like our thought process and and and it's important to note this is a pre-deepin world, right? You just had this idea.

Now, I'm going to we're going to think through, okay, how do I implement this? What what are the what are the challenges to do this? First thing you should ask is why, right? So, in this vertical depends are various, right? They're the verticals are different.

um in physical things, location dependent things. One really important thing is geography. You want to be able to spread out and get as much infrastructure in many places as possible, right? So, if you do this in a decentralized way, it sounds like a good idea, right? It's it's much easier to to not have all that capital expenditure.

You can bring those people in from different areas and you know, it's much easier to stand up that infrastructure. Risk also uh if you're a centralized entity, you have one risk profile and you need to manage your business in that way. With decentralization, you have you kind of open this risk aperture, right? And you have other people's varying risk profiles. Um that that can be a great benefit, too.

It allows you to be a little bit more um dynamic in the way that you can spread this infrastructure. And then the last is reactive supply. So in centralized models, if I have a bunch of infrastructure and nobody's using it, then I'm bleeding money and um that's just not a good thing. So in a decentralized market um the idea is that a market will kind of prune off excess supply right this is not real time but that's kind of one idea that you might think is oh this is a beneficial aspect of of going decentralized right but then we should think about what changes so this is I think where we need to slow down and a lot of protocols do not slow down and think about what are the new issues that are arising that we need to address in a deepen protocol so I have four listed here demand prediction which um uh Basically the the idea is when you decentralize and you want to put um new infrastructure in places where there's new demand, you need to now publicly signal that to your nodes and that needs to be priced in. That is not a trivial issue, right?

That's a dynamic pricing issue. You need to figure out how to incentivize people to come to an area. That's a new issue that you need to solve. Bootstrapping, right? In the centralized model, it's simple.

You raise capital, you go buy, you know, infrastructure, you deploy it, whatever. Uh there's the cold start problem in deepen, right? you there's no supply so nobody's going to come use your service so there's not going to be anybody who wants to give you the supply right it's this chicken and egg problem that you need to address this is one of the major issues that I think you can trace back to kind of the failures in deepen and then quality assurance right in a centralized entity it's much more it's much easier to trust that that the service being provided is of quality right um the issue with the decentralized model is now each of your nodes is an adversary and they can lie to you and they can try to game you and and kind of make money off of you in kind of like a moral hazard way. So that's a new issue you need to work with, right? You have a game theoretic aspect of this business now.

And then revenue distribution. So um you have to figure out how to do pricing, how to reward people, it becomes part of this game, right? Back to this game theoretic idea. Now that you have adversaries which are also your infrastructure, that's a much more complicated issue. So what we'll do is we'll go through these problems.

We'll think of a way to solve it and that will kind of give us requirements, right? And this gives us a structured way of thinking about what does a deepen protocol actually need. So the first one the question you're really asking is if when you're trying to incentivize demand in an area say in our in our mapping protocol we want um in some really high traffic area we want more nodes there there's not enough coverage. The question you ask is what is the minimum premium I can pay operators so that enough of them come and I get enough coverage in this area. So that means we need to be able to track operator histories.

We need to be able to track this data so that we can dynamically price these things and learn the best way to price this so that we can incentivize the right amount of people and not too many people and not and not enough people, right? We need enough capital or enough uh infrastructure in an area at any one time given the demand. So, you know, there's plenty of ways to do that, but this is one of our requirements. The other one is solving the cold start. So, we have to build out the supply first.

I think a lot of people think it's a chicken and egg where, you know, does demand come first or supply? I argue that you need to have supply first. It's very rare that you're going to have a a deep pin where you're going to have a bunch of demand for a service that doesn't exist yet, right? So, this is something that we need to figure out. We need to subsidize initial supply when there's no money coming into the network yet so that we can stand up an actual infrastructure network.

This is also something that people just thought that tokens would solve and we've kind of seen it doesn't do that um for I think somewhat obvious reasons in hindsight. quality assurance. So operators are now adversaries. As I said, we need to ensure that any bad behavior is not profitable um and that you can punish people for doing bad things. So to avoid moral hazards.

So without control over these individual people, we need some mechanism to verify that people are doing the work they're saying and that it's good quality work. Those are very important so that people who are using your users need this requirement. This is extremely important. And then revenue distribution. So there's a lot of questions that come with revenues.

One thing is you'd probably want it to be global. So crossber payments suck. They're slow. Um this is obviously hinting towards blockchain, but um we need to be able to dynamically adjust revenue. We need to be able to do this globally and and distribute it globally.

Okay, so these are all those requirements listed. I'm not going to read them out, but this is what we just did. It was it was the ones in blue. Now we're going to say the first question because remember we're in a pretty deepened world. Can we do this without blockchains?

So the first one, yeah, you can track operator histories with a database. That's not that hard, right? Subsidizing initial supply, we can raise capital to deploy, but that kind of kills this whole point of this decentralized thing. We wanted to not have to do that. Um, so that doesn't really get solved without blockchains.

We need something else. Um, a mechanism to verify that work is done accurately. Well, we need to hire a QA team or introduce auditors into this. But now that's really much more complex. What are the auditors incentives?

How how do they get how do we like audit the auditors? this this becomes an issue. And then dynamically adjust revenue splits um and distribute them globally. That's an obvious uh issue with fiat payments. It's slow and expensive cross borders.

Now let's go to blockchains. What do blockchain solve? Blockchain solves some of these problems, right? I think a lot of people assumed because when you think about it that oh blockchains, you know, verify work, they do all these things. This this is going to give us, you know, the solution to all these issues.

I think blockchain solved two out of these four. The first one is tracking operator histories. Natural place. It's a ledger, right? You can track how operators are performing.

You can do public uh you know easy to trust uh neutral pricing logic with with smart contracts. Um subsidize initial supply. This was I think the major assumption of most deepen protocols in like their first phases is that tokens will solve this issue. They can inject speculative value into this but you still don't have revenue. You need revenue.

So that's still an issue that blockchains do not solve. Now this next one, verifying that work is done accurately and that bad actors are punished. Blockchains do not solve this for deep at all. Blockchains can verify the provision of blockchains themselves, but they cannot verify work done outside of the blockchain. So that's an issue you need to work with.

And then dynamically adjusting revenues uh tokens are a natural solution to that. So the two things that are left generating demand there's no easy answer here. This is something that we still need to figure out for Deepen, but a lot of it looks like centralized deals with institutional customers. Um, building out that kind of that that kind of demand. Um, you know, go to market strategies, marketing.

Um, and on the supply side as well. We saw this with Helium. Um, doing things with T-Mobile, AT&T, those are things that actually let Helium become a profitable, not profitable, but a revenue generating protocol. Um, those are the kind of things that that are required. Like I said, there's no easy way around the fact that you need to build these things first and then verifying work.

So this is a hard problem to solve in general. There's very recent academic research on on you know incentive mechanisms that can solve this but prior contrary to what you might read in white papers there is no bulletproof way to verify work in any deepen protocol live on chain right now. It might be it might be resilient to a lot of attack vectors, but there I I I will always be able to show you an attack vector that they cannot solve for. So why do deep dins ignore these issues? I think it's because we inherit these L1 primitives, right?

L1 tokens secure consensus. They're used for pricing block space which has a lot of demand um and and the utility is directly related to the token or consensus. Um, and I think speculation, which was kind of the the the flywheel effect that helped bootstrap these these L1s, was great for bootstrapping liquidity. It doesn't do anything for infrastructure service, right? It just creates this other speculative bubble that doesn't have anything to do with the usage of your of your infrastructure or any revenues, right?

So, perpetual emissions make sense for L1's, but for DPIN, it doesn't really make much sense, right? So, I think this is the issue of of not inheriting these because it's building on blockchains. We assume that we can inherit all these primitives. A lot of these don't apply. This is a completely different thing.

We're using the ledger for two out of four of those requirements, not all four. So, one way to think about this is is like subsidy ratios, for example, which is the percent of the operator revenue that comes from emissions. Um, a lot of the deepen protocols right now have like standard set constant emissions. They're constantly inflating similar to L1's. Um, and that ends up being a huge part of how operators are being uh, paid.

I think that's obviously not a sustainable way to sustain uh, infrastructure at all. You need to have revenues that are that are coming into this. So, if you look at a at a at a ratio of those two things, how much of the provider uh, payment is through uh, emissions as opposed to revenues, then you can see it's pretty dire, right? Something like Filecoin is over 99%. Um, the best performing here is Helium due to the fact that these are as of Q4 2025.

Um, Helium, this dropped down pretty pretty quickly because they had like $1.5 million of revenue in November of last year due to those AT&T and T-Mobile deals because they actually had revenue. So, this is one way to measure the health of of a deepen protocol and how it's how it's tracking um with with building actual revenues. So, I think the what is the future of deepen design? How do we fix these issues?

I think demand responsive emissions is is is kind of you know BME which is burn and mint equilibrium kind of hints towards this but there's still constant inflation for no reason. Um having something related to uh demand and related to revenues for for emissions is the smart way to do this and the only sustainable way to do this. Um staking for verification. Staking is a lot of times used for like a token sync, but I think when you do that for verification um and this is related to some research on on peer prediction mechanisms and stuff on on how to solve these issues in deepen protocols, staking can solve a lot of those issues for you. So uh that's one easy way easy lift way to in uh increase the quality assurance of a deepen protocol.

Dynamic burn um this is something that we kind of have seen a lot. Helium kind of uh led this, but uh this is a still a great way to add some deflationary uh pressure to your token and continue uh building out a sustainable protocol and then planning for growth. So once you reach that level where revenues are starting to sustain your your your infrastructure, you should change the way that your emissions work. No deepen protocols actually have this written into their tokconomics. They have an infinitely um inflating supply.

So planning for that and and and rushing towards that as fast as possible is the best way to create a sustainable deepin network. Um because after that you can change your tokconomics to uh actually accommodate the fact that you have revenues and you don't need to overinflate and create these you know uh really volatile pricing uh uh token price actions. So is deepen dead? The answer is kind of, but hopefully uh we'll we'll iterate, we'll we'll come up with better designs and we'll actually go towards sustainable infrastructure in the future. Thank you.

I write about this on Twitter if you want to read with Vault Capitals Research. Thank you.