upgrade contract anchor version to 0.31.1 #1081

jshiohaha · 2025-10-01T19:03:42Z

Description

Upgrade Anchor to 0.31.1 and relevant dependencies. Anchor changelog here: https://www.anchor-lang.com/docs/updates/changelog
- Notably, discriminator() was removed in favor of ::DISCRIMINATOR which is a variable slice because discriminators can of length != 8 now. Most changes are related to this.
- 💡 I didn't add yet, but I thought it might be useful to have tests to validate each account's discriminator bytes match what we currently have? By default, Anchor will use the legacy 8 byte discriminators, but it might be a useful sanity check. I saw we have 1 existing discriminator test.
Please see other in-line comments related to relevant changes

Proposed PR process

There are a lot of changes related to this upgrade (>100 files). My plan is to split up the changes into smaller PRs, and merge everything into TKN-700/base. After each PR has been reviewed, approved, and merged into the base branch, we can easily merge into main.

Testing

✅ Build program: anchor build -p whirlpool
✅ Unit tests: cargo test -p whirlpool --lib
✅ Anchor integration & sdk tests: anchor test --run anchor_tests/int/* and anchor test --run anchor_tests/sdk/*
- NOTE: these tests were run across the collective changes to all whirlpools packages. More details on the tests themselves will be included in the PR for legacy-sdk: update legacy-sdk #1088

jshiohaha · 2025-10-01T19:04:31Z

programs/whirlpool/src/auth/admin.rs

@@ -1,5 +1,5 @@
 use anchor_lang::prelude::*;
-use anchor_lang::solana_program::pubkey;


It seems like most places we rely directly on our pinned version of solana-program. If this import was intentional, I will revert.

Do we really need solana_program as a separate dependency if anchor already exposes solana_program? Can we get rid of the direct solana_program dep if we use anchor_lang::solana_program everywhere?

At first I removed the direct dependency, but then I figured there was a specific reason we had it. In the spirit of making as few changes as possible, I kept the direct dependency. I'm happy to remove if there's no issue.

Don't think it matters that much, deps such as spl-token also still require solana-program and the version needs to be in sync between all the deps. Let's just keep it like it is in this PR and not bother as it won't benefit us much

+1 for removing direct dep on solana_program, but also agree that it should be handled in another PR to reduce diffs.

Could I ask what is "a specific reason we had it".

Could I ask what is "a specific reason we had it".

I'm not sure, to be honest. But since I haven't worked on Whirlpools before, I didn't want to just remove without first confirming there is no issue with doing so.

Since I removed spl-token and spl-token-metadata-interface, what do you think about just removing solana-program now? I'm fine to leave as-is, but it could be convenient to just yank it now.

jshiohaha · 2025-10-01T19:07:11Z

programs/whirlpool/package.json

  "version": "0.6.0",
  "scripts": {
-    "build": "RUSTUP_TOOLCHAIN=1.78.0 anchor build -p whirlpool",
+    "build": "anchor build -p whirlpool",


I could not get RUSTUP_TOOLCHAIN=1.xx.xx anchor build -p whirlpool to work. I tried many different versions of the rust toolchain and directly compared against my local toolchain. Even when using the same version, I got the error below. I tried troubleshooting for a while but ultimately decided to just open the PR and get feedback on this proposed update.

Error

error[E0277]: the trait bound `PacketFlags: Deserialize<'_>` is not satisfied --> /Users/jacobshiohira/.cargo/registry/src/index.crates.io-6f17d22bba15001f/solana-packet-2.1.0/src/lib.rs:51:38 | 51 | #[cfg_attr(feature = "serde", derive(Deserialize, Serialize))] | ^^^^^^^^^^^ the trait `Deserialize<'_>` is not implemented for `PacketFlags` | = note: for local types consider adding `#[derive(serde::Deserialize)]` to your `PacketFlags` type = note: for types from other crates check whether the crate offers a `serde` feature flag = help: the following other types implement trait `Deserialize<'de>`: &'a Path &'a [u8] &'a str () (T,) (T0, T1) (T0, T1, T2) (T0, T1, T2, T3) and 147 others note: required by a bound in `next_element` --> /Users/jacobshiohira/.cargo/registry/src/index.crates.io-6f17d22bba15001f/serde-1.0.213/src/de/mod.rs:1732:12 | 1730 | fn next_element<T>(&mut self) -> Result<Option<T>, Self::Error> | ------------ required by a bound in this associated function 1731 | where 1732 | T: Deserialize<'de>, | ^^^^^^^^^^^^^^^^ required by this bound in `SeqAccess::next_element` = note: this error originates in the derive macro `Deserialize` (in Nightly builds, run with -Z macro-backtrace for more info) error[E0277]: the trait bound `PacketFlags: Deserialize<'_>` is not satisfied --> /Users/jacobshiohira/.cargo/registry/src/index.crates.io-6f17d22bba15001f/solana-packet-2.1.0/src/lib.rs:51:38 | 51 | #[cfg_attr(feature = "serde", derive(Deserialize, Serialize))] | ^^^^^^^^^^^ the trait `Deserialize<'_>` is not implemented for `PacketFlags` | = note: for local types consider adding `#[derive(serde::Deserialize)]` to your `PacketFlags` type = note: for types from other crates check whether the crate offers a `serde` feature flag = help: the following other types implement trait `Deserialize<'de>`: &'a Path &'a [u8] &'a str () (T,) (T0, T1) (T0, T1, T2) (T0, T1, T2, T3) and 147 others note: required by a bound in `next_value` --> /Users/jacobshiohira/.cargo/registry/src/index.crates.io-6f17d22bba15001f/serde-1.0.213/src/de/mod.rs:1871:12 | 1869 | fn next_value<V>(&mut self) -> Result<V, Self::Error> | ---------- required by a bound in this associated function 1870 | where 1871 | V: Deserialize<'de>, | ^^^^^^^^^^^^^^^^ required by this bound in `MapAccess::next_value` = note: this error originates in the derive macro `Deserialize` (in Nightly builds, run with -Z macro-backtrace for more info) error[E0277]: the trait bound `PacketFlags: Serialize` is not satisfied --> /Users/jacobshiohira/.cargo/registry/src/index.crates.io-6f17d22bba15001f/solana-packet-2.1.0/src/lib.rs:51:51 | 51 | #[cfg_attr(feature = "serde", derive(Deserialize, Serialize))] | ^^^^^^^^^ the trait `Serialize` is not implemented for `PacketFlags` | = note: for local types consider adding `#[derive(serde::Serialize)]` to your `PacketFlags` type = note: for types from other crates check whether the crate offers a `serde` feature flag = help: the following other types implement trait `Serialize`: &'a T &'a mut T () (T,) (T0, T1) (T0, T1, T2) (T0, T1, T2, T3) (T0, T1, T2, T3, T4) and 133 others note: required by a bound in `_::_serde::ser::SerializeStruct::serialize_field` --> /Users/jacobshiohira/.cargo/registry/src/index.crates.io-6f17d22bba15001f/serde-1.0.213/src/ser/mod.rs:1867:21 | 1865 | fn serialize_field<T>(&mut self, key: &'static str, value: &T) -> Result<(), Self::Error> | --------------- required by a bound in this associated function 1866 | where 1867 | T: ?Sized + Serialize; | ^^^^^^^^^ required by this bound in `SerializeStruct::serialize_field` = note: this error originates in the derive macro `Serialize` (in Nightly builds, run with -Z macro-backtrace for more info) For more information about this error, try `rustc --explain E0277`. error: could not compile `solana-packet` (lib) due to 5 previous errors

programs/whirlpool/src/math/bn.rs

jshiohaha · 2025-10-01T19:10:24Z

programs/whirlpool/src/state/mod.rs

 pub use tick_array::*;
 pub use token_badge::*;
-pub use zeroed_tick_array::*;
+pub(crate) use zeroed_tick_array::*;


from compiler warning

Compiling whirlpool v0.6.0 (/Users/jacobshiohira/projects/solana/orca/whirlpools/programs/whirlpool) warning: glob import doesn't reexport anything with visibility `pub` because no imported item is public enough --> programs/whirlpool/src/state/mod.rs:31:9 | 31 | pub use zeroed*tick_array::*; | ^^^^^^^^^^^^^^^^^^^^ | note: the most public imported item is `pub(crate)` --> programs/whirlpool/src/state/mod.rs:31:9 | 31 | pub use zeroed*tick_array::*; | ^^^^^^^^^^^^^^^^^^^^ = help: reduce the glob import's visibility or increase visibility of imported items = note: `#[warn(unused_imports)]` on by default

wjthieme · 2025-10-02T19:21:04Z

💡 I didn't add yet, but I thought it might be useful to have tests to validate each account's discriminator bytes match what we currently have? By default, Anchor will use the legacy 8 byte discriminators

Would be great to add this as a regression test. Can you do in a separate PR (we can merge that directly into main before merging this)

wjthieme

Awesome! Couple small remarks but the gist LGTM

wjthieme · 2025-10-02T19:22:13Z

programs/whirlpool/src/auth/admin.rs

@@ -1,5 +1,5 @@
 use anchor_lang::prelude::*;
-use anchor_lang::solana_program::pubkey;


Do we really need solana_program as a separate dependency if anchor already exposes solana_program? Can we get rid of the direct solana_program dep if we use anchor_lang::solana_program everywhere?

programs/whirlpool/src/math/bn.rs

Cargo.toml

yugure-orca · 2025-10-03T01:25:47Z

programs/whirlpool/src/util/token_2022.rs

        StateWithExtensions::<spl_token_2022::state::Mint>::unpack(&token_mint_data)?;
    let new_account_len = token_mint_unpacked
-        .try_get_new_account_len::<spl_token_metadata_interface::state::TokenMetadata>(&metadata)?;
+        .try_get_new_account_len_for_variable_len_extension::<spl_token_metadata_interface::state::TokenMetadata>(&metadata)?;


memo: breaking change on spl-token-2022-1.0.0 (0.9.0 -> 1.0.0)

Noted, thank you! Is there a change you are requesting as a result of this?

ah sorry, this is not change request. I believe your update is correct of course.
Just a memo for reviewers. 😅

Haha ok, no worries! I just wanted to make sure that I didn't miss any change requests. I really appreciate the comment - I think more context is always helpful 🙌

yugure-orca · 2025-10-03T02:04:10Z

Based on slack logs, I believe you've already done anchor test.
Could you add anchor test on Testing section of PR comment ?

yugure-orca

I think removing direct deps on spl-token and spl-token-metadata-interface is possible in thie PR because the changes are very small (~10 lines only)

programs/whirlpool/Cargo.toml

yugure-orca · 2025-10-03T02:06:36Z

programs/whirlpool/src/auth/admin.rs

@@ -1,5 +1,5 @@
 use anchor_lang::prelude::*;
-use anchor_lang::solana_program::pubkey;


+1 for removing direct dep on solana_program, but also agree that it should be handled in another PR to reduce diffs.

Could I ask what is "a specific reason we had it".

yugure-orca · 2025-10-03T02:13:49Z

Integration tests (anchor tests) check all instructions, and since the changes aren’t that many, I think it should be fine. But in the end, I’d like to build more confidence by running a regression test that executes a few days’ worth of transactions with both the current binary (v0.29.0) and the new binary (v0.31.1).

https://github.com/orca-so/whirlpool-tx-replayer/tree/main/whirlpool-regression-test-command

whirlpool-regression-test <archive storage path> <date to replay> whirlpool_anchor0290.so whirlpool_anchor0311.so

jshiohaha · 2025-10-03T02:27:34Z

Based on slack logs, I believe you've already done anchor test. Could you add anchor test on Testing section of PR comment ?

Yes, I think that makes sense. I didn't originally add it since these tests depend on some changes in legacy-sdk, but I think it makes sense to assert that I did run those tests even if the changes are part of a different PR. I will also link that PR once it's up 🔗

jshiohaha · 2025-10-03T02:29:10Z

Integration tests (anchor tests) check all instructions, and since the changes aren’t that many, I think it should be fine. But in the end, I’d like to build more confidence by running a regression test that executes a few days’ worth of transactions with both the current binary (v0.29.0) and the new binary (v0.31.1).

https://github.com/orca-so/whirlpool-tx-replayer/tree/main/whirlpool-regression-test-command
whirlpool-regression-test <archive storage path> <date to replay> whirlpool_anchor0290.so whirlpool_anchor0311.so

Ooh, I didn't realize this testing tool existed - thank you for linking! I will look into this and follow up with results 🗒️

Update: what a cool tool! I got this working, currently running the command against 10/01 transactions and will go from there.

jshiohaha · 2025-10-03T04:37:59Z

programs/whirlpool/Cargo.toml

-arrayref = { version = "=0.3.8" }
-borsh09 = { package = "borsh", version = "=0.9.3" }
+arrayref = { version = "=0.3.9" }
+borsh = { version = "=0.10.3" }


It seems like we no longer need a separate borsh import after removing impl_borsh_serialize_for_bn and impl_borsh_deserialize_for_bn. If there are no concerns, I can remove this dependency as well.

jshiohaha · 2025-10-07T19:59:54Z

Integration tests (anchor tests) check all instructions, and since the changes aren’t that many, I think it should be fine. But in the end, I’d like to build more confidence by running a regression test that executes a few days’ worth of transactions with both the current binary (v0.29.0) and the new binary (v0.31.1).
https://github.com/orca-so/whirlpool-tx-replayer/tree/main/whirlpool-regression-test-command
whirlpool-regression-test <archive storage path> <date to replay> whirlpool_anchor0290.so whirlpool_anchor0311.so
Ooh, I didn't realize this testing tool existed - thank you for linking! I will look into this and follow up with results 🗒️

Update: what a cool tool! I got this working, currently running the command against 10/01 transactions and will go from there.

hey @yugure-orca, i wanted to let you know i ran your tool over data from 10/01 -> 10/06 without regression. would you like me to further run the regression test tool - include more days, test a specific day in particular, etc?

.changeset/cold-emus-lead.md

jshiohaha requested review from odcheung, rawfalafel, wjthieme and yugure-orca as code owners October 1, 2025 19:03

jshiohaha commented Oct 1, 2025

View reviewed changes

programs/whirlpool/src/math/bn.rs Outdated Show resolved Hide resolved

jshiohaha commented Oct 1, 2025

View reviewed changes

This was referenced Oct 1, 2025

update rust-sdk/client #1082

Merged

update ts-sdk/client #1083

Merged

update ts-sdk packages: core, tx-sender, whirlpool #1086

Merged

wjthieme approved these changes Oct 2, 2025

View reviewed changes

yugure-orca reviewed Oct 3, 2025

View reviewed changes

jshiohaha commented Oct 3, 2025

View reviewed changes

jshiohaha mentioned this pull request Oct 3, 2025

update legacy-sdk #1088

Merged

jshiohaha force-pushed the TKN-700/contract branch from 896a2e9 to 265101b Compare October 10, 2025 14:48

jshiohaha commented Oct 10, 2025

View reviewed changes

.changeset/cold-emus-lead.md Outdated Show resolved Hide resolved

jshiohaha added 5 commits October 10, 2025 09:49

upgrade contract anchor version to 0.31.1

f1da326

explicitly set overflow-checks = false

1689e14

remove unused macro and borsh (de)serialize implementation

b656845

remove direct dependencies on spl-token-metadata-interface and spl-token

6fafb53

remove direct dependencies on borsh

4ea3c7f

jshiohaha force-pushed the TKN-700/contract branch from 265101b to 4ea3c7f Compare October 10, 2025 14:50

jshiohaha changed the base branch from TKN-700/base to main October 10, 2025 14:53

jshiohaha changed the base branch from main to TKN-700/base October 10, 2025 14:53

This was referenced Oct 10, 2025

apply remaining updates for anchor upgrade #1111

Merged

[TKN-731] upgrade all packages to anchor 0.32.1 #1114

Merged

jshiohaha merged commit b790c02 into TKN-700/base Oct 19, 2025
1 check passed

jshiohaha deleted the TKN-700/contract branch October 19, 2025 21:37

jshiohaha mentioned this pull request Oct 22, 2025

Upgrade contract and all related packages to Anchor 0.32.1 #1142

Merged

		@@ -1,5 +1,5 @@
		use anchor_lang::prelude::*;
		use anchor_lang::solana_program::pubkey;

upgrade contract anchor version to 0.31.1 #1081

upgrade contract anchor version to 0.31.1 #1081

Uh oh!

Conversation

jshiohaha commented Oct 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Proposed PR process

Testing

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wjthieme commented Oct 2, 2025

Uh oh!

wjthieme left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jshiohaha Oct 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yugure-orca commented Oct 3, 2025

Uh oh!

yugure-orca left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yugure-orca commented Oct 3, 2025

Uh oh!

jshiohaha commented Oct 3, 2025

Uh oh!

jshiohaha commented Oct 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jshiohaha commented Oct 7, 2025

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

jshiohaha commented Oct 1, 2025 •

edited

Loading

jshiohaha Oct 3, 2025 •

edited

Loading

jshiohaha commented Oct 3, 2025 •

edited

Loading