{"componentChunkName":"component---src-pages-sips-sip-markdown-remark-frontmatter-sip-tsx","path":"/sips/sip-173/","result":{"data":{"markdownRemark":{"fileAbsolutePath":"/vercel/path0/content/sips/sip-173.md","frontmatter":{"sip":173,"sccp":null,"title":"Synth Upgrader Contract","network":"Ethereum","author":"Justin J Moses (@justinjmoses)","type":"Governance","proposal":null,"implementor":null,"release":null,"created":"2021-08-03T00:00:00.000Z","updated":null,"status":"Rejected"},"html":"\n

Simple Summary

\n\n

Create and deploy a SynthUpgrader contract allowing the protocolDAO to easily upgrade the underlying Synth.sol logic contract in a single atomic transaction.

\n

Abstract

\n\n

Following the success of contract-based migrations in SIP-151, this SIP proposes a SynthUpgrader migration contract to more easily handle the various aspects of a synth's logic upgrade and to avoid system downtime. This includes removing the old synth, adding the new one, updating its token state and proxy, along with the address resolver. This SIP also proposes supporting migration in batches, rather than a single synth at a time, to more easily complete the process.

\n

Motivation

\n\n

There are a number of reasons to replace a synth's logic contract outside of a regular deploy. The most common is when a synth is marked for delisting and requires purging, but the synth is not purgeable. This is relevant in the case of both SIP-166 and SIP-169 as the long synths mentioned in both SIPs are not marked as purgeable. Currently there exists a command to do this in the synthetix repo - requiring at least 6 protocolDAO transactions per synth. Moreover, because the transactions are not atomic[1], the system currently needs suspension to perform the replacements, which cause disruption to regular users and exchanges.

\n

This SIP proposes leveraging the work begun with migration contracts in SIP-151 by creating a reusable and permissioned SynthUpgrader contract.

\n
\n
    \n
  1. To replace a synth, the totalSupply needs to be set to 0 in order for it to be removed from the sytem however the new synth needs to track the same totalSupply. If we don't upgrade synths atomically, any issuing or burning of a synth's supply (via an exchange) that happens in between fetching and persisting the totalySupply can lead to data corruption - hence why in the past we've opted to suspend the system.
    2. \n
\n
\n

Specification

\n\n

Overview

\n\n

The creation of a custom and reusable SynthUpgrader contract that allows the batch upgrades of synths.

\n

Rationale

\n\n

Unlike SIP-151, the logic of upgrading a synth is consistent and fairly intricate (requiring custom code and predicates that the generate-solidity command isn't able to reproduce). Thus, it makes sense to deploy a reusable SynthUpgrader contract which requires the new Synth contract be predeployed and only allow execution from the protocolDAO.

\n

Technical Specification

\n\n
interface ISynthUpgrader {\n    // Restricted to owner\n    function upgrade(bytes32[] calldata synthContractLabels, address[] calldata newSynths) external;\n}\n
\n

Test Cases

\n\n\n

Configurable Values (Via SCCP)

\n\n

N/A

\n

Copyright

\n

Copyright and related rights waived via CC0.

"}},"pageContext":{"id":"667c77b6-c93e-5387-a2ee-144fd55f5f96","frontmatter__sip":173,"__params":{"frontmatter__sip":"173"}}},"staticQueryHashes":[]}