Contract upgrade 1.7.0 (Referral Fee)

  1. 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):

  1. 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.

  1. 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)
  1. 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

1 Like

At the moment, there are a total of 12 referrals, of which 6 have been active in the last 30 days.

// referral_id: relevant instant swap action count
{
‘’: 18, // inactive
‘jreive.near’: 3, // inactive
‘adanlink.near’: 256, // inactive
‘zackmorris.near’: 3229, // inactive
‘ref-fee.testnet’: 1, // inactive
‘0f70b471d0536cac0d241d48ed08a269296683f7bd9ddf5fbafcad0970a08f9c’: 1, // inactive

‘abbot.near’: 2042, // still active in last 30 days
‘arbitoor.near’: 565, // still active in last 30 days
‘kundark.near’: 6771, // still active in last 30 days
‘nearalex.near’: 4306, // still active in last 30 days
‘senderswap.near’: 1554, // still active in last 30 days
‘skyward-ref.near’: 6877, // still active in last 30 days
}

By default, the team will keep the active AND non-circular referrals in the new model.

Pembrock (v1.pembrock.near) will also be added.

If you think that your project should be added in the new referral list, please notifty us by responding in this thread.

According to the non-circular rule, among the 6 active referrals, skyward-ref.near, senderswap.near and arbitoor.near will be added to the new referral list by default, along with Permbrok(v1.pembrock.near).


Here are the latest statistics.

refferal_id referee number relevant instant swap action count
skyward-ref.near 1693 6883
senderswap.near 948 1613
arbitoor.near 112 566
kundark.near 1 7556
abbot.near 1 2042
nearalex.near 1 4431
1 Like

Is Skyward still active? I thought the project stopped after the hack.
See: Delist SKYWARD Token