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
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) externalPrerequisites:
partyBmust 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
BindingConfirmedevent.
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

