Forget Retro-Build, Ship, Earn

Hi. Hi. Hi. Good morning, or good morning. I'm Denise.

I'm co-founder of Bivi, and I'm here to share a little bit about our thinking around Builder Funding. So, I'm glad you can see the slides. So as an ecosystem, as a community in Web3, we know that billions of dollars have been given out to, as incentives, grants, programs, retrofunding, hackathons, to fund builders over the last, I don't know, 10 plus years. Yet, we know also that all those builders that receive funding have kind of failed to deliver the user adoption and the on-chain usage that we expected from that funding. And so, we have billions 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 this ecosystem and all the products it's created. There's only like 30 to 60 million crypto holders, so these are really passive individuals who hold crypto, and a very small percentage of them, you can see on this chart, are actually active, trading, exploring, and getting value out of Web3 every day or every week. 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 into the space. Billions, again, spent, hackathons, organized, a lot of overhead.

We see this quote here that after two weeks, or a couple of months, sorry, a couple of months after Bangkok, 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 bounty hunting in hackathons. So, what's also happening beyond hackathons is that the grant process has become really political. It's very subjective and resource-intensive.

The builders that are rewarded, they are the ones that maybe know people on the grant teams that evaluate and make decisions on grant disbursements. They 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 grant process rather than building and innovating on UX to deliver the products that we want. So, what we've come to the conclusion is that Web3 has a growth problem because of the broken incentive system. The incentives that we've been putting out there, they are rewarding the wrong behaviors and they're creating an unsustainable growth loop for Web3.

So, let's talk a little bit about this Web3 funding trap. The first part is that, as I mentioned, the grant programs, hackathons, they're not really delivering the incentives to those that create value and are driving on-chain usage. They are funding the incumbents, so big projects that have an early mover advantage or the have great connections within an ecosystem are the ones that get funding the most, and then they 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. If you think about a hackathon, there's so many bounties that 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 broken incentive systems to try to get some support 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 on-chain usage, the number of users we see on-chain, the number of transactions we see happen, keeps going down. So, the ROI decreases for the ecosystems, the foundations of Layer 1, Layer 2, and there's less funding out there for builders. And so, when funding dries up in one ecosystem, what do builders do? They burn 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 funding cycle that I just described, the top projects get the funding earliest, and then they start to form these modes, right? Like, the projects that get this early funding, they are the ones that are able to innovate faster, and the other ones are left behind. So, the competition is no longer an even playing field. The smaller builders have to do Canadian beauty contests. 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 are focused on what's going to make them win the next grant contest. And so, how does this end up? The early movers, those incumbents that have the modes, they have an efficiency advantage because they receive all that funding up front. They are likely, if they are a top mover or early mover, they have 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.

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 on-chain usage through their apps. The ROI keeps dropping, and then the grants just start drying up, as I mentioned. And so, small builders, innovators, they're completely burned out. They are not able to respond to the UX challenges of their users and really evolve their products, and so they just move to the next ecosystem, as I mentioned. They build very fragmented products, and there's just a lot of unintuitive user experiences out there.

For these burned-out builders, these poorly built apps, it means we have no new users in Web3, right? Like, we've seen liquidity and users migrate from one chain to another as these 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 Web3. So we have two comparisons here, like grants and retro. They're like different types of grant funding. 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 that's what's rewarded rather than the on-chain impact, very political and unpredictable, and that's what really leads to ecosystem hopping. I was chatting to a friend yesterday who's an app builder, and his opinion was that retro funding is nice for the devs of the builder team of the project because those funds, the impact has happened such a long time in the past. By the time they get the retro funds, they go into the, let's say, the DAO or the app treasury, the organization's project treasury, and then they pay out bonuses to the devs. And as a dev, 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 retro funding, that's not really there because the incentive, the paying for that retro funding happens so much after the impact, and so it's not really generating this flywheel of continuous on-chain growth. Okay.

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 how long it takes to do the application process and submitting all the data and reporting, although it's on-chain data, it has to be submitted anyways, but there's also this bureaucracy to it. Here in the suites, another friend reports that it took so much paperwork to receive $232 of funding from Optimism and Sello. So it's a lot of work, a lot of bureaucracy for very little payout, and something that Web3 supposedly should be able to do really efficiently, especially a builder, would have been, in this person's opinion, more efficiently via PayPal.

So that's kind of sad, I think. Okay, so moving on and reimagining how this all could really change or should change to drive that flywheel that I mentioned of paying for impact or incentivizing impact, on-chain impact that then can turn into more on-chain 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.

They could receive incentives automatically because all the things you want to incentivize is on-chain traction, right? You want on-chain growth, you want more transactions, more users, more gas usage. And so that should all be tracked on-chain because 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 that way of monetizing to fuel more usage of their products. Okay, so I'm with Vivi. As I mentioned, I'm a co-founder of Vivi. And Vivi, we're trying to do exactly that. Vivi is the first on-chain protocol that allows ecosystems like Layer 1s, Layer 2s to pay builders, app builders, only when they drive on-chain results, on-chain impact, on-chain usage that is measurable on-chain, avoiding grants, avoiding the guesswork, the politics, and the overhead.

So I will talk a little bit about Vivi now and how it works. So here's the vision. The vision is a three-stakeholder kind of ecosystem where the protocols, Layer 1s, Layer 2s, DeFi protocols, they launch an on-chain incentive campaign to unlock builder growth. So this is an incentive campaign that defines exactly what on-chain growth means to that 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 building apps that drive that on-chain impact, so that are really delivering on the growth that the ecosystem is incentivizing. And so they can do this permissionlessly because it's on-chain, so they don't need to know members of the teams that are funding these incentive 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 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 on-chain 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 on-chain 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. And it's outcome-based, so it's only paying when the outcome, that on-chain 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 on-chain impact. There's different programs for that.

The idea here is to really incentivize the actual growth. So how it works, again, in the framework of these three stakeholders, the protocols, they define the outcome, as I mentioned. We call it the on-chain KPI. They find a reward contract. This is a smart contract.

We call it a reward tool. They deploy it, and they set the duration of this reward campaign. The builders, they integrate DIVI through our builder hub. It's about 10 lines of code, just a couple of snippets. And they start onboarding users to the product.

They don't have to do anything else about the funding. They just start driving usage to their product. And the users, as they are onboarded to these products, they transact, they bring value on-chain, and all of that user's activity is measured by the DIVI protocol through that integration that's listed. And so DIVI is able to attribute all of the user's on-chain actions and usage to that builder, and that is what determines how much funding the builder gets. So based on that verified on-chain impact that the users have through the app, the app builders are receiving incentives for that verified impact directly from the protocol through the DIVI campaign contract.

So we have a couple of campaigns live already. We've learned so much. I'll share that in a second. But first, why do these growth teams, and Layer 1 teams, Layer 2 teams, on the protocol side, why do they love it? They love it because there's no overhead.

They don't need a team of 10 people to reach hundreds of builders, to incentivize them, and to even understand the type of impact that these builders are driving on-chain. It's very scalable because the DIVI campaign, because it's permissionless and it's on-chain, can serve five builders or thousands of builders. Anybody can sign up and it's really high ROI for the growth team because they're only paying when the builders are driving the on-chain growth, the on-chain impact that is defined by that KPI. Any funds that aren't used at the end of the campaign, the growth team or the protocol team can claim back. So they really keep the full control.

It's very, very automated and efficient for them. On the flip side, for the builders, why do they love it? It's very transparent, 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 that's maybe different to their native language to be able to apply to the grant.

So all of that time-consuming grant application process and reporting 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 on-chain impact. It's all transparent and all that data is available through the Divi app. And that's what 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, and they know that they will be able to continue receiving incentives based on the impact that they drive, so these campaigns are super transparent. So with Divi, we like to say that Divi helps grow the Web3 Pi for everyone, for protocols, for builders, and for users. So the way this campaign works is that the top-used apps, so the apps that drive most on-chain usage, they're still the ones that get the most. Like, it's proportionate to how much on-chain usage they're driving, but it's not just the top builders. Every builder that's driving on-chain usage 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 pro-rata based on their impact. And so it's very transparent and fair. It really incentivizes post-impact rather than making guesses on who is going to have the most impact or grow the pile the most. 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 mainnet can sign up. There's more funding available when the ROI goes up because it becomes even more efficient for the foundations, the ecosystem growth teams to fund this campaign and to continue to 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 Divi today and some of the ways that they're using it or planning to use it.

Some of these are not live yet. VANA, they're creating data dials, and so there are L1s for user-owned data. RWA Chain, who launched recently, their mainnet was literally a week or two ago. So they're going to use Divi to incentivize their testnet builder community to deploy their mainnet really fast rather than wait for, I don't know, months. It can take a long time.

It's kind of like putting a carrot in front of the builder and be like, if you deploy fast, you have all those rewards, all the incentives to claim. Tether is planning a campaign to drive circulation of USDT. I'll dive into the fellow public goods, the fellow DAO campaign in a minute. We also have one with Lisk, and we're also experimenting with a builder community to grow our own builder community that is participating in multiple campaigns with Scoutgate. So this is the fellow DAO campaign, fellow 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 referred or participating or using fellow as a chain through these 105 builders and a ton of gas usage. So the KPI that fellow public goods is incentivizing is gas usage of fellow because that's the seller's revenue model as a layer two. Fellow public goods knows all the builders, so they're doing all the registration onboarding, and I have seen already the first month, if you compare the first week of the second month in purple to the first month of the campaign, gas consumption has already doubled for the top builders.

So it's really like providing that flywheel. If you provide incentives to builders, they'll just drive more on chain usage in the next month. It's very easy if you're a protocol or gross team to launch a campaign. You define the KPI. You define the budget and the duration of your campaign.

We, the core team behind Zevi, can help you implement what we call the impact reward function, so how much you're going to provide incentives per unit of impact. You fund things for a contract, deploy it, and then we go into builder onboarding, and it's all then automated on the Zevi dashboard from there. The builders integrate some snippets of code. Some people report that it takes like two hours, maybe half a day, depending on how Web3 native the app builders are. And then together we grow the price.

So the builders build, the on-chain value grows because they bring more users, and Zevi is able to track and attribute all of those users' on-chain usage to that builder in real time, and builders can then go to the Zevi dashboard and claim rewards at the end of each reward period based on all of that traction that they address. So this is how we are rethinking Web3 funding. We're moving away from hype and from politics, from manual, like outdated process, into impact-based funding of builders, automated so they don't sync in time and paperwork. They can sync 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 builders don't need to know anyone.

They can just start experimenting, or they can be really further along their builder journey and their app growth, and they can join Zevi's campaigns at any time. So the idea is to forget retro, and for builders to build, ship, and earn. So if you're a builder, you should head over to app.zevi.xyz.

You can see all the live campaigns and also past campaigns there, depending on which protocols you're building on. You can even sign up for some of the campaigns now. You can join the Telegram community, that's what the QR code is here for, and get updates on new campaigns that go live, or follow us on Twitter as well, with app.zevi. So we're ready for the next evolution, which is one where we don't fund hype, we fund outcomes.

Thank you. Thank you, Denise. Okay. Funding in the... Oh, before you go, we have some questions with the crowd.

Oh, 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, and if we have any questions for Denise before we go to lunch, now is your opportunity. If not, we'll let you go.