SIP-165: Debt Pool Synthesis

Simple Summary

This SIP seeks to merge the debt pools across all chains on which Synthetix is deployed, tracking the total synth debt with a common oracle.

Abstract

Currently, each chain that Synthetix is deployed on has its own isolated debt pool. In order to seamlessly provide liquidity across chains and allow synths to be transferred between them, we must ensure that debt is tracked properly cross-chain.

We are able to do this by relying on an oracle which reports the value of the total debt (i.e. the value of the total issued synths) and the total amount of debt shares issued across all chains.

Motivation

Merging the debt pools is necessary to provide maximum liquidity across the protocol and allow synths to be transferred between multiple chains efficiently via cross-chain messaging, rather than relying on automated market makers (which are limited by the depth of their liquidity pools and subject to slippage).

Specification

Overview

The Chainlink oracle must monitor the debt composition across all chains, and simultaneously push updates for the aggregated amount of debt and total debt shares to all of those chains.

The issuer should rely on the global values provided by this oracle—rather than chain-specific values—for the total debt shares (which is replacing the debt ledger system) and the debt pool oracles (which is replacing the debt caching system).

Rationale

Although it would be possible to transmit debt updates between chains directly, relying on an oracle allows for a substantially more elegant implementation. Further, with debt shares, it is straightforward to track debt responsibility across an arbitrary number of chains.

Technical Specification

Implementation of this SIP involves a new Chainlink oracle and assorted updates to the protocol.

Debt Synthesis Oracle

This SIP relies on a single oracle that tracks the total issued synths and the total debt shares across all chains and then updates these values across all chains. It is important that the oracle reports these values together to minimize front-running opportunities. Review the Test Cases for more considerations regarding front-running.

This JavaScript code demonstrates the value that the oracle should update on each chain every block:

const { BigNumber } = require("ethers");
const { synthetix } = require('@synthetixio/contracts-interface');

async function debtSynthesisOracle() {
    const NETWORK_IDS = [1, 10]

    let totalIssuedSynths = BigNumber.from(0)
    let totalDebtShares = BigNumber.from(0)

    for (networkId of NETWORK_IDS) {
        const snxjs = synthetix({ networkId });

        totalIssuedSynths = totalIssuedSynths.add(await snxjs.contracts.Synthetix.totalIssuedSynthsExcludeOtherCollateral(snxjs.toBytes32('sUSD')))
        totalDebtShares = totalDebtShares.add(await snxjs.contracts.Synthetix.totalDebtShares());
    }

    const totalIssuedSynthsPart = totalIssuedSynths.toHexString().slice(2).padStart(32, '0');
    const totalDebtSharesPart = totalDebtShares.toHexString().slice(2).padStart(32, '0');
    return "0x" + totalIssuedSynthsPart + totalDebtSharesPart
}

Note that SIP-156 is not a dependency for this SIP. Once the debt pool oracle is deployed, it will provide the value of totalIssuedSynths rather than the debt cache. This is inconsequential to the implementation of this oracle.

Protocol Updates

• Synth Issuance: The issuer will now rely on the totalIssuedSynths and totalDebtShares reported from the oracle rather than the existing values on chain.

• Staking Rewards: Similarly, all rewards can be provided proportionally to the chains on which a user is staking by calculating their rewards based on the total amount of debt shares across all chains, as communicated by the oracle.

• Fee Pool Closure: The fee pool will need to be updated via cross-chain communication. Initially, L1 can use the Optimism Messenger to trigger the closure of the fee period on L2. Ultimately, this can use a cross-chain broadcaster to support additional chains.

• Loans: The interest rates charged on loans are determined by examining an aggregate skew in the system. This may be difficult to compute accurately across two chains. It should be verified that the behavior of the loans contracts only examine the skew on their own chain, not involving the full cross-chain debt, if it isn’t feasible to properly account for it.

Also note that is possible for the totalIssuedSynths (technically totalIssuedSynthsExcludeOtherCollateral in this case) to become negative if the value of synths backed by SNX tokens is less than the amount backed by wrappers and shorts. This risk already exists and is mitigated by the growth of incentives for individual SNX stakers as the debt pool becomes smaller.

Test Cases

Review two test cases here pertaining to oracle latency.

Configurable Values (Via SCCP)

N/A

Copyright