Instant Trading Condition Checks

Instant Open

Instant Open and sendQuote Condition Checks

This section outlines the required checks necessary for executing Instant Open and sendQuote actions with SYMMIO. These checks ensure that the operations meet all necessary criteria before they are processed in order to minimize the likelihood of an order being invalid when attempting to write it to the contract.

Overview

As a solver/FE there should be several validation checks on a quote that must be passed before an Instant Open or Regular sendQuote action can be executed. These checks cover various aspects, such as user account status, market conditions, and master agreement rules.

Purpose

The condition checks are designed to:

1. Verify user and account status: Ensure that the user (Party A) is eligible to perform the requested action.

2. Validate market conditions: Confirm that the requested operation adheres to current market rules and conditions, and the order is able to be hedged.

3. Enforce platform constraints: Ensure the action complies with the Master Agreement limits, such as maximum number of open orders and solvency checks.

Key Checks and Validations

• Conditions:

• • Check Suspension(FE/Solver): Ensure that Party A is not suspended on Symmio contract. If they are, refuse the quote.

  • Check RFQ is enabled(FE): Verify whether RFQ is enabled for the requested symbol and that the symbol is not blacklisted in the solver.

  • Check the quote deadline(FE/Solver): Check if the deadline for processing the quote is sufficient.

  • Check the number of open orders(Solver): Ensure that the number of open orders for the symbol does not exceed Binance's limits. (200 quotes per symbol)

  • Check the usage cap(FE/Solver): Verify that the order would not violate your notional cap limit.

  • Check the Binance bracket condition(Solver): (this check can be ignored if it is considered in notional cap value). Check if a given quote falls within a "bracket" on Binance depending on the current position on the same symbol of Binance, determined by the current notional value of the position. Also find the maintenance margin ratio Additionally, verify that the leverage used in the quote is within the limits set by Binance for that bracket.

  • Check the counterparty health ratio(FE/Solver): Ensure that the counterparty's (partyA) health ratio is adequate to fulfill their request.

  • Check the mark price(Solver): Ensure that the difference between the mark price in the quote (given from Muon) and the actual market price is within an acceptable threshold (for MARKET orders).

  • Check the quote data(Solver): Verify that the quote data from the contract matches the expected data. Check various attributes like state, quantity, cva, party A and B maintenance margin and the requestedOpenPrice.

  • Check whether the quote was unlocked(Solver): Prevent locking of quotes that have already been unlocked by the solver.

  • Check the max funding rate of the quote(Solver): Validate that the funding rate specified in the quote matches the allowed funding rate on the solver.

  • Validate the partyB mm(Solver): Validate that the maintenance margin (MM) for Party B is within an acceptable boundary.

  • Validate the price range (FE/Solver): Validate that the requested price for the quote is within the allowable range according to Binance's rules (solver rule).

  • Validate the notional value of the quote(FE/Solver): Ensure that the notional value of the quote is within the solver defined upper and lower boundaries.

  • Check the quote locked values percentage(FE/Solver): Verify that the locked values (CVA, LF, and Party A’s MM) are within the acceptable percentage ranges for the quote.

  • Check the number of pending quotes for partyA(FE/Solver): Ensure that partyA’s pending quotes do not exceed the maximum for the Master Agreement. Include both the regular sendQuotes and instant orders.

  • Check whether Party A has a sufficient available balance(FE/Solver): Check whether Party A’s available balance will cover his order. Also in Instant Open, verify that Party A’s allocated balance covers the Symmio platform fee for the quote.

  • Check the partyA is not liquidated(FE/Solver): Check that the partyA is not liquidated or just about to face liquidation

Instant Close

Request to Close and Instant Close Condition Checks

This section outlines the required checks necessary for executing requestToClosePosition and Instant Close actions with SYMMIO. These checks are crucial for ensuring that a position can be safely and successfully closed without causing issues such as insufficient allocated balance. By implementing these checks at both the UI level and within the solver logic, scenarios where a user’s request to close a position fails can be minimized.

UI Checks and Solver Responsibilities

Before a requestToClosePosition or Instant Close, several condition checks must be conducted by both the user interface (UI) and the solvers. These should checks include:

• Solvency Verification: Ensure that the user’s allocated balance is sufficient to cover the position being closed. The UI should prevent users from initiating a close if their balance does not meet the required threshold.

• Position Count Check (This policy is valid until Symmio v0.8.4, after that parties can use settleUpnl function to tackle the issue):If a user holds more than one position in a subaccount, certain actions like setting a stop-loss should be restricted to prevent scenarios where conflicting positions might cause issues during closure.

Checking PartyA has enough Allocated Balance

This function should verify whether Party A (the user) has sufficient allocated balance to close the requested position, especially in the case of a non-profitable close.

Details:

• Profitable Close Check: First determine if the close is profitable by comparing the current market price with the price at which the position was opened.

• • For a LONG position, check if the market price is greater than or equal to the opened price.

  • For a SHORT position, check if the market price is less than or equal to the opened price.

Allocated Balance Check: If the close is not profitable, it checks if the user’s allocated balance is sufficient to cover the potential loss calculated as:

loss = abs(opened_price - approximate_close_price) * quantityToClose

Check the Quote Deadline

This check should ensure that the deadline provided in the close request is adequate to process the request on time.

Details:

• Retrieve the minimum time required for processing the request based on the symbol and order type.

• Compare the current time plus the required processing time against the provided deadline in the close request.

Check PartyA’s remaining amount

This check verifies that the remaining amount after the close request is acceptable based on predefined conditions.

Details:

Calculate the remaining quantity after the close using:

remaining_amount = filled_opened_amount - filled_closed_amount - quantityToClose

• The check should then confirm if the remaining amount is acceptable.

If the remaining amount is acceptable, the check passes.

Check the number of open orders

This check ensures that the number of open orders does not exceed the maximum limit allowed by Binance.

Details:

• First verify if the position is hedged.

• If it is hedged, it should check the number of open orders for the symbol.

Check PartyA’s solvency after the close

This check should ensure that the counterparty remains solvent after the close request is processed.

Details:

• Retrieve Party A’s account information, including their allocated balance, unrealized profit and loss (Upnl), and locked funds.

• Calculate the unlock amount based on the proportion of the position being closed.

# position.cva, position.lf and position.mm dont update during position lifetime
        unlock_amount = (
                (position.cva + position.lf)
                * close_request_struct.quantityToClose
                / position.quantity

• Compute the available balance after considering the uPnl, unlocked amount, and the locked funds.

available_balance = (
                account_info.allocated_balance
                + upnl
                + unlock_amount
                - (account_info.cva + account_info.lf)
        )

The check should then verify:

• Long Position: The function should check if the approximate close price is at or below the current market price and ensures that Party A's available balance can cover any potential loss.

• Short Position: The function should check if the approximate close price is at or above the current market price and ensures that Party A's available balance can cover any potential loss.

approximate_close_price=close_request_struct.approximate_close_price
        )
        if (
                position.position_type == PositionType.LONG
                and close_request_struct.approximate_close_price <= price
        ) or (
                position.position_type == PositionType.SHORT
                and close_request_struct.approximate_close_price >= price
        ):
            return Comparator.gte(
                Operands(available_balance, "available_balance"),
                Operands(
                    (
                            close_request_struct.quantityToClose
                            * abs(close_request_struct.approximate_close_price - price)
                    ),
                    "solvency_threshold",
                ),
            )
        return True

If the position is not profitable, the function should ensure that the available balance is greater than or equal to the expected loss, which is calculated as the difference between the close price and the market price multiplied by the quantity being closed.

Validate Close Request Data

This check should validate that the close request data matches the contract's current data.

Details:

• Retrieve the current quote data from the SYMMIO Diamond.

• Compare various attributes like quoteStatus, requestedClosePrice, and quantityToClose between the quote data and the close request data.

Check the Price Range of the Close Request

This check should ensure that the requested close price is within an acceptable range according to Binance’s trading rules.