SIP-302: Pools (V3)

Author
StatusDraft
TypeGovernance
NetworkEthereum & Optimism
ImplementorDaniel Beal (@dbeal-eth), Leonardo Massazza (@leomassazza), Alejandro Santander (@ajsantander)
ReleaseTBD
Created2022-05-03

Simple Summary

This SIP proposes the creation of pools in Version 3 of the Synthetix protocol. Pools accept collateral in vaults, enable the creation of collateralized debt positions, and delegate credit to markets.

Abstract

Governance determines the types of collateral that can be deposited in the system. Accounts can delegate their staked collateral to pools by opening staking positions. Accounts can then mint and burn snxUSD, backed by their collateral. Optionally, the owner of a pool can delegate credit to markets and assume credit and debt generated by these markets.

Motivation

By introducing the concept of a pool, we are able to allow stakers to have custom exposure to specific markets' performance. This enables the benefits of a differentiated debt pool, as discussed in SIP-300)

Specification

Overview

The implementation of pools involves logic for vaults of collateral, stablecoin issuance, and the delegation of credit and debt from markets.

Rationale

Pools create a clean abstraction for provisioning liquidity between vaults of collateral and markets. An alternative approach could involve a module for managing all collateral in the system, another module to manage minting and burning snxUSD, and then developing a system to that allows accounts to provide liquidity directly to markets. This is not desirable because it adds unnecessary components to the system and significantly increases the implementation complexity of features like delegated staking positions.

It may seem as if we could allow pools to decide which types of collateral are acceptable, rather than configuring this across the entire protocol. This is not an option because we want to allow snxUSD to be fungible (regardless of the pool from which it was minted). In other words, we need to prevent the creation of a pool that accepts low quality collateral, exposing all snxUSD holders to that risk.

Technical Specification

We can develop this system in a series of modules:

Collateral Module This module manages all collateral held in the protocol. With an account, users can depositCollateral() and withdrawCollateral() via this interface. The TVL of the protocol will consist of the value of all tokens held at the core proxy address. The SCCP-configurable values pertaining to accepted collateral types are also managed in this module. (See Configurable Values below.)

Vault Module vaults of each collateral type per pool Each pool Think of this like a CDP (MakerDAO, Liquity). Deposited collateral can be delegated to vaults, and then snxUSD can be minted against it, creating a staking position.

mint and burn

delegateCollateral

Pool Module Users can create pools and configure settings relating to the markets they are backing (if any) using this module. Pools are created with the createPool() function, specifying an owner. Ownership can be transferred with the nominate/accept pattern or renounced. The pool owner can specify the following configuration for each market with the setPoolConfiguration() function:

  • Weights - This value determines what proportion of the liquidity in a particular pool should be allocated to this market. The proportion of weight assigned to a market (relative to the total weights assigned by this pool) determines what proportion of credit delegated to this market can be utilized by this market.
  • Maximum Debt per Dollar of Collateral - This value determines the maximum amount of debt the pool is willing to assume for this market relative to the amount of credit being delegated towards it. For example, if a pool holds $1,000 of collateral, half of its weight is delegated to a given market, and it's maximum debt per dollar of collateral for this market is $0.75, then the market could attribute a maximum of $375 debt to this pool.

The module also manages an SCCP-configurable Minimum Liquidity Ratio. If this ratio (taken with the proportion of delegated credit from the pool) results in a lower maximum debt than the calculation involving the maximum debt per dollar of collateral, it is used to determine the maximum debt instead. We envision this value being set at least has high as the most conservative target c-ratio.

The maximum debt for a given market, aggregated across all pools backing it, is also the maximum amount of snxUSD that a market is able to withdraw.

Pool Configuration Module This manages a list of SCCP-configurable approved pools and a preferred pool.

Test Cases

Relevant tests will be developed during implementation.

Configurable Values (Via SCCP)

For each collateral type

  • Token (address) - An ERC-20 contract that represents the collateral.

  • Price Feed (address) - A contract which provides the current value of this asset, denominated in USD.

  • Minimum C-Ratio (uint) - The minimum ratio that the value of this collateral type must maintain in relation to the value of the debt that it backs to avoid becoming subject to liquidation.

  • Target C-Ratio (uint) - The lowest C-Ratio that the protocol allows stakers to reach voluntarily with this collateral type (by minting snxUSD, for example).

  • Disabled (bool) - Whether the protocol should accept any more collateral of this type from stakers.

  • Preferred Pool (uint) - This is the ID of a pool which the Spartan Council prefers that stakers join. This will be the default pool for stakers in the official UI.

  • Approved Pools (uint[]) - This is a list of pools’ IDs owned (or otherwise approved) by the Spartan Council and will be listed in the official UI.

  • Minimum Liquidity Ratio - This is... (See Pool Module above.)

Copyright and related rights waived via CC0.