Sponsor Program

[aggre]

Moved from #36 (Closes #36)

[aggre]

@defi-er I prefer to program the Sponsor Program as I would a normal Market. I'd like to generalize it as much as possible, but first I'd appreciate it if you could comment here with any ideas you think would be ideal. (If you have an idea that is not yet written in the DIP)

[defi-er]

What characteristics did you imagine that the Sponsor Program would have that would make it similar to the General Market?

[aggre]

Yes, because essentially, many requirements should be realized by Market. However, since Market can be programmed rather freely, I believe that brainstorming and then generalization are necessary.

[defi-er]

Could you detail how this would look like? Do you want a Sponsor Program that would allow users to withdraw regardless for unauthenticated properties?

[aggre]

I'll comment on the thoughts I have at the moment.

1. Having multiple minting methods in one protocol is basically an idea I want to avoid. More minting methods and APYs complicate the code base, and tokenomics to be cautious about this. If we want to inflate tokens, I think it is better to use the existing APY. (In this regard, I thought it made the most sense to use the existing Market mechanism)
2. I think it's a good idea to put a lock and time limit on the rewards that accrue during the idle period (when waiting to be authenticated by the project author). It's a viable idea even if we create the Sponsor Program as a Market.

Please give me more time to think about the concept of "boosting."

[defi-er]

1. Agreed, but then APY is low and if rewards are locked then there must be extra incentive (Boosted Rewards)

[defi-er]

I'll propose a few alternative models tomorrow!

[aggre]

Thank you! If I can come up with an alternative, I'll share it here.

[defi-er]

Model #1
Inflationary Rewards + Boosted Rewards (Geyser)

Community vote every 90 days to add 5 projects to Sponsor Program
Team decides Boosted Reward allocation for each project
Users stake DEV in the Escrow which holds the rewards
Inflationary + Boosted Rewards begin to accumulate
Geyser's logic is used to distribute Boosted Rewards based on time and liquidity provided
If an OSS project authenticates then rewards are unlocked. If project doesn't authenticate by X days then allocated DEV for Boosted Rewards are kept in escrow, and inflationary rewards are burned.

Model #2
Traditional Market

Community applies OSS projects to application process
Team approves and a synthetic pool is made
Users stake DEV which begins to accumulate rewards for both parties
OSS projects unlock rewards when they authenticate

Model #3
Boosted Rewards (Geyser)

Community vote every 90 days to add 5 projects to Sponsor Program
Team decides Boosted Reward allocation for each project
Users stake DEV in the Escrow which holds the rewards
Geyser's logic is used to distribute Boosted Rewards based on time and liquidity provided
If an OSS project authenticates then rewards are unlocked.
If the OSS project doesn't authenticate by X days then allocated DEV for Boosted Rewards are kept in escrow and used for the next round

[calaber24p]

I like the idea of a sponsor program and personally im leaning towards model 2. I think users should be rewarded what they would usually be rewarded for staking, while supporting potential future projects on the platform. If those projects choose to not join dev the rewards on their side are burnt and inflation will go down, giving the token a higher scarcity.

[CyberYama]

I like the number 2 model. Also, the creator's rewards should have a vesting period or allocated percentage available for them to sell in the market at a time to prevent the prices from dropping significantly.

[aggre]

Also, the creator's rewards should have a vesting period or allocated percentage available for them to sell in the market at a time to prevent the prices from dropping significantly.

@BTC100x I think DIP #38 will significantly reduce the problem you are concerned about.

[aggre]

In my understanding, the "boost" is intended to work as an incentive to accept that rewards are locked.

And the "reward locking" is intended to work to prevent an unhealthy network. For example, prevent the situation where only staking increases without creators. Perhaps the purpose of "reward locking" is somewhat optimistic under team supervision. However, if the Sponsor Program becomes decentralized in the future, its functionality will become important.

I understand that the challenges we need to solve are:

1. Prevent growth without creators
2. If it implements the "reward locking" to solve (1), what is the "boost" source?

There are two ways to solve (1):

1. Incentives for projects that are likely to be authenticated
2. Disincentives for projects that are unlikely to be authenticated

Boost applies to the former solution.

I share the latter idea as follows:

• Staking rewards will be generated even during the idle period.
• If an idle project is not authenticated for "X" months, a staker will not receive any staking rewards after "X" months.
• If an idle project is authenticated, a staker will be rewarded from the time the project is authenticated—for example, Alice stakings to Project-P from day 0. If Project P is authenticated after "X + 30 days", Alice's rewards are "0 to X" + "X + 30 days or later".

If the project is unlikely to be authenticated, users may not stake, avoiding losing the staking rewards they were supposed to get.

[defi-er]

I understand that the challenges we need to solve are:

1. Prevent growth without creators
2. If it implements the "reward locking" to solve (1), what is the "boost" source?

There are two ways to solve (1):

1. Incentives for projects that are likely to be authenticated
2. Disincentives for projects that are unlikely to be authenticated

Boost applies to the former solution.

The boost applies to both. How?

1. Allocated DEV for boost is decided by an "impact score" (Github metrics). The higher the impact score the higher the allocated DEV which means a larger boost. The purpose for this is for the Boosted Rewards to be correlated to the probability that the OSS project joins based on their impact score.
2. The Geyser program for Sponsor Program has the same mechanics as the Dev Protocol Geyser for liquidity. An allocation is provided (Boosted Rewards) and users compete against each other with liquidity and time to capture rewards. This method rewards the users who took the risk and increased the probability of the OSS project joining by increasing their incentive.

[defi-er]

Examples

Chalk will have less allocated DEV (Lower Boosted Rewards) because their onboard probability is higher than Linux Foundation. In the Geyser program that means that the APY will be lower to stake, but the probability of receiving the reward is higher.

Linux Foundation will have more allocated DEV. You could imagine 50,000% APY in the Geyser program so users stake a lot of DEV to capture the Boosted Reward, but there's a 95% chance that Linux Foundation doesn't join.

We could discuss later how the rewards will be vested if the project onboards.

[aggre]

So far, I am in favor of model (2) in #39 (comment). I shared a new idea about disincentive, but I believe that just locking rewards is sufficient.

However, to understand models (1) and (2), let me ask you the following questions. @defi-er

• How do you propose to deal with the situation when the team can no longer raise the budget to allocate to Boosted Rewards? (Or are you proposing that the Sponsor Program will cease to function by that time?)
• The "liquidity" described in "Geyser's logic is used to distribute Boosted Rewards based on time and liquidity provided" is the liquidity of what token?

[defi-er]

• How do you propose to deal with the situation when the team can no longer raise the budget to allocate to Boosted Rewards? (Or are you proposing that the Sponsor Program will cease to function by that time?)

We will need to test the community's willingness to earn Boosted Rewards which will determine allocation needed. The Sponsor Program should aim at targeting Tier A & B OSS projects to start a network effects and garner awareness from smaller OSS projects. Therefore, I believe that Sponsor Program won't require much DEV and that it won't be necessary for ever. If projects don't sign up then Boosted Reward is sent back to treasury.

• The "liquidity" described in "Geyser's logic is used to distribute Boosted Rewards based on time and liquidity provided" is the liquidity of what token?

Liquidity in this scenario is the DEV staked inside the Sponsor Program and time is when you join which could be from Day 1 to Day 90.