SIP-1: Block Trade

Summary

Block Trade is a cross-chain order execution mechanism that connects source chains (e.g., BSC, Solana) with the StandX settlement engine. Orders are published and matched on the blockchain, while settlement is performed by StandX — every step of the trade lifecycle is open, transparent, and traceable on-chain. Users can broadcast trading intent from any supported chain and, in a single transaction, bridge on-chain activity with perpetual contract execution on StandX. It offers two match policies — incremental matching as counterparties arrive (Flexible), and an all-or-nothing mode (FullMatch) where the block must be fully matched before settlement begins — accommodating different levels of execution certainty.

The name “Block Trade” comes from Blockchain — trades built on the chain — while also echoing the traditional finance term for large negotiated transactions. A fitting double meaning.

Motivation

Institutional participants with large order requirements often seek negotiated, multi-party trades to reduce market impact. Existing solutions typically sacrifice either transparency or execution quality. StandX Block Trade addresses this by providing:

• Transparent on-chain order discovery
• StandX-side risk validation and settlement
• Execution styles not easily expressed on the central limit order book
• Block Trade execution fully isolated from price discovery
• Minimum taker quantity enforcement for predictable block completion

Specification

Roles

Maker — The party that publishes a Block Trade order. A Maker Fee is charged upon successful settlement.

Taker — The party that matches against an existing Block Trade order (i.e., the counterparty). A Taker Fee is charged upon successful settlement.

Order Parameters

When creating or participating in a Block Trade, the following parameters are specified:

Fill Price

Because latency exists between the source chain and the StandX execution layer, Fill Price determines how the settlement price is resolved:

• Mark Price — Settlement uses the Mark Price observed by the StandX settlement engine at settlement time. Execution timing is determined by the engine and cannot be controlled by users.
• Limit Price — Settlement uses a fixed price specified by the Maker. The price must still pass risk validation (see Risk Validation below).

Future versions may enable BBO (Best Bid / Best Ask) strategies.

Price Isolation

Block Trade executions are independent of the CLOB (central limit order book). Block Trade prices DO NOT affect:

• Mark Price
• Last Trade Price
• Public Trade Prints / Recent Trades
• Candlestick / K-line construction
• CLOB price discovery
• Funding rate calculations
• Liquidation triggers

This isolation ensures that Block Trade prices cannot influence the broader platform pricing infrastructure.

Match Policy

Match Policy governs how the on-chain matching engine processes counterparty participation. Matching occurs on the source chain; StandX settles matched trades as best effort — a successful on-chain match does not guarantee settlement.

A single Block Trade supports a maximum of 25 counterparties. A Block Trade concludes when either condition is met:

1. The total quantity is 100% matched.
2. The current time exceeds the configured Expiration Time.

Matches are processed on a first-come, first-served basis.

On-chain match finality: Once a match is recorded on the source chain, the matched quantity is permanently consumed from the block’s remaining capacity — regardless of whether StandX settlement results in Filled or Failed. The on-chain match is irreversible, and the consumed quantity is never returned to the block. However, if a Taker closes their order before on-chain matching occurs (i.e., while the order is still in Open status), their reserved quantity is returned to the block’s available capacity.

Taker Match Quantity Validation

Every Taker match must satisfy one of the following conditions to ensure the block remains completable for subsequent Takers:

1. Exact remainder: remaining_qty - match_qty = 0 — the Taker matches the entire remaining block.
2. Sufficient remainder: remaining_qty - match_qty ≥ taker_min_qty — the remaining quantity after the match is still large enough for another Taker to participate.

Any match that would leave a remainder between 0 (exclusive) and taker_min_qty (exclusive) is rejected by the on-chain matching engine.

Flexible

• For Maker: Upon each successful Taker match, StandX immediately attempts settlement. If settlement succeeds, positions open and are final — regardless of whether the remaining block size is filled before expiration. If settlement fails, that matched portion becomes Failed — the on-chain matched quantity is not returned to the block; other portions continue independently.
• For Taker: The Taker is willing to accept a partial fill. If the remaining block size is less than the Taker’s requested amount, the Taker is matched for whatever quantity remains (subject to Taker Min Qty).

FullMatch

• For Maker: Takers join until the total size is fully matched on-chain. No settlement occurs until matching is complete. Once fully matched, StandX attempts settlement for each participant individually. If a participant’s settlement fails, that participant is marked Failed and skipped — their allocated portion is not returned to the block. Other participants’ settlements are unaffected. If the Block Size is not 100% matched by the Expiration Time, the entire block is closed.
• For Taker: The Taker’s match must be executed in full. If the remaining block size cannot satisfy the Taker’s requested amount, the match is rejected.

Expiration Time

Every Block Trade carries an expiration time. Once expired, the Block Trade is automatically closed and no further matches are accepted.

Execution and Settlement

Settlement Semantics

An on-chain match event does not constitute StandX execution. The match event (e.g., BlockMatched on BSC) represents a successful match on the source chain; StandX then settles the matched trade as best effort. StandX is the authoritative source of settlement truth.

Block Trade uses two separate status models: one for the block itself, and one for each participant’s order.

Block Status:

Order Status:

Only the Filled status results in positions being opened.

Settlement Flow

When a Taker submits a transaction to match a Maker’s Block Trade, the source chain emits a match event in its native format.

The StandX settlement engine monitors these events and, for each valid match:

1. Validates the match event (chain finality, contract allowlist, deduplication).
2. Performs risk validation for both Maker and Taker (see below).
3. If validation passes, settles the trade — opens positions and deducts fees atomically.
4. If validation fails, marks the match as Failed. The failed portion is not returned to the block.

Risk Validation

Before settlement, StandX checks post-trade account health for both Maker and Taker.

When the Block Trade fill price deviates from the Mark Price, the position may carry an immediate unrealized loss at the moment of opening (Opening Loss). To protect users and maintain platform stability, StandX incorporates this Opening Loss into the margin requirement — similar to how traditional exchanges account for order potential loss.

Opening Loss Cap: The Opening Loss must not exceed 25% of the initial margin for that position:

Opening Loss ≤ 0.25 × Initial Margin

The user’s account must have sufficient available funds to cover both the initial margin and the Opening Loss. If the account cannot satisfy this requirement, the settlement is rejected.

This rule applies to both Maker and Taker, and ensures no party enters a position that is immediately close to liquidation. Specific calculation methods and parameters may be adjusted based on platform risk policies.

Inherited Risk Controls

Block Trade must inherit all existing risk controls from the standard trading path, including but not limited to:

• Maximum leverage per tier
• Margin mode constraints (cross / isolated)
• Reduce-only restrictions at critical leverage thresholds
• Position size limits per tier

A trade that would be rejected on the standard CLOB path due to risk controls must also be rejected via Block Trade.

Settlement Failure

Because Block Trade involves cross-chain coordination, latency between the source chain match event and StandX settlement is expected. During this interval, a user’s available margin may change — for example, if funds are allocated to other positions.

If either party’s margin is insufficient or risk validation fails at the time of settlement:

• Flexible: The matched portion becomes Failed. The on-chain match is irreversible — the consumed quantity is not returned to the block, and no position is opened for that match. Other matches in the same block are unaffected.
• FullMatch: The failed participant is marked Failed and skipped — their allocated portion is not returned to the block. Other participants’ settlements are unaffected.

To maintain platform integrity, repeated settlement failures attributed to a user may result in restrictions on their Block Trade participation. Specific enforcement policies may be adjusted over time based on observed usage patterns.

Event Processing Safeguards

Given the cross-chain architecture, the StandX settlement engine enforces:

• Finality: Match events are only processed after the source chain transaction has reached sufficient finality.
• Deduplication: Each match event is identified by a unique key (chain, contract/program address, transaction hash, log/instruction index) and processed exactly once.
• Contract allowlist: Only events from verified Block Trade contracts/programs are accepted.
• Atomic settlement: For each fill, the position opening, fee deduction, and margin update for both parties are committed as a single atomic operation. A partial write (e.g., one side booked without the other) must not occur.

Extensibility

Future versions of Block Trade may introduce:

• Block Fee — An optional fee between Maker and Taker, paid by one party to the other, to facilitate more flexible negotiation.
• Block Margin — Additional margin pledged by either party to strengthen settlement certainty.
• BBO Strategies — Fill Price options based on Best Bid / Best Ask at settlement time.

These settings will be introduced progressively based on platform conditions and security validation.

Scenarios (User Story)

Context: BTC Mark Price is 100,000 USDT.

Scenario 1: Basic Flexible Match

Jack wants to go long 20 BTC at a fixed price of 98,000 USDT. He creates a Block Trade on StandX with the following parameters:

• Trading Pair: BTC-USD
• Size: 20 BTC
• Direction: Long
• Fill Price: Limit Price (98,000 USDT/BTC)
• Match Policy: Flexible
• Taker Min Qty: 0.8 BTC (= max(20/25, platform minimum))
• Expiration Time: 1 day

StandX verifies that Jack’s margin is sufficient and that the Limit Price passes risk validation (Opening Loss for the Long side at 98,000 vs. Mark 100,000 is 0%, since the price is favorable). After verification, Jack signs the transaction with his wallet and the order is published to the source chain.

Alice browses the StandX Block Trade page and sees Jack’s order. She is willing to short BTC at 98,000 USDT and decides to participate as a counterparty. Alice chooses to match 8 BTC (≥ taker_min_qty of 0.8 BTC; remaining 12 BTC ≥ 0.8 BTC ✓), signs the transaction, and submits it to the source chain. The match event is emitted on-chain.

StandX detects the match event, validates risk for both parties (Alice’s Opening Loss as Short at 98,000 vs. Mark 100,000 is 2%, which must be within the Opening Loss Cap), and if validation passes, settles the trade:

• Jack (Maker) opens Long 8 BTC at 98,000 USDT/BTC
• Alice (Taker) opens Short 8 BTC at 98,000 USDT/BTC

Bob later sees that 12 BTC of Jack’s order remains unmatched. He decides to match the remaining 12 BTC (remaining = 0 ✓), signs and submits his transaction. Another match event is emitted on-chain. StandX settles:

• Jack (Maker) opens Long 12 BTC at 98,000 USDT/BTC
• Bob (Taker) opens Short 12 BTC at 98,000 USDT/BTC

Jack’s 20 BTC Block Trade is now 100% matched and settled. Maker Fee is deducted from Jack’s account; Taker Fees are deducted from Alice’s and Bob’s accounts respectively.

Scenario 2: Taker Min Qty Enforcement

Jack creates a 20 BTC Block Trade (Flexible, taker_min_qty = 0.8 BTC).

Alice wants to match 19.5 BTC. After her match, only 0.5 BTC would remain — but 0.5 < 0.8 (taker_min_qty) and 0.5 ≠ 0. The on-chain matching engine rejects Alice’s match.

Alice has two valid options:

1. Match 19.2 BTC — leaving 0.8 BTC remaining (= taker_min_qty ✓). Bob can later match the final 0.8 BTC.
2. Match 20 BTC — taking the entire block (remaining = 0 ✓).

Scenario 3: Concurrent Taker Submissions

Jack creates a 20 BTC Block Trade (Flexible, taker_min_qty = 0.8 BTC). Two Takers — Alice and Bob — both submit matches for 11 BTC at roughly the same time.

Matches are processed first-come, first-served:

1. Alice’s transaction arrives first and is matched for 11 BTC (remaining 9 BTC ≥ 0.8 ✓). Match event is emitted on-chain. StandX settles if risk validation passes.
2. Bob’s transaction arrives second. Only 9 BTC remains, so Bob is matched for 9 BTC (remaining = 0 ✓). Match event is emitted on-chain.
3. The block is now 100% matched. Any subsequent Taker submissions are rejected.

Scenario 4: FullMatch Mode — Settlement Failure

Jack creates a 20 BTC Block Trade (FullMatch, Limit Price 98,000). Alice matches 12 BTC and Bob matches 8 BTC. The block is now fully matched on-chain.

StandX attempts settlement for each participant individually. Jack vs Alice (12 BTC) settles successfully — positions are opened. Jack vs Bob (8 BTC) fails because Bob’s margin is insufficient; Bob’s match is marked Failed. Bob’s allocated 8 BTC is not returned to the block. Final result: Jack and Alice each hold 12 BTC positions; Bob has no position.

Scenario 5: Risk Validation Rejection

BTC Mark Price is 100,000. Jack wants to create a Block Trade: Long 10 BTC at Limit Price 110,000, using 20x leverage.

Jack’s initial margin at 20x = 5% of notional. His Opening Loss buying at 110,000 vs. Mark 100,000 = 10% of notional. The Opening Loss Cap is 25% × 5% = 1.25% of notional. Since 10% far exceeds 1.25%, Jack’s Block Trade creation is rejected by risk validation.

To pass, Jack would need to either use lower leverage (e.g., 2x, where initial margin = 50% and cap = 12.5%) or set a Limit Price closer to Mark Price.

Scenario 6: FullMatch — Taker Cancellation Before Full Match

Jack creates a 10 BTC Block Trade (FullMatch, Long).

1. Alice takes 4 BTC — block remaining quantity drops to 6 BTC. Since the block is FullMatch, no on-chain matching occurs yet. Alice’s order is in Open status; she can still cancel.
2. Bob takes 2 BTC — remaining drops to 4 BTC. Bob’s order is also Open and cancellable.
3. Alice cancels her order. Her 4 BTC is returned to the block — remaining quantity goes back to 8 BTC.
4. Jimmy takes 8 BTC — the block is now fully matched. Block status transitions to OnchainMatched. All Taker orders (Bob and Jimmy) enter Matching status; cancellation is no longer possible.
5. StandX proceeds with settlement for each participant.

Scenario 7: Flexible — Immediate Matching, No Cancellation Window

Jack creates a 10 BTC Block Trade (Flexible, Long).

1. Alice takes 4 BTC. Since the block is Flexible, on-chain matching occurs immediately — Alice’s order enters Matching status and cannot be cancelled. Block remaining quantity is 6 BTC.
2. Bob takes 6 BTC. On-chain matching occurs immediately — Bob’s order enters Matching status. The block is now fully matched.
3. StandX settles each match independently as they arrive.