# Referral Code System
We want to incentivize platforms / partners to drive interest. We're looking at something similiar to liquitys front end tag system.

## LQTY Front End Incentives
So in Liquity, when people deposit into the stability pool they can have a referral code in the function call. This gives some % of their LQTY gains from being staked to another party.

It's permissionless to register a referral code.

This is used to incentivize FE providers when users deposit into stability pool via their app.

## eBTC Fee Sharing
What we want to give rewards to platforms that drive people opening debt positions. To do this, we use the referral code when someone opens or increases a trove.

We have a continuous interest rate on open positions. Some of this goes to badger, some of this goes to the referral code holder.

Badger would be the only referral code holder at the start, so we get all the interest. If referral code holder is not passed in, it all goes to badger by default.

## The issue
with Liquity, there is no benefit for passing in your own code. You can get all the LQTY just by passing in no code. Also it's only for Stability pool depositors rather than all CDP openers.

In this eBTC setup, it's beneficial for a user to open their own referral code (if it's permissionless). So users can halve their interest rate by just doing some etherscan activity.

A way around this is governance around registering referral codes. Those platforms can of course halve interest for their own positions but that's ok.

We could use some sort of **minimum issuance** before referral codes kick in, too. So if you bring X ETH or X USD worth of loans via your code, fee sharing kicks in.

There is a lot we could do here, but hardcoding it is a tricky decision as it may evolve over time and isn't core to protocol function.

We could also design the contracts in such a way that it **could be automated**, but governance would have to do some work to enable that. Say, an open proxy that captures the fees and gets a hook on evey trove open or position increase. We could then build whatever on top of that by upgrading the fee capture proxy.

We also need to consider when gains are realized. They currently are realized whenever a trove is acted upon. This means interest is claimed lazily and requires O(n) operations to claim all outstanding interest. We're looking into bulk O(1) claimable interest.