Divvi is a new onchain protocol that coordinates the growth of the blockchain ecosystem by creating a market for participants to define onchain objectives and reward other participants for helping achieve those objectives.
The Divvi protocol exposes a set of interfaces that allow an onchain participant (e.g., a DEX) to define objectives (e.g., increase transaction volume) and rewards for other participants (e.g., frontend builders or local ambassadors) who help achieve those objectives (e.g., 10% of incremental revenue). With this interface, onchain participants can decide what they’re willing to share (or pay) for growth and also select which other participants they’re willing to support.
This document describes a high-level, scalable architecture for the Divvi protocol based on a directed acyclic graph of entities connected by referrer relationships. Each entity in the graph generates revenue through Divvi rewards. Recursively, Divvi rewards earned by an entity consist of Divvi rewards earned by downstream entities, plus any additional incentive rewards offered by those entities.
Consider an example with the following participants:
The yield optimizer can utilize Divvi to increase its revenue by stipulating that Divvi should share 50% of incremental harvest fees (i.e., revenue) with local dapps. The project codifies the harvest fees and reward calculation using Divvi, which makes it verifiable to any potential dapp builder.
Each dapp builder can grow their revenue by declaring that Divvi should share 50% of all rewards received from the yield optimizer with local marketing ambassadors who onboard users. A dapp provides each local ambassador with a referral link for onboarding users, and the dapp is responsible for calling Divvi to associate the user, dapp builder, and marketing ambassador.
Marketing ambassadors grow their revenue with Divvi by onboarding new users to the dapps, for example, by providing local educational content and sharing their referral link.
In this example, the Divvi system enables the yield optimizer, local dapp builders, and marketing ambassadors to align incentives by configuring onchain reward sharing.
Incentive rewards are the core component of Divvi that provide entities a means to generate revenue; supporting them requires us to define a few terms in advance.
Incentive rewards are an additional pool of rewards an entity is willing to offer for referred users. An entity $A$ who wishes to provide incentive rewards chooses some objective function $\phi_{A}$ they wish to increase on a per-user basis. This objective function must be a monotonically increasing function [1] with respect to time.
In regular intervals, entities offering incentive rewards will post the values of $\phi_{A,t}(x)$ for the current time $t$ for each user $x \in \Chi_{A,B}$ that has been referred to them by some other entity $B$, to some data availability layer onchain in order for the Divvi protocol to calculate rewards accurately. These intervals will be identical across all entities; that is to say, updates to the data availability layer will be synchronized for all entities offering incentive rewards. If the values for $\phi_{A,t_1}$ are available on the data availability layer for some time $t_1$ and some entity $A$, the values $\phi_{B,t_1}$ will necessarily also be available for some other entity $B$. This synchronization implies some design decisions with respect to the data availability layer, but as we’ll see, this guarantee of synchrony greatly simplifies Divvi reward calculation. In general, the specifics of the data availability layer are beyond the scope of this document; we take it as given that data will be available in one way or another.
These objective function values alone are not enough to determine incentive rewards; an additional layer of translation is needed to determine how a user’s impact on an objective function affects the rewards owed to some referring entity. As such, entities offering incentive rewards need to define an incentive function $\Theta$, which accepts a change or delta in the objective function value for some user $x \in \Chi$. Precisely, over a timespan $[t_{1}, t_{2}]$, which corresponds to intervals at which the objective function data was posted to the data availability layer, let