RFC: Linked Pools (Technical Proposal)

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-linkage for which a pool also act as a reserve. A linked pool can be used to ((semi) - automatically) invest its tokens into other pools, receiving tokens of a tranche in return.

A pool is denominated with a defined token (e.g. USDC) — named pool token (PT) — and investors can only invest into a pool with these PTs. In return, they receive Tranche Tokens (TTs). The issuer of a loan is then able to borrow tokens against a given loan and the loans logic subsequently takes the borrowed amount of PTs from the pool account and deposits them into the issuer 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 with their PTs. The process to create a pool with linking capabilities is as follows:

  1. Administrator proposes the registration of a new pool via on-chain governance

  2. On-chain governance executes the registration

    2.1. A registry entry for the pool is created

    2.2. A pool in the pallet-pool-system is created

  3. Administrator proposes to register the pool in the pallet-pool-linkage

  4. Administrator executes the registration — This is only possible if

    a) A fixed period of time has passed (e.g. 7 days). A value that is defined on a runtime level and can
    only be changed by on-chain governance

    b) There are no outstanding redemptions left — i.e. no investor wants to leave the pool

Both of the above requirements are in place to protect investors of a pool from unwanted action of the pool’s administrator; in this case, the registration of the pool for linking functionality.

After step 4, the pool is registered in pallet-pool-linkage, and its PTs can be used to fund other pools. The pallet-investments hereby ensures that the pool must be allowlisted 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.
Note that it is possible for an arbitrary amount of time to pass between step 2 and step 3.



The graphic above shows that the pallet-pool-linkage 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 with its PTs.
As a pool with linking capabilities is just another pool at its core, the pallet-pool-system still ensures how investors PTs flow in and out of the pool, ensuring that investors receive interest on their 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 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 PTs of a pool with linking capabilities. The first flow shows the flow of PTs and TTs when PTs are being invested into a pool. The flow of the PTs branches when they reach Pool A. The pool either funds loans with new PTs 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 pool, redemptions can either be satisfied by the given reserve of PTs a pool has, wait for repayments of active loans or the pool, or, if possible, redeem some TTs of other pools it is holding.

The graphic below shows the flow of TTs and PTs 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 linkage to other pools might take more time as the epoch of linked pools needs to fulfill the orders made by the pallet-pool-linkage. At the same time, it might take more time for the PTs of a pool with linkage to other pools to generate interest as the investments made by the pallet-pool-linkage 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-linkage and explain the calculation approach for the TTs valuation.

pallet-pool-linkage

The pallet itself exposes the additional functionality for deploying a pool’s PTs. Compared to the pallet-loans that allows borrowers to borrow PTs against a loan, the pallet-pool-linkage provides functionality to invest PTs 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 register

An extrinsic that marks a pool as capable of being able to link against other pools. 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 deregister

An extrinsic that removes the capability of a pool as being capable to link against other pools. 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 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 PTs 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.

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