DAPPCON 2025: Forget Retro-Build, Ship, Earn - Denisse Halm
DappCon 2025 · June 2025 · 23:12
Denisse Halm's talk is framed, as its own title states, as forgetting retro-build in favor of a build, ship, and earn approach. It situates that framing as a question about how builders and contributors in Ethereum's ecosystem get rewarded for their work.
Topics
From DappCon 2025, hosted by Dappcon Berlin.
Transcript
Hi. Hi. Hi. Good morning or good morning mug. Um, I'm Denise. I'm co-founder of Divi and I'm here to share a little bit about our thinking around builder funding. So, I'm glad you can see these slides. Um so as an ecosystem as a community in web 3 we know that billions of dollars have been given out to uh as incentives grants programs retrofunding hackathons to fund builders over the last I don't know 10 plus years. Um yet we know also that all those builders that have
received funding have kind of failed to deliver the user adoption and the onchain usage that we expected from that funding. And so we have billions of of dollars spent or euros spent and there's no product market fit. Users still don't know where to get started, how to join and how to start getting value out of out of this ecosystem and all the products we've created. um there's only like 30 to 60 million crypto holders. So these are really passive individuals who um hold crypto and a very small percentage of them you can see on this chart um are actually active trading, exploring and getting value out of web 3 every day or every
week. Um so what's the problem? The problem is that grants are not rewarding the long-term impact and delivering the products that we want or we envision will bring the users uh into the space. um billions again spent hackathons organized a lot of overhead um we see this quote here that after two weeks after or a couple of months sorry a couple months after Bangkok Dvcon um there were only two out of 100 sorry 80 deaf participants in a hackathon they're still actively building right so we have created this culture of of bounty hunting uh in hackathons
so what's also happening ing beyond hackathons is that the grants process has become really political. Um it's very subjective and and resource intensive. Um the builders that are rewarded, they are the ones that maybe know people on the grants teams that evaluate and make decisions on grant dispersements. Um they uh are have to do a lot of networking. They have to become really good writers and all of this is energy and time that builders are spending on navigating the grants process rather than building and innovating on UX to deliver the products that we want.
So what we've came to come to the conclusion is that web 3 has a growth problem because it has a broken incentive system. the incentives that we been putting out there, they are rewarding the wrong behaviors and they're creating an unsustainable growth loop for web 3. So let's talk a little bit about this uh web 3 funding trap. The first part is that as I mentioned the grants, programs, hackathons, they're not really delivering um the incentives to those that create value and are driving onchain usage.
They are funding the incumbents. So big projects that have an early mover advantage or that have great connections within an ecosystem are the ones that get funding the most and uh then they like are the ones that are able to move forward and continue innovating leaving others behind. So the builders that are left behind, the smaller builders, the ones that are trying to get into the space, they are focused on optimizing for grants, right? If we think about a hackathon, there's like so many bounties at a hackathon and hackers try to build products that apply to or apps that apply that can make them
eligible to apply to as many bounties as possible rather than focusing on the user problem or on the vision that they want to execute on. So start optimizing for these um broken incentive systems to try to get some support for for continuous building. And so what happens is that more is spent on these hackathons on these grants programs and the ROI starts to go down because the spending goes up but the onchain usage the number of users we see on chain the number of transactions we see happen keeps going down. So the ROI decrease decreases for the ecosystems, the foundations of layer ones, layer 2s and there's less funding out there for builders and so when funding dries up in
one ecosystems, what do builders do? They are burned out and then they migrate to the next ecosystem where funding has started to emerge and try to get this early mover advantage there. Okay, so to recap a little bit this uh funding uh cycle that I just described, the top projects get the funding earliest and then they start to form these modes, right? Like they the projects that get these this early funding, they are the ones that are able to innovate faster and the other ones are are left behind. So the competition is no longer an even playing field. The smaller builders have to do this beauty contest. What does that mean? It means that they're optimizing for what they
think the grant committees are going to vote for or what one of the members is going to advocate for internally instead of focusing on building and shipping results. They're focused on like what's going to make them win the next grand contest. And so how does this end up? The early movers, those incumbents that have the modes, they have an efficiency advantage because they received all that funding up front. they are likely if they are a top mover or early mover they had funding from outside the ecosystem like VC funding and so they're able to move fast and evolve but that's really a handful of builders it the rest they're not able to compete they're not able to innovate on the user feedback that they
receive and so they're able to deliver less onchain usage through their apps the ROI keeps dropping and then grants just start drying up as I mentioned and so small builders innovators they're completely burnt out. They are not able to um respond to the UX challenges of their users and and really evolve their products. Instead, they just move to the next um ecosystem. As I mentioned, they built very fragmented products and there's just like a lot of um unintuitive user experiences out there.
So, these burntout builders, these poorly built apps, it means we have no new users in web 3, right? like we've seen liquidity and users migrate from one chain to another as these um kind of come up. They are new and they're exciting, but there's no new users and no new usage really coming on chain. So this is the growth cycle that we're in. It's kind of like a vicious cycle in my opinion and it's hurting our growth as a community. We have these misaligned incentives and these poor builder experiences and the poor growth outcomes for web 3. So we have two comparisons here like grants and retro they're like kind of different types of grant funding um grants fund intent they're slow
competitive the application process for certain grants can take a builder multiple weeks to complete and the ROI is really unclear for retro it's all about getting visibility and so um that's what's rewarded rather than the onchain impact very political and unpredictable and that's what really leads to ecosystem hopping Um I was chatting to a friend yesterday who's an app builder and uh his opinion was that retrofunding is nice for the devs of the builder team of the project um because those funds they the impact has happened such a long time in the past by the time they get the retro funds this go into the let's say the DAO or the app
treasury the organization projects treasury and then they pay out bonuses to the deafs and as a deaf that's really nice but in terms of creating a flywheel that will bring more value on chain to those chains that are giving out the retrofunding that's not really there because the incentive the paying for that retrofunding happens so much after the impact and so it's not really generating this flywheel of of continuous onchain growth. Okay. Um so it's on the builder side it's really no fun either. So it's not just on the ecosystem side that they spend a lot of money. Builders are reporting that getting a grant is
extremely complicated. I mentioned um how long it takes to do the application process and submitting all the data and reporting although it's onchain data has to be submitted anyways. Uh but there's also this bureaucracy to it. here in this tweet. Uh another friend uh reports that it took so much paperwork to receive $232 of funding um from optimism and salo. So it's it's a lot of work, a lot of bureaucracy for um very little payout and something that web 3 supposedly should be able to do really efficiently, right? Like pay especially a builder um would have been in this person's opinion more efficiently via PayPal. So that's kind
of like sad I think. Okay, so moving on and like reimagining how this all could really change or should change to drive that flywheel that I mentioned of like paying for impact or incentivizing impact onchain impact that then can turn into more onchain impact. So imagine if builders can ship fast, find product market fit, get user feedback, and actually iterate on the user feedback and then grow their products and their users on chain usage or traction faster. That's kind of like the perfect product flow. Imagine if builders could focus on building instead of focus on applying for grants. um they
could receive incentives automatically because all of uh all of all the things you want to incentivize is onchain traction, right? Like we want onchain growth. We want more transactions, more users, more gas usage. And so that should all be tracked on chain because, you know, it's a public ledger. And so there's no need for there shouldn't be a need for reporting for applying for these things. It's all transparently out there. And if this were to happen, then builders could really monetize their usage and use those uh that way of monetizing to like fuel more usage of their products.
Huh. Okay. So, I'm with Divvy, as I mentioned, I'm a co-founder of Divvy. And Divvy, we're doing we're trying to do exactly that. Um DV is the first onchain protocol that allows ecosystems like layer ones layer twos to pay builders app builders only when they drive onchain results onchain impact onchain usage that is measurable on chain uh avoiding grants avoiding the guessworks the politics and the overhead so I will talk a little bit about um the now and how it works so here's the vision the vision is is this three stakeholder um kind of ecosystem system where the protocols layer ones, layer 2's, DeFi protocols, they launch an onchain incentive campaign uh to unlock
builder growth. So this is an incentive campaign that defines exactly what onchain growth means to that protocol. Is it number of transactions? Is it number of users? Is it gas consumption? Anything that can be measured on chain. The builders sign up for this campaign. they register on chain and they start driving um building apps that drive that onchain impact. So that are really delivering on the growth that the ecosystem um is incentivizing and so they can do this um permissionlessly because it's onchain.
So they don't need to know uh members of the teams that are funding these incentives campaigns and the builders are building these apps are able to innovate on their user feedback and are therefore driving users very efficiently through go to market efforts to those apps and to the chains that those apps are built on and those users are the ones that are bringing more uh value on chain new value on chain and more usage of the chain. So the idea here you see here on the right side is that incentives for builders become really smart. They're really transparent because they're fully on chain. They're fully based on that onchain growth that we really want to see as a community. They're permissionless. So it doesn't matter who
you are as a builder. If you're driving that onchain impact, you can get the incentives. You don't need to know anybody or be located in a specific place or be able to attend a conference in a beautiful city like Berlin. Um and it's outcome based. So it's only paying when the outcome that onchain growth that we want to incentivize happens. It's not for anything that happens. We're not paying for anything that is happening before the onchain impact. It's that's there's different programs for that. The idea here is to really incentivize the actual growth. So how it works again in the in the framework of these three stakeholders.
The protocols they define the outcome as I mentioned it's we call it the onchain KPI. They find the rewards contract. This is a smart contract. We call it reward pool. They deploy it uh and they set the duration of this uh rewards campaign. The builders they integrate Divvy through our builder hub. It's about 10 lines of codes, just a couple snippets and they start onboarding users to the product. They don't have to do anything else about like the funding. They just start uh driving usage to their product and the users as they're onboarded to these products, they transact. they bring value on chain and uh all of that users activity is measured by the Divvy protocol through that integration that builders did and so Divi is able to attribute all of the
users onchain actions and usage to that builder and that is what determines how much funding the builder gets. So based on that verified onchain impact that the users have through the apps, the builders, the app builders are receiving um incentives for that verified impact directly from the protocol through the DV campaign contract. So we have a couple of campaigns live already and we've learned so much. I'll show share that in a second. But first, why do these growth teams and like layer one teams, layer two teams, uh on the protocol side, why do they love it? um they love it because there's no overhead. They don't need a team of 10
people to reach hundreds of builders uh to incentivize them and to even understand the type of impact that these builders are driving on chain. It's very scalable because the divy campaign because it's permissionless and it's on chain can serve five builders or thousands of builders. anybody can sign up and uh it's really high ROI for the for the growth team because they're only paying when the builders are driving the onchain growth, the onchain impact that is defined by that KPI. Any funds that aren't used uh at the end of the campaign, the the growth team or the protocol team can claim back. So, they really keep the full control. It's very very um automated and efficient for
them. On the flip side, for the builders, why do they love it? It's very transparent. the same reason but it's very clear what kind of incentives they will get for the impact that they will drive. They don't have to do the politics dance or game. They don't need to be fluent in a language. So it's maybe different to their native language to be able to apply to the grant. So all of that like time consuming grants application process and reporting is is gone. It's very transparent attribution. So they themselves can understand I got this much in incentives because I drove this much impact or my users drove this much onchain impact. It's all transparent and and all that data is available through a divy um app and that that's what uh results in the builder's
long-term commitment to a protocol. They have predictability because these campaigns keep going live. These protocols launch multiple campaigns. They iterate and um they know that they will be able to continue uh receiving incentives. based on the on the impact that they drive because these campaigns are super transparent. So with divy we like to say that we Divi helps grow the web 3 pi for everyone for protocols for builders and for users. So the way the campaign works is that the top used apps so the apps that drive most onchain usage they're still the ones that get the most right like it's proportionate to how much uh onchain usage they're driving. Um but it's not just the top builders. Every build that
is driving onto usage will drive will get a proportionate share of the campaign pool. They just have to register for the campaign. So all participants in a campaign get something that is prata based on their impact. And so it's it's very um transparent and fair. Right. It really incentivizes post impact rather than making guesses on who is going to have the most impact or grow the pilot west. So what's the result? There's no early advantage. There's no modes. Everybody can sign up at any point in time during the campaign. Any builder with an app that is live on mainet can sign up.
um there's more funding available when the ROI goes up because it becomes even more efficient for the foundations, the ecosystem growth teams to to fund these campaign and so continue to um fund the builders that are driving the most impact and the small builders will win more. Again, there's no politics, there's no overhead for them. They can really just build, ship, and earn. So, here are some of the protocols that are using Divvy today and some of the ways that they're using it or or planning to use it. Some of these are not live yet. Um, VA is a they're creating data dowels and so they're are L1 for user owned data. Plume is RWA chain who launched recently. Plume is
looking they their mainet was literally a week or two ago. So they're going to use divvy to incentivize their test net builder community to deploy on mainet really fast rather than wait for I don't know months. It can take it can can take a lot of time. It's kind of like putting a carrot in front of the builder be like if you deploy fast you have all those rewards or the these incentives to claim. Tether is planning a campaign to drive circulation of USDT. Uh I'll dive into the sell public goods the sell DAO campaign in a minute. Uh we also have one with Lisk and we're also experimenting with a builder communities to um grow our own builder community that is participating in multiple campaigns with Scott game.
So this is a Cello DAO campaign, Cello public goods campaign. There's 105 builders. I think the campaign is like four weeks in now. So some of this data on the chart is a bit outdated. 50,000 unique users um referred or or participating or using Cello as a as a chain through these 105 builders and a ton of gas usage. So the KPI that Cell Public goods is incentivizing is gas usage on Cello because that's Celos's revenue model as a layer 2. Um Cello public goods knows all the builders. So they're doing all the builder registration on boarding and I have seen already week sorry the first month if you compare the first week of the second month in purple to the first month of
the campaign um gas consumption has already doubled for um the top builders. So it's really like providing that flywheel like if you provide incentives to builder they'll just drive more onchain usage in the next round. It's very easy if you're a protocol or growth team to launch a campaign. You define the KPI um you define the budget and the duration of your campaign. We the team the core team behind Devi can help you implement what we call the impact rewards function. So how much you're going to provide incentives per unit of impact. uh you find your smart contract, deploy it and then we go into builder onboarding and it's all then automated on the on the DV dashboard from there. The builders to integrate some snippets of code. It's it some
people report that it takes like two hours maybe half a day depending on how web 3 native uh the app builders are and then together we grow the pie. So the builders build, the onchain value grows because they bring more users and uh Divvy is able to track and attribute all of those users onchain usage to that builder in real time. And builders can go to the Divvy dashboard and claim rewards at the end of each reward period based on all of that traction that they drive. So this is how we rethinking web 3 funding. We're moving away from hype and from politics.
um from manual like outdated process into impactbased funding of builders uh automated so they don't sink in time and paperwork. They can sink in or not sync that's not the right expression but like invest time in evolving their UX and their product. And what is really nice is that it's permissionless. So no builders don't need to know anyone. they can just start experimenting or they can be really further along their uh builder journey and their app um growth and they can join DV uh Divy's campaigns at any time.
So the idea is to forget Retro and for builders to ship uh build ship and earn. So if you're a builder, you should head over to app.dvy.xyz. You can see all the live campaigns and also past campaigns there. uh depending on which protocols you're building on you can even sign up for for some of the campaigns. Now you can join a telegram community that's uh what the QR code is here for and get updates on new campaigns that go live or or follow us on Twitter as well uh with uh let at levy. So we're ready for the next evolution which is one where we don't fund hype, we fund outcomes. Thank you.
[Applause] Thank you, Denise. Okay. Funding uh in the Oh, before you go, we have some some questions with the with the crowd. Great. If you can spare a few minutes. I was just going to say funding in the Ethereum ecosystem is a design space that has interesting challenges. Um, and if we have any questions for Denise, uh, before we go to lunch, now is your opportunity. If not, we'll let you go.