chore: add comments on things that seem redundant or incorrect#32
chore: add comments on things that seem redundant or incorrect#32
Conversation
| // Amount locked for scheduled withdrawals last week; | ||
| uint128 public lastQueuedWithdrawAmount; | ||
| // % of funds to be used for weekly option purchase | ||
| // TODO: Do we need this? |
There was a problem hiding this comment.
We dont need it, unless we introduce a limit on number of amount of options sold and have this to be upgradable. Idea is to start the system slowly and lift limitation with time
There was a problem hiding this comment.
Right, but does not vault cap solve this?
There was a problem hiding this comment.
Yes you are right, since we have one strategy per vault
| uint maxDeltaGap; // 5% ? | ||
| uint minVol; // 80% | ||
| uint maxVol; // 130% | ||
| // TODO: Do we need this? |
There was a problem hiding this comment.
we dont use maxVol, we can get rid of it
There was a problem hiding this comment.
we also dont really use size, we can refactor the code
| uint maxVol; // 130% | ||
| // TODO: Do we need this? | ||
| uint size; // 15 | ||
| // TODO: This we don't use as of now. Maybe we should consider. TBC |
There was a problem hiding this comment.
We dont use it too, Im still reviewing my finance courses might have an input on that later
| HackMoneyStrategyDetail public strategyDetail; | ||
| uint public activeExpiry; | ||
| uint public currentBoardId; | ||
| // TODO: Should we move this into strategy details |
| // update active strikes | ||
| _addActiveStrike(strike.id, result.positionId); | ||
|
|
||
| // TODO: Remove this check as well? |
There was a problem hiding this comment.
I think this is redundant if we specify the minExpectedPremium inside the openPosition, the OptionMarket does _checkCostInBounds
| /** | ||
| * @dev use premium in strategy to reduce position size if collateral ratio is out of range | ||
| */ | ||
| // TODO: Remove this |
There was a problem hiding this comment.
Is there any cases where we would want to reduce position? In the current definition of strategy Id say no, but would it be an "emergency" case where we would want to get out?
There was a problem hiding this comment.
What is this "emergency" case? We might want to stop most of the actions and let users withdraw assets
There was a problem hiding this comment.
yes that's something to think about later, maybe worth checking what's the security measures of Ribbon
| * @param collateralToLock collateral available to lock. | ||
| * @return size how many options we can sell. | ||
| */ | ||
| // TODO: Never used. Remove? |
There was a problem hiding this comment.
this one was used for _getRequiredCollateral in case we trade different type of options. For the current strategy not useful we can drop
| // uint exchangeValue | ||
| ) = strategy.doTrade(size); | ||
| // update the remaining locked amount | ||
| // TODO: This might be fucked up as capitalUsed now returns total sum with premiums exchanged. I still need to have amount we have been able to get from exchange as I need to display this in the UI |
There was a problem hiding this comment.
Yes need correction, return one more variable
|
|
||
| strategy.setBoard(boardId); | ||
|
|
||
| // FIXME: Do we have tests for this? |
There was a problem hiding this comment.
Not really, once we have the script with the fork we can test the whole work flow for one week
| lastQueuedWithdrawAmount = uint128(queuedWithdrawAmount); | ||
| emit RoundStarted(vaultState.round, uint104(lockedBalance)); | ||
|
|
||
| // TODO: should we use lockedAmount? |
There was a problem hiding this comment.
they are the same at this moment, i dont see the difference?
| } | ||
|
|
||
| // helper to set strategy size | ||
| // TODO: Do we need this? |
There was a problem hiding this comment.
do you need it for the UI? Could also need it for trading to know how much we still can trade
There was a problem hiding this comment.
We can get it from subgraph easily
| * @dev verify if the strike is valid for the strategy | ||
| * @return isValid true if vol is withint [minVol, maxVol] and delta is within targetDelta +- maxDeltaGap | ||
| */ | ||
| // TODO: Remove as never used or use in the code |
| /** | ||
| * @dev check if the vol variance for the given strike is within certain range | ||
| */ | ||
| // TODO: Remove as never used |
| secondsToExpiry <= strategyDetail.maxTimeToExpiry); | ||
| } | ||
|
|
||
| // TODO: Think how to handle dynamic fees of synthetix not to sell cheap.. https://blog.synthetix.io/dynamic-exchange-fees-explained/ |
There was a problem hiding this comment.
I dont think this is an issue, we use Synthetix to exchange premiums. Premiums are small portion of the notional and fees on exchanging premiums is a small portion of premiums, a max of 0.3% rare difference on premiums will not hurt in my opinion. Besides we are trading eth/usd which is not subject to high volatility compared to other markets. However Ill check, maybe we set a max fee to accept say 0.25%?
There was a problem hiding this comment.
Maybe we can have max slippage specified in the contract
There was a problem hiding this comment.
Synthetix have 0 slippage, see https://docs.synthetix.io/litepaper/#system-architecture (cmd+F 'slippage'), only trading fees are paid.
There was a problem hiding this comment.
Yep, but that's what I refer. We can have slippage that would be reflecting fees that we have paid
Baraa42
left a comment
Baraa42
left a comment
There was a problem hiding this comment.
Commented on your notes, let me know when you open tickets
2 participants
No description provided.