[DEPRECATED] Please see https://gov.centrifuge.io/t/rfc-linked-pools-technical-proposal/5569

Title: RFC: Linked Pools

Tags: cp-4, May, 2023

Proposal type: CP4
Author(s): @mustermeiszer
Contributor(s): @jeroen @akhan
Technical/non-technical proposal: Technical proposal
Date proposed: 2023-05-23

Short Summary

Linked Pools, like the existing loans logic, are an extension for on-chain pools. This feature will allow other pools to be funded directly by another pool where the system was previously limited to fund only loans.

High level objective

The main objective for this is to extend the capabilities of the Centrifuge Chain, making the protocol more flexible, suitable for a wider range of use cases and allowing to automatically manage how liquidity is distributed among linked pools. This RFC is deliberately not concerned with proposing use cases or business ideas and rather only deals with the technical aspects.

Description of Activity

The goal of this feature is to extend the given pools logic and not to implement a new type of pool. While the latter would be easier to accomplish, it would drastically increase maintenance work and increase the attack surface of the codebase. Relying on the existing pools logic allows us to make use of well-reviewed and well-audited code that takes care of capital flows inside of the pool.
Linked Pools are an extension for how a pool can be used. Currently, the pool acts as a reserve for the loans logic of Centrifuge Chain. The loans logic can take tokens from the pool but must return the same amount of tokens later in time plus an additional possible interest payment.

We propose a pallet-pool-links for which a pool also acts as a reserve. A linked pool can be used to ((semi) - automatically) invest into other pools, receiving tokens of a tranche in return.
The funds of a linked pool (most frequently a stablecoin such as USDC) can be used to invest into other pools. In return, they receive Tranche Tokens (TTs) which are held in the linked pool account.

A pool with linking capabilities is at its core a normal pool. This architecture allows flexible pools that are able to fund both loans as well as other pools. The process of how a pool can be registered as a linked pool is to be determined.
Once the pool is registered in pallet-pool-links, reserves in the pool can be used to fund other pools. The pallet-investments hereby ensures that the pool must be listed like a normal investor for each pool it wants to invest into. This means that in order to invest into another pool, a pool must go through the other pool’s onboarding process, including KYC and signing subscription agreements.



The graphic above shows that the pallet-pool-links is just another pallet on Centrifuge Chain that interacts with the pallet-pool-system. Furthermore, it interacts with the pallet-investments in order to fund other pools.
As a pool with linking capabilities is just another pool at its core, the pallet-pool-system still ensures interest is received (if applicable) on the investments and that senior tranches are protected by the value of more junior tranches. In order to ensure the above, this feature also contains a way of valuing the extended portfolio of pools with linking capabilities. This is needed as the total value of a pool now (possibly) not only consists of the valuation of the individual loans it has funded, but also of the value of the TTs it holds.



The total value of a pool’s portfolio is calculated by the sum of the values of all loans (if any) plus the amount of TTs times the value of the TTs as determined by the on-chain valuation logic for both loans and TTs. The value of the TTs is calculated by the pallet-pool-system on-chain valuation method for tranches that is also used when epochs are closed and investments and redemptions are fulfilled.

The following graphic visualizes the flow of funds of a pool with linking capabilities. The first flow shows the flow of TTs when funds are being invested into a pool. The flow branches when they reach Pool A. The pool either funds loans or funds other pools with it. Pools can be restricted to only fund loans, only fund other pools or fund both. In any case, the decision of what is funded at which time needs to be decided by an account with right on-chain permissions.



When investors want to redeem from a linked pool, redemptions can either be satisfied by the given reserve the linked pool has, wait for repayments of active loans or the pool or redeem some TTs of other pools it is holding.

The graphic below shows the flow in this case.



In both cases, the fulfillment of investments and redemptions depend on the execution of the epoch of a pool. Subsequently, this means that redeeming from a pool with links to other pools might take more time as the epoch of linked pools needs to fulfill the orders made by the pallet-pool-links. At the same time, it might take more time for a pool with links to other pools to generate interest as the investments made by the pallet-pool-links need to be fulfilled by the epoch of the linked pools.

Technical Details

The following sub-chapters roughly sketch the modules that are part of the implementation of this feature. They describe the public API of the pallet-pool-links and explain the calculation approach for the TTs valuation.

pallet-pools-links

The pallet itself exposes the additional functionality for deploying the funds of a pool. Compared to the pallet-loans that allows borrowers to borrow against a loan, the pallet-pool-links provides functionality to invest into another pool, retaining tranche tokens in exchange. The actual investment action is triggered by an account with the right permissions on-chain. This is similar to how the chain controls which accounts are allowed to borrow against a loan.

Extrinsics
fn link_pool

An extrinsic that adds another existing pool to the possible pools that can be invested into. This extrinsic will not be callable by anybody and will be restricted. Which accounts are allowed to trigger this call is controlled by on-chain permissions and the configuration details for a given pool.

fn unlink_pool

An extrinsic that removes a previously linked pool. This extrinsic will not be callable by anybody and will be restricted. Which accounts are allowed to trigger this call is controlled by on-chain permissions and the configuration details for a given pool.

fn target_positions

An extrinsic that allows to define how the funds in the pool should be distributed among the pools that have previously been linked via link_pool. This extrinsic will not be callable by anybody and will be restricted. Which accounts are allowed to trigger this call is controlled by on-chain permissions and the configuration details for a given pool.

fn update_positions

An extrinsic that does invest/redeem according to the defined target positions. This extrinsic will not be callable by anybody and will be restricted. Which accounts are allowed to trigger this call is controlled by on-chain permissions and the configuration details for a given pool.

Tranche holding valuation

With this feature, as shown above, the portfolio of a pool can now contain both loans and tranche tokens.
As the value of the tranche token can only indirectly be determined by the value of the pool it is coming from, the valuation logic must account for this fact.
Whether this valuation needs to be its own pallet is to be determined depending on the need for storage. Otherwise, it will be a simple struct wiring together the valuation of the loans and the tranche holdings of a pool.

Change or improvement

The given proposal will

  • extend the versatility of the Centrifuge protocol

Responsible

Responsible for implementing this feature would be k/f.

Alignment to the mission of Centrifuge DAO

Adaptability is part of the Centrifuge mission. It is beneficial for Centrifuge to develop new functionalities to meet potential future market needs.


EDIT NOTES

  • Replace usage of the word Pool Token (PT) with the word funds or investments – Reasoning: the wording could imply we are creating a new token, which we are not.
  • Remove description how the registration of a linked pool works (and associated extrinsic in the pallet-pool-links technical part) – Reasoning: The actual flow is to be determined and not a technical aspect.
  • Renamed pallet-pool-linkage to pallet-pool-links – Reasoning: Cleaner and more modern wording
9 Likes

This gets my support! This enhancement to the loans logic will make possible some oft-requested use cases, like a “pool of pools.”

3 Likes

Good day here.
I’m quite surprised that so an important proposal has not attracted any curiosity or demand from the community and DeFi experts.
@mustermeiszer Actually, i have one question about the default and how the default case will be managed with TTs/PTs?

Hello! this is a very insteresting proposal. Thank you for sharing!

I am trying to understand how would work the inflow of investments and the outflow of redemptions in the linked pools. Each pool is manage using Epoch mechanism, so is posible that this flow could cause investments and redemptions delays?

I’m also curious, how does the system ensure that it has enough reserve of PTs to satisfy the redemptios of each Epoch?.

3 Likes

Assume:

  • Pool A: Just loans
  • Pool B: Just investments into A
  • PoolC: Both loans and investments into A

Now:

  • A has some defaulting loans
  • The token price of A’s junior tranche drops
  • As a result the token price of B also goes down as the valuation of its holdings on A are worth less
  • The same goes for C

NOTE:

  • The token price of B can ONLY be affected by defaults in A
  • The token price of C can be BOTH affected by defaults in A and by defaults in C, meaning defaults on its own loans

Let me know if this helps getting the right mind model.

1 Like

Yes, that is definitely true. The linked pool depends on the execution of epochs of linked-into pools in order to redeem and invest.

There is no guarantee, as with other “normal” pools in the system. But in contrast to these pools, the linked pools logic will recognize a misbalance between PTs and redemptions and allow to reduce positions as a consequence and by this free up more PTs for redemptions.

1 Like

Thank you for your explanation @mustermeiszer !

1 Like

Great! thank you very much for your explanation.

FYI, I slightly adapted the above proposal in order to have a clearer wording.

1 Like