WebsiteGithubCommunity Docs

Option System

Overview of the Bond Protocol Option system contracts

Smart contracts for Option Tokens (oTokens) and Options Liquidity Mining (OLM).

Background

Our mission began as a paradigm shift in the way protocols utilize emissions to acquire assets, own liquidity, and diversify their treasuries. Liquidity mining incentives are still, for better or worse, widely utilized in crypto to incentivize early network participants providing a valuable service - liquidity.

But incentives naturally attract short-term participants and mercenary capital. Liquidity is also inherently temporary, a good mental model is that LM incentives "rent" liquidity.

Re-contextualizing liquidity mining incentives as call options unlocks the ability for protocols to capture value and own their liquidity.

This implementation draws inspiration from a number of sources including:

Overview

Bond Protocol's Option System is a flexible system for unlocking the power of Option Liquidity Mining (OLM) for projects of all sizes. We incorporated insights gained from bonding, notably designing a system that can be used with or without a price oracle.

Fixed Strike oTokens

ERC20 implementation of a Fixed-Strike Option Token (oToken). When the token is created, strike price is set to a fixed exchange rate between two ERC20 tokens - the Payout and Quote tokens. oTokens inherit the units of the Payout token, and they are created 1:1. The Strike Price is provided in Quote token units and is formatted as the number of Quote tokens per Payout token. Timestamps are used to determine when the option is Eligible to be exercised and its Expiry, beyond which it cannot be exercised. The interplay between Eligible and Expiry times gives rise to the entire design space between American-style and European-style options.

Fixed Strike Option Teller

The Teller contract handles token accounting and manages interactions with end users exercising options. oTokens can be permissionlessly deployed and created by depositing the appropriate quantity of tokens as collateral. oTokens can be used as incentives via the OLM contracts, used within an existing ERC20 reward contract, or sold via a bond market (likely in an instant swap). Users can exercise their options by providing the appropriate quantity of tokens as payment alongside Eligible (but not Expired) option tokens. Exercised oTokens are burned after being provided to the Teller. After Expiry, the Receiver can reclaim collateral from unexercised options. Receivers can unwrap oTokens they possess at any time via the exercise function.

Options Liquidity Mining (OLM)

Liquidity mining implementation that issues oToken rewards to stakers via an epoch-based system. OLM instances are deployed with immutable Staked Token (ex: LP token), Payout Token, and Option Teller addresses. Owners manage parameters used to create oTokens for a given epoch, as well as that epoch's duration and reward rate. Strike price can be set for the next epoch via a Manual implementation (only Owner) or based on a set discount from Oracle price. Owners manage rewards payouts in the OLM contract by directing sending (or withdrawing) Payout Tokens to the contract.

Users can stake and un-stake tokens at any time. An emergency un-stake function is provided for edge cases, but users will forfeit all rewards if stake is withdrawn using this function. Rewards can be claimed for each eligible epoch. Option tokens which have already expired are not claimed in order to save on gas costs.

New epochs can be triggered manually by the Owner, or they can be started when users call a function that tries to start a new epoch. If a user starts a new epoch, they are sent Option Tokens as the Epoch Transition Reward in order to compensate for increased gas cost paid.

Setting up an OLM requires three steps.

  1. Deploy an OLM contract from a factory.

  2. Fund the OLM contract with payoutTokens to pay rewards with (via a simple ERC20 transfer). Owners must monitor the balance of payoutTokens in the contract to ensure that users can claim their rewards.

  3. Initialize the OLM contract, including inputting the remaining options and staking parameters.

OLM Factory

Factory contracts deploy instances of OLM contracts. The MOLMFactory deploys ManualStrikeOLM contracts, and the OOLMFactory deploys OracleStrikeOLM contracts. The sender of a deploy transaction is made the owner of the OLM contract. OLM contracts are not active when deployed. Owners must deposit rewards to the contract and then to call initialize to provide additional inputs and allow deposits.

Design Decisions

In designing this system, we made a few opinionated decisions that differentiate it from other option protocols:

  1. Our oTokens are Physically Settled, meaning that the underlying assets are actually exchanged when the option is exercised. This is in contrast to some systems which use Cash Settlement, where the difference in value from the strike price and the market price is exchanged in a separate unit of account asset when exercised. Traditional options markets often work on a cash settlement basis, but for protocols issuing options as rewards, physical settlement is superior since they often have large amounts of their native token and little "reserves".

  2. Our initial oToken implementations use a fixed strike price determined when it is deployed instead of an oracle to track market price over time. Oracles are a challenging problem and are expensive to maintain. This means that many projects, especially new ones, do not have reliable oracles for their tokens. Liquidity mining is more common in early stage projects so it makes sense to build a system that is usable without an oracle. However, we recognize the convenience of reliable oracles and did make a version of the OLM contract which uses an oracle to set the fixed strike price at the beginning of each epoch. Our token + teller design can easily be extended to a true oracle-strike version in the future.

  3. We sacrificed some fungibility of our oTokens by having each be unique to a receiver address in order to route proceeds from oToken exercises directly to the issuer (while providing them some flexibility on where these funds go). Our primary use case is not creating an exchange for options, and, therefore fungibility of the tokens was not the top priority. A future version may alter this part of the design to be more fungible.

  4. Our oTokens have configurable eligible and expiry dates which allow for the creation of European options (only exercisable at the expiry), American options (exercisable any time from issuance up to expiry), or somewhere in between. Other options do not have expiries or implement one specific flavor.

Audits

The smart contracts in this repository were audited by Sherlock. The comprehensive audit report can be found in the audit/ directory of the GitHub repository.

License

The source code of this project is licensed under the AGPL 3.0 license.

Deployments

Testnets

Production

PreviousLimit OrdersNextFixed Strike oTokens

Last updated