B.Protocol Affiliate Program

Ideas for Discussions
#1

Tl;Dr

In order to incentivize a high-quality stream of integrations, this proposal aims to create an affiliation program, where an individual or an entity who will facilitate a successful integration of B.Protocol into an existing or a new Fuse pool, will be rewarded with 10% of the DAO stream of revenues generated by that specific pool’s Admin Fees and its liquidation profits.

Intro

B.Protocol offers a user-based backstop as an improved liquidation engine for DeFi lending markets. Fuse is a permissionless, isolated lending markets platform, where anyone can open a “Pool” and list whatever assets they wish to enable a lending and borrowing market with set interest rate curves.

As B.Protocol growth is measured, among other metrics, by its integration base, aligning incentives for these integrations to happen can facilitate a better rate of successful integrations. An affiliation program can create the required alignment as it opens the opportunity for those who work on such integrations to get rewarded for it, growing the “growth team” of B.Protocol. Another desired outcome will be harnessing the internal Business Development teams of projects who look to open new pools on Fuse, as well as those who already have an active pool without a backstop integration.

The Incentives

A B.Protocol affiliation program should incentivise active, long term, and successful integrations. As such, the rewards are suggested to be streamlined from the Admin Fees and the liquidation profits that will be generated on the integrated pool - the more successful and long lasting the integration is, so will be the distributed rewards.

The Admin Fees on Fuse are being generated by the borrowing activity of the pool and are set by the pool’s admin, with a default set to 10%.

I propose to distribute 10% of the DAO’s revenues from a pool - to the affiliating individual/entity that will facilitate a successful integration.

The revenues of the DAO from each pool are generated from the pool’s Admin Fees and liquidations’ profits made by the B.AMM.

A successful integration of B.Protocol with Fuse can be for an existing or a new Fuse pool, which runs on Ethereum mainnet, Arbitrum, or any other network that will be supported by the Fuse platform in the future.

Next steps

This proposal is posted in the #ideas-discussions category for feedback and comments from the community for the coming 5 days.

After 5 days of posting this under #Ideas for Discussion it will be posted under #Proposals with whatever comments that will be taken from the discussion, for a minimum of 48 hours and then posted as a formal BIP with a Snapshot to be voted on by the DAO.

2 Likes
#2

A suggestion I have for this initiative is compiling a list of partnerships that are already underway or have been approached so these projects don’t get barraged by a million people asking to integrate with us over and over. I just checked with Ichi and they said you guys are already talking, which is awesome :slight_smile:

I just think it could become an annoyance unless we make the community aware of partnerships that are already happening.

3 Likes
#3

I agree.
There should be an updated list of partnerships the team is already in touch with to avoid such incidents.

Should probably have a (simple) method to decide who is the appropriate affiliator for a partnership which more than one reached out to (can be a simple approval from the integrated party).

1 Like
#4

Some addtl questions on the affiliate fee terms:

  • How long will fees flow to the affiliate? Limited in time or in perpetuity?
  • What if three parties want to integrate BPRO into the same pool. Who becomes the affiliate?
  • I imagine fees can stream into any address, incl multisigs (in case there is a group of people behind one affiliate)

Idea for affiliate fees is great!!

1 Like
#5

First, this is amazing idea.

I have a question.

Would affiliate have a dashboard that track the performances of project(s) he initiated?

#6

Very good point.

@EitanK
I suggest setting up a google form where affiliates submit the details of the targeted project, additional info (contact details) of the lead.

This way the team can discern whether there is already an ongoing effort being made for an integration and can notify the affiliate about the status of his inquiry individually.

I’d tend towards making only final phase or already completed integrations public, for the following reasons:

  • allows to minimize administrative effort of handling affiliates requests because they are funnelled through a single-point of entry (said google form; or anything suitable, similar)
  • protects the planned dedication of the affiliate to bring such an integration to fruition (no one else ‘jumps’ on the very same project and tries to compete which - as I feel - allows for a higher quality in establishing interest and liaison with the 3rd party than ‘under time pressure’
  • we can all agree that the best outcome for growth of b.protocol are successful integrations and thus, while not actively encouraged, different affiliates can enter the process of rallying attention at the same time. Results should assess the success of an affiliates commitment, i.e. first-come-first-serve will be honored, but should the second runner-up succeed in making true meaningful discussion resulting in actual development of the integration, I believe the team should be able to recognize this fact at their discretion. (I don’t say that projects should get barraged by a million people asking to integrate with us over and over; just that the team should decide individually if they shall allow for two affiliates to be working on achieving the very same result, if - say - one affiliate did not succeed for whatever reason within 60-90 days in facilitating a meeting/meaningful initial discussion)

These I my very raw first thoughts on the matter - very open to cut the edges and trimming to essentials :exclamation:

1 Like
#7

Thanks @Austrian_Guy @a7om and @nonstopTheo for the valuable feedback.

Here are a few more thoughts/comments:

I agree a list of on-going integration efforts should be public in some sort.
My question, similar in a way to @Austrian_Guy reply, is how do we avoid “leechers” from piggybacking on already initiated interactions, on one hand, while not letting anyone list many/all potential integrations as “in progress” before s/he really made significant work with the project to be integrated.
We can probably start with a simple list and create the right-size solution once we bump into issues. I would suggest not sharing the contact details of the champion within the project to prevent leechers (or at least not encourage them).

I would start with a table with these categories:
Affiliate name | Project Name | Reached Out Date | Established communication channel with the 2 teams - Yes/No)

Can’t see a reason to limit this. As long as the integrated pool/market is active and the DAO receives fees from it, so should the affiliate IMO.

Not sure I follow this. As long as the DAO receives fees, those who made the integration happen should get their portion of it. I assume it can be a multisig address that distributes the funds to the relevant entities/individuals.

LMK any further comments/ideas.

I will soon add a separate proposal as discussed over Discord regarding an “incentive” for integrated projects according to their backstop TVL (Discord)

1 Like
#8

I believe this is a later stage feature…

1 Like
#9

Excellent. Let’s proceed.

I suppose you are thinking of something like this, for example: CoW - Referral Data (dune.com)

Just as Eitan stated, we probably will keep it simple until we bump into necessities and scale up.

#10

One solution to this would be a timer on the affiliate resolution (accepted/rejected) and disqualification from the program if they have more than 1 “time-out.”