RFC: Centrifuge Protocol Fees

Centrifuge Governance Proposals
, , , ,
1

Good day Community :raised_hand:
We, Governance and Coordination Group, would like to ask Centrifuge Community and CFG token holders for feedback regarding this proposal. Any feedback, comment, or suggestions from the Community are highly appreciated.

Proposal type: CP-4
Authors: Governance and Coordination Group (ImdioR, Rhano)
Contributor(s):
Technical/non-technical proposal: Technical
Date proposed: 2023-01-19

Short Summary

  • Implement protocol fees on Pools Centrifuge Chain

High-level objective

  • This proposal, if passed, will add protocol fees on Centrifuge Chain in order to ensure self-sustainability of the protocol

Background

Over the past three years, Centrifuge has been able to achieve significant goals, not only in terms of development, integration, and partnerships but also financially in DeFi. Until now Centrifuge didn’t accrue any fee from Issuers or Investors for using the Tinlake application.

That is why the development and implementation of protocol fees is an expected and considered step that will ensure the independence and protection of the protocol from external economic shocks, ensuring stable, regular, and predictable development.

The only way to be able to run a successful Protocol is the availability to fund future development and innovation of the protocol. Even a small protocol fee would provide significant funding to help cover general protocol expenses.

There have been several discussions among community members regarding introducing protocol fees in the past. Based on the feedback received on this topic, the Governance and Coordination group would like to propose the following proposal to the Community.

Detailed description of proposal

The main objective of protocol fees is to provide an economic incentive and to help ensure that the protocol can function smoothly and efficiently during any external economic situation.

In the initial phase, fees will simply be accrued into the on-chain treasury. There are many possibilities and opportunities to pursue once fees accumulate.

The funds in the treasury will typically be used to finance the development and maintenance of the protocol, and expansion as well as to support other activities that are deemed to be in the best interests of the protocol and its users.

Given the volatility of native token currencies in general, we would like to propose the protocol fee currency be in a stablecoin (the currency of the Pool on Cent Chain) in order to avoid developing complex solutions for cross-exchange.

  • The fee is defined as a % of all outstanding loans in the pool. It is set on each pool during deployment and can only be changed by governance. The proposed initial fee is 0.4% per year.

  • The protocol fees are accrued every second on each loan and paid by the Issuer on any borrowing or repayment transaction into an on-chain treasury, which is a special account controlled by governance(i.e. the token holders).

The formula for calculation of the Protocol Fees, based on the outstanding loans:

image
image976×213 16.4 KB

where L = Loan in Pool Currency, i = protocol fee value in decimal, t = Time → Loan duration in years = [Days/365] , n = seconds per year.

Example: L= 10, 000,000 Pool Currency, i = 0.004, Repayment in 120 days → t= [120:365] = 0,3287671232876712, n=31,536,00

image
image903×205 35.5 KB

Change or improvement

  • Extend the pools pallet to start collecting protocol fees as described above.
  • Activate Protocol Fees on Centrifuge Chain and set a fee of 0.4% of all outstanding loans in the pool.

Alignment to the mission of Centrifuge DAO

We believe that the implementation of Protocol Fees is one of the most important functions for the future of the Protocol.

The fees paid in stable tokens will ensure the ongoing development and maintenance of the protocol and will guarantee future development and innovation of the Protocol, as well as support other activities that are deemed to be in the best interest of the protocol and token holders.

The RFC will be open for a minimum of 7 days.

Looking forward to any feedback and any concerns that you might have with this proposal.

Next steps

If there is support for this proposal, the next steps will be to submit it to the Proposal Repository on Github and create an Opensquare snapshot vote. There will be a separate post here on the Forum once that’s done.

If the Opensquare snapshot vote passes, this proposal will either be submitted as a motion by the Council or it will be part of the next Runtime Upgrade.

If you have any questions or comments, please feel free to reply to this post.

10 Likes
2

Hey Centrifuge community! Engaging call this morning!

Here are my thoughts on protocol fees as someone interested in building a platform on the Centrifuge chain.

  1. Would a fee prevent issuers from on-boarding because it disrupts their business model?
    1a. I believe Kevin from Blocktower brought this up briefly.

  2. Is the fee only for issuers? Or would dapps built on Centrifuge somehow incur the same fee?

  3. I know there was some discussion on this, but what is a comparable protocol incurring fees in a similar structure.

  4. How does the fee compare to fees in traditional TradFi? Does this fee undermine the value prop of “lower cost of capital” to issuers after the fee is extracted?

I think some underwriting examples from the Credit Group would help to display the fee impact.

Hope these questions help! Always looking to learn so please reach out about any of this!

6 Likes
3

@ImdioR thanks for submitting this proposed RFC for protocol fees!

I wanted to comment on the details of the technical implementation. I believe it would be good if some of the technical specifics are left out in this proposal, and the proposal focuses instead on the goal (a 0.4% annual fee based on the pool value excluding the reserve, paid in stablecoins by the borrower to the on-chain treasury). I believe there are a few technical details that would warrant more research from the k/factory engineering team before we can make the best decision, such as:

  1. Should the fee be based on the total outstanding debt of all loans, or the portfolio valuation?
  2. Should this be implemented in the loans pallet or use a trait implementation based on hooks from the loans pallet and be implemented in a new pallet? (note: there is no pools pallet in the runtime)
  3. Should the fee be paid on originations and repayments, or are there other mechanisms? E.g. we can explore whether it’s technically feasible that the fee is automatically deducted from the borrowers wallet.

One other detail that I believe could be technically complex is: “It is set on each pool during deployment and can only be changed by governance.”. There currently is no per-pool storage properties that are configurable by governance. All properties are either per pool and can be controlled by the pool admin, or are global properties (i.e. apply to all pools) and are controlled by governance. This certainly is technically possible, but if the goal is for now to have a fixed fee for all pools on Centrifuge Chain, I would suggest we keep this simple and use a global property rather than store this fee % per pool.

4 Likes
4

Thanks @ImdioR!

  1. As @jeroen described I think the technical implementation of the protocol fees is beyond the scope of the RFC and should be split into a second more technical RFC. Details like how and when protocol fees are being paid need more input from the developing team as well as the issuers. Further, the more technical RFC could explore the technical possibilities to change fee structure in the future after passing a governance vote. This would need input from a governance perspective as well as technical know-how.
  1. How would this account be structured? Can you give an example of the control mechanism?
3 Likes
5

I agree, Centrifuge seems to attrack capital (around 112 m$ TVL), in order to continue the developpement and run the protocol like a business, Centrifuge needs cash flow.

Could you detail the price of 0.4% versus standard Finance?

6

Hi ItsJake
Thank you for your comment and very interesting questions.

Would a fee prevent issuers from on-boarding because it disrupts their business model?
1a. I believe Kevin from Blocktower brought this up briefly.

I think this is not the case and Issuers will be able to include this fee in the business plan. In comparison with other Protocols, that are working with RWA, (Goldfinch - +10%,Maple 0.99%,Credix performance fee 10%, Ribbon Finance takes 10% performance fees and 2% management fees, Truefi: 0.50%) the proposed fee is the smallest one.
Before starting the RFC we had a discussion about this argument with the Community and the Issuers and we received positive feedback from the Issuers.

Is the fee only for issuers?

Yes, for now, the fee that we propose in this proposal is for Issuers only.

Or would dapps built on Centrifuge somehow incur the same fee

What about the second part of your question I think that the fee structure for dApps built on Centrifuge could be discussed in the future

I know there was some discussion on this, but what is a comparable protocol incurring fees in a similar structure.
How does the fee compare to fees in traditional TradFi? Does this fee undermine the value prop of “lower cost of capital” to issuers after the fee is extracted?

Securitizations frequently cost between 0.5% and 2% annually in fees charged by various intermediaries (fund administration, payment agents, calculation agents etc.). The Centrifuge will replace the vast majority of these intermediaries with the lowest fee. :cyclone:

3 Likes
7

Good day Jeroen and thank you for your questions.
Your questions are very important because you are one of the most experienced Devs.

Should the fee be based on the total outstanding debt of all loans, or the portfolio valuation?

The fee should be based on the total outstanding debt of all loans.

Should this be implemented in the loans pallet or use a trait implementation based on hooks from the loans pallet and be implemented in a new pallet? (note: there is no pools pallet in the runtime)

I think that this question should be addressed to Devs who will work on this proposal if this proposal will pass and Community will approve it via Opensquare voting. Because the Community doesn`t have enough expertise to evaluate this (me neither).

E.g. we can explore whether it’s technically feasible that the fee is automatically deducted from the borrowers wallet.

With automatic deduction from the borrowers’ wallet do you refer to the deduction of the fee during the origination of additional loans and during the repayment as well or only during the repayment?

One other detail that I believe could be technically complex is: “It is set on each pool during deployment and can only be changed by governance.”. There currently is no per-pool storage properties that are configurable by governance. All properties are either per pool and can be controlled by the pool admin, or are global properties (i.e. apply to all pools) and are controlled by governance. This certainly is technically possible, but if the goal is for now to have a fixed fee for all pools on Centrifuge Chain, I would suggest we keep this simple and use a global property rather than store this fee % per pool.

About your last question.
The proposal proposes to implement and set a unique fee (now) for all pools during the deployment with the possibility to change it via governance. If this is possible from the technical side to assign different fees for each pool and track them or this should be developed apart?
In case this option could be too complex technically now and will require more time could we set a fixed fee for all pools and in future development and provide (probably will be required to add RU) a variable parameter via hoock?

1 Like
8

Hello Anna and thank you for your questions.

As @jeroen described I think the technical implementation of the protocol fees is beyond the scope of the RFC and should be split into a second more technical RFC. Details like how and when protocol fees are being paid need more input from the developing team as well as the issuers. Further, the more technical RFC could explore the technical possibilities to change fee structure in the future after passing a governance vote. This would need input from a governance perspective as well as technical know-how

The main purpose of this RFC stabilize the structure of protocol fees, clarify the main points and check if the Community will confirm the implementation of this proposal via voting on Opensquare.
If the community will positively accepts this proposal, in the next step the Team who will work on the implementation of this proposal could definitely inquire for more input via the technical RFC.

How would this account be structured? Can you give an example of the control mechanism?

Yes, sure.
A unique account with different Pool currencies (for example USDC, USDT, EUROC). We can use the same logic as the Polkadot account which can manage different assets (Dot, CFG and etc) with correlated wallet addresses for each asset.

That wallet address will be controlled by Governance (Centrifuge Councillors in Gov1) in the same way/mechanism as how the Treasury wallet address is actually controlled by Centrifuge Councillors.
Will be possible to have one wallet address for native CFG tokens, Pool currency? I think @lucasvo mention this during the last governance call.

1 Like
9

Good day Yannick
Thank you for your question.

Thank you for your support. I totally agree that the protocol should be self-sustainable as soon as possible.
Please note, that the proposal proposes to implement Protocol Fees on Centrifuge Chain (for Centrifuge Pools).

Between 0.5% and 2% annually in fees, but i saw also the higher fee (up to 4%).

1 Like
10

Just to be clear, will the fee be on the aggregate amount of capital in the pool or on the amount of capital drawn from the pool by the issuer? A strong preference to the latter, as the former would incentivize issuers to draw more credit than they need.

1 Like
11

I would propose rewriting this to base it on the portfolio valuation rather than the debt. The reason is that if it’s based on the debt, and a loan defaults and is written off, then the borrower will still have to pay fees in perpetuity. The portfolio valuation (otherwise known as the Net Asset Value or NAV) fairly reflects the current AUM of the pool.

To change this, I would propose to rewrite

The protocol fees are accrued every second on each loan and paid by the Issuer on any borrowing or repayment transaction …

to

The protocol fees are accrued every second on the portfolio valuation and paid by the Issuer on any repayment transaction …

And

The fee is defined as a % of all outstanding loans in the pool.

to

The fee is defined as a % of the valuation of all loans in the pool.

And changing the term Loan in Pool Currency in the formula to Valuation of Loan in Pool Currency.

In that case, I would propose changing the line

Extend the pools pallet to start collecting protocol fees as described above

to

Extend the Centrifuge Protocol to start collecting protocol fees as described above.

To leave out the details of which pallet this belongs in.

Yes I think it makes sense to start with a fixed fee for all pools now and implement the logic to make this per pool in the future, when this is needed. Indeed this would then require a runtime upgrade.

3 Likes
12

Saw this post by “benruggedafewtimes” in another Governance discussion re: fees and I thought it was valuable so let me paste it here since he didn’t

"
I like the idea of giving cfg more utility! I don’t think it should be a reward token unless you want tremendous sell pressure. Consider, a loan that has been taken out and based on the value the user has accumulated a large amount of CFG tokens. The user runs into some financial problems and can’t afford the loan repayment, but they do have a large amount of CFG they can dump for cash. More than likely they will do it to generate income to repay the loan. Now imagine 5-10 users having this problem in a short period of time. There could be a considerable drop in price for CFG disincentivizing other investors and punishing current holders.

What I think would work is using CFG to capture the protocol value, the fee structure could be designed so that the protocol fees are collected and distributed with certain percentages going to different vaults mainly one to the team managing the development and maintenance of the protocol and one for CFG holders. The CFG token could then be redeemable for a certain amount of vault value. This would give CFG underlying value and I think it would be less likely to see severe price dumps. Instead we would probably see more and more of it being used to redeem the underlying value from the designated vault. The redeemed CFG could be burned or taken out of circulation to further increase the value of the CFG token. This strategy may prove to be a hinderance to other functions of the chain. But it may be resolved by allowing a selection of other tokens to pay the gas fee similar to how Karura does, where any token can be used for gas fees but transactions are cheaper using CFG. I’m sure there are some kinks to work out with this idea but the general concept is that CFG accumulates if value from fees charged when opening a loan, servicing it, and transferring it (I guess proportional to the loan size). I don’t think there should be a fee to close a loan. This strategy would reward all holders and may open the door to self-repaying loans which I’m sure the borrowers would be interested in. The tokens should probably be burned rather than being taken out of circulation if there is no max supply. Transactions can cost a fraction of a CFG if the price and supply dictate it. If we can give CFG tangible value other than gas fees the borrowers are more likely to give the token value and not dump it. This underlying value would also open up CFG to more defi opportunities in essence making CFG a money lego. Thus collecting fees in stablecoins is critical to the aforementioned strategy.

Acquiring external insurance should be done in addition to any internal protection measures. This would diversify the risk and possibly create a plan A and plan B should an unforeseen situation arise. I hope this help guide the community to the right decision. I can’t be here everyday without getting paid and I’m sure that many others are in the same boat. Therefore I do agree with a delegation of CFG or at least the attached voting power to a group of qualified “loan auditors” however they need to be held accountable for their actions and need to be regularly vetted to ensure there are no conflicts of interest while performing their duties. For example voting to accept certain loans because of receiving bribes or having personal/business connections to the borrower.

Please don’t over burden CFG holders with too much maintenance for their investment. Also the voting power should remain in control of the CFG holder, so that if there is a decision made they don’t agree with they can vote differently and the vote will immediately count, so no cool down time period for CFG holders overruling the vote done by their selected “loan auditor”
"

1 Like
13

I think it should be based on the portfolio valuation, which is the total value of all outstanding assets in the pool. This excludes the pool reserve, and thus achieves what you are also proposing.

2 Likes
14

That makes sense to me.

1 Like
15

Good day @lakejynch lakejynch

Thank you for your feedback and participation!

Good day @jeroen
Thank you for the clarification and your suggestion. In case there aren`t any additional changes, improvements, or objections i will update the proposal before submitting it on GitHub.

16

I supported these parts, “I like the idea of giving cfg more utility”, but am not sure about the details. And “Please don’t over burden CFG holders with too much maintenance for their investment”. I doubt that sentiment can be over-emphasized as ease of use is paramount.

2 Likes
17

Exactly for this reason the creation of the Protocol Engineering Group is proposed with the result, CFG-token holders with lower technical expertise can focus on the non-technical content of each proposal to deliberate about whether a proposal should be implemented or not

18

Thanks, Tjure07.

Patrick Finn

19

Hello Community! :raised_hand:
The snapshot vote for this proposal has passed.

image
image1061×757 145 KB

Results:

  • Voted 7.11M CFG
  • Voters 61

We will keep the community updated on the progress here in this post.
Thank everyone for voting and for participating.

3 Likes
20

Very good news! This is another milestone in the history of the Centrifuge protocol :hugs: :rocket: :metal:

2 Likes