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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
The given proposal will
- extend the versatility of the Centrifuge protocol
Responsible for implementing this feature would be k/f.
Adaptability is part of the Centrifuge mission. It is beneficial for Centrifuge to develop new functionalities to meet potential future market needs.
- 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-linkstechnical part) – Reasoning: The actual flow is to be determined and not a technical aspect.
pallet-pool-links– Reasoning: Cleaner and more modern wording