Discussion: Add an Admin fee to be distributed to veSBR holders

Governance
#1

Hello,

I wanted to get discussion of an admin fee introduction started. The goal of this discussion would be to gather feedback on if an admin fee should be introduced that flows to veSBR stakers. This discussion should end with a proper proposal to implement an admin fee.

Rough outline:
An admin fee on all pools would be used to buy the USDC/USDT LP tokens (lets call this 2SBR) then distributed to veSBR holders much like 3CRV is for veCRV holders. Based on the most recent 24 hour data at Saber Info this would be ~6,977 2SBR distributed to veSVBR holders over the last 24 hours (extrapolates to $2,546,605 annually) if it followed the simple CRV formula of 50% of fees go to LPs, 50% of fees going to veCRV.

I encourage people to read these post on the curve forums to see how this was developed within the community:

Key points to start discussion:

  • Should the withdraw fee be removed completely (only on the USDC/USDT pool currently) or also split between LPs & veSBR holders?

  • What percentage of trading/swap fees actually go towards veSBR holders? As I mentioned above it is 50% for Curve. Is this the right number for Saber?

  • If implemented, how should the admin fee be delivered to veSBR hodlers? As presented above as USDC/USDT LP tokens? Should 2SBR consist of these two tokens or should we focus on a more decentralized variant such as UST/FRAX or UST/CASH?

2 Likes
Buy Back + Burn + Lock up
Buy Back + Burn + Lock up
#2

As far as I know, the withdrawal fee on USDT/C was introduced to ensure sufficient stable liquidity in this key trading pair & to bootstrap the treasury. As TVL has actually decreased (Saber Info), I would suggest not to remove the fee & adjust the distribution as you suggested.

Why wouldn’t it be?

I would love to see any of those two pairs.

2 Likes
#3

This seems fair and reasonable. It could also serve to keep more tokens locked up for longer periods, as they become yield bearing. Finally, it could attract even more participation from people who aren’t comfortable farming, but have other attributes to contribute to the community.

2 Likes
#4

I am fully supportive of an admin fee that flows back to veSBR holders.

This would 1) incentivize governance participation of protocol and 2) give value to the SBR token (via veSBR)

Currently, holding SBR allows you to govern through the DAO. Let’s fast forward to a successful scenario where TVL of Saber protocol is 20B and doing trade volume of 1B per day. Without an admin fee or similar mechanism, I still think SBR should have a marketcap gravitating toward zero, as the protocol’s success is not economically connected to the token.

Stakeholders:

  1. Traders…want high TVL for low slippage, want low trade fees (gross fees will not be affected so non-issue)
  2. LPs…want high yield for placing their liquidity
  3. SBR holders or future holders…want a reason to hold, eg dividend yield

We want the LPs to be incentivized to having sticky liquidity in pools, so that the traders keep swapping on Saber . LPs will be directly affected by redirecting 50% of current trade fees back toward veSBR holders.
How to address that?

  1. increased value of SBR will increase their yield. but how much of their return is in trade fees and how much in SBR emissions?
  2. maybe Saber protocol increases emission schedule on pools?

no as per @tmnxeq

this seems fine. Curve i think has same fee structure. what about other protocols?

i think 2SBR is a perfect, simple vehicle as USDC/USDT are both stable coins and the “dividend yield” to veSBR holders can easily be forecasted. I definitely do not want more SBR. Theres something about holding more of tokenX to get more of tokenX that does not sound right at all.

If anyone can share historical perspective on Curve’s implementation of their admin fee, that would be great. eg, after implementation, what happened to their TVL and daily volume? How quickly did they roll out admin fee to the other pools?

1 Like
#5

i think 2SBR is a perfect, simple vehicle as USDC/USDT are both stable coins and the “dividend yield” to veSBR holders can easily be forecasted. I definitely do not want more SBR. Theres something about holding more of tokenX to get more of tokenX that does not sound right at all.

I agree, I think it is important to note that Curve started distributing the admin fee in CRV and then changed to distributing 3CRV–discussion can be found in these two post:

If anyone can share historical perspective on Curve’s implementation of their admin fee, that would be great. eg, after implementation, what happened to their TVL and daily volume? How quickly did they roll out admin fee to the other pools?

Historical curve tvl/fee/trading data can be found here: Dune Analytics
Additional data can be found here: Token Terminal | Fundamentals for crypto
TLDR: TVL up and to the right.

Admin fee was rolled out to all pools on upon vote passing & all new pools have had the same admin fee: https://dao.curve.fi/vote/parameter/2

The admin fee has been live since the 19th of September 2020.

#6

Here is a draft proposal based on the feedback above:

Summary:

Proposal to introduce an admin fee. This would split the current 0.04% trading fee between veSBR holders and liquidity providers.
This ensures all SBR stakeholders benefit from an increase in volume on Saber and it brings an additional valuable feature to being an active member of governance and SBR holder.

Abstract:

The Saber token (SBR) has a growing range of attractive properties when it is locked for veSBR, ranging from gauge boosts to protocol governance. Through these governance levers, these token holders influence the direction of the Saber protocol, which is an important responsibility for Saber’s long term success. This work should be financially rewarded and we propose to use the Admin fee feature in Saber for that.

Saber should introduce an admin fee of up to 50% of the trading fee. This proposal is therefore to introduce an admin fee that will flow to veSBR holders from the 0.04% trading fee. With most of the returns to liquidity providers coming from SBR, we expect liquidity providers to be unaffected by this.

Motivation:

  1. Liquidity Providers : they provide capital for the pools and earn a yield on trading volume. They are currently earning additional incentives in the form of SBR distribution.
  2. veSBR holders are SBR holders who decided to lock SBR to participate in the governance process. They govern the Saber protocol which manages over a billion USD in liquidity. They may also be Liquidity Providers.
  3. To ensure there is no incentive misalignment , every participant should be incentivized to grow Saber. Practically speaking, this means maximizing trading volume.
  4. Liquidity providers should be compensated for their capital, which is why they would still earn 50% of the trading fee as well as SBR rewards. These participants are free to do whatever they want with their SBR.
  5. veSBR holders , who have locked their SBR and are showing a long term commitment to the protocol, should be compensated for their good governance decisions to build Saber. By introducing an admin fee for veSBR holders, this ensures incentives are aligned and that these committed holders benefit from their governance.

Specification:

  1. Introduce an admin fee.
  2. The admin fee would then be directed to veSBR holders. The admin fee should be delivered in the form of 2SBR, the official name for USDC/USDT LP tokens. This has a secondary fee generating effector for the protocol as USDC/USDT has a .5% withdraw fee.
  3. Based on 24hr volume (Saber Info) as of this post, .02% would represent ~$2.54 million per year distributed to veSBR holders.

What we need more input on is implementation, execution & timeline. Perhaps members of the core team can help here.

3 Likes
#7

Great idea. The only question is, how could we send fees to veSBR stakers on-chain? Tribeca does not support querying historical vote balances, since due to the fee model of Solana this could be very expensive.

Here’s one idea of an implementation:

History

There are two accounts that will be used to compute historical balances:

  • LockerHistory, which stores the total number of veSBR eligible for fees for each Solana rent epoch, and
  • EscrowHistory, which stores the veSBR in each Escrow per Solana rent epoch.

LockerHistory

The LockerHistory account stores 1 year worth of epochs. It contains the following fields:

  • first_epoch, the first epoch in the buffer
  • locker, the Locker being tracked (the set of all vote escrows)
  • ve_balances: [u64; 120] One year’s worth of Lockers.

There will be at least 6 of these accounts existing at any given time, since the maximum lock period is 5 years.

EscrowHistory

Any veSBR holder can create an EscrowHistory account which basically computes their veSBR balance for each epoch. This will take up 8 (anchor discriminator) + 32 (escrow key) + 1 (bump seed) + 120 (epochs per year) * 8 (bytes per u64) = 1,001 bytes, which currently would cost 0.00792048 SOL.

$ solana rent 1001 -u mainnet-beta
Rent per byte-year: 0.00000348 SOL
Rent per epoch: 0.000021514 SOL
Rent-exempt minimum: 0.00785784 SOL

Any time someone refreshes and/or modifies their vote escrow, they should refresh their EscrowHistory accounts. If they are 5-year locked, they would also pay 0.00785784 * 5 = 0.0392892 SOL of Rent fees.

Fee Distribution

Each epoch will have the epoch’s worth of fees sent to a token account. One’s fee share is determined by the following:

user_fees = total_fees[epoch] * user_ve_balance[epoch] / total_ve_balances[epoch]

A user may claim their fees at any given time for each epoch.

Airdrops

If one desires to airdrop a token retroactively to veSBR stakers, one could use this same fee mechanism to send tokens to anyone. All tokens sent to an EpochDistribution account will be split proportionally amongst all users in the epoch.

Note: NFTs would not be able to be sent to the EpochDistribution mechanism, since NFTs cannot be split.

Funding

If someone else wants to build this mechanism, I would be open to voting on a proposal to grant SBR to fund the development of this project. Ideally it’s someone who already understands the inner workings of Tribeca, so I propose for one of the TribecaDAO members to build this.

I will personally be building the history program, so what’s left is for someone to build out the distributor program.

5 Likes
#8

I second this, and feel this is a good way to reward long term governance participants.

4 Likes
#9

Very thoughtful response and plan. Thanks igm :pray:

#10

Hi, i’m sunnymicrosystems, one of the devs at Sunny. (I’m not Surya, thats the other dev)

We (Sunny team) would really like to see some sort of fee distribution back into the veSBR holders. We are motivated for 3 main reasons:

  1. The Sunny DAO is a big holder of Saber. So some of these fees will go back to the Sunny DAO.

  2. The upcoming sunSBR that we have already started writing the programs for would benefit from this. The sunSBR system would give SBR holders an interest bearing SBR token, in exchange for giving voting power to Sunny (which is really important for Sunny’s strategy). It would be nice to integrate such a fee distribution system, as it adds yet another source of appeal to get users to convert SBR into sunSBR

  3. The Sunny protocol curently is largely centered around Saber. We are currently in the process of expanding to other protocols other than Saber. But a fee distribution back to veSBR would help Sunny as a protocol remain interested in participating in Saber. (Though I guess this is more explaining the incentives of why Saber should want to bend over for Sunny)

The scheme of organizing it into epochs is good. 0.0392892 SOL is an acceptable cost to 5 year stakers.

Given our motivations, we would like to help make progress on this. I can take on this and write the distributor program to speed things up. Seems pretty straight forward.

How can I move things along and get a proposal to get a grant for writing this distributor program?

p.s. Personally, I think the withdraw fee is stupid and should’ve never been implemented, but thats another story… I’m mostly interested in capturing the swap fees to veSBR holders. Sorry this is kinda rambly.

6 Likes
#11

Hey @sunnymicrosystems, thanks for reaching out! I think the best way to structure this grant might be to have tokens distributed with a lockup.

The grant deliverable would be to build this distributor program + to build the initial integration into the Tribeca frontend.

I’ll propose giving 125,000 SBR linearly released over 12 months + a 3 month cliff, with an option to clawback unreleased funds at any point in time if the DAO thinks you no longer deserve compensation. We can use https://venko.app for this.

Knowing you, I expect you to ship this out in a week or two :slight_smile: but deferred compensation seems more fair here especially for the DAO’s first grant.

If this sounds good to you, I can help you draft a proposal.

1 Like
Discussion: Grant Sunny Microsystems 125,000 SBR for building the Saber fee distribution system (5 year locked)
#12

This is a great proposal! What do you all think about also increasing the withdrawal fee for some of the Saber pools?

To date, the Saber DAO has collected a little over $4 million in USDC and USDT from admin withdrawal fees (source: Explorer | Solana) on the USDC-USDT pool, which can be distributed to veSBR lockers. Enabling withdrawal fees gives us an easy way to make protocol owned liquidity proposed by @knjoeyn happen and allows the DAO to benefit from weekly gauge rebalancing.

#13

I think we need to be careful about withdraw fees on anything other than USDC/USDT as it can be a barrier to liquidity coming to Saber, especially if competitors do not have withdraw fees. Curve never introduced such fees and has grown exponentially.

I think keeping the fee on USDC/USDT makes sense for the time being, as fees will be generated as people realize/trade their 2SBR stream from veSBR. Having another proposal on how the withdraw fee is used (for example as a funding mechanism for POL) should be independent of this proposal.

1 Like
#14

i agree with @sbhk that withdrawal fee is disincentive for LPs

Thank you @igm and @sunnymicrosystems for kickstarting the technical execution discussion!

#15

Makes sense. Let’s discuss withdrawal fees in a different thread.

#16

@igm okay this all sounds good. I don’t have enough SBR to create a proposal, so it would be nice if someone could write and propose it on Tribeca.

All this earned SBR is going to get 5-year locked anyways since we are believers in Saber. :gem::raised_hands:

4 Likes
#17

Creating a proposal is free, but we can activate it after you write it! :smile:

1 Like
#18

Happy to write it on Monday as I proposed the :thread:. Would love to leave this open for additional feedback until then.

#19

Update: I went ahead and wrote the balance snapshot program as described in my technical implementation post. It should be on mainnet + in the Tribeca interface some time this weekend, after I get some other eyes on it. The program is extremely simple so I doubt there will be any major issues.

8 Likes
#20

igm always be shipping! :pray: :muscle: :clap:

3 Likes