In our previous blog, we emphasized the importance of implied volatility for option traders and demonstrated how to retrieve it—across any strike scale and expiry—using a flexible API that:

• Supports a range of expiry definitions (tenor-based, listed, or custom date/time).
• Offers multiple strike scales (strike, moneyness, log-moneyness, delta call/put, or FX-style).

Transitioning from implied volatility to actual pricing requires the same versatile API—offering possibility to calculate these with different premium conventions (especially in FX or digital assets). In this post, we explore how to streamline pricing by:

• Allowing configurable premium conventions (for example, paying the premium in a chosen currency), and
• Defining preset payoffs that let users retrieve implied volatility, pricing, and risk metrics for multiple structures (European vanilla, digitals, risk reversals, strangles, ...) in one request.

Today, our focus is on European vanilla options as a straightforward example. The same method applies to more complex payoffs, which we’ll cover in future blogs.

Options on Futures, Inverse Payouts in Digital Assets, and Premium Conventions

In the digital asset options market, it is common for options to be written on futures rather than the underlying spot price, although the difference is generally not material as we discuss below. Settlement currencies may be "foreign" in FX terms (e.g. BTC) or domestic (e.g. USDC). For example, settling a BTCUSD option in BTC avoids direct USD exposure, while options on altcoins like XRP/USDC are typically settled in USDC—a digital asset pegged to USD. Below, we explain how these structures work and why they matter to traders. In general, exchange-traded options follow specific settlement and premium conventions; however, with a flexible API, users can also price and calculate risk for OTC (over-the-counter) options that are not exchange traded.

Reminder: Call, Put, and Inverse Options

A call option grants the holder the right—but not the obligation—to buy the underlying asset at a predetermined strike price at (or before) expiry, while a put option grants the holder the right to sell. For standard "vanilla" options, the payoffs at expiry are defined as:

• Call payoff: max(S − K, 0)
• Put payoff: max(K − S, 0)

Here, S represents the underlying asset's price (spot or futures) at expiry, and K is the strike price.

In the cryptocurrency market—such as BTC/USD—options may also be structured as "inverse," a term specific to crypto. In traditional FX markets, these are simply described as options settled in the foreign currency. For instance, in a BTC/USD pair, BTC is considered the "foreign" currency and USD the "domestic." Thus, an inverse option on BTC/USD settles in BTC rather than USD. This structure avoids USD cash exchange at maturity and can simplify regulatory considerations.

The payoffs for inverse options at expiry are:

• Inverse Call payoff: max(S − K, 0) / S
• Inverse Put payoff: max(K − S, 0) / S

In this context, S is the USD price of BTC at expiry, and the payoff is denominated directly in BTC. Although the underlying asset is often quoted as the spot price, these options typically reference future prices expiring at the same time as the option itself.

After properly adjusting for discount factors and changing numeraires (the reference currency for valuation), inverse options become economically similar to their standard (linear) counterparts. In other words, when accounting for the time value and currency conversions, inverse and linear options exhibit identical economic characteristics and risk-return profiles.

Options on Futures

In the digital asset options market, particularly for Bitcoin, options are usually written on futures contracts rather than directly on the BTCUSD spot price. These futures are linked to an index aggregating prices from multiple exchanges and aren't generally tradable themselves. Options typically inherit expiry dates and attributes from these underlying futures, adding complexity due to indirect linkage to the spot price via futures and indices.

However, because digital asset options and futures typically share expiry dates, this indirect relationship has minimal practical impact. At expiry, futures prices converge with the underlying index price, aligning option values with their intrinsic index-based values.

Unlike commodities, where options and underlying futures often have mismatched expiry dates, crypto markets commonly align these expirations. Additionally, platforms like Deribit calculate settlement prices by averaging the underlying index price over a 30-minute window before expiry, reducing manipulation risk and ensuring fairness.

Cash Settlement

Most digital asset options are cash-settled, meaning that at expiry you receive (or pay) the net "cash value" in either currency X or Y (for X/Y options). For example, BTC/USD options typically settle in BTC, while SOL/USDC options settle in USDC. Cash settlement avoids the logistical complexities associated with "physically" delivering multiple currency flows.

• Physically Settled: This method involves exchanging the underlying asset (e.g., BTC for USD or vice versa) at the strike price upon expiry. Physical settlement is less common in crypto markets but is standard practice in many FX markets.
• Cash Settled: With cash settlement, the difference between the option’s payoff and the strike price is paid out directly in BTC or USD. This approach is generally preferred due to its simplicity, provided the settlement procedure remains consistent and transparent.

Premium Conventions

Exchanges often use specific premium conventions, but multiple possibilities exist for expressing premiums, particularly within FX markets. Typically, FX traders use different premium conventions depending on the currency pairs traded.

With Qytrees API, beyond selecting the asset for final settlement (e.g., BTC vs. USD), users can also choose how the option premium is quoted. Similar to FX markets—where a call option’s premium can be expressed in either the domestic or foreign currency—our API supports several premium conventions, represented through the PremiumConvention enum. These conventions are inspired by FX market practices, offering flexibility in how premiums are interpreted and reported.

We will cover the detailed mapping of these conventions, along with practical examples, in an upcoming blog post.

• QUOTE_ASSET: Premium denominated in the “quote” (domestic) currency.
• BASE_ASSET_PERCENTAGE: Premium denominated in the “base” (foreign) currency (e.g., paying in BTC for BTC/USD options). Usually referred to as percentage foreign in FX.
• QUOTE_ASSET_PERCENTAGE and BASE_ASSET are more generally used in FX markets rather than digital assets markets, and commonly known as percentage domestic and foreign pips respectively.
• UNDISCOUNTED_...: These represent the same conventions but exclude discount factors, enabling pricing in terms of undiscounted amounts or percentages.

By treating either asset as the numeraire, these conventions allow users to incorporate multiple quoting styles within a consistent framework,

The payoff node

Qytrees API leverages GraphQL, offering several advantages as discussed in our previous blog. GraphQL allows you to precisely define your requirements by specifying each node and subnode. We've already explored how to define the strike and expiry nodes. Below, we will discuss the payoff node that applies to each strike and expiry.

For instance, a user can specify a range of strikes in Moneyness between 0.9 and 1.1 with increments of 0.1, along with a list of expiries in tenor format such as 1M, 6W:

strike:{
  selection: null
  strikeType:{scale: MONEYNESS}
  range: [0.9, 1.1, 0.1]
}
expiry:{
  selection: null
  list: ["1M", "6W"]
}

For each strike and expiry combination, the payoff node assigns a payoff type.

The payoff node consists of two subnodes: Selection and List described below.

• Selection: Using the selection subnode, a user can choose for example "LISTED," which includes all payoffs available from the selected source.
• List: With the List subnode, a user can explicitly define the desired payoff types. For example, the user below specifies two payoff types: a vanilla call and a vanilla put. This means that for each of the defined strikes and expiries, both of these payoffs will be generated.

While many other payoff structures are supported, this section focuses specifically on vanilla options:

 payoff:
    {
      selection: null
      list : [
        {vanilla:{callPut: CALL}}
      	{vanilla:{callPut: PUT}}
      ]
    }

Output Nodes

The previously discussed nodes—strike, expiry, and payoff—form part of the input portion of the GraphQL query, enabling precise control over what the user wants to analyze. Once the inputs are defined, the output section determines what information is retrieved in response to the query.

In this blog, we focus on the Price Node, one of several available output nodes.

Price Node

The price node, together with your selected premium convention and payoff structure, allows the API to compute option prices.

Below is an example using GraphQL aliases to retrieve prices using two different premium conventions simultaneously:

 quote_price: price(premiumConvention: QUOTE_ASSET) {
  mid
}

quote_price_percentage: price(premiumConvention: QUOTE_ASSET_PERCENTAGE) {
  mid
}

In this example, quote_price and quote_price_percentage are aliases. They enable users to query the same field (price) multiple times with different arguments, without conflicts in the GraphQL response. Here, the user is requesting prices using two different premium conventions for all strikes, expiries, and payoffs defined in the input.

A Practical Example

Say you want to price a 3-month BTC/USD At-The-Money Zero-Delta Straddle, where the premium is expressed in BTC. This can be configured in a single request using the API.

Query to price a 3-month BTC/USD At-The-Money Zero-Delta Straddle, where the premium is expressed in BTC

In future blog entries, we’ll explore additional output nodes, including:

• Implied Volatility Node – returns the full IV surface or selected slices.
• Risk Node – provides option Greeks and sensitivity metrics.

These modular output fields give users fine-grained control over the structure and granularity of the returned data.

Conclusion

This blog highlights the flexibility of the API, allowing users to build custom queries and request data of completely different nature—all within a single request.

We’ll explore additional data types and features in future posts.

If you have a specific use case or topic you'd like us to cover, feel free to reach out.