1. Overview

Let's consider this token

WETHUSDC 30-April-2021 1280Put USDC Collateral

https://etherscan.io/token/0x18ebe982fd5a6f724837549c03f186438e90eee3

It represents an Opyn Option with

Underlying = WETH
Strike Asset = USDC
Strike Price = 1280
Type = Put
Expiry = 30 Apr 2021

The confirmation of this can be found analysing the source code in the related Smart Contract OToken.sol

        tokenSymbol = string(
            abi.encodePacked(
                "o",
                underlying,
                strike,
                "/",
                collateral,
                "-",
                _uintTo2Chars(day),
                monthSymbol,
                _uintTo2Chars(year),
                "-",
                displayStrikePrice,
                typeSymbol
            )
        );

It was created 60 days before its expiration so on 03 Mar 2021when ETHUSD was about 1560 so this put was essentially betting on ETH loosing >18% in 2 months

2. TX Analysis

This is its minting Tx

https://etherscan.io/tx/0x052a2a5cc5c43d2247ae238beb9bc0445d0850dd56cd53f4198cdc9d31e4aa66

The Contract Creator interacted with the smart contract UpgradeableProxy for Controller that is a proxy for Controller You can check this by looking at the internal TXs of this contract here and you can see it's interacting with the proxy UpgradableProxy for Controller all the time
This is interaction consisted of 2 token transfers: first 256.000 USDC are transferred from Contract Creator to the Opyn System and then 200 WETHUSDC 30-April-2021 1280Put USDC Collateral options are returned to it
The reason is obviously the options needs to be collateralized to avoid liquidation risk so since the Strike Price is 1280 USDC for 200 Options we get 256000 USDC
Let's analyze this more in-depth
It all starts calling Controller --> operate() passing the params to Mint an OToken for the Put Option
It internally calls Controller --> _runActions() which acts as a proxy here for a bunch of actions

            if (actionType == Actions.ActionType.OpenVault) {
                _openVault(Actions._parseOpenVaultArgs(action));
            } else if (actionType == Actions.ActionType.DepositLongOption) {
                _depositLong(Actions._parseDepositArgs(action));
            } else if (actionType == Actions.ActionType.WithdrawLongOption) {
                _withdrawLong(Actions._parseWithdrawArgs(action));
            } else if (actionType == Actions.ActionType.DepositCollateral) {
                _depositCollateral(Actions._parseDepositArgs(action));
            } else if (actionType == Actions.ActionType.WithdrawCollateral) {
                _withdrawCollateral(Actions._parseWithdrawArgs(action));
            } else if (actionType == Actions.ActionType.MintShortOption) {
                _mintOtoken(Actions._parseMintArgs(action));
            } else if (actionType == Actions.ActionType.BurnShortOption) {
                _burnOtoken(Actions._parseBurnArgs(action));
            } else if (actionType == Actions.ActionType.Redeem) {
                _redeem(Actions._parseRedeemArgs(action));
            } else if (actionType == Actions.ActionType.SettleVault) {
                _settleVault(Actions._parseSettleVaultArgs(action));
            } else if (actionType == Actions.ActionType.Call) {
                _call(Actions._parseCallArgs(action));
            }

from the above discussion we know there are 2 actions called here: first, the collateral is deposited and then the OTokens are minted

2.1 Deposit Collateral

The related action is Actions.ActionType.DepositCollateral which calls here the _depositCollateral

it is important to observe here in the function definition

onlyAuthorized(msg.sender, _args.owner)

so only a set of authorized users can call this method

2.1.1 Checks

2.1.1.1 VaultID Validity and Accessibility for `_args.owner`

Link

        require(_checkVaultId(_args.owner, _args.vaultId), "Controller: invalid vault id");

2.1.1.2 Being allowed to deposit collateral

Link

        require(
            (_args.from == msg.sender) || (_args.from == _args.owner),
            "Controller: cannot deposit collateral from this address"
        );

2.1.1.3 Whitelisted Collateral

Link

        require(
            whitelist.isWhitelistedCollateral(_args.asset),
            "Controller: asset is not whitelisted to be used as collateral"
        );

2.1.2 Changes

2.1.2.1 Increasing the collateral balance in a Vault

Link

        vaults[_args.owner][_args.vaultId].addCollateral(_args.asset, _args.amount, _args.index);

This shows there is a N x M relationship between Owners and Vaults and it is modeled in the vaults variable

The addCollateral() function interface is defined as follows

    function addCollateral(
        Vault storage _vault,
        address _collateralAsset,
        uint256 _amount,
        uint256 _index
    )

NOTES

The _index is just a convenience variable: it is an internal index in the _vault.collateralAssets which is an array tracking the collaterals
This is confirmed here by the following consistency check

            require(
                (_vault.collateralAssets[_index] == _collateralAsset) ||
                    (_vault.collateralAssets[_index] == address(0)),
                "MarginVault: collateral token address mismatch"
            );

Technically, this check passes if one of the following conditions is True (note the || so Logical OR operator and the fact the 2 conditions are mutually exclusive)
- Case 1 : _vault.collateralAssets[_index] == _collateralAsset
- the collateral address _collateralAddress is already tracked and represented by _index
- Case 2 : the _index corresponds to address(0) which essentially means the _collateralAddress is not tracked yet, but since it is whitelisted (remember the previous check) it just means it has not been used yet
so the only case this Tx fails is when a whitelisted collateral previously used and hence tracked is passed with an _index that does not match the one that already tracks it: essentially it should never happen since it would be a bug in the code elsewhere

So ultimately the changes made here by this function are

            _vault.collateralAmounts[_index] = _vault.collateralAmounts[_index].add(_amount);
            _vault.collateralAssets[_index] = _collateralAsset;

Line 1: the current amount of the collateral in the vault represented by _vault.collateralAmounts[_index] is increased by _amount
Line 2 : in case the asset is already tracked (so Case 1 of the check discussed above) this is just repetitive, but if it is not tracked (so Case of the check discussed above) then it starts tracking it

2.1.2.2 Transferring the collateral

Link

        pool.transferToPool(_args.asset, _args.from, _args.amount);

The transferToPool() function interface is defined as follows

function transferToPool(
        address _asset,
        address _user,
        uint256 _amount
    )

After a basic sanity check on _amount > 0 shown here

        require(_amount > 0, "MarginPool: transferToPool amount is equal to 0");

what happens is

        assetBalance[_asset] = assetBalance[_asset].add(_amount);

The current Asset Balance for _asset represented in assetBalance[_asset] is increased by _amount

        ERC20Interface(_asset).safeTransferFrom(_user, address(this), _amount);

The _asset is then finally transferred in the Token Balance Sheet by calling the ERC20 safeTransferFrom() which ultimately transfers the taken from _user to address(this) so this contract for _amount amount

2.1.3 Summary

At this point the situation is

at ERC20 level, so in the _args.asset Balance Sheet, an amount _args.amounthas been transferred from_user` to this contract
at Opyn Level, there are 2 Balance Sheets that have been updated
- the Vault so vaults[_args.owner][_args.vaultId] and
- the Pool so pool which is defined as
Link

pool = MarginPoolInterface(addressbook.getMarginPool());

so the address of the related smart contract is taken from the addressbook which is set at deployment time

2.2 Minting the OToken

related action is Actions.ActionType.MintShortOption which calls here the internal function called _mintOtken()

The args _mintOtken() requires are defined in the mintArgs struct

    struct MintArgs {
        // address of the account owner
        address owner;
        // index of the vault from which the asset will be minted
        uint256 vaultId;
        // address to which we transfer the minted oTokens
        address to;
        // oToken that is to be minted
        address otoken;
        // each vault can hold multiple short / long / collateral assets but we are restricting the scope to only 1 of each in this version
        // in future versions this would be the index of the short / long / collateral asset that needs to be modified
        uint256 index;
        // amount of oTokens that is to be minted
        uint256 amount;
    }

NOTE

The otoken address is also used to reach the actual implementation of mintOtoken() which is the function that actually mints the token

2.2.1 Checks

2.2.1.1 Authorization

it is important to observe here in the function definition
Link

onlyAuthorized(msg.sender, _args.owner)

only a set of authorized users can call this method

2.2.1.2 Sanity check on the Vault

Link

require(_checkVaultId(_args.owner, _args.vaultId), "Controller: invalid vault id");

2.2.1.3 Otoken Whitelist Check

Link

require(whitelist.isWhitelistedOtoken(_args.otoken), "Controller: otoken is not whitelisted to be minted");

2.2.1.4 OToken Expiry Sanity Check

Link

        OtokenInterface otoken = OtokenInterface(_args.otoken);

        require(now < otoken.expiryTimestamp(), "Controller: can not mint expired otoken");

2.2.2 Changes

2.2.2.1 Tracking the number of Short OTokens

Link

        vaults[_args.owner][_args.vaultId].addShort(_args.otoken, _args.amount, _args.index);

The addShort() function interface is defined here

    function addShort(
        Vault storage _vault,
        address _shortOtoken,
        uint256 _amount,
        uint256 _index
    )

So just looking at the interface we can say this function tracks the number of the specific Short=Put OTokens minted in the Vault using the already analysed _index pattern instead of the _shortOtoken address identifying the actual smart contract for the OToken given

2.2.2.2 Actual OToken Minting

Link

        otoken.mintOtoken(_args.to, _args.amount);

For the actual minting it is necessary to go through the OtokenInterface to access the mintOtoken() abstract abstract method
The actual implementation can be called after the actual instantiation here providing the _args.otoken related smart contract address

OtokenInterface otoken = OtokenInterface(_args.otoken);

Appunto

NicolaBernini / BlockchainAnalysis

Transaction Analysis - Creation of an Opyn Option #12

1. Overview

2. TX Analysis

2.1 Deposit Collateral

2.1.1 Checks

2.1.1.1 VaultID Validity and Accessibility for `_args.owner`

2.1.1.2 Being allowed to deposit collateral

2.1.1.3 Whitelisted Collateral

2.1.2 Changes

2.1.2.1 Increasing the collateral balance in a Vault

2.1.2.2 Transferring the collateral

2.1.3 Summary

2.2 Minting the OToken

2.2.1 Checks

2.2.1.1 Authorization

2.2.1.2 Sanity check on the Vault

2.2.1.3 Otoken Whitelist Check

2.2.1.4 OToken Expiry Sanity Check

2.2.2 Changes

2.2.2.1 Tracking the number of Short OTokens

2.2.2.2 Actual OToken Minting

NicolaBernini / BlockchainAnalysis

Transaction Analysis - Creation of an Opyn Option #12

1. Overview

2. TX Analysis

2.1 Deposit Collateral

2.1.1 Checks

2.1.1.1 VaultID Validity and Accessibility for _args.owner

2.1.1.2 Being allowed to deposit collateral

2.1.1.3 Whitelisted Collateral

2.1.2 Changes

2.1.2.1 Increasing the collateral balance in a Vault

2.1.2.2 Transferring the collateral

2.1.3 Summary

2.2 Minting the OToken

2.2.1 Checks

2.2.1.1 Authorization

2.2.1.2 Sanity check on the Vault

2.2.1.3 Otoken Whitelist Check

2.2.1.4 OToken Expiry Sanity Check

2.2.2 Changes

2.2.2.1 Tracking the number of Short OTokens

2.2.2.2 Actual OToken Minting

2.1.1.1 VaultID Validity and Accessibility for `_args.owner`