SIP-395: P2P Settlement Strategy

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:

• Extremely low-cost instant execution, with most of the transaction cost being L2 computation, which is relatively inexpensive. Matched trades can be relayed as soon as they are matched, bypassing asynchronous on-chain settlement through Synthetix contracts.
• Improved trust assumptions compared to similar systems, as operating a relayer can be a permissionless process with Synthetix’s role as a shared derivative settlement layer. This contrasts with existing systems where a single entity runs the only relayer.
• The order book/ambient liquidity hybrid model offers beneficial properties for users, combining CEX-grade order book performance with the reliability of on-chain ambient liquidity through Synthetix. This ensures prompt processing of liquidations with guaranteed liquidity.

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

Final technical details TBD once implementation has been assigned pending Spartan Council approval, but high level technical flow will follow industry standard matching practices:

• A maker creates an order, including market ID, amount, maker address, relayer address, expiry, and nonce.
• The order is hashed, signed, and sent to the Relayer off-chain.
• A taker retrieves the maker’s order exposed via the Relayer and includes appends a taker address.
• The order is signed and sent to the relayer.
• The Relayer publishes matched orders with Synthetix smart contracts, which verify the correctness of the order message payload on-chain and creates/modifies positions for both users within Synthetix (see figure below).

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

Copyright and related rights waived via CC0.