lazer/sui: Update V2 API#3680
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
dbdf251 to
762ae1e
Compare
762ae1e to
3ad7d76
Compare
| let update = parse_and_verify_le_ecdsa_update_v2(&state, &clock, TEST_LAZER_UPDATE); | ||
|
|
||
| // If we reach this point, the function successfully verified & parsed the payload (no assertion failures) | ||
| // Validate that the fields have correct values | ||
| assert_eq!(update.timestamp(), 1771252161800000); | ||
| assert!(update.channel().is_fixed_rate_200ms()); |
There was a problem hiding this comment.
Can we use a fixed_rate@1000ms update in this test to validate that ChannelV2 works?
There was a problem hiding this comment.
Sure, will do 👍
| tx.pure.vector("u8", update), | ||
| ], | ||
| target: `${id}::pyth_lazer::parse_and_verify_le_ecdsa_update`, | ||
| target: `${id}::pyth_lazer::parse_and_verify_le_ecdsa_update_v2`, |
There was a problem hiding this comment.
🚩 SDK breaking change: return type changes from update::Update to update_v2::Update
The SDK function addParseAndVerifyLeEcdsaUpdateCall at lazer/contracts/sui/sdk/js/src/index.ts:18 now calls parse_and_verify_le_ecdsa_update_v2 instead of parse_and_verify_le_ecdsa_update. This changes the on-chain return type from pyth_lazer::update::Update to pyth_lazer::update_v2::Update. Any existing deployed consumer smart contracts that accept update::Update as a parameter will fail at transaction execution time when used with the updated SDK, because the types are incompatible on-chain. The package version at lazer/contracts/sui/sdk/js/package.json:59 remains 0.3.0 and was not bumped despite this being a breaking change. Per REVIEW.md guidelines, public packages with changes should have their version bumped — suggest a minor bump to 0.4.0 (since semver 0.x allows breaking changes in minor versions).
Was this helpful? React with 👍 or 👎 to provide feedback.
Summary
Adds V2 version of API, including support for
fixed_rate@1000mschannel ID.Rationale
As we need to extend
Channeltype to support the new variant, and it is currently a Sui enum, we will need to release a new API alongside the existing one to pass upgrade checks on-chain. To avoid the same problem in the future, newChanneltype is a wrapped integer, followingMarketSessionconvention. Old API will be deprecated, moving as much internal logic into V2 as possible.Notes
At some point we may decide to replace V1 exports with failing stubs, but right now we'll keep supporting existing contracts that use V1. In case of future redeploy, we should use the opportunity to remove old API completely.
TODOs
How has this been tested?