CP59: Linked Pools (Technical Proposal)

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.


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.

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 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


Eli5? For all pools you need to sign a contract and I try to understand which problem you solve and which solution you offer. Maybe your proposal is too technical for me :wink:

Good day
What is the estimated time request to develop, test and deploy Linked Pools?
I know that hard to give any ETA, but approximately?

Let me try:
Historically Centrifuge pools were built to directly invest into real world (off chain assets) like Real Estate, Trade Finance etc. Each asset in the pool was a loan or non-fungible asset that was pledged to the pool. It can be used to create different financial products on chain: a credit fund, a CLO (collaterlized loan obligation) or a private loan portfolio/account.

However there are many users who might want to hold multiple pool and investments. I might say: I’m a DAO and my treasury investment strategy is 30% real estate pools, 20% trade finance pools and 50% tokenized US treasuries. Another potential use case on Centrifuge might be a fund that comes along and wants to offer an index across all private credit pools on Centrifuge today. They might say we’ll sell a fund to investors who want to get broad exposure to RWAs.

To enable these use cases “Linked Pools” proposes to extend the functionality of pools to not just be used to provide money to borrowers off chain but also create pools that simply pass on the pools according to some rules (e.g. a portfolio split of 20% for A, 30% for B and 50% for C) of all capital into other pools.

This proposal is technical and has been led by @mustermeiszer because of the wide applications and different applications the technology could have from automated portfolio management for individual users to a backend for a tokenized RWA fund.


That is really hard to say and I can not give any estimates on this one.

This proposal has moved on to an OpenSquare snapshot.

The vote will be open from 14th August 20:30 CET - 21st August 20:30 CET.

:ballot_box: Vote here: CP59: Linked Pools

1 Like

Good day, Community!
The proposal has successfully passed.

Voted 8.69M CFG
Voters 113

  • Yes 8.69M CFG
  • No 72.35 CFG

Thanks everyone.

Hey Lucas, sorry for late reply. Summer was too hot :wink: …Thanks for the explanation. This is a great development of investment scenarios. Congrats! Really looking forward to see Centrifuge blossoming. :heart: