The Developer Revenue Incentivization Program (DRIP)
Disclaimer: This work is funded by the AADAO. Although this research post is topically related to the recent joint Community Spend proposal by Informal Systems & Hypha, this is by no means an attempt to interfere with that process. If ATOM holders agree that the Developer Revenue Incentive Program is a workable and desired solution, development will likely only be completed somewhere in 2024, well beyond the timeframe for their funding request. This work should not be considered a viable alternative to their proposal.
TL;DR - This is a post requesting feedback on how to change the infrastructure behind the way we fund development teams. It proposes a ranged percentage based allocation of inflation + revenue. This percentage is based on the USD value of ATOM and has an upper percentage limit that cannot be exceeded. A revenue share model is also suggested.
Author: Noam Cohen (Binary Builders)
Introduction
Over the course of the years, the Cosmos Hub has developed a “founder absence”. Other chains in the ecosystem, like Osmosis, Neutron, Injective and so many more all enjoy a thriving founding team that remains focussed on achieving success for their blockchains. Several years ago, the original founders Jae Kwon and Ethan Buchman started shifting their attention to other initiatives via their companies and foundations (All in Bits, Informal Systems & the ICF).
Although Ethan remains indirectly involved in the future of the Hub through the ICF and the great work Informal Systems has achieved shipping Interchain Security, the Cosmos Hub has had a hard time finding a replacement in a consistent team whose primary concern is the future of the Hub. In 2021, Interchain GmbH (a subsidiary of the ICF) built out a team led by Billy Rennekamp, which had merged into Informal Systems at the end of 2022. Through these frequent changes and departures, continuity concerns arise and intellectual capital is lost.
Work is now split between multiple entities such as Informal Systems & Hypha, and smaller independent contributors such as Notional. As the Hub considers expanding its functionality, this fragmentation of development is generally a good thing for the maturation and decentralization of the network. But as the ICF is shifting focus to the development of the core stack and ideally leaves the Hub to fund its own development in the near future, we are left with finding the means to fund future development while incentivizing long term alignment.
There are no sufficient revenue streams to maintain operational costs (developers and validators) in the long term unless we maintain high levels of inflation. We cannot put all our eggs in the Interchain Security basket. We need someone to step up and build the next Celestia, Axelar or Babylon on or adjacent to the Hub. But without proper incentivization, it remains infinitely more attractive to do so on a separate chain under a new token. Two main concerns need to be addressed:
1. Funding Core Teams:
The Community Pool has been used to perform one-off payments to development teams, most recently the proposal to fund Notional. For small funding requests with clear deliverables such as the Replicated Security audit, this is a rather effective means to get funding across as it requires little oversight and the funding amounts are generally low enough to afford the small chance of the project not delivering. However, for long term development teams, there are a few concerns with this mechanism:
-
Size of the Request: Development teams with a significant headcount cost considerable amounts of money to be funded for a year or longer. Shorter periods impose risk to development teams. This is both a big drain on the Community Pool as well as a risk to the Hub for two reasons:
- No Clawbacks: In case milestones are not achieved, there are no means to guarantee the return of funds. Committees could be used to hold the funds, but generate other accountability risks that leave ATOM holders unable to retain veto power.
- Price Impact: Vesting schedules protect ATOM holders from the full amount being “dumped” on the open market in one go. However, this results in the exposure to price volatility for both parties. Without vesting, a development team would be incentivized to convert all ATOM to fiat as soon as possible in order to make sure its operational costs can be covered for the remainder of the year.
-
Price Volatility: This is both a risk to the Hub and the development teams. If the price of ATOM ends up much lower over time, a development team runs the risk of running out of funds before work can be completed. Similarly, if the price of ATOM rises beyond expectations, the Hub ends up having paid much more than needed to achieve its goals.
Large funding proposals could theoretically be split up into several repeating 3-6 month proposals, but anyone that runs a business will tell you that these are extremely difficult circumstances to survive under. Companies require a runway of at least several months to a year in case of unexpected changes, while employees need the comfort of knowing they have job security. Without this, talent leaves for better opportunities.
Splitting up funding requests leaves companies without any guarantees that the next proposal will pass. Without these guarantees, businesses can’t take hiring risks, teams can’t scale, and developers are incentivized to direct resources towards more sustainable projects. What the Hub has lacked the most is consistent development teams that stick around for the long term. The intellectual capital that is lost by rotating teams on the regular is a huge risk for the Hub’s future.
2. Enabling Long Term Incentive Alignment:
Shipping a feature is not enough. Software needs to be maintained and improved, but equally important marketing and business development work need to be done in order for protocols to succeed. Partnerships, sales and effective marketing are essential to a product’s success.
Simply receiving compensation for this work is not an effective means to achieve excellence. In early stage start-ups, team members are motivated by both their passion for the product and the success-based compensation. Founders are generally rewarded when their products do well in two ways:
- Token Price Increases: Founding teams often receive significant portions of their initial token allocation. When demand for their product increases, so does the price of their token.
- Revenue Share: In some cases, a percentage of the protocol’s revenue is directed back to the development team in order to sustain long term technical and business development. This is quite a common practice in protocols without a token.
If ATOM holders want to create an environment where innovative features are built within the AEZ that benefit ATOM directly (and not just a Consumer Chain or dApp’s token), we need to consider how to foster long term incentive alignment.
The Cosmos Hub cannot afford significantly investing in the first option. Handing out large sums of ATOM as an investment for a product that may or may not succeed is a huge risk for ATOM holders. Revenue share is an interesting option to explore as it leaves the burden of reward on the product team, while simultaneously offering them considerable upside that benefits ATOM holders as well.
It’s with these two main issues in mind that Binary Builders set out to design a solution.
Initial Design For The DRIP
Instead of one-time large payments, we propose a ranged percentage based allocation, offset with revenue generated in case the product maintained generates direct income. The percentage is based on the USD value of ATOM, and has an upper limit. Let’s use an example:
Some company “Team A” wants to request a minimum of 2 Million USD to maintain a critical feature on the Hub for the year 2024. At current prices ($7.42) and 15% inflation, the Hub is looking to generate around ~159m ATOM (1.18b USD) that year through inflation and revenue (fees). 2 Million USD would be around 0.17% of the Hub’s yearly budget.
Team A knows prices can fluctuate greatly, and makes a new type of governance proposal requesting to receive 0.17% of the budget, ideally between 1.8 and 4 million USD each year, with a maximum percentage of 1% being allocated to them, as well as an initial allocation of 200,000 USD to cover the first month of the year. ATOM holders vote yes, and the proposal passes.
The initial 200.000 is paid out from the Community Pool, similar to a Community Spend proposal. A new module, likely a significant variation of the Budget Module, is now tasked to payout Team A on a per-block or per-day basis. It uses an oracle to know the price of ATOM, and decides how much ATOM to pay out. If 0.17% of the daily budget in ATOM is lower than the minimum USD value requested, the percentage is raised, until the maximum percentage of 1% is reached. If the amount is higher than the maximum USD value requested, the percentage is reduced.
Let’s use some examples to see what that means and how the maximum percentage plays out. I’m assuming a daily payout and am using simplified rounded numbers for clarity. At daily payouts, the minimum daily amount requested is ~5k (1.8m / 365), and the maximum is 11k (4m / 365).
ATOM Price is $8:
- The Hub generates ~3.5m USD that day.
- 0,17% is 6k USD.
- This is within the range of 5k and 11k, so the percentage is not adjusted and 6k worth of ATOM is paid out.
ATOM Price is $40:
- The Hub generates ~17,5m USD.
- 0.17% is 30k USD.
- This is above the 11k daily maximum, so only 11k is paid out (which is effectively 0.06% of the Hub’s daily budget).
ATOM Price is $1:
- The Hub generates ~0.44m USD.
- 0.17% is 740 USD.
- This is well below the 5k minimum. Reaching 5k would require a percentage of 1.15%, but this is above the maximum percentage of 1%, so the payout is capped at 1% (4.3k USD)
What do we do to meet the team’s minimum daily requirement when price falls below the threshold?
In order to protect the Hub’s income and guarantee sufficient funds are available for the security of the network, there is a chance that teams temporarily receive insufficient funds. This risk can unfortunately not be completely avoided. But, measures can be put in place to reduce risk for the development teams in three ways:
- Team Buffer at Higher Prices: Teams provide an upper USD bound to the amount they receive. This means that at high ATOM prices, teams might earn more than they need, which they can use as a buffer.
- Balancing it out in future payments: A payout tally is maintained. If prices recover to a higher amount, more is paid out to cover the outstanding “debt” to the team. This never exceeds the maximum percentage allocated to the team on a daily basis.
- Optionally: The Hub sets aside ATOM tokens when the price does well (e.g. in a bull market) and keeps this in a reserve to pay for teams, as well as validators. There is a potential path to converting a percentage of these tokens to USDC when ATOM prices are high, which could then be used to offer USDC based payments. This is essentially the design of the Stability Reserve Fund we are working on, which will be addressed in a future forum post.
This does not fully remove the risk for teams. But it remains a much more secure alternative for both the Hub and the development teams than either going for a large yearly community spend or quarterly proposals.
Why do teams get to receive more than the minimum amount they need?
Besides enabling teams to build up a buffer, a maximum range facilitates incentive alignment. If ATOM does well, so should our development teams. We want them to want the Hub to succeed.
We have to keep in mind that single payments inherit a much stronger version of this exposure as well, as 2m USD in ATOM at current prices could very well be 10m a year from now. The DRIP model establishes safe bounds for both the Hub and developers.
What about revenue generation?
This depends on what a team is developing and whether or not it generates revenue. For teams like Hypha, who are mostly involved in public goods work, there is no revenue for them to receive. As such, they could potentially ask for a higher upper bound than a team building a product that generates revenue.
However, things change if a team deploys a protocol that generates revenue within the AEZ, either on the Hub or a tokenless consumer chain or smart contract (for example, on Neutron). If the revenue is directed strictly to the Cosmos Hub (i.e. to ATOM delegators), a part of that revenue could be shared with the team. If this is the case, the revenue is offset from the daily payment.
Let’s use another example for one specific day with the same variables from our earlier example where ATOM is worth 8 USD:
- Scheduled base-payout: 6k USD
- Max daily payout: 11k USD
- Revenue share: 50%
- Revenue generated: 10k USD
- Team share: 5k USD
- Actual payout by the DRIP: 6k USD in ATOM (1k from inflation & fees + 5k from revenue share)
Like our other example, if ATOM price was 40 USD, DRIP base-payout would be targeted at 30k, but capped at the 11k daily max. If the team’s revenue share was 15k that day, it would completely replace the DRIP’s base-payout and the team would earn 15k. At this stage we could say the team has potentially become self-sustainable.
Keep in mind the revenue share only applies to the revenue generated by the protocol that the team maintains. Other revenue generated (i.e. through Interchain Security) is handled as normal.
Do these funding streams ever end?
The proposal to request a funding stream can contain a start and end date, after which the funding stream stops. Teams can choose not to provide an end date, meaning that the funding stream will continue forever until a governance proposal passes to stop funding the team, or an update proposal introduces an end date.
How do we pull the plug in case teams don’t deliver?
ATOM delegators should retain full control over the payment stream. If a team is failing to deliver, payment should be stopped or adjusted. However, due to the existential threat this could cause on small companies that have dedicated the majority of their resources to the Hub, we propose two types of governance proposals:
- Regular Funding Stop: In case a team has generally delivered well, but ATOM holders want to decide whether to stop pursuing a particular development project, a request to stop funding can be proposed. When this passes, the team continues to receive funding for 3 months after the voting period ends. This functions similar to labor contracts, or could also be understood as a severance payment. The reason for doing so is to reduce the risk (and as such, the barrier to entry) for new talent interested in building for the Hub. If the team has worked for less than 6 months, the severance payment does not apply. This can either be a governance parameter, or a parameter chosen per funding proposal.
- Emergency Funding Stop: If a team has completely misappropriated funds or has maliciously acted against the Cosmos Hub in some other way, funding can be stopped immediately. A supermajority (2/3rd yes vote) would be required to pass this critical proposal.
Isn’t revenue share just the same thing we have with Consumer Chains right now?
Yes and no. Although we do have a revenue share agreement with consumer chains, the ownership of the underlying protocol, its integrations and network effect (and as such, the leverage) does not belong to the Hub. If a consumer chain decides to leave, there is little the Hub can do about it. Additionally, the revenue share is generally majorly skewed towards the consumer chain’s token holders, and potentially mostly paid out in the consumer chain’s more volatile native token.
Conversely, Cosmos Hub features should generate demand for ATOM, and revenue is likely paid in ATOM, which is generally a less volatile asset than newer tokens. Talented developers who are keen to build novel revenue-generating products, but are less risk-tolerant than founders are the exact target group for the DRIP. Without major investments, and while maintaining the ability to cut funding at any point in time, the DRIP provides a means for the Hub to expand its functionality while maintaining ownership of the protocol and incentive alignment with development teams through revenue share. Whether or not these projects launch directly on the Hub, or as a tokenless consumer chain or smart contract on Neutron is less important within this framework.
Accountability
It’s risky to enable a persistent allocation of the inflation to a development team without adequate accountability measures in place. We cannot expect every ATOM holder to read through detailed quarterly developer reports. Although the technical implementation of the DRIP is agnostic to which accountability structure is put in place, we want to emphasize that a subDAO committee of some sorts should be tasked with reviewing the development team’s reporting.
Although any ATOM holder can submit a governance proposal to stop the funding stream, the committee’s mandate should include informing the Cosmos Hub community about the performance of the team and proposing the cancellation of funding in case this is deemed necessary.
Developing the DRIP
If ATOM holders are in favor of developing the DRIP, Binary Builders would be happy to build out this functionality. Several core components will need to be modified or created:
Distribution Module / Budget Module
The distribution module is responsible for distributing the Hub’s inflation and revenue streams to delegators and the Community Pool. Modifications will need to be made so that the Hub’s income can be distributed to other addresses on a ranged USD value basis. This will require integrating with one or more oracles. Additionally, revenue streams need to be tallied separately in order to facilitate the revenue share.
Parameters will need to be added that manage the majority requirement for the emergency funding stop proposal, as well as the severance period for a regular funding cancellation proposal, although the latter could potentially be included in the funding stream creation proposal.
Further research is required to assess whether this functionality should be built in a separate module, or whether modifications to the distribution module are sufficient. A significant modification of the budget module might also suffice.
Governance
Three proposal types need to be created: a funding stream creation proposal, an update proposal, and a cancellation proposal. With Cosmos SDK 0.46 and above, this requires a custom message type to be included that only the Distribution or Budget module is authorized to execute. The Hub is currently on 0.45.x and still using legacy proposal types but will be updating to SDK 0.47 as soon as the LSM is upgraded.
Feedback
Before we get into further details and specifications on this topic, we’d like to gather feedback from the community about our ideas for the DRIP. The primary questions we’d like to ask are:
- Is a ranged USD based percentage allocation the right way to go forward?
- Would the revenue-share model sufficiently incentivize talent to be onboarded to the Hub? Or is the DRIP only suitable for the type of public goods work that Informal and Hypha are doing.
- Are grants programs like the AADAO potential candidates for using the DRIP?
- Are we missing any critical perspectives or concerns in our thinking?
If the general consensus is positive and feedback has been processed, we’ll proceed with a formal proposal on the forum, which will later be put on-chain.
Thank you for your time and attention!
