steve0xp/yearn_mellow-gearbox-strategy

yearn strategy depositing vault assets into mellow protocol gearbox strategy(ies)

Welcome!

🙋🏻‍♂️ About Me :

• 🔭 I’m a smart contract dev / dev rel currently with over three years of experience in DeFi full-time. I am currently working full-time on a number of projects (using different github accounts :)). That said, I am always open to meeting more people in the industry so please feel free to reach out to chat! Please inquire for my formal resume :), otherwise here's some details about some of my work / me!
• 🌱 As well, I contributed / contribute to open-source DeFi projects including:
  • Smart Contract Work (Solidity): Yearn strategies && general oracle design
  • Technical Writing: technical threads for Yearn, Balancer, DAO tooling, Subgraphs, && NFTs
  • Developer Advocacy: beginner tutorials & more advanced tutorials about integrating into actual DeFi protocols for BUIDL GUIDL
    • Most recent work is focused on finishing the Scaffold-ETH-DeFi-Challenge-2 revolving around ERC4626 Adaptors with Sommelier and Aura Protocol as an example. I am also working with a handful of other developers on Custom Balancer pool content for Scaffold-Balancer.
• 👨🏻‍💻 Recent public work: Serve as a Balancer Grants Committee member, co-hosted a hackerhouse at EthDenver 2023 with Jessy's Hackerhouse && BUIDL GUIDL, core contributor to Photon, a decentralized stablecoin protocol (see pinned repos && CV Details below for highlights)
• ⚡ Fun facts: I've hitch hiked in Iceland, and was CTO of a hockey equipment startup in the NHL (but can't stop on skates 🤷🏻‍♂️)

---

📜 CV - (newest to oldest, if no README see description)

1. April 2023 - Present: Defi Smart Contracts Contributor && Dev Rel w/ numerous projects

2. January 2023 - April 2023: Yearn Mellow-Gearbox_wETH Strategy

3. January 2023 - Present: Standardized Oracle System - in private repo currently.

• Draft Thread: https://typefully.com/t/yNLqP7A
• Figma: https://www.figma.com/file/cJnuNMpZaU7qto39P8NxR2/Today%27s-Oracle-Design-Flow-Chart-v1?node-id=0%3A1&t=0I5QbBWpBvaO4G6M-1

4. March 2022 - January 2023: Ekonomia Technologies core contributions to Photon Finance Protocol - Smart Contract Development && Partnerships Integration (see architecture schematic & whitepaper here for reference. Highlighted PRs below showcase my past experience in conceptual design, implementation, reviewing, && testing for various contracts:

   • ModuleManager.sol :
     • The Module Manager acted as the intermediary between the Modules and the Kernel.
   • *Genesis TWAP Oracle for stablecoin, governance token, and possibly other modules :
     • Oracle exposed USD/PHO price using v1 Curve PHO/FraxBP Metapool TWAP Pair Oracle && USD PriceFeeds (USD/FRAX && USD/USDC). Initial design was an oracle aggregator w/ built in contingencies for a modular oracle system to be used throughout protocol. It was simplified to carry out an iterative design process.
   • PIDController.sol, Pool.sol, Share.sol inspired from Frax && wrote foundry tests mainly for PIDController.t.sol :
     • Developed the initial conceptual designs of a PID Controller within stablecoin mechanism design for peg control similar to FRAX foundational tech.
   • Liquity Subgraph for Reputation Scoring :
     • Created and deployed the first iteration of the liquity subgraph that follows the "Lending Subgraph Standard" schema. It was meant to be used for a potential reputation scoring system within early iterations of Photon protocol where lending and borrowing rates would differ based on on-chain reputation scores from accrued & ongoing on-chain activity.

5. March 2022 - Pak Subgraph : Implemented my first subgraph whilst thinking about perspective & use cases of end-user.

6. January 2022 - Present BUIDL GUIDL Contributor

*TWAP implementation found not suitable for curve, so implemented other corrections. Spun out to now deeper understanding && research for a generic oracle setup for all protocols to use.

yearn_mellow-gearbox-strategy's Issues

c0.1 - Write Strategy Code && Onboard into Yearn Codebase

• Research the architecture of yearn, mellow, and gearbox first
• Write basic rough draft code for strategy
• Peer review to solidify understanding and next steps to complete strategy implementation code (including writing unit tests at least)

t3.0 - Extra tests (specific to this vault if I don't get them beforehand)

c4.0 - make strategy generic to all mellow strategies

Context: Initially brought up in PR #6 in this thread.

The issue is that the strategy currently will be usable for Mellow Fearless Gearbox Strategies, but may not be usable for other Mellow Vaults and Strategies pre-existing and in the future.

This is possibly not a v1.0 concern for this strategy but it is up for debate and that is why this issue exists for now.

Illiquidity of v1 of this Strategy

This strategy ultimately uses Gearbox protocol but due to the nature of the protocol, credit accounts can only be closed after a fixed period of time, two weeks currently. Gearbox is working on an upgraded version that will eventually add the option of partial withdrawal of funds from its credit accounts, so we will have the opportunity to make the withdrawals instant and in one step (not having restrictions like 1 day).

After this upgrade of Gearbox, Mellow will likely deploy a new vault system for this strategy due to required integration changes to accommodate the new Gearbox protocol version.

dd1.0 - Update due diligence doc

Some things to include:

• Black swan events where Gearbox goes underwater
• " for Mellow

Holistic strategy design wrt to harvestTrigger() conditions & functionality

☑️ Goal: figure out the holistic routing when thinking about the KEEP3R calls and manual calls from vault to strategy.

Started out by thinking about considering having harvestTrigger() have conditional code checking that the period is close to elapsing.

NOTE - this is my simplistic understanding of the harvest() flow:

via harvestTrigger() implementation code, check certain conditions to warrant a harvest() call from a yearn bot. harvest() then pulls at the least the rewards out of the strategy (MellowVault). It does that via registerWithdraw(). The timing would have to be figured out, but ultimately at the end of the period, the Yearn vault would get any requested funds.

Moving onward:

Consider having a bot not call harvest() w/ a nonzero _debtOutstanding unless the vault really needs to access illiquid strategy assets.

This is because of the partial illiquidity due to period duration for underlying Gearbox credit account lifespan. Thus, harvest() would be called to just get accounting, claim rewards, BUT NOT liquidate.

If someone manually calls harvest() w/ a nonzero value for _debtOutstanding, then withdrawSome() would not actually successfully change the balance of want token, all it would do is queue up a withdraw.

• TODO - have talks with Mellow to have them auto-push yearn the withdrawal amount, otherwise, we'll have to have a separate bot claim it or something.

Add `forceHarvestTriggerOnce`

From Val John:

Also, for the harvest triggers, maybe we should consider setting forceHarvestTriggerOnce to true, so it accounts for gas price.

Setting the trigger to true when we want to claim profit, or at least including the basefee in the logic to consider gas price.

c1.0 - Figure out harvesting timing / sequence details wrt to DR (on DR change && to report profit to vault)

Live Notes from Chats with Mellow Team && Val John

• • No difference in when we call registerWithdraw() when it comes to how the period works within MellowStrategy. Thus no need to design harvest() timing around periods really.
• Keep in mind the queued up registeredWithdraws that Yearn already has. That logic matters. Empty out the withdraws before calling registerWithdraw() perhaps? Gotta think about it.

Decide between:

1. Go with typical harvestTriggers() && get possibly incorrect losses or not have them reported due to the async nature of this strategy, OR
2. Prompt harvest() from the SMS (strategist multisig) --> 3/9 multisig of strategists. --> SMS calls harvestTrigger() once && KEEP3Rs harvest() when gas makes sense.

Increasing Capacity or Creating New Mellow Fearless Gearbox Vault/Strategy for Yearn

This is a coordination issue but is very important.

Currently tests use what's likely not going to be the actual smart contracts associated to the true Mellow vault/strategy set. Need to test with actual contracts once they are ready from Mellow protocol

This is because of underflow/overflow issues seen in the most likely candidate for Yearn to deploy funds into:

WETH: 0xa2607696699dbF3c4de584e244f4E3df58cdf69c (partially filled)
USDC: 0x34c277B0c690936168cF436B904B2242a11E7eeA (full)

errors seen with the WETH contract due to (from Dmitriy contributing to Mellow Protocol):

... This turned out about a week ago we forgot to set params.limit so that too much was deposited, so we had to impose it so that it initially holds in this deployment of the strategy that tokenLimit < supply
You may use these addresses for testing (another deployment of the same strategy), it seems limits are set correctly there and I suppose it won't fail there

• Root Vault: 0xD3442BA55108d33FA1EB3F1a3C0876F892B01c44
• ERC20 Vault: 0x27E3E8E275523850236485FE2341e55689a81Bb1
• Gearbox Vault: 0x3e80E11C8fD3e05221fE63BE3487f9f0A4316Dc8

Thus we are using the quoted addresses for tests.

c2.0 - `deposit()` sequence

• Mellow bot monitors new deposits in the Mellow vault and deploys when ready. Will need to do DD on this to see how it does that so we're aware.
• Possibly monitor our active assets under management everytime we deposit() by reading the Gearbox contracts

c3.0 - estimatedTotalAssets() details

See PR #6 comments - https://github.com/umphams/yearn_mellow-gearbox-strategy/pull/6/files/80f3c9cc17bda4c7d880929d7447e42f8e119369#r1096589332

In particular (tldr);

All in all, we'd want estimatedTotalAssets() to check these other possible spots for wantToken even if the usual patterns from keep3rs or the sms or accounting is supposed to result in most of these areas depleted of wantTokens.

Where does the strategy measure health metrics from: Yearn (internal calcs), Mellow, or Gearbox?

Bot monitoring: It is important to be aware of the health factor of the actual strategy, but are we trusting these metrics based on:

1. Mellow metrics - their system where they use Marginal Factor Balance & State checks?
2. Gearbox metrics - health factors for specific credit accounts?
3. Yearn own metrics - health bots querying blockchain to see value of assets based off of converting assets in open strategy positions & other internal math

Context:

• Mellow uses M*x as the Marginal Factor Balance that is strives to have. Basically M is the marginal factor, x is the total USD for assets in a strategy. Rebalancing occurs to ensure that this is in a healthy state, defined by the strategist I think.
• Gearbox monitoring: view functions available to see total && twv && hf. Yearn could check the hf directly for the mellow-gearbox credit account and gauge if they want to withdraw or not based on this and any other internal aspects (perhaps Yearn has its own way of calculating the hf with it's own twv calculation. --> ex. I'm not sure how the max price drop during liquidation is calculated in gearbox.

function calcTotalValue(address creditAccount)
        external
        view
        returns (uint256 total, uint256 twv);

&&

function calcCreditAccountHealthFactor(address creditAccount)
        external
        view
        returns (uint256 hf);
```

t1.0 - Unit tests: ensure strategy performs w/ unit tests

• Go one by one on tests, make traces single

m1.0 - Set up yearn monitoring to be direct to source (Gearbox)

• margin factor / health factor of entire position so we know even if Mellow's bots don't catch it for some reason.
  • Use cronJob

Auto-Compounding Frequency (Reinvesting Yields)

Are we interested in tend() for this strategy, whether it be through the Yearn strategy or the underlying Mellow strategy?

Context

Style of accounting of all LPTs involved with the Mellow Strategy affects rewards timing

• if Mellow does not reward earlier LPs for the Mellow strategy per period, similar to masterChef style contracts, this effects how Yearn will time its investments into the strategy possibly.
• This is only if Yearn wants to be strategic with its liquid assets in other strategies, and can wait and see what the APY is on a specific period within this strategy and wait til the last moment to invest in the already of credit account. ** tbh this seems like something that should not be allowed in the Mellow Strategy**

There are a number of different paths to take and I hope for discussion here to outline any incorrect assumptions, misunderstandings, and progress with a solid design path for this strategy.

---

Detailed Context

This is just me thinking out some of the research I have done regarding Mellow's strategy && the Yearn UX:

Details:

1. Every period, yearn bots would get harvestTrigger() to return true if:
   1. period is about to be done, or
   2. stopLoss hit, or
   3. rewardsClaim >> gasRequired (so taking profits makes sense && possibly reinvesting them depending on Vault’s debt allowance to strategy).

Mellow Side:

So how does auto-compounding and rebalancing work for this strategy? Context of how the Mellow Fearless Gearbox Strategy works:

1. Yearn provides liquidity to Mellow Vault for Fearless wETH Gearbox Strategy
2. Mellow allocates liquidity in already open credit account, or new credit account depending on date respective to credit account periods (2 weeks typically)
3. Mellow has bots monitoring Margin Factors for the Gearbox strategies. It rebalances via adding to its credit account leverage position (lowering gearbox health factor), or removing (increasing gearbox health factor)
   1. Their take on Health Factor imo. Gearbox has health factors, that I think should still be monitored.
   2. Margin Factor, M > 1. So M * x is the equilibrium state that Mellow strives for in their Gearbox credit account.
      1. ex.) If M = 1.5, then if CreditAccountAssets_State = 1.25x, then Mellow adjustPosition() to get more leverage in Gearbox credit account and integrate with curve/convex adaptors.
         1. This rebalances wrt to market prices for collateral vs leveraged tokens
            • Say if collateral token prices went up, but leveraged token prices did not, then there is more collateral and more debt to be taken out to reach equilibrium.

• Question: Does it auto-compound claimed rewards in this sequence?

  1. Couldn’t you make conditional statements to have this happen? NOTE: These are generic function names, not actual ones.

     if(claim >= autoCompoundGasCost) { 
     
      claimRewards(); // claim 
      checkHealthFactor(); // some kind of helper function checking how hf is && if it can reinvest this yield
      adjustPosition(); // puts primaryToken into adaptor protocol within Gearbox (Curve/Convex in this case)
     
     }

t2.0 - Integration Tests: ensure vault and other yearn tests work

Set Up 1-Tx Withdrawals

The current Mellow "Fearless Gearbox Strategies" setup involves LPs carrying out two txs to get liquidity out.
a. First tx: registerWithdraw() where withdraw is recorded and accommodated once the current two-week period ends.
b. Second tx: user calls withdraw() to take the requested funds out of the strategy in the first place.

Possible solutions include:

1. Make a whitelist of addresses (where we can add addresses needed for Yearn) where Mellow is able to send funds automatically after the closing of gearbox credit accounts.
2. Have Keep3rs listen for the transference of funds IF our vault is waiting for funds from this strategy.

NOTE: This issue is only pressing if there are large allocations of Yearn’s wETH vault to this strategy. Initially, this strategy will have lower allocations relative to other battle-tested strategies. Thus this issue can be put on the back burner for now.