# Position Lifecycle

<mark style="color:$info;">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.</mark>

{% stepper %}
{% step %}
**Opening a Position**

<mark style="color:$info;">The user selects:</mark>

* <mark style="color:$info;">a supported prediction market</mark>
* <mark style="color:$info;">a direction (YES or NO)</mark>
* <mark style="color:$info;">a leverage level</mark>
  {% endstep %}

{% step %}
**The terminal requests a quote from Multiply, passing information such as:**

* <mark style="color:$info;">market and trader</mark>
* <mark style="color:$info;">direction</mark>
* <mark style="color:$info;">requested leverage</mark>
* <mark style="color:$info;">notional demand and collateral value</mark>
  {% endstep %}

{% step %}
**Multiply evaluates:**

* <mark style="color:$info;">current venue price and market microstructure</mark>
* <mark style="color:$info;">hedgeability of requested size within slippage bounds</mark>
* <mark style="color:$info;">required collateral and margin</mark>
* <mark style="color:$info;">per-market, per-side, and per-user cap headroom</mark>
  {% endstep %}

{% step %}
**Multiply returns a firm executable quote that includes:**

* <mark style="color:$info;">entry price and execution cost</mark>
* <mark style="color:$info;">required collateral</mark>
* <mark style="color:$info;">maximum allowed size (if clipped by caps or depth)</mark>
* <mark style="color:$info;">implied liquidation price</mark>
* <mark style="color:$info;">an expiry timestamp — the offer is only valid for a limited window. The</mark> <mark style="color:$info;">`expires_at`</mark> <mark style="color:$info;">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.</mark>
  {% endstep %}

{% step %}
**Hedge-first execution**

<mark style="color:$info;">If the user accepts, the front-end submits an execute call. Multiply executes the hedge on the external venue first.</mark>

* <mark style="color:$info;">Only if the hedge fills within slippage bounds is the position created, user collateral is locked, and the leveraged exposure is established.</mark>
* <mark style="color:$info;">If the hedge fails or slippage exceeds bounds, the order is rejected and no position is created.</mark>

<mark style="color:$info;">After the hedge fills, the position payload exposes both the indicative entry price quoted on the offer (</mark>`entry.price_*`<mark style="color:$info;">) and the actual fill price reported by the venue (</mark> `entry.effective_entry_price_*`<mark style="color:$info;">). The difference is reported as</mark> `entry.effective_slippage_bps` <mark style="color:$info;">— signed basis points, positive when the fill came in worse than the quote and negative when better. These three fields are</mark> `null` <mark style="color:$info;">until the onchain fill is recorded.</mark>
{% endstep %}

{% step %}
**Active monitoring**

<mark style="color:$info;">The position becomes active and appears in the front-end's portfolio view. Once active:</mark>

* <mark style="color:$info;">Multiply monitors margin, venue health, and eligibility continuously</mark>
* <mark style="color:$info;">Limits and maximum leverage evolve dynamically based on market conditions</mark>
* <mark style="color:$info;">The market may enter close-only if any eligibility threshold is breached</mark>
  {% endstep %}

{% step %}
[**Leverage decay (J-factor)**](/leverage-and-risk/leverage-decay-j-factor.md)

* <mark style="color:$info;">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.</mark>
* <mark style="color:$info;">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.</mark>
  {% endstep %}

{% step %}
**Liquidation** **(if triggered)**

* <mark style="color:$info;">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.</mark>
  {% endstep %}

{% step %}
**Voided markets**

* <mark style="color:$info;">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</mark> <mark style="color:orange;">`timing.is_voided`</mark> <mark style="color:$info;">field on the position becomes</mark> <mark style="color:orange;">`true`</mark><mark style="color:$info;">, and</mark> <mark style="color:orange;">`timing.is_settlement_pending`</mark> <mark style="color:$info;">indicates that settlement is incoming. PnL is calculated against the trading venue refund.</mark>
  {% endstep %}
  {% endstepper %}

## On-chain transaction visibility

<mark style="color:$info;">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</mark> [<mark style="color:$info;">position transactions endpoint</mark>](/for-developers/api-reference.md#position-transactions-sub-resource) <mark style="color:$info;">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.</mark>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.dimes.fi/positions/position-lifecycle.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.