SIP : Simple Summary Source

Author
Status
Created

Simple Summary

Allow for bypassing unnecessary fee reclamation functionality when waiting period is set to zero.

Abstract

SIP-117 will enable synth exchanging on L2. Given that frontrunning is less likely to represent a problem in Optimistic Ethereum (OΞ), there is no need for storing exchanges and settling them after a certain amount of time has elapsed. This SIP proposes to skip fee reclamation if the waiting period is 0, which can be very efficient when doing exchanges on Optimism.

Motivation

In Phase 1 of the transition to Optimistic Ethereum, basic synth functionality is going to be enabled, already proposed in SIP-117. Every time a user exchanges a synth for another, the trade is stored temporarily and can be settled after a certain waiting period (waitingPeriodSecs in SystemSettings) has elapsed, currently set to 6 minutes. For further details please check SIP-37. This procedure will not be needed on OΞ, unless proven otherwise later. Thus, if the waiting period is set to 0, then part of the overhead imposed by settlement will be skipped.

Specification

Overview

No new contracts will be developed for this SIP, only contract functionality needs to be altered slightly. If the waiting period is set to 0 when deploying an OVM instance then no rebate/reclaim has to take place. In the Exchanger contract, an extra check can be added to prevent storing exchanges and subsequently having to settle them, saving gas in this way by reducing both the computational and storing overhead.

Rationale

Due to the near-instant confirmation time of the transactions on L2, oracle front-running is no longer an big issue, thus, exchanging needs no settlement. If the waiting period parameter is set to 0 when deploying on L2, and there are extra checks in the code that bypass storing exchanging information, unnecessary computations and contract calls will be bypassed and hence gas cost will be reduced. More specifically, no exchange entries will be created via appendExchange() when the waiting period is 0. However, when a subsequent exchange takes place, the code that settles and calculates the ‘fair’ amount, namely _settleAndCalcSourceAmountRemaining(), is still being called. This is done to protect the system from the edge case where the waiting period is switched from a non-zero value to zero, and there are still exchanges in need of settlement stored in the system.

Technical Specification

Note: this is the proposed change in Exchanger.sol

 // iff the waiting period is gt 0
 if (getWaitingPeriodSecs() > 0) {
            // persist the exchange information for the dest key
            appendExchange(
                destinationAddress,
                sourceCurrencyKey,
                sourceAmount,
                destinationCurrencyKey,
                amountReceived,
                exchangeFeeRate
            );
        }

Test Cases

TBD

Configurable Values (Via SCCP)

It is worth noting that the value of the waiting period (waitingPeriodSecs in SystemSettings) determines whether fee reclamation will be skipped (waitingPeriodSecs=0) or not (waitingPeriodSecs>0).

Copyright and related rights waived via CC0.