Title: RFC: Linked Pools
Tags: cp-4, July, 2023
Proposal type: CP4
Author(s): @mustermeiszer
Contributor(s): @jeroen @akhan
Technical/non-technical proposal: Technical proposal
Date proposed: 2023-07-14
Short Summary
Linked Pools are an extension of functionality for on-chain pools beyond the existing asset-financing logic. This feature will allow so-called “linked” pools to be funded directly by another pool where the system was previously limited to fund only assets.
High level objective
The main objective for this is to extend the capabilities of Centrifuge Chain, making the protocol more flexible, suitable for a wider range of use cases and allowing the protocol 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 existing 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, each pool acts as an individual reserve. Each pool on Centrifuge allows stablecoins to be deposited into the reserve of a pool, and these stablecoin reserves can be taken from the pool and the same amount of tokens must be returned later in time plus an additional possible interest payment.
We propose a pallet-pool-links for which there is an extension of the existing functionality that a pool can also act as a reserve for other pools. A linked pool can be used as an individual reserve as well as a reserve for other pools. When the reserve of a linked pool (most frequently a stablecoin, such as USDC) is used by another pool, it receives Tranche Tokens (TTs) in return which are held in the linked pool account.
A pool with linking capabilities, a linked pool, is at its core a normal pool. This architecture allows additional flexibility for linked pools that are able to fund both assets directly 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, stablecoin 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 with the stablecoins in its reserve.
As a pool with linking capabilities is just another pool at its core, the pallet-pool-system still facilitates interest received (if applicable) on the investments. 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 assets it has funded, but also of the value of the assets being held by other pools, represented by the Tranche Tokens (TTs) it holds.
The pool’s portfolio is calculated by the sum of the values of all assets (if any) plus the value of the linked pools as determined by the on-chain valuation logic for assets. The value of the linked pools is calculated by the pallet-pool-system on-chain valuation method that is also used when epochs are closed and investments and redemptions are fulfilled.
The following graphic visualizes the flow of stablecoin 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 assets or funds other pools with it. Pools can be restricted to only fund assets, 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 the right on-chain permissions.
Redemptions or distributions can either be satisfied by the given reserve the linked pool has, wait for repayments of actively financed assets 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 or processing a distribution 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 each pools’ valuation.
pallet-pools-links
The pallet itself exposes the additional functionality for deploying the funds of a pool’s stablecoin reserve. Compared to the existing pallet-loans that allows funds to be borrowed directly from the pool against an asset, the pallet-pool-links provides functionality for another pool to use the reserves of a linked pool, and the linked pool retains tranche tokens in exchange. The actual redemption 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 an asset.
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 fn 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.
Linked pool valuation logic
With this linked pool feature, as detailed above, the portfolio of a pool can now contain both assets and tranche tokens (TTs).
As the value of the linked pool can only indirectly be determined by the value of the pools it has invested in, 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 assets in the pool and the assets from the other pools linked to it.
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 note: This RFC is an updated version of RFC 5453 with clearer language. 5453 has been closed in favor of this rfc.
UPDATE 14th August 20:24 CET
This proposal has been submitted to the proposal repository on GitHub as CP59 so it is now final and the OpenSquare snapshot has been created.
The OpenSquare snapshot will be open from 14th August 20:30 CET - 21st August 20:30 CET (7 days)
Link to proposal on GitHub: https://github.com/centrifuge/cps/blob/main/cps/CP59.md
Vote here: CP59: Linked Pools
Vote here: 
