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

Simple Summary

\n\n

Add support for the restriction of specific synth exchanges during market closures without impacting their transfer.

\n

Abstract

\n\n

The current SystemStatus contract (introduced in SIP-44) should be amended to support a new type of suspension - synth exchanges. These must be less restrictive than the synth suspensions that currently exist and only prevent exchanging to and from the specified synth, but still allow their transfer.

\n

Motivation

\n\n

The SystemStatus contract supports the synthSuspension(bytes32) method allowing the protocolDAO to suspend a synth, thereby preventing its exchange, settlement or transfer. This has been used as a fairly blunt instrument to implement daily market closures of the equity synths sFTSE and sNIKKEI. However, given the need to support forex and commodity market closures as well over the weekend, and the fact that some of these synths, including sEUR are part of distributed pools such as the Curve sEUR pool, prohibiting transfers is too restrictive. Thus a new mechanism to merely prevent the exchange of these synths during market closures is required.

\n

Specification

\n\n

Overview

\n\n

Add a new suspension type: SynthExchange to SystemStatus, and support the suspension and resumption of these, along with the current Synth suspension, in groups, thereby reducing the number of transactions required to suspend a class of synths simulatenously (say all forex or commodity synths).

\n

Rationale

\n\n

The SystemStatus contract is where all suspension is currently managed and is already integrated with exchanging, using it to create another check is the most logical and non-intrusive spot.

\n

Technical Specification

\n\n

Add the following functions to SystemStatus:

\n
    bytes32 public constant SECTION_SYNTH_EXCHANGE = \"SynthExchange\";\n\n    function suspendSynthExchange(bytes32 currencyKey, uint256 reason) external;\n\n    function resumeSynthExchange(bytes32 currencyKey) external;\n\n    event SynthExchangeSuspended(bytes32 currencyKey, uint256 reason);\n\n    event SynthExchangeResumed(bytes32 currencyKey, uint256 reason);\n
\n

In addition, add the following helper functions to prevent the number of individual transactions required when working with a collection of synths:

\n
    function suspendSynthsExchange(bytes32[] calldata currencyKey, uint256 reason) external;\n\n    function resumeSynthsExchange(bytes32[] calldata currencyKey) external;\n\n    // helper function for existing suspendSynth() function\n    function suspendSynths(bytes32[] calldata currencyKeys, uint256 reason) external;\n\n    // helper function for existing resumeSynth() function\n    function resumeSynths(bytes32[] calldata currencyKeys) external;\n
\n

During exchanges, on top of the existing checks, if either synth is suspended for exchanging, then the exchange will revert.

\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":"4ead231a-4b66-5004-8db9-f87230d54744","frontmatter__sip":109,"__params":{"frontmatter__sip":"109"}}},"staticQueryHashes":[]}