FAQ

FAQ Why focus on an options protocol?

• An option contract is the simplest type of financial contract that requires conditional logic and guarantees of execution. If programmable distributed ledger technologies (DLTs) should be good for anything, it should be good for allowing counterparties to enter into an option agreement with confidence. Bilateral options are not fancy or complicated, but it is a product that is used in the real world that should benefit from DLTs. Our goal is to create the best possible version of this simple contract using DLTs.

Why not a fungible token?

• Our approach has been one of first principles. At the most basic level, an option contract is a financial insurance agreement between two counterparties. Since each contract can have a unique set of terms, counterparties, and committed collateral, the contracts themselves are fundamentally unique and non-fungible.

• While options contracts can be made fungible and tradable on exchanges, it can only be done effectively by restricting the terms, collateral, and underlyings to the few that are the most liquid. The few products that are popular and liquid are already widely available on both centralized and decentralized exchanges.

• The fundamental issue with fungible tokens is that they require a minimum amount of liquidity on exchanges for price discovery to occur. The liquidity requirements for options tokens are exponentially higher as each underlying may have dozens or hundreds of derivatives, each of them requiring their own liquidity.

• Recognizing options contracts as fundamentally non-fungible allowed us to retain full flexibility of terms, collateral, and underlyings and led us to choose a price discovery mechanic that is independent of liquidity (dutch and reverse-dutch auctions).

What about liquidity?

• The existing OTC derivatives market is already significant (~25 trillion USD annual gross market value). We have plans to engage existing market participants as liquidity providers as well as establish a liquidity reward program.

What about capital and opportunity costs?

• For version 2 of our contracts we will be adding the ability to use yield generating tokens (e.g. aave tokens) so that users can simultaneously generate premium and interest on the committed collateral.

Why capped options vs. standard options?

• In order to serve effectively as price insurance, we decided that it is critical that the contracts fulfill their terms even in extreme circumstances. As such, each contract itself controls a dedicated amount of unmargined collateral. Synthesizing a standard option would require the implementation of margin mechanics which would be prone to failure.

What about partial fills on offers and requests?

• We are considering this for version 2 of our contracts

Why Cash Settled?

• ‘Physically’ settled arrangements are limited to on-chain assets and we wanted to offer a product that had real world applications. As a result, we made the design choice to use oracles for real world price data and settle in cash.

• Cash settlement allows our contracts to have a leverage multiplier (number of underlyings it represents).

Why aren’t you using a black-scholes on your platform?

• Black-sholes is a pricing model. As with any valuation model for any asset, black scholes is an imperfect estimation. The actual fair price of an asset can only be determined by an open market of buyers and sellers. Our platform creates a market; it is up to the buyers and sellers to choose which models they want to use.

Why not use real world implied vols to create an AMM?

• This would be possible, but such a platform would be restricted to underlyings for which there are existing liquid markets. This would be a poor accomplishment as the platform would not be an original market; it would not be able to exist on its own and would only offer a few highly liquid products that already exist.

• Our design goal is to create a platform that can support options contracts for anyone, anywhere, and for anything. Depending on implied vols would contradict that goal.

Why not design a DEX based AMM?

• Our design goal is to create a platform that can support options contracts for anyone, anywhere, and for anything. As discussed in “Why not a fungible token?”, aside from a few of the most popular assets, options are too illiquid to support price discovery through DEXs.

How decentralized will your platform be?

• Our contracts are truly non-custodial. There is no master account that can steal funds, rescue them, or upgrade the contracts to something new.

• We have intentionally designed the platform such that in it’s ultimate form:

  • We do not sell products. Users do.

  • We do not buy products. Users do.

  • We do not price products. Users do.

  • We do not decide what products are available. Users do.

  • We do not provide underlying price data. Users do.

  • We do not arbitrate in conflicts. Users do.

• We have deployed a version of our front end on ICP, which is a decentralized network capable of hosting web applications.

• We plan to use ICP to replace our backend services

• We plan to use ICP to allow users to host their own price data services

• Our ultimate goal is that the SmartPiggies ecosystem be solely operated by users, exist solely on decentralized infrastructure, and be fully self-sustaining.