Welcome to DeFiOptions Discussions!

[TCGV]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[remote-gildor]

Hey, maybe I missed this in readme, but is there any front-end yet for Kovan smart contracts?

[TCGV]

Nice. This could speed things up, and I could focus on running simulations for validating/optimizing solidity code.

I can provide you the exchange / liquidity pool use cases and a rough design mock up for guidance. Also, let me check with a colleague that was willing to help me build the front-end in case no volunteer showed up if he has any inputs on this.

I'll get back to you today after work or tomorrow morning (I'm only available here on my free time).

[remote-gildor]

Sure, no problem 🙂 A simple website sketch/wireframe would be very helpful + some notes on which contract function calls are used on various parts of the website (forms and info displays).

[TCGV]

Hey @remote-gildor, so I just added two new contract functions that I think will be required for building the front-end:

• [OptionsExchange] function getBook(address owner) for listing all options an address is holding or has written
• [LiquidityPool] function listSymbols() external returns (string memory) for listing all tradable option symbols within the liquidity pool

I will redeploy contracts on Kovan tomorrow, test these new functions and then prepare a website sketch indicating which contract function calls you should use throughout the UI to share with you.

The UI will mostly interact with the OptionsExchange contract and the LiquidityPool interface.

[TCGV]

@remote-gildor here's an initial wireframe proposal:

• https://docs.google.com/document/d/1BIERD0R_4LaXCVyhBprA9Wr416Gv2_dz-o25r1NeYPw/edit?usp=sharing

I focused more on functionality and less on the UI. Feel free to add your personal touch to it.

If you have any doubts just let me know, and don't hesitate to share your progress as you go along ;)

[remote-gildor]

Great! I'll go through it and let you know if/when I have any question.

[cinquemb]

Read your latest blog post, a couple of ideas wrt some of the disadvantages you listed:

• Would it be possible to incentivize updates of pricing parameters/ pool operations with the credit token? I.e. users call contract functions that awards credit tokens depending on the state of a particular aspect of the system.

• In the same line of thought, users could post collateral and/or pay fees to register any particular security/defining spreads? Maybe this would require some kind of pool factory?

[TCGV]

Hi Cinque, regarding your first question, I think incentivizing updates of pricing parameters/ pool operations is a great idea for sustaining operational costs in the long run. Besides the credit token we could also consider issuing governance tokens instead.

Regarding the second question, the LiquidityPool implementation is decoupled from the OptionsExchange, so yeah, it will be possible for anyone to deploy it and run an independent LP with different pricing parameters. The only limitation is that the LP can only trade options whose underlying assets are registered in the OptionsExchange.

Registration of a new underlying asset happens when the ProtocolSettings setUdlFeed function is called specifying the address of the asset price feed contract. Only the exchange administrator or a governance approved Proposal contract will be allowed to call this administrative function.

[cinquemb]

Besides the credit token we could also consider issuing governance tokens instead.

Both could work, you could have it set up where people can specify if they want their incentives in either or some combination of them. Combined with:

Only the exchange administrator or a governance approved Proposal contract will be allowed to call this administrative function.

It seems like this would be sufficient incentive to not only get writers to manage the upkeep (the more governance tokens, the more ability to create new underlying assets), but as well as allowing for 3rd parties who want no direct exposure in exchange for credit tokens (people can create their own erc20 contracts to wrap those tokens and sell them on uniswap for liquidity).

[cinquemb]

Hi Thomas,

Do you have a way to deploy mock aggregator contracts locally (if not, what do you think the best way to do it would be)? Are there more requirements I need to have besides the existing deployment scripts you have to simulate this locally besides having some kind of mock aggregator?

I have more free time now and I want to be able to deploy your master branch as is (and any updates you make) against a local test net and simulate agents interactions with it (I will probably just fork your master and keep updating it as you make updates). I will be using avalanchego instead of gananche-cli because its way faster, but at this time I do not want to make any solidity modifications (unless absolutely necessary to get everything up and running), and just use it to start building an understanding of how agents can interact with the system and the states that can evolve over time by randomizing the parameter space (esp overall collateralization levels overtime). Hopefully this will be useful for you as well when doing your tests (as I will post simulation output on github or send it to you directly, whichever you works for you).

I'm talking with the folks at ava-labs and they are working on chainlink feeds now for their c-chain and I told them that btc/usd and eth/usd are ones they should start on first (I see those commented out in your deployer scripts), if there are any more feeds you think people would want to use I can tell them if you tell me.

[cinquemb]

xD

[TCGV]

Hey cinque,

Yesterday I pushed a major refactor in the options liquidation and profits redemption code in the feature/optimization branch:

• Refactoring liquidation/redemption logic

Now the RedeemableToken has a function that receives an account address and redeems his share of profits as exchange balance:

function redeem(address owner) external returns (uint value) {

    address[] memory owners = new address[](1);
    owners[0] = owner;
    value = redeem(owners);
}

Initially I was planning to make these changes in the master branch but their scope turned out larger that I antecipated so I decided to make them in the most up to date branch.

Hope it helps.

[cinquemb]

Hi Thomas,

Awesome! I'm not in a rush for it to be on master, I've only just implemented all the core class/functions that the agents will use (except for the redeem) and now I'm working on getting proper initialization of the feeds, so it will probably be a bit of time before I get to needing this.

[TCGV]

All rigth. And for the purposes of your simulation I guess you can stay in the master branch and use the OptionToken(addr).destroy(); function for now which will liquidate all positions for that token and perform redemption for all holders.

[cinquemb]

Ok cool.

I have a couple questions related to initialization of feeds/settings and the pool:

• It seems like the liquidity pool takes a maturity argument, does this mean for that every different maturity that a writer wants to write an option for, they need to create a pool just for that? I wanted to have agents randomly write options for different maturities (and buyers randomly choose which ones to buy [if they wanted to buy]), so this would be good to know.

• I have historical daily ohlc data for btc usd that i will normalize the first time stamp to be the start time in the evm (which I can fast forward at will). Does this mean that instead of initializing the AggregatorV3Mock of the btcusd with all the data, I should set the data to what it needs to be for the time its at within the evm (i.e. set day 1 data up until then end of day one, then set day 2 data when day 1 crosses over to day 2)?

[TCGV]

Hi Cinque,

does this mean for that every different maturity that a writer wants to write an option for, they need to create a pool just for that?

Not really. The liquidity pool will accept any option (registered for trading by the pool operator by calling the pool's AddSymbol function) whose maturity is inferior to the pool maturity. That's because the pool is also a redeemable token, so all options it trades must expire before the pool maturity/redemption date.

should set the data to what it needs to be for the time its at within the evm?

For the purposes of your simulation I suggest you tweek the EthFeedMock and "inject" it into your deployment, it will make things easier. Then internally you could add a series of if-else conditions based on the blockchain time for returning the appropriate price, or you could set the "current" price at each simulation step by calling the "setPrice" function.

Besides that you'll have to pre-calculate the price volatility as well, and return it in the "getDailyVolatility" function, since it directly affects collateral requirements calculations.

[TCGV]

Hey Cinque,

Also I see the way that you are structuring a symbol, shouldn't there be like a format symbol function that takes the needed parameters and generates this string?

Sure. This function is defined within the OptionsExchange contract, here.

but i'd rather use something closer to what is going to be used live (ChainlinkFeed)

All right. In this case, just be aware that you'll need to call the ChainlinkFeed contract prefetch functions for optimizing gas usage in your simulation (in case gas usage is a concern) when the clock crosses over to the next day:

• First call prefetchDailyPrice passing in the "roundId" of the latest sample you appended to your mock, corresponding to the underlying price for the new day
• Then call prefetchDailyVolatility passing in the volatility period defined in the ProtocolSettings contract (defaults to 90 days)

so is it necessary to add a symbol directly through a pool via addSymbol or must a pool owner then take the symbol generated from the options exchange and call addSymbol if they want a pool for it?

You can simply add the symbol to the pool along with its pricing parameters that when a trader buys from the pool the option token contract will be deployed if it doesn't yet exist. In the optimized code the option token contract is deployed separately from the pool so that a trader doesn't incur the costs of the contract deployment himself.

Either way don't forget that the symbol string added to the pool should exactly match the string that will be generated by the exchange internally when the option token contract gets deployed, otherwise I guess you may end up introducing a bug in your deployment environment due to symbols mismatch.

Also what do these variables mean in the addSymbol function and if they need to be computed, how will they need to be computed (and updated if necessary).

I have described these parameters in my blog (before refactoring the struct for better packing):

• https://thomasvilhena.com/2021/03/a-linear-interpolation-based-liquidity-pool

:)

They define the pricing surface that is interpolated for calculating the option price. It's not trivial to calculate this price surface, I'm using a monte carlo options pricing model for testing it. Do you have any options pricing model implemented in your environment that you can use?

[cinquemb]

Hi Thomas,

All right. In this case, just be aware that you'll need to call the ChainlinkFeed contract prefetch functions for optimizing gas usage in your simulation (in case gas usage is a concern) when the clock crosses over to the next day:

Ok thanks for this, ill do this. And i'll stick to the 90 day lookback for vol (i'll probably need to add more data initially so that this can be computed properly? or will it work with less than 90 days?)

Either way don't forget that the symbol string added to the pool should exactly match the string that will be generated by the exchange internally when the option token contract gets deployed, otherwise I guess you may end up introducing a bug in your deployment environment due to symbols mismatch.

Ok, so i think ill add something like what you do in OptionsExchange.sol in the liquidity pool so that I wont be passing in the symbol directly but by providing the necessary info, it will get generated so that I can avoid any potential issues:

function getOptionSymbol(OrderData memory ord) private view returns (string memory symbol) {
        
        symbol = string(abi.encodePacked(
            UnderlyingFeed(ord.udlFeed).symbol(),
            "-",
            "E",
            ord.option._type == OptionType.CALL ? "C" : "P",
            "-",
            MoreMath.toString(ord.option.strike),
            "-",
            MoreMath.toString(ord.option.maturity)
        ));
    }

They define the pricing surface that is interpolated for calculating the option price. It's not trivial to calculate this price surface, I'm using a monte carlo options pricing model for testing it. Do you have any options pricing model implemented in your environment that you can use?

Ahh ok, yeah that makes sense for t0, t1, x and y (and yeah I do have monte carlo model as well I can use as well). How do you determine buyStock and sellStock though? Also after the curve parameters are added via the addSymbol, how would one go about updating them (I'm assuming i'll need to update them everyday at thee cross over timestamp)?

[TCGV]

i'll probably need to add more data initially so that this can be computed properly? or will it work with less than 90 days?

It won't work with less than the period defined in the ProtocolSettings, which defaults to 90 days.

and yeah I do have monte carlo model as well I can use as well

Cool. In case you need I can share my model with you as well.

How do you determine buyStock and sellStock though?

I'm not following any specific rule. You could define the same limits for all of them. Once the pool detects its "free balance" falls bellow the predefined ratio it will stop writing/selling options independent of the "stock" parameter.

Also after the curve parameters are added via the addSymbol, how would one go about updating them (I'm assuming i'll need to update them everyday at thee cross over timestamp)?

You can call the "AddSymbol" again for updating the parameters for a registered symbol. For the kovan testnet environment I'm updating once per week.

[cinquemb]

It won't work with less than the period defined in the ProtocolSettings, which defaults to 90 days.

Ok this is good to know.

I'm not following any specific rule. You could define the same limits for all of them. Once the pool detects its "free balance" falls bellow the predefined ratio it will stop writing/selling options independent of the "stock" parameter.

Hmm, I'm just trying to figure out how to go about randomly determining the ratio. I think what I'll need to do is first just set the pool (or multiple pools) expiry really long, and then do something like 2:1 sell stock (as well as 1:1: and 1:2 buy stock), but this really needs to be explored more with multiple pools going at the same time. Or am I misinterpreting what you mean by ratio?

You can call the "AddSymbol" again for updating the parameters for a registered symbol. For the kovan testnet environment I'm updating once per week.

Ok, this is good to know as well, Thanks.

[TCGV]

Or am I misinterpreting what you mean by ratio?

The "free balance" ratio I talked about is a parameter that the pool uses for managing its collateral requirements.

In the Kovan testnet environment it's set to 20% which means that if the pool has US$ 100k balance in the exchange it will only write options for selling them to buyers if its balance allocated as collateral is bellow US$ 80k, leaving some margin for oscillations in collateral requirements due to underlying price changes.

This calculation is performed by the calcFreeBalance function and is used for validating buy volumes.