- Context
The referral fee can be defined as where a developer (or project) receives a commission for redirecting users to swap on Ref.
The referral fee is designed to encourage and incentivise developers to create their own Swap/Trading Interface.
Current implementation examples (non-exhaustive):
- Rubic: live
- Perk: live
- Omomo: work in progress
- Nearblocks: work in progress
- Problem
As highlighted in a previous post, the current design allows the referral fee to be claimed by the same user/address that executes the swap.
In other words, the referral fee can be ‘circular’. For example, an arbitrageur could claim the referral fee for every swap executed, thus rerouting the fee to itself.
In that specific use case and in the scope of normal pools (vs. stable and rated pools), the arbitrageur pays less fee to the detriment of LPs. As LPs get the referral fee when it is not claimed.
- Solution
The contract upgrade 1.7.0 introduces the concept of ‘registered referrals’. In simple terms, ‘registered referrals’ are addresses that have been approved by the owner (ref-finance.sputnik-dao.near) or the Guardians.
Today, the referral fee is fixed to 4% of the total pool fee. The new design enables the referral fee to be dynamic and specific to each corresponding referral address. The referral fee can go up to 20% of the total pool fee. In the new design, the ‘admin fee’ encapsulates/includes the referral fee and the protocol fee.
The proposed design has pros and cons (non-exhaustive).
Pros:
- Potentially more incentives for developers (vs. current fixed 4% of the total pool fee)
- More flexibility in the way Ref could manage dynamically its referral partners (for example, Ref could implement three referral tiers: 5, 10 and 20% of the total pool fee)
- More control over its referral partners
- Dynamic referral fee depending on project partners’ performance
Cons:
- Point of centralisation (what are the objective criteria to be referral AND what fee am I entitled to?) vs. permissionless design
- Friction in the implementation (relies on internal processes and decision at the DAO level) vs. instant implementation at the contract level
- Potential additional cost/effort to maintain the list of registered referrals (question of removing depreciated projects)
- Next steps
The deployment date of the upgrade is planned on Nov 30th.
Any questions relating to the above, let’s discuss here!
More details about the upgrade: ref-contracts/fee_details.md at main · ref-finance/ref-contracts · GitHub