-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add october 17th, 2024 spell and tests #55
base: master
Are you sure you want to change the base?
Conversation
.github/workflows/test.yml
Outdated
@@ -40,7 +40,7 @@ jobs: | |||
BASE_RPC_URL: ${{secrets.BASE_RPC_URL}} | |||
GOERLI_RPC_URL: ${{secrets.GOERLI_RPC_URL}} | |||
run: | | |||
forge test -vvv | |||
forge test -vvv --evm-version cancun |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This flag was added based on this open issue in foundry.
We can remove it but we would need to remove the tests for the price of the pt token oracles.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did initial review:
- URLs LGTM
- Addresses good except PT price feeds, still need to figure out where those came from
- sUSDS onboarding LGTM (besides seeding)
- sDAI oracle update LGTM
- WBTC changes LGTM
- First pass review of PTs (need to revisit)
- First pass review of tests
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
spell
couldn't understand the pendle price oracle setup, would like to do so before approving
the rest of the spell looks good to me, see checklist below (feedback of course welcome on if I'm missing any item)
tests
I only performed a superficial review of the tests, will give them another look tomorrow!
checklist
- sUSDS listing
- sUSDS oracle returns 1* sUSDS pot chi
- sUSD onboard params match the forum post
- no borrowing
- suppy cap gradual increase
- sUSDS deposit
- sDAI pricefeed update
- sDAI oracle returns 1 * sDAI pot chi
- Pendle onboarding
- december
- token address is correct
- pricefeed is correct -- does consider 15%ytm
- other params
- march
- token address is correct
- pricefeed is correct -- does consider 20%ytm
- other params
- december
- WBTC collateral
- LLTV update
- borrow cap update
- supply cap update
|
||
address internal constant SDAI_PRICE_FEED = 0x0c0864837C7e65458aCD3C665222203217019436; | ||
|
||
address internal constant PT_26DEC2024_PRICE_FEED = 0x81E5E28F33D314e9211885d6f0F4080E755e4595; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see this oracle mocks a chainlink pricefeed which composeds with the newly-deployed pricefeed cited in the post
I verified the latter has a correct implementation & deploy params, however I don't understand what purpose it serves and can't find where Pendle published them 👉 👈
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I looked deeper into this and it looks like the MorphoChainlinkOracleV2
is only scaling the return of the PendleSparkLinearDiscountOracle
up to 36 decimals.
This strikes me as sub-optimal, since we could be either
- using the oracle composition to consider both the discounted price of the PT and the market usd value of the collateral (although iirc risk already mentioned we are okay with assuming USDe value to always be 1)
- using the
PendleSparkLinearDiscountOracle
directly, if it returned 36 decimals, and save an external call
this is a nitpick and should't block the PR, however I'd be glad to be corrected if I misunderstood any of the above 😁
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
changeset looks good to me (checklist below)
only actionable (albeit minor and non-blocking) items are
- set the evm version in
foundry.toml
to have consistency between ci and local test execution if we dont revert the changes to ci in the future - extra assertion on oracle prices after maturity to remain at 1
checklist:
- sUSDS listing
- sUSDS oracle returns 1* sUSDS pot chi
- sUSD onboard params match the forum post
- no borrowing
- suppy cap gradual increase
- sUSDS deposit
- sDAI pricefeed update
- sDAI oracle returns 1 * sDAI pot chi
- Pendle onboarding
- december
- token address is correct
- pricefeed is correct -- does consider 15%ytm (possible optimization)
- other params
- march
- token address is correct
- pricefeed is correct -- does consider 20%ytm (possible optimization)
- other params
- december
- WBTC collateral
- LLTV update
- borrow cap update
- supply cap update
assertEq(IMorphoChainlinkOracle(PT_26DEC2024_PRICE_FEED).price(), 1e36); | ||
|
||
vm.warp(IMorphoPT(PT_SUSDE_27MAR2025).expiry()); | ||
assertEq(IMorphoChainlinkOracle(PT_27MAR2025_PRICE_FEED).price(), 1e36); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
non-blocking, but a test ensuring that prices remain at one past maturity can't hurt
|
||
address internal constant SDAI_PRICE_FEED = 0x0c0864837C7e65458aCD3C665222203217019436; | ||
|
||
address internal constant PT_26DEC2024_PRICE_FEED = 0x81E5E28F33D314e9211885d6f0F4080E755e4595; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I looked deeper into this and it looks like the MorphoChainlinkOracleV2
is only scaling the return of the PendleSparkLinearDiscountOracle
up to 36 decimals.
This strikes me as sub-optimal, since we could be either
- using the oracle composition to consider both the discounted price of the PT and the market usd value of the collateral (although iirc risk already mentioned we are okay with assuming USDe value to always be 1)
- using the
PendleSparkLinearDiscountOracle
directly, if it returned 36 decimals, and save an external call
this is a nitpick and should't block the PR, however I'd be glad to be corrected if I misunderstood any of the above 😁
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All questions were answered and the report is attached below.
17 Oct 2024 - Before Deployment.pdf
b0b0315
// assertEq(ptUsde26DecPrice, 0.969105874238964993e36); | ||
// assertEq(ptUsde27MarPrice, 0.908944818619989853e36); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Update to (commented out)
assertEq(ptUsde26DecPrice, 0.970544002092846271e36);
assertEq(ptUsde27MarPrice, 0.910862322425164891e36);
And add a note // NOTE: Can run this test individually after commenting out these assertions with forge t --mt testMorphoVaults -vvv --evm-version cancun
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
verified compiled smart contract is the same, with bytecode differences caused by the change in compiler version only
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
after looking into it in a bit more detail, I believe we should actually be forcing the evm version to cancun, since it's the spec under which both gnosis and mainnet will run the spells. If foundry chooses to use a different hardfork, it's actually reducing the usefulness of our tests. this also has the benefit of allowing all of the tests defined herein to pass, and a smaller spell bytecode I propose we set I still can't explain why foundry is choosing to use anything other than cancun when not forced to, since since the spells are equivalent, this does not block execution and could be implemented in a subsequent PR if the timeline requires it |
@0xteddybear even though I think that at some point we will be using cancun by default, the execution team doesn't want to make the change now and they want to use when it's fully default and supported for everything |
https://forum.sky.money/t/oct-3-2024-proposed-changes-to-spark-for-upcoming-spell/25293