---
sip: 174
network: Ethereum
title: Redeem Deprecated Synths
status: Implemented
author: Justin J Moses (@justinjmoses)
created: 2021-08-18T00:00:00.000Z
type: Governance
---

<!--You can leave these HTML comments in your merged SIP and delete the visible duplicate text guides, they will not appear and may be helpful to refer to if you edit it again. This is the suggested template for new SIPs. Note that an SIP number will be assigned by an editor. When opening a pull request to submit your SIP, please use an abbreviated title in the filename, `sip-draft_title_abbrev.md`. The title should be 44 characters or less.-->

## Simple Summary

<!--"If you can't explain it simply, you don't understand it well enough." Simply describe the outcome the proposed changes intends to achieve. This should be non-technical and accessible to a casual community member.-->

Allow synths to be removed from the protocol without the need to purge holders back to `sUSD`.

## Abstract

<!--A short (~200 word) description of the proposed change, the abstract should clearly describe the proposed change. This is what *will* be done if the SIP is implemented, not *why* it should be done or *how* it will be done. If the SIP proposes deploying a new contract, write, "we propose to deploy a new contract that will do x".-->

In order to easily remove synths from the protocol, a contract will be created that will allow holders of a synth that is deprecated to redeem them at a fixed price for `sUSD`.

## Motivation

<!--This is the problem statement. This is the *why* of the SIP. It should clearly explain *why* the current state of the protocol is inadequate.  It is critical that you explain *why* the change is needed, if the SIP proposes changing how something is calculated, you must address *why* the current calculation is inaccurate or wrong. This is not the place to describe how the SIP will address the issue!-->

To remove a synth from the protocol, its `totalSupply` must be `0`, to account for the debt pool. To achieve this in the past the protocolDAO has manually purged holders back to `sUSD`. On top of the obvious overhead this causes, there is the greater concern that the purged holders may be contracts - such as AMM pools like Balancer, Curve, et al - and purging their synths to `sUSD` would cause them to potentially fail.

## Specification

<!--The specification should describe the syntax and semantics of any new feature, there are five sections
1. Overview
2. Rationale
3. Technical Specification
4. Test Cases
5. Configurable Values
-->

### Overview

<!--This is a high level overview of *how* the SIP will solve the problem. The overview should clearly describe how the new feature will be implemented.-->

Allow the owner of the protocol to remove a synth with existing supply by issuing the equivalent amount of sUSD of the synth's open interest at the current exchange rate to a new contract `SynthRedeemer` and allowing holders to redeem back to sUSD at any time in the future their deprecated synths using the redeem rate.

When a user later invokes `SynthRedeemer.redeem(IERC20)` then contract will burn the synth tokens and send the user the equivalent amount of `sUSD`.

### Rationale

<!--This is where you explain the reasoning behind how you propose to solve the problem. Why did you propose to implement the change in this way, what were the considerations and trade-offs. The rationale fleshes out what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.-->

By connecting the `SynthRedeemer` contract to `Issuer.removeSynth()`, we can atomically ensure the debt pool is balanced by issuing the equivalent amount of sUSD to account for the debt removed from the system by the synth's supply. Moreover, when the redeemer attempts to burn, it can instruct the synth to burn via the `Issuer` which has the privileges to do so.

### Technical Specification

<!--The technical specification should outline the public API of the changes proposed. That is, changes to any of the interfaces Synthetix currently exposes or the creations of new ones.-->

```solidity
interface ISynthRedeemer {
    // Rate of redemption - 0 for none
    function redemptions(address token) external view returns (uint redeemRate);

    // sUSD balance of deprecated token holder
    function balanceOf(IERC20 token, address account) external view returns (uint balanceOfInsUSD);

    // Full sUSD supply of token
    function totalSupply(IERC20 tokens) external view returns (uint totalSupplyInsUSD);

    function redeem(IERC20 token) external;

    function redeemAll(IERC20[] calldata tokens) external;

    function redeemPartial(IERC20 token, uint amountOfSynth) external;

    // Restricted to Issuer
    function deprecate(IERC20 token, uint rateToRedeem) external;

    // Events
    event SynthRedeemed(address synth, address account, uint amountOfSynth, uint amountInsUSD);

    event SynthDeprecated(address synth, uint rateToRedeem, uint totalSynthSupply, uint supplyInsUSD);
}
```

### Test Cases

<!--Test cases for an implementation are mandatory for SIPs but can be included with the implementation..-->

- _When_ non-owner calls `Issuer.removeSynth(*)` it reverts (same as the current system)
- _When_ owner calls `Issuer.removeSynth(sUSD)` it reverts (same as the current system)
- _Given_ the rate of `sAAVE` is `500` and the totalSupply is `10`
  - _When_ owner calls `Issuer.removeSynth(sAAVE)`, _Then_ `5000` sUSD is issued to the `SynthRedeemer` contract, `SynthRedeemer.deprecate(ProxysAAVE)` is invoked setting the `redemptions` rate to `500` and `sAAVE` is removed from synthetix.
    - _Given_ Alice holds `4` units of `sAAVE`, _When_ Alice calls `SynthRedeemer.redeem(sAAVE)`, then she receives `2000` sUSD from the SynthRedeemer contract, and all of her `sAAVE` is burned.

### Configurable Values (Via SCCP)

<!--Please list all values configurable via SCCP under this implementation.-->

N/A

## Copyright

Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).