SIP-2004: Better DelayedOrder Integration/Trading Experience
Author | |
---|---|
Status | Implemented |
Type | Governance |
Network | Optimism |
Implementor | David (@davidvuong) |
Release | TBD |
Proposal | Loading status... |
Created | 2023-02-06 |
Simple Summary
Improve integration experience for frontends and trading experience for real end users.
Abstract
We propose the following:
- New
submitClose{Offchain}DelayedOrderWithTracking
function(s) that operates similarly toclosePosition
but for delayed orders (both on and off-chain). Closing a position without needing to specify size. - Allow a non-liquidatable position to be reduced/closed iff it does not place the position into liquidation.
- Remove the commitment fee required at order submission (both on and off-chain) and disallow cancellations until after the confirmation window is over.
- Move
liquidationBufferRatio
from globally configurable (i.e. across all markets) to be market specific. - Update the price protection design from the current
priceImpactDelta
to adesiredPrice
design.
Motivation
Since the initial release of PerpsV2, we've received repeated questions and suggestions from integrators to make it easier for future integration/usage. This is one of many coming SIPs that implements said feedback, improve experience overall, and empower integrators to build the best possible UX.
In reference to the proposed changes defined above:
- It's not obvious that inverting a position size is the same as closing. Adding a
submitCloseXXX()
function simplifies and abstracts out technical details for devs to focus on frontends. - Not allowing a safe position to reduce/close without adding more margin can irritate users, making them feel trapped, overall a bad experience.
- The commitment fee was added to allow traders to cancel their order before it was executed. It's generally regarded as bad or confusing UX. Off-chain delayed orders have an expeditious execution process. Removing the ability to cancel means no longer needing an upfront commitment fee. Assuming execution keepers are operating correctly, is it rarely possible to cancel an order before the order is executed.
- As an example, forex markets should have different liquidation buffers compared to crypto as they're not as volatile. Having this global means we don't have the flexiblity to adjust for this.
- The main motivation behind the
desiredPrice
approach is to provide traders with the necessary tools to protect their trades from changes in asset prices between the time a trade is committed and is eventually executed. Although the current state of optimism doesn't incorporate public mempools, rendering it resistant to MEV attacks, this might no longer be the case in future optimism updates.
Specification
Technical Specification
The following functions will be added to Delayed{Offchain}Orders
to abstract closing of orders:
function submitCloseOffchainDelayedOrderWithTracking(
uint priceImpactDelta,
bytes32 trackingCode
) external;
function submitCloseDelayedOrderWithTracking(
uint desiredTimeDelta,
uint priceImpactDelta,
bytes32 trackingCode
) external;
A change within _updatePositionMargin
to consider whether the new order is reducing the position size. If indeed true, we avoid performing the _maxLeverage
assertion that's currently disallowing order closure without the addition of more margin.
Eliminate commitDeposit
(whether it be set to zero or removal) upon submission, then update/adjustment of subsequent downstream interactions during execution and cancellation operations (if the order becomes stale) to no longer consider commitDeposit
. Note that this also makes the overrideCommitFee
redundant.
Test Cases
Relevant tests will be developed during implementation.
Configurable Values (Via SCCP)
N/A
Copyright
Copyright and related rights waived via CC0.