Position Lifecycle

How positions are opened, monitored, hedged, and settled.

This section describes how a leveraged prediction market position moves from creation to settlement. All user actions occur through the originating front-end. Dimes executes and maintains the underlying hedge through Multiply.

1

Opening a Position

The user selects:

• a supported prediction market

• a direction (YES or NO)

• a leverage level

2

The terminal requests a quote from Multiply, passing information such as:

• market and trader

• direction

• requested leverage

• notional demand and collateral value

3

Multiply evaluates:

• current venue price and market microstructure

• hedgeability of requested size within slippage bounds

• required collateral and margin

• per-market, per-side, and per-user cap headroom

4

Multiply returns a firm executable quote that includes:

• entry price and execution cost

• required collateral

• maximum allowed size (if clipped by caps or depth)

• implied liquidation price

• an expiry timestamp — the offer is only valid for a limited window. The expires_at field in the API response indicates the deadline. If the user does not execute before this time, the offer becomes invalid and a new quote must be requested.

5

Hedge-first execution

If the user accepts, the front-end submits an execute call. Multiply executes the hedge on the external venue first.

• Only if the hedge fills within slippage bounds is the position created, user collateral is locked, and the leveraged exposure is established.

• If the hedge fails or slippage exceeds bounds, the order is rejected and no position is created.

After the hedge fills, the position payload exposes both the indicative entry price quoted on the offer (entry.price_*) and the actual fill price reported by the venue ( entry.effective_entry_price_*). The difference is reported as entry.effective_slippage_bps — signed basis points, positive when the fill came in worse than the quote and negative when better. These three fields are null until the onchain fill is recorded.

6

Active monitoring

The position becomes active and appears in the front-end's portfolio view. Once active:

• Multiply monitors margin, venue health, and eligibility continuously

• Limits and maximum leverage evolve dynamically based on market conditions

• The market may enter close-only if any eligibility threshold is breached

7

Leverage decay (J-factor)

• J-factor is Multiply's dynamic risk engine. It continuously monitors depth profile, odds dynamics, open interest microstructure, and resolution conditions, defining when leverage should be reduced.

• Leverage reduction is triggered only when microstructure conditions warrant it. On the winning side, this means leverage often remains intact through resolution. On the losing side, deteriorating microstructure typically triggers deleverage earlier, protecting both the user and the facility.

8

Liquidation (if triggered)

• Multiply is designed to keep your position alive. The J-factor risk engine works continuously to ease your leverage down as a position deteriorates, giving your collateral room to recover before hard limits are reached. As such, forced liquidations are rare. But the system can't guard against every market move. If your remaining collateral falls to maintenance margin at any point during the position lifecycle, Multiply liquidates to protect what's left: the hedge is unwound on the originating venue and all execution costs are deducted from your collateral.

9

Voided markets

• Occasionally a market is voided — cancelled, forfeited, or closed with no winner (e.g. rescheduled sporting events). When this happens, both YES and NO tokens pay out at $0.50 each via the Conditional Token Framework. The position's mark price updates to $0.50 immediately. The timing.is_voided field on the position becomes true, and timing.is_settlement_pending indicates that settlement is incoming. PnL is calculated against the trading venue refund.

On-chain transaction visibility

Every on-chain step above — opening, finalizing, closing, liquidating, settling, force-unwinding, and redeeming — is recorded as a transaction the position owner can inspect. The position transactions endpoint returns these transactions grouped by operation type, including the on-chain hashes of the nested exchange (CLOB/DEX) fills that hedge the position. Only transactions that landed and finalized on-chain are returned — pending, failed, and reverted attempts are excluded — so the result reflects the transfers that actually moved funds.

Reverted opens

If an open fails after the on-chain position is created — most often because the hedging exchange order could not be filled — the protocol reverts the open and returns the collateral and origination fee in full. No position is held. The closed-position response carries close_reason: "reverted" and a revert_reason enum explaining why:

• exchange_unavailable — the prediction-market venue was temporarily unavailable (e.g. its matching engine was restarting). This is transient; submitting the same offer again shortly after will usually succeed.

• slippage_exceeded — the price moved beyond the offer's slippage tolerance before the order could fill. Re-quote and retry.

• unknown — the revert could not be attributed to a specific cause.

revert_reason is null for any non-reverted close.