Skip to content
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

Open
wants to merge 12 commits into
base: master
Choose a base branch
from
Open

Conversation

0xShaito
Copy link
Collaborator

@0xShaito 0xShaito commented Oct 9, 2024

  • [Mainnet] Onboard sUSDS into SparkLend as collateral-only
  • [Mainnet] Update sDAI oracle to use fixed DAI/USD at $1
  • [Mainnet] Onboard PT-sUSDe-26Dec2024 and PT-sUSDe-27Mar2025 to Morpho Spark DAI vault
  • [Mainnet] Delayed WBTC Changes

https://forum.sky.money/t/oct-3-2024-proposed-changes-to-spark-for-upcoming-spell/25293

Copy link

github-actions bot commented Oct 9, 2024

Spell Caster

Inspect the impact of spell execution on forked networks:

Spell App URL RPC URL
SparkEthereum_20241017 🎇 App 🌎 RPC

Deployed from b3ecb90 on 2024-10-14T15:41:30.370Z

@@ -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
Copy link
Collaborator Author

@0xShaito 0xShaito Oct 9, 2024

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.

Copy link
Contributor

@lucas-manuel lucas-manuel left a 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

src/proposals/20241017/SparkEthereum_20241017.t.sol Outdated Show resolved Hide resolved
src/proposals/20241017/SparkEthereum_20241017.t.sol Outdated Show resolved Hide resolved
src/proposals/20241017/SparkEthereum_20241017.sol Outdated Show resolved Hide resolved
Copy link
Collaborator

@0xteddybear 0xteddybear left a 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
  • 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;
Copy link
Collaborator

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 👉 👈

Copy link
Collaborator

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 😁

0xteddybear
0xteddybear previously approved these changes Oct 11, 2024
Copy link
Collaborator

@0xteddybear 0xteddybear left a 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
  • 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);
Copy link
Collaborator

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;
Copy link
Collaborator

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 😁

lucas-manuel
lucas-manuel previously approved these changes Oct 11, 2024
RedLikeRosesss
RedLikeRosesss previously approved these changes Oct 11, 2024
Copy link
Collaborator

@RedLikeRosesss RedLikeRosesss left a 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

0xteddybear
0xteddybear previously approved these changes Oct 11, 2024
Comment on lines 227 to 228
// assertEq(ptUsde26DecPrice, 0.969105874238964993e36);
// assertEq(ptUsde27MarPrice, 0.908944818619989853e36);
Copy link
Contributor

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

Copy link
Collaborator

@0xteddybear 0xteddybear left a 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

Copy link
Collaborator

@RedLikeRosesss RedLikeRosesss left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@0xteddybear
Copy link
Collaborator

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 evmVersion = 'cancun' in foundry.toml and set the payload back to 0x74b3D0E74f2711f30442536832D7fBCB0F42C195

I still can't explain why foundry is choosing to use anything other than cancun when not forced to, since solc version is pinned to 0.8.25, for which the default hardfork is cancun, and as reported in the issue linked in the diff: foundry-rs/foundry#6228 (comment) , foundry's execution environment defaults to the hardfork the contracts were compiled for.

since the spells are equivalent, this does not block execution and could be implemented in a subsequent PR if the timeline requires it

@0xShaito
Copy link
Collaborator Author

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants