For the complete documentation index, see llms.txt. This page is also available as Markdown.

Party Binding System

The Symmio Options Protocol's Party Binding System sets up an exclusive trading relationship between PartyA (traders) and PartyB (liquidity providers). It lets off-chain services optimize performance while on-chain settlement stays authoritative.

Binding defines a dedicated execution path for a PartyA/PartyB pair:

  • PartyA binds exclusively to one designated PartyB.

  • All of PartyA's trading intents route through the bound PartyB.

  • Off-chain infrastructure (for example, order routers) can improve execution, cut latency, and lower gas costs.

  • Final settlement happens on-chain, which keeps it transparent, auditable, and secure.

Binding states

State
Description
Available actions

Unbound

PartyA has no active binding

Bind to PartyB

Bound

PartyA is bound to a specific PartyB

Trade, activate instant mode, initiate unbinding

Unbinding

Unbinding initiated, cooldown active

Complete unbinding, cancel unbinding

Instant Mode

Enhanced trading mode with a bound PartyB

Deactivate instant mode, continue trading

Core binding operations

The binding lifecycle controls each phase of binding and unbinding explicitly, for consistency and stability.

1. Binding to PartyB

function bindToPartyB(address partyB) external

Prerequisites:

  • partyB must be active and whitelisted.

  • PartyA must not already be bound to another PartyB.

  • PartyB must have capacity to accept new bindings.

Process:

  • Validates PartyB status via partyB.isPartyB().

  • Checks that PartyA has no existing binding.

  • Establishes the PartyA to PartyB relationship in storage.

  • Emits a BindingConfirmed event.

2. Initiating unbinding

Prerequisites:

  • PartyA must currently be bound to a PartyB.

  • Instant Actions Mode must be inactive.

  • No unbinding process is already in progress.

Process:

  • Records a timestamp marking the unbinding request.

  • Begins a protocol-defined cooldown period.

  • Disables Instant Actions Mode during the cooldown.

  • Lets existing trades stay active until closed.

3. Completing unbinding

Prerequisites:

  • Unbinding must have been initiated.

  • The cooldown must have fully elapsed.

  • All trades and obligations between PartyA and PartyB must be settled.

Process:

  • Verifies the cooldown has passed.

  • Removes the binding relationship from storage.

  • Clears unbinding timestamps and related metadata.

  • Returns PartyA to the unbound state.

4. Cancelling unbinding

Use this when PartyA decides to stay bound before the cooldown expires, when market or strategic conditions change, or when operational issues with PartyB are resolved.

Process:

  • Cancels the unbinding request.

  • Resets the binding lifecycle to an active state.

Instant Actions Mode

Instant Actions Mode is a performance-optimized trading layer available only to bound PartyA accounts. It gives gas-free, low-latency execution through off-chain signatures:

  • Meta-transactions using EIP-712 signatures (gas-free for users).

  • Batched operation execution.

  • Template-based workflows that standardize trade intents.

  • Lower latency and confirmation time.

  • Built for use with the off-chain services a PartyB provides.

Activation

Prerequisites:

  • PartyA must be actively bound to a PartyB.

  • The binding must not be under unbinding cooldown.

  • Instant mode must not already be active.

Process:

  • Enables meta-transactions and instant trading features.

  • Updates the account status to reflect instant mode.

Deactivation

Deactivation is a two-step flow.

Step 1: propose deactivation

  • Begins the deactivation cooldown.

  • Prevents immediate toggling of trading modes.

  • Ensures a safe transition for in-flight operations.

Step 2: complete deactivation

  • Validates that the cooldown has completed.

  • Fully disables instant trading features.

  • Restores the account to standard trading mode.

Last updated