You are probably very much aware: The Devonomics program, launched by Starknet Foundation and StarkWare Ltd, had made waves within the Starknet community by allocating over 1600 ETH ($3.5M+ at launch) to dApp developers and core devs.
This great initiative aimed to empower those at the forefront of Starknet's development, encouraging growth and innovation. Its approach to fund allocation: letting dApp developers decide how to distribute funds to core developers.
As a reminder, 8% of the collected fees (1,200 ETH) was to be distributed based on the value each smart contract would bring to the users of Starknet, measured through the fees generated by these contracts. This 8% was distributed to dApp Developers who were then tasked with recommending the allocation of their revenue to Core Developers. An additional 2% of fees was then apportioned by dApp Developers to Core Developers whose work they value, through manual nomination.
For more details on this, please read the article here.
However, with great power (or in this case, funding) comes great responsibility—the challenge of ensuring a fair process of distribution. How do you choose how to allocate those funds? What is deemed as “fair”?
Indeed, there are three main challenges to address: the fairness of the nomination process, the equitable distribution of rewards, and the issue of "the winner takes it all." So how can we go about this? For each of these challenges that we will discuss, we will offer suggested guidelines to help serve the program’s intended purpose of fair and equitable support.
1. The dilemma of nominations
One of the complexities encountered in this journey is the process by which projects decide on the allocation of these funds. Usually, the community nominated whoever came to mind to receive support.
This proved to be problematic, as the community tended to favor high-visibility individuals, companies, or projects outside of the ecosystem, often overlooking lesser-known yet potentially impactful projects.
The solution
In order to rectify this, we suggest to provide nomination guidelines rather than just nominate a name. And in order for this process to be fair, only open-source projects should be listed for nomination, excluding individuals or companies.
This measure aims to level the playing field, allowing all open-source projects within the ecosystem an equal opportunity to be recognized and supported. A clear, visible list of all projects and their descriptions will facilitate a more informed and logical nomination process.
2. The dilemma of distribution
Besides the limitations of nominations, another important question that was raised for these projects that received ETH from the Devonomics program was: How should they distribute the funds among their contributors fairly?
This challenge is not unique to the Devonomics program; it mirrors the situation faced by recipients of the latest round of Optimism's retroactive funding for example. Once the maintainer receives the funds, what comes next?
The solution
Below is a framework that we suggest for those that received ETH in the last round and which we suggest for following rounds:
Retroactive Recognition: Rewarding current & seasonal contributions
This method focuses on retroactively rewarding those who have contributed significantly, as well as rewarding the core team. We recommend to allocate 70% of rewards for retroactive recognition, which can be used to reward:
- The Core Team: Allocate a significant portion (40%) of the rewards to core developers and maintainers who are actively contributing to the project. This acknowledges their ongoing efforts and incentivizes continued innovation and dedication.
- Seasonal Contributors: Distribute rewards (30%) to part-time contributors who have helped shape the project. This can be done in the following ways:
- Based on the value created: This can be measured through the impact of their contributions, possibly quantified by the grants that they received.
- Equitably: Each contributor receives an equal share, recognizing their participation regardless of the size or impact of their contribution.
- Tier-based (manual): Contributors are categorized into tiers based on predefined criteria (e.g., contribution size, project impact), with distribution adjusted accordingly.
- Future Recognition: Incentivize new talent We recommend to allocate 30% of remaining rewards for future contributors. This ensures the project remains strong and continues to evolve with fresh perspectives.
Ideal retroactive approach “case study”
To further support this framework, we’ve got a great case study on how The Cairo Book, receiving an 8 ETH grant, approached the distribution of funds.
LFG Labs, the maintainers of The Cairo Book, decided to redistribute 100% of this grant to its seasonal contributors, choosing a methodology focused not on the number of contributions but on the monetary value of those contributions measured in USD/USDC. Because the core team had already received grants from the foundation, and they have enough budget for future contributors, they believed that this approach was ideal for everyone. For example, Fricoben, project lead, rewarded himself not as part of the Core Team but as part of past contributions.
This process involved several steps:
- Normalization: Contributions were normalized to a common currency (USDC), treating USD and USDC contributions equivalently and valuing STRK at 2 USD. This created a uniform basis for calculation.
- Proportional Allocation: The total contribution of each contributor was calculated as a percentage of the overall project contributions, based on their USDC value.
- ETH Distribution: Finally, the 8 ETH was distributed on OnlyDust proportionally according to these percentages. Each contributor received an amount of ETH corresponding to their share of the total contributions, ensuring fairness based on the value they brought to the project. Below is an illustration of how this was done.
For more info, you can check out the google sheet here.
In the end, it’s not just about distributing funds; it's about recognizing value, effort, and contribution fairly and transparently.
Here are a few other case studies of projects on OnlyDust that described how they would like to distribute the grant received:
Cairovm.codes (Walnut)
Background
Walnut, a project recognized for its significant contributions to the ecosystem, was very grateful to have received 20ETH grant from the Devonomics Program. Despite a Development Partnership with the SN Foundation, the grant gave an extra support for their ongoing work, because the DP doesn't cover all of their expenses.
The Dilemma
The grant was awarded specifically to Walnut, a closed-source project maintained by a dedicated core team, without external contributors. This situation presented a unique challenge: how to distribute the grant in a way that honors the intent behind the funding while also embracing the broader ethics of supporting open-source development and community involvement.
Walnut also maintains cairovm.codes, an open-source project separate from the primary focus of the grant. Allocating funds from the Walnut grant to cairovm.codes contributors posed a challenge, as they believe that the decision by those who nominated Walnut to receive the grant, should be respected.
The Proposal
After careful consideration, Walnut proposed a balanced approach to distributing the grant:
- Core team (50% of the funds): Allocate half of the grant to the core Walnut team to cover future salaries. This decision was made with a clear stance against retroactive grants, focusing instead on sustaining the project's future development.
- External contributors (50% of the funds): The remaining half of the grant would be dedicated to external contributors for future open-source projects on Starknet, facilitated through OnlyDust. This approach aims to nurture the project's external contributor base and encourage the development of new open-source initiatives. It also addresses the desire to support the open-source community while respecting the specific intent behind the grant to Walnut, rather than redirecting those funds to cairovm.codes.
Apibara & Starknet React
For projects Apibara and Starknet React, the team decided to use the USDC value to weight the airdrop and to split the rewards between contributors and future contributions. They chose to do a “proportional allocation” that was recommended, which allowed to give a retroactive grant to their contributors.
As you can see from the tables below, column A shows how much a contributor received for their work and in column D the added bonus thanks to the retroactive grant.
- 3 ETH for Apibara contributors and save the rest of the funds for future contributors:
- 7 ETH for Starknet React and distribute all of it to the contributors retroactively :
Madara
Madara’s committee preferred to use the funding for future rewards. Because they already have a cohort on the way and exciting projects ahead, the Devonomics Program will greatly support them with their future needs.
3. The dilemma of “the winner takes it all”
And lastly, in order to ensure fair nomination and distribution, it was important to address the issue of projects receiving multiple grants. Indeed, some projects have received grants by Starkware, Devonomics Program AND other grant programs. Although it's great to be rewarded on all sides, it doesn't offer a fair way of distribution to projects that haven’t received any.
We therefore would like to offer the following suggestion for the future rounds.
The solution
We recommend to define who is eligible for a Devonomics Program grant and how to distribute accordingly, in reference to the recommendation in part 2, above. Hence, in order to be eligible for the program, your project should have at least 5 contributors. And within this, we categorize those with DPs and those without DPs.
Let’s look in more detail below.
The goal is to reward developers that have made an impact in the ecosystem who haven't had a meaningful compensation previously. In this case, we believe that in order to be eligible for the Devonomics Program, your project should have at least 5 external contributors.
In other words: projects that have been granted budget as part of the DP (developer partnership that is directly related to their open-source project) and have less than 5 external contributors will not be eligible for voting or distribution. Why? Because the granted budget from the DP is already being used to reward the core team.
Therefore, for future rounds, we would advise the distribution of rewards in the following way (same as mentioned in the solution in part 2):
- Projects that have been granted budget as part of the DP and with more than 5 external contributors, we ask that they distribute budget in the following way:
- 20% should go to the core team, and 80% to be used for contributions. Why? Because these projects help onboard new contributors.
- The idea is to reward the core team that have been working hard to sustaining the project, and to have the remaining budget for seasonal and future contributions:
- Based on the value created: This can be measured through the impact of their contributions, possibly quantified by the grants that they received.
- Equitably: Each contributor receives an equal share, recognizing their participation regardless of the size or impact of their contribution.
- Tier-based (manual): Contributors are categorized into tiers based on predefined criteria (e.g., contribution size, project impact), with distribution adjusted accordingly.
For projects without DP, we ask that 40% of the allocated budget go to the core team and 60% to contributions:
Seasonal Contributors
Distribute rewards (30%) to part-time contributors who have helped shape the project. This can be done in the following ways:
- Based on the value created: This can be measured through the impact of their contributions, possibly quantified by the grants that they received.
- Equitably: Each contributor receives an equal share, recognizing their participation regardless of the size or impact of their contribution.
- Tier-based (manual): Contributors are categorized into tiers based on predefined criteria (e.g., contribution size, project impact), with distribution adjusted accordingly.
Future Contributors
We recommend to allocate 30% of remaining rewards for future contributors. This ensures the project remains strong and continues to evolve with fresh perspectives.
In this way, we ensure a more fair way to vote and distribute grants to projects deserving of recognition, and not because they are high-profile.