> For the complete documentation index, see [llms.txt](https://docs.callput.app/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.callput.app/traders/pricing-and-execution.md).

# Pricing and execution

## Pricing and execution

Callput uses separate reference, mark, execution, and settlement values. Reference data informs pricing. Mark price is indicative. Execution price is set for each queued request. Settlement value applies after expiry under protocol rules. Feed availability and pricing must be checked before every trade.

For exact formulas and state transitions, read [Pricing Mechanics](/traders/pricing-mechanism.md). This page focuses on trader outcomes.

### Value definitions

| Value            | Meaning                                                           |
| ---------------- | ----------------------------------------------------------------- |
| Reference price  | Market-data input used in the pricing process                     |
| Mark price       | Indicative option value shown for discovery                       |
| Execution price  | Request-specific value resolved through the queued execution path |
| Settlement value | Protocol-defined value used after expiry                          |

These values can differ from exchange, broker, or vendor prices. Market closures, halts, corporate actions, stale data, and liquidity conditions can affect them.

## Three pricing stages

Callput has three distinct pricing stages.

| Stage              | What it does                                                           | Main output                                         |
| ------------------ | ---------------------------------------------------------------------- | --------------------------------------------------- |
| Public market feed | helps traders discover listed markets and compare strikes and expiries | `markIv`, `markPrice`, greeks, directional RP rates |
| Keeper pricing     | recalculates price and risk for the actual queued request              | request-specific `markPrice` and `rpRate`           |
| Onchain execution  | stores the final premium adjustment and resolves the trade             | `riskPremium` and final `executionPrice`            |

The practical implication is simple: the displayed market is an indicative discovery layer, while the request queue is the final execution layer.

## How Callput determines mark price

At a high level, Callput builds mark price from option-specific inputs rather than from a generic swap quote.

The pricing stack uses:

* futures reference prices
* spot indices
* implied volatility data
* risk-free rate inputs

The public market pipeline first computes an `underlyingFutures` value from the futures index and the selected risk-free rate for the expiry. It then resolves option mark price in one of two ways:

* if direct mark IV and mark price data are available for the instrument, those values are used
* if they are not available, the system estimates IV from nearby strikes with the same underlying, expiry, and option side, then derives mark price from the pricing model

For spreads, the mark price is derived from the net value of the two legs instead of from a single-leg quote.

This is why Callput prices behave like option prices. Strike, expiry, volatility, and term structure all matter.

## How Callput determines risk premium

Risk premium is not a flat fee added to every trade. It is a directional premium that reflects how the request changes protocol-side inventory and risk.

At a high level, the backend calculates RP from:

* the greeks of the new trade
* current OLP greeks
* moneyness
* time to expiry
* vault utility-ratio changes after the trade
* volatility-score inputs

The public feed exposes this as:

* `riskPremiumRateForBuy`
* `riskPremiumRateForSell`

Those values are useful for pre-trade exploration, but they are still indicative. Final execution uses the request-specific pricing path described below.

## Why request timing and queue position matter

When the keeper prepares a queued request for execution, it recalculates pricing for the actual request context:

* the actual `optionTokenId`
* the actual request size
* whether the request is open or close
* the current OLP state when the request is processed

The keeper then converts the request-specific RP rate into an absolute premium amount:

* `riskPremium = markPrice * rpRate`

That premium amount is written onchain for the specific `requestIndex`, and the contracts use it to resolve final execution.

This means:

* two requests against the same displayed market can execute differently
* the final execution price is not fixed when the request transaction is first submitted
* the queue is part of the pricing mechanism, not only part of the transport layer

## Mark price vs execution price

The `mark price` is the current option price reference.

The `execution price` is the final price associated with the request when it is processed.

At a high level:

| Request flow | Directional effect versus mark |
| ------------ | ------------------------------ |
| open buy     | moves upward                   |
| open sell    | moves downward                 |
| close buy    | moves downward                 |
| close sell   | moves upward                   |

The full rule is implemented as `markPrice ± riskPremium`, with the sign determined by whether the trader is opening or closing long or short exposure.

## Why risk premium matters for traders

Risk premium is one reason the buy side and sell side of the same listed option can feel different even when the displayed mark is unchanged.

Callput is explicitly designed so that execution reflects:

* option market inputs
* protocol inventory pressure
* the actual request path being processed

That is a more option-native pricing model than simply applying one fixed markup to every user.

## How a request becomes an execution

1. the user discovers a market from the public feed
2. the user submits an open or close request with execution constraints
3. the request enters the queue
4. the keeper recalculates mark price and RP for the request
5. the keeper writes the final values onchain
6. the contracts resolve the request as `Executed` or `Cancelled`

The practical consequence is simple: a successful request transaction means the request was registered, not that execution is already final.

## Timing and cancellation risk

Requests do not stay valid forever. The current protocol-level request validity window is limited by `maxTimeDelay`, which is currently `180` seconds.

If a request cannot be executed under the relevant conditions, it can end as `Cancelled`.

Common reasons include:

* the request expired under `maxTimeDelay`
* minimum execution constraints could not be satisfied
* subtract-side execution became invalid because `riskPremium` was too large relative to `markPrice`
* the relevant fast price became stale or unusable for execution

In practice:

* cancelled open requests can return input funds
* cancelled close requests can return option tokens
* the execution fee should not be assumed refundable

## Slippage and minimum-output controls

Callput requests include minimum execution constraints such as `_minSize`, `_minAmountOut`, and `_minOutWhenSwap`.

* tighter thresholds can increase cancellation risk
* looser thresholds can reduce execution quality

These controls do not replace the pricing mechanism. They sit on top of it and determine whether the current execution conditions are acceptable to the trader.

## Close is not settlement

### Close

Closing before expiry requires a separate close request and remains queue-based.

### Settlement

Settlement happens after expiry through `SettleManager`. It is a separate path, not a delayed close.

## What traders should expect

* displayed pricing is indicative, not final
* request-index-specific pricing means two similar requests can resolve differently
* request registration and request execution are different events
* last-minute entry and exit are constrained by the deadline buffer
* `Cancelled` can be a normal outcome rather than a malfunction