SIP-395: P2P Settlement Strategy

Author
fif, mr.mat
StatusDraft
TypeGovernance
NetworkOptimism & Base
ImplementorTBD
ReleaseTBD
Created2024-06-20

Simple Summary

This SIP proposes the implementation of a P2P order settlement strategy for Synthetix perps markets which parse signed maker/taker messages pushed onchain by user-designated relayers.

Motivation

Currently users can execute peer-to-pool trades priced via pull oracle, but this has some notable drawbacks including asynchronicity, limited flexibility, and gas intensiveness. Addition of a peer-to-peer matched order settlement strategy can significantly enhance the flexibility and extensibility of Synthetix market infrastructure for users and integrators.

Rationale

The design layed out here follows common order matching conventions that enables creation of positions that will exist alongside and be fungible with position management via existing asynchronous order settlement strategies. Most notably, this settlement strategy will enable integrators of Synthetix perps to offer a more familiar trading experience to users by acting as relayers.

Technical Specification

Orders will be represented as signed messages following the EIP-712 standard. This ensures that the orders are secure, tamper-proof, and easily verifiable on-chain.

EIP-712 Order Structure:

struct Order {
    address maker;
    address taker;
    address relayer;
    address market;
    uint256 amount;
    uint256 price;
    uint256 expiration;
    uint256 nonce;
}

EIP-712 Domain Separator: EIP712 defines a domain separator which is a struct that uniquely identifies the message to be signed. This is because messages that have the same data type across two different applications, although may look the same, may not be compatible.

bytes32 constant DOMAIN_SEPARATOR = keccak256(
    abi.encode(
        keccak256("EIP712Domain(string name,string version,uint256 chainId,address verifyingContract)"),
        keccak256(bytes("SyntheticPerpetualFutures")),
        keccak256(bytes("1")),
        chainId,
        address(this)
    )
);

For simplicity and progressive rollout, an initial implementation should begin with fill-or-kill order types which only specify an amount and expiration without possibility for partial fills. In the future, this implementation can be adapted to stateful limit orders which can be partially filled with updated amounts.

Configurable Values (Via SCCP)

TBD

Copyright and related rights waived via CC0.