Lido

[JTraversa]

We had commented out Lido for some later considerations awhile back, and never re-introduced it.

Its 100% worth taking the bit of time to add Lido and ensure we're good to go for the next year or so.

That said, we need to address the three interfaces for integrations:

1. deposit -- wrap
2. withdraw -- unwrap
3. exchangeRate -- getStETHByWstETH

Alex generally likes having supplyRatePerBlock to calculate APY as well, but I'm fairly sure that supplyRate will be extremely difficult to extrapolate. Its easy enough now, but varies based on tips/MEV post merge...

Other notes:

The underlying is not ETH or WETH, but stETH for wstETH.

So we can assume users have stETH ahead of time, or can write a wrapper that converts ETH->stETH through curve?

[robrobbins]

1. i'll start on the integrations
2. worry about supplyRate in a sep thing

[JTraversa]

ah and for the underlying in one of those compounding libs, it can be hardcoded to 0xae7ab96520de3a18e5e111b5eaab095312d7fe84 (stETH)

[robrobbins]

oh, ic. ok. lemme look at the best place for that.

was just reading the whole:

_stETHAmount must be non-zero
msg.sender must approve at least _stETHAmount stETH to this contract.
msg.sender must have at least _stETHAmount of stETH.```

for wrap...