The making of ohmydai — part 2

Willian Mitsuda
ohmydai
Published in
3 min readDec 21, 2019
This is NOT the kind of mint we are going to talk about here (“Mint” by James Jardine is licensed under CC BY-NC-ND 2.0)

Overview

In this post we'll focus on the inner mechanics of the smart contract.

The option contract behaves differently before and after the series expiration. Let's explore how it works.

Consider the scenario where a DAI holder buys a put option that grants him the right to sell 1 DAI for 1 USDC until the expiration. For this to happen, first some USDC holder has to issue 1 option token by locking 1 USDC.

The option token is a regular ERC20 token, so all its standard operations behave like any other ERC20 token and won't be covered here. We'll cover only the option-specific functions.

Before expiration

There are 3 functions that contract callers are allowed to call before the series expiration: mint, burn and exchange. They only work until expiration, calling these functions after that will make them to fail with a revert().

Option issuers use the mint/burn functions to create and destroy option tokens from a certain series.

Mint

Minting 1 option requires locking 1 USDC. Once the option is minted, it can be freely traded as any ERC20 token.

All USDC from minters are pooled inside the contract.

Burn

Burning 1 option unlocks 1 USDC. The caller can't burn an option if he has not locked USDC inside the contract.

Burning is the mechanism that allows the option writer to exit (partially or totally) his position. If the writer has any USDC locked into the contract, he will be subjected to be exercised. If he wants to not be exposed anymore, he must burn his option tokens. If he doesn't have the options anymore because he has sold them in the market, he must first buy them back from another person.

Exchange

Exchange is the operation that allows an option holder to exercise his right at any time before the expiration.

In our use case, the caller should be a DAI holder who wants to exercise his right to exchange his DAI for some option issuer USDC.

The smart contract will enforce this exchange and in the process 3 things will happen:

  1. The options will be burned
  2. The DAI from the caller will be locked inside the contract in a common pool
  3. The pooled USDC will be transferred back to the caller

This way we ensure that the economics of the smart contract are consistent. Every time USDC is locked into the contract the corresponding amount of option tokens are created. Every time USDC is removed from the contract, we ensure the corresponding amount of option tokens are destroyed.

After expiration

After the option series is expired the option tokens should have no market value. They can still be transferred between addresses like any other ERC20, but besides that, the exchange() function is disabled, ensuring that there is no more blockchain enforcement for exercising the option, rendering it useless.

After expiration a new function becomes available in the contract: withdraw(). Calling this function before the series expiration causes it to fail with a revert().

The withdraw() function is supposed to be called by option issuers and allows them to redeem all of their locked underlying asset. The outcome of this function is a transfer back from the smart contract to the caller of USDC and/or DAI.

The trick

Since there is no matchmaking and all locked USDC and exercised USDC that was exchange for DAI are pooled, withdrawing the collateral can result in the caller receiving back USDC and/or DAI on a first come/first serve basis. The early withdrawers will get back their locked USDC, while the last ones will be considered "exercised" and will only receive back DAI.

In the next post of this series, we are going to dive even deeper into the technologies we've leveraged to make this product happen.

--

--