Time Considerations
Last updated
Last updated
oTokens are created and distributed on an epoch-basis at a given reward rate, which leads us into one of the most critical components of deploying an OLM program — time.
Just like liquidity, options do not last forever. Options also implicitly have an eligibility date, where American options are instantly eligible and European options are only eligible on the expiration date. American options are typically more valuable to holders since the instant eligibility gives more flexibility to the option holder. However, European options are more likely to be traded and many protocols have implemented dynamic pricing models to establish liquid options markets.
In order to accommodate oToken expiry within a liquidity mining program, OLM issues different oTokens on an epoch basis. Liquidity mining implementations work very similarly, where some amount of reward tokens are issued over a period of time. With OLM, the main difference is that the reward token is an oToken unique to each epoch. The OLM contract owner can update the strike price, eligibility window, and quote asset before the next epoch starts.
In the example above, different oTKNs are issued for each epoch. The eligible and expiry dates of each oTKN are specified from the beginning of each epoch as `timeUntilEligible` and `eligibleDuration`. Additionally, the strike price can be updated for each epoch via two implementations of the OLM contract:
Manual: strike price manually updated by issuer before next epoch (example above)
Oracle: strike price set at a % discount from oracle feed at beginning of epoch
Consequently, oTokens issued by our OLM implementation are fungible within an epoch (ERC-20) but are not fungible across epochs (different tokens). We chose this implementation to focus specifically on oToken recipients exercising their options instead of trading them.
Connecting the pieces together, let’s review some examples of OLM implementations. The two below are scenarios based on the expected activity of Liquidity Providers (LPs). Shorter epoch lengths and option expiries require more active LPs, while longer epochs are more passive. However, strike price for oTokens is set on an epoch-basis and epoch length will impact how responsive OLM programs can be to market conditions.
Epoch Length: 7 days
Expiry: 8 days (day after epoch ends)
Pros: Short epoch duration and eligibility window allows for rapid experimentation with settings. Strike price can be updated quickly during periods of volatility. Tight expiry window post-epoch gives instant feedback on the quantity of tokens issued from OLM.
Cons: Configuration is unattractive for passive LPs as they need to pay attention to shorter epochs. Value of OLM emissions are tightly coupled to exercise value (market price — strike price). Gas costs from more frequent claim and redeem cycles can price out smaller participants.
Epoch Length: 4 weeks
Expiry: 8 weeks
Pros: Long epoch duration requires less maintenance and fewer oToken instances, resulting in more time for LPs to exercise their oTokens. Long eligibility window increases time-value of oToken, decoupling value from instant exercise (market price — strike price).
Cons: Longer time horizons can be difficult in periods of high volatility.
For any OLM configuration, the oToken eligibility is fully customizable. The examples above showcase American-style options, which grant holders instant eligibility. However, this can create a situation where some users may claim and exercise their oTokens mid-epoch, leading to disparities.
An alternative configuration is to set the Eligible Time to start at the end of the epoch. This approach provides LPs a more fair experience when claiming oTokens, particularly in circumstances where gas costs are high.
Fortunately, the eligibility window is configurable for the upcoming epoch so protocols can adjust if necessary.
