2.1.1 (2025-05-12)

@solana/addresses@2.1.1

Patch Changes

#473 36a9dee Thanks @steveluscher! - The identity of all branded types has changed in such a way that the types from v2.1.1 will be compatible with any other version going forward, which is not the case for versions v2.1.0 and before.
If you end up with a mix of versions in your project prior to v2.1.1 (eg. @solana/addresses@2.0.0 and @solana/addresses@2.1.0) you may discover that branded types like Address raise a type error, even though they are runtime compatible. Your options are:
1. Always make sure that you have exactly one instance of each @solana/* dependency in your project at any given time
2. Upgrade all of your @solana/* dependencies to v2.1.1 at minimum, even if their minor or patch versions differ.
3. Suppress the type errors using a comment like the following:
```
const myAddress = address('1234..5678'); // from @solana/addresses@2.0.0
const myAccount = await fetchEncodedAccount(
    // imports @solana/addresses@2.1.0
    rpc,
    // @ts-expect-error Address types mismatch between installed versions of @solana/addresses
    myAddress,
);
```
#236 ca1d4ec Thanks @steveluscher! - The minimum TypeScript version is now 5.3.3
Updated dependencies [36a9dee, ca1d4ec]:
- @solana/codecs-strings@2.1.1
- @solana/nominal-types@2.1.1
- @solana/codecs-core@2.1.1
- @solana/assertions@2.1.1
- @solana/errors@2.1.1

@solana/errors@2.1.1

Patch Changes

#473 36a9dee Thanks @steveluscher! - The identity of all branded types has changed in such a way that the types from v2.1.1 will be compatible with any other version going forward, which is not the case for versions v2.1.0 and before.
If you end up with a mix of versions in your project prior to v2.1.1 (eg. @solana/addresses@2.0.0 and @solana/addresses@2.1.0) you may discover that branded types like Address raise a type error, even though they are runtime compatible. Your options are:
1. Always make sure that you have exactly one instance of each @solana/* dependency in your project at any given time
2. Upgrade all of your @solana/* dependencies to v2.1.1 at minimum, even if their minor or patch versions differ.
3. Suppress the type errors using a comment like the following:
```
const myAddress = address('1234..5678'); // from @solana/addresses@2.0.0
const myAccount = await fetchEncodedAccount(
    // imports @solana/addresses@2.1.0
    rpc,
    // @ts-expect-error Address types mismatch between installed versions of @solana/addresses
    myAddress,
);
```
#236 ca1d4ec Thanks @steveluscher! - The minimum TypeScript version is now 5.3.3

@solana/rpc-transport-http@2.1.1

Patch Changes

#473 36a9dee Thanks @steveluscher! - The identity of all branded types has changed in such a way that the types from v2.1.1 will be compatible with any other version going forward, which is not the case for versions v2.1.0 and before.
If you end up with a mix of versions in your project prior to v2.1.1 (eg. @solana/addresses@2.0.0 and @solana/addresses@2.1.0) you may discover that branded types like Address raise a type error, even though they are runtime compatible. Your options are:
1. Always make sure that you have exactly one instance of each @solana/* dependency in your project at any given time
2. Upgrade all of your @solana/* dependencies to v2.1.1 at minimum, even if their minor or patch versions differ.
3. Suppress the type errors using a comment like the following:
```
const myAddress = address('1234..5678'); // from @solana/addresses@2.0.0
const myAccount = await fetchEncodedAccount(
    // imports @solana/addresses@2.1.0
    rpc,
    // @ts-expect-error Address types mismatch between installed versions of @solana/addresses
    myAddress,
);
```
#236 ca1d4ec Thanks @steveluscher! - The minimum TypeScript version is now 5.3.3
Updated dependencies [36a9dee, ca1d4ec]:
- @solana/rpc-spec-types@2.1.1
- @solana/rpc-spec@2.1.1
- @solana/errors@2.1.1

@solana/sysvars@2.1.1

Patch Changes

#374 2fb1fbc Thanks @steveluscher! - The SysvarEpochRewards encoder/decoder no longer produces malformed data
#473 36a9dee Thanks @steveluscher! - The identity of all branded types has changed in such a way that the types from v2.1.1 will be compatible with any other version going forward, which is not the case for versions v2.1.0 and before.
If you end up with a mix of versions in your project prior to v2.1.1 (eg. @solana/addresses@2.0.0 and @solana/addresses@2.1.0) you may discover that branded types like Address raise a type error, even though they are runtime compatible. Your options are:
1. Always make sure that you have exactly one instance of each @solana/* dependency in your project at any given time
2. Upgrade all of your @solana/* dependencies to v2.1.1 at minimum, even if their minor or patch versions differ.
3. Suppress the type errors using a comment like the following:
```
const myAddress = address('1234..5678'); // from @solana/addresses@2.0.0
const myAccount = await fetchEncodedAccount(
    // imports @solana/addresses@2.1.0
    rpc,
    // @ts-expect-error Address types mismatch between installed versions of @solana/addresses
    myAddress,
);
```
#379 e143797 Thanks @steveluscher! - The SysvarStakeHistory encoder/decoder no longer produces malformed data
#236 ca1d4ec Thanks @steveluscher! - The minimum TypeScript version is now 5.3.3
Updated dependencies [36a9dee, 41b679c, ca1d4ec]:
- @solana/rpc-types@2.1.1
- @solana/accounts@2.1.1
- @solana/codecs@2.1.1
- @solana/errors@2.1.1

@solana/accounts@2.1.1

Patch Changes

#473 36a9dee Thanks @steveluscher! - The identity of all branded types has changed in such a way that the types from v2.1.1 will be compatible with any other version going forward, which is not the case for versions v2.1.0 and before.
If you end up with a mix of versions in your project prior to v2.1.1 (eg. @solana/addresses@2.0.0 and @solana/addresses@2.1.0) you may discover that branded types like Address raise a type error, even though they are runtime compatible. Your options are:
1. Always make sure that you have exactly one instance of each @solana/* dependency in your project at any given time
2. Upgrade all of your @solana/* dependencies to v2.1.1 at minimum, even if their minor or patch versions differ.
3. Suppress the type errors using a comment like the following:
```
const myAddress = address('1234..5678'); // from @solana/addresses@2.0.0
const myAccount = await fetchEncodedAccount(
    // imports @solana/addresses@2.1.0
    rpc,
    // @ts-expect-error Address types mismatch between installed versions of @solana/addresses
    myAddress,
);
```
#236 ca1d4ec Thanks @steveluscher! - The minimum TypeScript version is now 5.3.3
Updated dependencies [36a9dee, 41b679c, ca1d4ec]:
- @solana/codecs-strings@2.1.1
- @solana/codecs-core@2.1.1
- @solana/addresses@2.1.1
- @solana/rpc-types@2.1.1
- @solana/rpc-spec@2.1.1
- @solana/errors@2.1.1

@solana/assertions@2.1.1

Patch Changes

#473 36a9dee Thanks @steveluscher! - The identity of all branded types has changed in such a way that the types from v2.1.1 will be compatible with any other version going forward, which is not the case for versions v2.1.0 and before.
If you end up with a mix of versions in your project prior to v2.1.1 (eg. @solana/addresses@2.0.0 and @solana/addresses@2.1.0) you may discover that branded types like Address raise a type error, even though they are runtime compatible. Your options are:
1. Always make sure that you have exactly one instance of each @solana/* dependency in your project at any given time
2. Upgrade all of your @solana/* dependencies to v2.1.1 at minimum, even if their minor or patch versions differ.
3. Suppress the type errors using a comment like the following:
```
const myAddress = address('1234..5678'); // from @solana/addresses@2.0.0
const myAccount = await fetchEncodedAccount(
    // imports @solana/addresses@2.1.0
    rpc,
    // @ts-expect-error Address types mismatch between installed versions of @solana/addresses
    myAddress,
);
```
#236 ca1d4ec Thanks @steveluscher! - The minimum TypeScript version is now 5.3.3
Updated dependencies [36a9dee, ca1d4ec]:
- @solana/errors@2.1.1

@solana/codecs@2.1.1

Patch Changes

#473 36a9dee Thanks @steveluscher! - The identity of all branded types has changed in such a way that the types from v2.1.1 will be compatible with any other version going forward, which is not the case for versions v2.1.0 and before.
If you end up with a mix of versions in your project prior to v2.1.1 (eg. @solana/addresses@2.0.0 and @solana/addresses@2.1.0) you may discover that branded types like Address raise a type error, even though they are runtime compatible. Your options are:
1. Always make sure that you have exactly one instance of each @solana/* dependency in your project at any given time
2. Upgrade all of your @solana/* dependencies to v2.1.1 at minimum, even if their minor or patch versions differ.
3. Suppress the type errors using a comment like the following:
```
const myAddress = address('1234..5678'); // from @solana/addresses@2.0.0
const myAccount = await fetchEncodedAccount(
    // imports @solana/addresses@2.1.0
    rpc,
    // @ts-expect-error Address types mismatch between installed versions of @solana/addresses
    myAddress,
);
```
#236 ca1d4ec Thanks @steveluscher! - The minimum TypeScript version is now 5.3.3
Updated dependencies [36a9dee, ca1d4ec]:
- @solana/codecs-data-structures@2.1.1
- @solana/codecs-numbers@2.1.1
- @solana/codecs-strings@2.1.1
- @solana/codecs-core@2.1.1
- @solana/options@2.1.1

@solana/codecs-core@2.1.1

Patch Changes

#473 36a9dee Thanks @steveluscher! - The identity of all branded types has changed in such a way that the types from v2.1.1 will be compatible with any other version going forward, which is not the case for versions v2.1.0 and before.
If you end up with a mix of versions in your project prior to v2.1.1 (eg. @solana/addresses@2.0.0 and @solana/addresses@2.1.0) you may discover that branded types like Address raise a type error, even though they are runtime compatible. Your options are:
1. Always make sure that you have exactly one instance of each @solana/* dependency in your project at any given time
2. Upgrade all of your @solana/* dependencies to v2.1.1 at minimum, even if their minor or patch versions differ.
3. Suppress the type errors using a comment like the following:
```
const myAddress = address('1234..5678'); // from @solana/addresses@2.0.0
const myAccount = await fetchEncodedAccount(
    // imports @solana/addresses@2.1.0
    rpc,
    // @ts-expect-error Address types mismatch between installed versions of @solana/addresses
    myAddress,
);
```
#236 ca1d4ec Thanks @steveluscher! - The minimum TypeScript version is now 5.3.3
Updated dependencies [36a9dee, ca1d4ec]:
- @solana/errors@2.1.1

@solana/codecs-data-structures@2.1.1

Patch Changes

#473 36a9dee Thanks @steveluscher! - The identity of all branded types has changed in such a way that the types from v2.1.1 will be compatible with any other version going forward, which is not the case for versions v2.1.0 and before.
If you end up with a mix of versions in your project prior to v2.1.1 (eg. @solana/addresses@2.0.0 and @solana/addresses@2.1.0) you may discover that branded types like Address raise a type error, even though they are runtime compatible. Your options are:
1. Always make sure that you have exactly one instance of each @solana/* dependency in your project at any given time
2. Upgrade all of your @solana/* dependencies to v2.1.1 at minimum, even if their minor or patch versions differ.
3. Suppress the type errors using a comment like the following:
```
const myAddress = address('1234..5678'); // from @solana/addresses@2.0.0
const myAccount = await fetchEncodedAccount(
    // imports @solana/addresses@2.1.0
    rpc,
    // @ts-expect-error Address types mismatch between installed versions of @solana/addresses
    myAddress,
);
```
#236 ca1d4ec Thanks @steveluscher! - The minimum TypeScript version is now 5.3.3
Updated dependencies [36a9dee, ca1d4ec]:
- @solana/codecs-numbers@2.1.1
- @solana/codecs-core@2.1.1
- @solana/errors@2.1.1

@solana/codecs-numbers@2.1.1

Patch Changes

#473 36a9dee Thanks @steveluscher! - The identity of all branded types has changed in such a way that the types from v2.1.1 will be compatible with any other version going forward, which is not the case for versions v2.1.0 and before.
If you end up with a mix of versions in your project prior to v2.1.1 (eg. @solana/addresses@2.0.0 and @solana/addresses@2.1.0) you may discover that branded types like Address raise a type error, even though they are runtime compatible. Your options are:
1. Always make sure that you have exactly one instance of each @solana/* dependency in your project at any given time
2. Upgrade all of your @solana/* dependencies to v2.1.1 at minimum, even if their minor or patch versions differ.
3. Suppress the type errors using a comment like the following:
```
const myAddress = address('1234..5678'); // from @solana/addresses@2.0.0
const myAccount = await fetchEncodedAccount(
    // imports @solana/addresses@2.1.0
    rpc,
    // @ts-expect-error Address types mismatch between installed versions of @solana/addresses
    myAddress,
);
```
#236 ca1d4ec Thanks @steveluscher! - The minimum TypeScript version is now 5.3.3
Updated dependencies [36a9dee, ca1d4ec]:
- @solana/codecs-core@2.1.1
- @solana/errors@2.1.1

@solana/codecs-strings@2.1.1

Patch Changes

#473 36a9dee Thanks @steveluscher! - The identity of all branded types has changed in such a way that the types from v2.1.1 will be compatible with any other version going forward, which is not the case for versions v2.1.0 and before.
If you end up with a mix of versions in your project prior to v2.1.1 (eg. @solana/addresses@2.0.0 and @solana/addresses@2.1.0) you may discover that branded types like Address raise a type error, even though they are runtime compatible. Your options are:
1. Always make sure that you have exactly one instance of each @solana/* dependency in your project at any given time
2. Upgrade all of your @solana/* dependencies to v2.1.1 at minimum, even if their minor or patch versions differ.
3. Suppress the type errors using a comment like the following:
```
const myAddress = address('1234..5678'); // from @solana/addresses@2.0.0
const myAccount = await fetchEncodedAccount(
    // imports @solana/addresses@2.1.0
    rpc,
    // @ts-expect-error Address types mismatch between installed versions of @solana/addresses
    myAddress,
);
```
#236 ca1d4ec Thanks @steveluscher! - The minimum TypeScript version is now 5.3.3
Updated dependencies [36a9dee, ca1d4ec]:
- @solana/codecs-numbers@2.1.1
- @solana/codecs-core@2.1.1
- @solana/errors@2.1.1

@solana/compat@2.1.1

Patch Changes

#473 36a9dee Thanks @steveluscher! - The identity of all branded types has changed in such a way that the types from v2.1.1 will be compatible with any other version going forward, which is not the case for versions v2.1.0 and before.
If you end up with a mix of versions in your project prior to v2.1.1 (eg. @solana/addresses@2.0.0 and @solana/addresses@2.1.0) you may discover that branded types like Address raise a type error, even though they are runtime compatible. Your options are:
1. Always make sure that you have exactly one instance of each @solana/* dependency in your project at any given time
2. Upgrade all of your @solana/* dependencies to v2.1.1 at minimum, even if their minor or patch versions differ.
3. Suppress the type errors using a comment like the following:
```
const myAddress = address('1234..5678'); // from @solana/addresses@2.0.0
const myAccount = await fetchEncodedAccount(
    // imports @solana/addresses@2.1.0
    rpc,
    // @ts-expect-error Address types mismatch between installed versions of @solana/addresses
    myAddress,
);
```
#236 ca1d4ec Thanks @steveluscher! - The minimum TypeScript version is now 5.3.3
Updated dependencies [36a9dee, ca1d4ec]:
- @solana/instructions@2.1.1
- @solana/transactions@2.1.1
- @solana/codecs-core@2.1.1
- @solana/addresses@2.1.1
- @solana/errors@2.1.1
- @solana/keys@2.1.1

@solana/instructions@2.1.1

Patch Changes

#473 36a9dee Thanks @steveluscher! - The identity of all branded types has changed in such a way that the types from v2.1.1 will be compatible with any other version going forward, which is not the case for versions v2.1.0 and before.
If you end up with a mix of versions in your project prior to v2.1.1 (eg. @solana/addresses@2.0.0 and @solana/addresses@2.1.0) you may discover that branded types like Address raise a type error, even though they are runtime compatible. Your options are:
1. Always make sure that you have exactly one instance of each @solana/* dependency in your project at any given time
2. Upgrade all of your @solana/* dependencies to v2.1.1 at minimum, even if their minor or patch versions differ.
3. Suppress the type errors using a comment like the following:
```
const myAddress = address('1234..5678'); // from @solana/addresses@2.0.0
const myAccount = await fetchEncodedAccount(
    // imports @solana/addresses@2.1.0
    rpc,
    // @ts-expect-error Address types mismatch between installed versions of @solana/addresses
    myAddress,
);
```
#236 ca1d4ec Thanks @steveluscher! - The minimum TypeScript version is now 5.3.3
Updated dependencies [36a9dee, ca1d4ec]:
- @solana/codecs-core@2.1.1
- @solana/errors@2.1.1

@solana/keys@2.1.1

Patch Changes

#473 36a9dee Thanks @steveluscher! - The identity of all branded types has changed in such a way that the types from v2.1.1 will be compatible with any other version going forward, which is not the case for versions v2.1.0 and before.
If you end up with a mix of versions in your project prior to v2.1.1 (eg. @solana/addresses@2.0.0 and @solana/addresses@2.1.0) you may discover that branded types like Address raise a type error, even though they are runtime compatible. Your options are:
1. Always make sure that you have exactly one instance of each @solana/* dependency in your project at any given time
2. Upgrade all of your @solana/* dependencies to v2.1.1 at minimum, even if their minor or patch versions differ.
3. Suppress the type errors using a comment like the following:
```
const myAddress = address('1234..5678'); // from @solana/addresses@2.0.0
const myAccount = await fetchEncodedAccount(
    // imports @solana/addresses@2.1.0
    rpc,
    // @ts-expect-error Address types mismatch between installed versions of @solana/addresses
    myAddress,
);
```
#236 ca1d4ec Thanks @steveluscher! - The minimum TypeScript version is now 5.3.3
Updated dependencies [36a9dee, ca1d4ec]:
- @solana/codecs-strings@2.1.1
- @solana/nominal-types@2.1.1
- @solana/codecs-core@2.1.1
- @solana/assertions@2.1.1
- @solana/errors@2.1.1

@solana/kit@2.1.1

Patch Changes

#473 36a9dee Thanks @steveluscher! - The identity of all branded types has changed in such a way that the types from v2.1.1 will be compatible with any other version going forward, which is not the case for versions v2.1.0 and before.
If you end up with a mix of versions in your project prior to v2.1.1 (eg. @solana/addresses@2.0.0 and @solana/addresses@2.1.0) you may discover that branded types like Address raise a type error, even though they are runtime compatible. Your options are:
1. Always make sure that you have exactly one instance of each @solana/* dependency in your project at any given time
2. Upgrade all of your @solana/* dependencies to v2.1.1 at minimum, even if their minor or patch versions differ.
3. Suppress the type errors using a comment like the following:
```
const myAddress = address('1234..5678'); // from @solana/addresses@2.0.0
const myAccount = await fetchEncodedAccount(
    // imports @solana/addresses@2.1.0
    rpc,
    // @ts-expect-error Address types mismatch between installed versions of @solana/addresses
    myAddress,
);
```
#409 24a329d Thanks @mcintyre94! - Loosen lifetime constraint on sendAndConfirmTransaction to only require lastValidBlockHeight
#236 ca1d4ec Thanks @steveluscher! - The minimum TypeScript version is now 5.3.3
Updated dependencies [2fb1fbc, 36a9dee, 41b679c, 24a329d, 41b679c, e143797, 776e18d, ca1d4ec]:
- @solana/sysvars@2.1.1
- @solana/transaction-confirmation@2.1.1
- @solana/transaction-messages@2.1.1
- @solana/rpc-subscriptions@2.1.1
- @solana/rpc-parsed-types@2.1.1
- @solana/rpc-spec-types@2.1.1
- @solana/instructions@2.1.1
- @solana/transactions@2.1.1
- @solana/functional@2.1.1
- @solana/addresses@2.1.1
- @solana/rpc-types@2.1.1
- @solana/accounts@2.1.1
- @solana/programs@2.1.1
- @solana/signers@2.1.1
- @solana/codecs@2.1.1
- @solana/errors@2.1.1
- @solana/keys@2.1.1
- @solana/rpc@2.1.1

@solana/options@2.1.1

Patch Changes

#473 36a9dee Thanks @steveluscher! - The identity of all branded types has changed in such a way that the types from v2.1.1 will be compatible with any other version going forward, which is not the case for versions v2.1.0 and before.
If you end up with a mix of versions in your project prior to v2.1.1 (eg. @solana/addresses@2.0.0 and @solana/addresses@2.1.0) you may discover that branded types like Address raise a type error, even though they are runtime compatible. Your options are:
1. Always make sure that you have exactly one instance of each @solana/* dependency in your project at any given time
2. Upgrade all of your @solana/* dependencies to v2.1.1 at minimum, even if their minor or patch versions differ.
3. Suppress the type errors using a comment like the following:
```
const myAddress = address('1234..5678'); // from @solana/addresses@2.0.0
const myAccount = await fetchEncodedAccount(
    // imports @solana/addresses@2.1.0
    rpc,
    // @ts-expect-error Address types mismatch between installed versions of @solana/addresses
    myAddress,
);
```
#236 ca1d4ec Thanks @steveluscher! - The minimum TypeScript version is now 5.3.3
Updated dependencies [36a9dee, ca1d4ec]:
- @solana/codecs-data-structures@2.1.1
- @solana/codecs-numbers@2.1.1
- @solana/codecs-strings@2.1.1
- @solana/codecs-core@2.1.1
- @solana/errors@2.1.1

@solana/programs@2.1.1

Patch Changes

#473 36a9dee Thanks @steveluscher! - The identity of all branded types has changed in such a way that the types from v2.1.1 will be compatible with any other version going forward, which is not the case for versions v2.1.0 and before.
If you end up with a mix of versions in your project prior to v2.1.1 (eg. @solana/addresses@2.0.0 and @solana/addresses@2.1.0) you may discover that branded types like Address raise a type error, even though they are runtime compatible. Your options are:
1. Always make sure that you have exactly one instance of each @solana/* dependency in your project at any given time
2. Upgrade all of your @solana/* dependencies to v2.1.1 at minimum, even if their minor or patch versions differ.
3. Suppress the type errors using a comment like the following:
```
const myAddress = address('1234..5678'); // from @solana/addresses@2.0.0
const myAccount = await fetchEncodedAccount(
    // imports @solana/addresses@2.1.0
    rpc,
    // @ts-expect-error Address types mismatch between installed versions of @solana/addresses
    myAddress,
);
```
#236 ca1d4ec Thanks @steveluscher! - The minimum TypeScript version is now 5.3.3
Updated dependencies [36a9dee, ca1d4ec]:
- @solana/addresses@2.1.1
- @solana/errors@2.1.1

@solana/react@2.1.1

Patch Changes

#473 36a9dee Thanks @steveluscher! - The identity of all branded types has changed in such a way that the types from v2.1.1 will be compatible with any other version going forward, which is not the case for versions v2.1.0 and before.
If you end up with a mix of versions in your project prior to v2.1.1 (eg. @solana/addresses@2.0.0 and @solana/addresses@2.1.0) you may discover that branded types like Address raise a type error, even though they are runtime compatible. Your options are:
1. Always make sure that you have exactly one instance of each @solana/* dependency in your project at any given time
2. Upgrade all of your @solana/* dependencies to v2.1.1 at minimum, even if their minor or patch versions differ.
3. Suppress the type errors using a comment like the following:
```
const myAddress = address('1234..5678'); // from @solana/addresses@2.0.0
const myAccount = await fetchEncodedAccount(
    // imports @solana/addresses@2.1.0
    rpc,
    // @ts-expect-error Address types mismatch between installed versions of @solana/addresses
    myAddress,
);
```
Updated dependencies [36a9dee, ca1d4ec]:
- @solana/transactions@2.1.1
- @solana/addresses@2.1.1
- @solana/promises@2.1.1
- @solana/signers@2.1.1
- @solana/errors@2.1.1
- @solana/keys@2.1.1

@solana/rpc@2.1.1

Patch Changes

#473 36a9dee Thanks @steveluscher! - The identity of all branded types has changed in such a way that the types from v2.1.1 will be compatible with any other version going forward, which is not the case for versions v2.1.0 and before.
If you end up with a mix of versions in your project prior to v2.1.1 (eg. @solana/addresses@2.0.0 and @solana/addresses@2.1.0) you may discover that branded types like Address raise a type error, even though they are runtime compatible. Your options are:
1. Always make sure that you have exactly one instance of each @solana/* dependency in your project at any given time
2. Upgrade all of your @solana/* dependencies to v2.1.1 at minimum, even if their minor or patch versions differ.
3. Suppress the type errors using a comment like the following:
```
const myAddress = address('1234..5678'); // from @solana/addresses@2.0.0
const myAccount = await fetchEncodedAccount(
    // imports @solana/addresses@2.1.0
    rpc,
    // @ts-expect-error Address types mismatch between installed versions of @solana/addresses
    myAddress,
);
```
#236 ca1d4ec Thanks @steveluscher! - The minimum TypeScript version is now 5.3.3
Updated dependencies [ca1d4ec, 7e7b2ef, 36a9dee, 41b679c, ca1d4ec]:
- @solana/rpc-api@2.1.1
- @solana/rpc-transformers@2.1.1
- @solana/fast-stable-stringify@2.1.1
- @solana/rpc-transport-http@2.1.1
- @solana/rpc-spec-types@2.1.1
- @solana/functional@2.1.1
- @solana/rpc-types@2.1.1
- @solana/rpc-spec@2.1.1
- @solana/errors@2.1.1

@solana/rpc-api@2.1.1

Patch Changes

#236 ca1d4ec Thanks @steveluscher! - RPC methods that take no parameters no longer rely on having a placeholder NO_CONFIG argument. Removing it will save you from wondering why it exists.
#473 36a9dee Thanks @steveluscher! - The identity of all branded types has changed in such a way that the types from v2.1.1 will be compatible with any other version going forward, which is not the case for versions v2.1.0 and before.
If you end up with a mix of versions in your project prior to v2.1.1 (eg. @solana/addresses@2.0.0 and @solana/addresses@2.1.0) you may discover that branded types like Address raise a type error, even though they are runtime compatible. Your options are:
1. Always make sure that you have exactly one instance of each @solana/* dependency in your project at any given time
2. Upgrade all of your @solana/* dependencies to v2.1.1 at minimum, even if their minor or patch versions differ.
3. Suppress the type errors using a comment like the following:
```
const myAddress = address('1234..5678'); // from @solana/addresses@2.0.0
const myAccount = await fetchEncodedAccount(
    // imports @solana/addresses@2.1.0
    rpc,
    // @ts-expect-error Address types mismatch between installed versions of @solana/addresses
    myAddress,
);
```
#433 41b679c Thanks @steveluscher! - Corrected a misspelling of readonlyIndexes in the AddressLookupTable type. This fixes the return type of the getTransaction RPC call.
#236 ca1d4ec Thanks @steveluscher! - The minimum TypeScript version is now 5.3.3
Updated dependencies [7e7b2ef, 36a9dee, 41b679c, 41b679c, 776e18d, ca1d4ec]:
- @solana/rpc-transformers@2.1.1
- @solana/transaction-messages@2.1.1
- @solana/rpc-parsed-types@2.1.1
- @solana/codecs-strings@2.1.1
- @solana/transactions@2.1.1
- @solana/codecs-core@2.1.1
- @solana/addresses@2.1.1
- @solana/rpc-types@2.1.1
- @solana/rpc-spec@2.1.1
- @solana/errors@2.1.1
- @solana/keys@2.1.1

@solana/rpc-graphql@2.1.1

Patch Changes

#473 36a9dee Thanks @steveluscher! - The identity of all branded types has changed in such a way that the types from v2.1.1 will be compatible with any other version going forward, which is not the case for versions v2.1.0 and before.
If you end up with a mix of versions in your project prior to v2.1.1 (eg. @solana/addresses@2.0.0 and @solana/addresses@2.1.0) you may discover that branded types like Address raise a type error, even though they are runtime compatible. Your options are:
1. Always make sure that you have exactly one instance of each @solana/* dependency in your project at any given time
2. Upgrade all of your @solana/* dependencies to v2.1.1 at minimum, even if their minor or patch versions differ.
3. Suppress the type errors using a comment like the following:
```
const myAddress = address('1234..5678'); // from @solana/addresses@2.0.0
const myAccount = await fetchEncodedAccount(
    // imports @solana/addresses@2.1.0
    rpc,
    // @ts-expect-error Address types mismatch between installed versions of @solana/addresses
    myAddress,
);
```
#433 41b679c Thanks @steveluscher! - Corrected a misspelling of readonlyIndexes in the AddressLookupTable type. This fixes the return type of the getTransaction RPC call.
#236 ca1d4ec Thanks @steveluscher! - The minimum TypeScript version is now 5.3.3
Updated dependencies [36a9dee, ca1d4ec]:
- @solana/fast-stable-stringify@2.1.1
- @solana/codecs-strings@2.1.1

@solana/rpc-spec@2.1.1

Patch Changes

#473 36a9dee Thanks @steveluscher! - The identity of all branded types has changed in such a way that the types from v2.1.1 will be compatible with any other version going forward, which is not the case for versions v2.1.0 and before.
If you end up with a mix of versions in your project prior to v2.1.1 (eg. @solana/addresses@2.0.0 and @solana/addresses@2.1.0) you may discover that branded types like Address raise a type error, even though they are runtime compatible. Your options are:
1. Always make sure that you have exactly one instance of each @solana/* dependency in your project at any given time
2. Upgrade all of your @solana/* dependencies to v2.1.1 at minimum, even if their minor or patch versions differ.
3. Suppress the type errors using a comment like the following:
```
const myAddress = address('1234..5678'); // from @solana/addresses@2.0.0
const myAccount = await fetchEncodedAccount(
    // imports @solana/addresses@2.1.0
    rpc,
    // @ts-expect-error Address types mismatch between installed versions of @solana/addresses
    myAddress,
);
```
#236 ca1d4ec Thanks @steveluscher! - The minimum TypeScript version is now 5.3.3
Updated dependencies [36a9dee, ca1d4ec]:
- @solana/rpc-spec-types@2.1.1
- @solana/errors@2.1.1

@solana/rpc-subscriptions@2.1.1

Patch Changes

#473 36a9dee Thanks @steveluscher! - The identity of all branded types has changed in such a way that the types from v2.1.1 will be compatible with any other version going forward, which is not the case for versions v2.1.0 and before.
If you end up with a mix of versions in your project prior to v2.1.1 (eg. @solana/addresses@2.0.0 and @solana/addresses@2.1.0) you may discover that branded types like Address raise a type error, even though they are runtime compatible. Your options are:
1. Always make sure that you have exactly one instance of each @solana/* dependency in your project at any given time
2. Upgrade all of your @solana/* dependencies to v2.1.1 at minimum, even if their minor or patch versions differ.
3. Suppress the type errors using a comment like the following:
```
const myAddress = address('1234..5678'); // from @solana/addresses@2.0.0
const myAccount = await fetchEncodedAccount(
    // imports @solana/addresses@2.1.0
    rpc,
    // @ts-expect-error Address types mismatch between installed versions of @solana/addresses
    myAddress,
);
```
#236 ca1d4ec Thanks @steveluscher! - The minimum TypeScript version is now 5.3.3
Updated dependencies [7e7b2ef, 36a9dee, 41b679c, ca1d4ec]:
- @solana/rpc-transformers@2.1.1
- @solana/rpc-subscriptions-channel-websocket@2.1.1
- @solana/rpc-subscriptions-spec@2.1.1
- @solana/fast-stable-stringify@2.1.1
- @solana/rpc-subscriptions-api@2.1.1
- @solana/rpc-spec-types@2.1.1
- @solana/subscribable@2.1.1
- @solana/functional@2.1.1
- @solana/rpc-types@2.1.1
- @solana/promises@2.1.1
- @solana/errors@2.1.1

@solana/rpc-subscriptions-api@2.1.1

Patch Changes

#473 36a9dee Thanks @steveluscher! - The identity of all branded types has changed in such a way that the types from v2.1.1 will be compatible with any other version going forward, which is not the case for versions v2.1.0 and before.
If you end up with a mix of versions in your project prior to v2.1.1 (eg. @solana/addresses@2.0.0 and @solana/addresses@2.1.0) you may discover that branded types like Address raise a type error, even though they are runtime compatible. Your options are:
1. Always make sure that you have exactly one instance of each @solana/* dependency in your project at any given time
2. Upgrade all of your @solana/* dependencies to v2.1.1 at minimum, even if their minor or patch versions differ.
3. Suppress the type errors using a comment like the following:
```
const myAddress = address('1234..5678'); // from @solana/addresses@2.0.0
const myAccount = await fetchEncodedAccount(
    // imports @solana/addresses@2.1.0
    rpc,
    // @ts-expect-error Address types mismatch between installed versions of @solana/addresses
    myAddress,
);
```
#236 ca1d4ec Thanks @steveluscher! - The minimum TypeScript version is now 5.3.3
Updated dependencies [7e7b2ef, 36a9dee, 41b679c, 41b679c, 776e18d, ca1d4ec]:
- @solana/rpc-transformers@2.1.1
- @solana/rpc-subscriptions-spec@2.1.1
- @solana/transaction-messages@2.1.1
- @solana/transactions@2.1.1
- @solana/addresses@2.1.1
- @solana/rpc-types@2.1.1
- @solana/keys@2.1.1

@solana/rpc-subscriptions-channel-websocket@2.1.1

Patch Changes

#473 36a9dee Thanks @steveluscher! - The identity of all branded types has changed in such a way that the types from v2.1.1 will be compatible with any other version going forward, which is not the case for versions v2.1.0 and before.
If you end up with a mix of versions in your project prior to v2.1.1 (eg. @solana/addresses@2.0.0 and @solana/addresses@2.1.0) you may discover that branded types like Address raise a type error, even though they are runtime compatible. Your options are:
1. Always make sure that you have exactly one instance of each @solana/* dependency in your project at any given time
2. Upgrade all of your @solana/* dependencies to v2.1.1 at minimum, even if their minor or patch versions differ.
3. Suppress the type errors using a comment like the following:
```
const myAddress = address('1234..5678'); // from @solana/addresses@2.0.0
const myAccount = await fetchEncodedAccount(
    // imports @solana/addresses@2.1.0
    rpc,
    // @ts-expect-error Address types mismatch between installed versions of @solana/addresses
    myAddress,
);
```
#236 ca1d4ec Thanks @steveluscher! - The minimum TypeScript version is now 5.3.3
Updated dependencies [36a9dee, ca1d4ec]:
- @solana/rpc-subscriptions-spec@2.1.1
- @solana/subscribable@2.1.1
- @solana/functional@2.1.1
- @solana/errors@2.1.1

@solana/rpc-subscriptions-spec@2.1.1

Patch Changes

#473 36a9dee Thanks @steveluscher! - The identity of all branded types has changed in such a way that the types from v2.1.1 will be compatible with any other version going forward, which is not the case for versions v2.1.0 and before.
If you end up with a mix of versions in your project prior to v2.1.1 (eg. @solana/addresses@2.0.0 and @solana/addresses@2.1.0) you may discover that branded types like Address raise a type error, even though they are runtime compatible. Your options are:
1. Always make sure that you have exactly one instance of each @solana/* dependency in your project at any given time
2. Upgrade all of your @solana/* dependencies to v2.1.1 at minimum, even if their minor or patch versions differ.
3. Suppress the type errors using a comment like the following:
```
const myAddress = address('1234..5678'); // from @solana/addresses@2.0.0
const myAccount = await fetchEncodedAccount(
    // imports @solana/addresses@2.1.0
    rpc,
    // @ts-expect-error Address types mismatch between installed versions of @solana/addresses
    myAddress,
);
```
#236 ca1d4ec Thanks @steveluscher! - The minimum TypeScript version is now 5.3.3
Updated dependencies [36a9dee, ca1d4ec]:
- @solana/rpc-spec-types@2.1.1
- @solana/subscribable@2.1.1
- @solana/promises@2.1.1
- @solana/errors@2.1.1

@solana/rpc-transformers@2.1.1

Patch Changes

#353 7e7b2ef Thanks @steveluscher! - Removed OPTIONS_OBJECT_POSITION_BY_METHOD, downcastNodeToNumberIfBigint(), applyDefaultCommitment(), getIntegerOverflowNodeVisitor(), getBigIntUpcastVisitor(), and getTreeWalker() from the exports of @solana/rpc-transformer
#473 36a9dee Thanks @steveluscher! - The identity of all branded types has changed in such a way that the types from v2.1.1 will be compatible with any other version going forward, which is not the case for versions v2.1.0 and before.
If you end up with a mix of versions in your project prior to v2.1.1 (eg. @solana/addresses@2.0.0 and @solana/addresses@2.1.0) you may discover that branded types like Address raise a type error, even though they are runtime compatible. Your options are:
1. Always make sure that you have exactly one instance of each @solana/* dependency in your project at any given time
2. Upgrade all of your @solana/* dependencies to v2.1.1 at minimum, even if their minor or patch versions differ.
3. Suppress the type errors using a comment like the following:
```
const myAddress = address('1234..5678'); // from @solana/addresses@2.0.0
const myAccount = await fetchEncodedAccount(
    // imports @solana/addresses@2.1.0
    rpc,
    // @ts-expect-error Address types mismatch between installed versions of @solana/addresses
    myAddress,
);
```
#236 ca1d4ec Thanks @steveluscher! - The minimum TypeScript version is now 5.3.3
Updated dependencies [36a9dee, 41b679c, ca1d4ec]:
- @solana/rpc-spec-types@2.1.1
- @solana/nominal-types@2.1.1
- @solana/functional@2.1.1
- @solana/rpc-types@2.1.1
- @solana/errors@2.1.1

@solana/rpc-types@2.1.1

Patch Changes

#473 36a9dee Thanks @steveluscher! - The identity of all branded types has changed in such a way that the types from v2.1.1 will be compatible with any other version going forward, which is not the case for versions v2.1.0 and before.
If you end up with a mix of versions in your project prior to v2.1.1 (eg. @solana/addresses@2.0.0 and @solana/addresses@2.1.0) you may discover that branded types like Address raise a type error, even though they are runtime compatible. Your options are:
1. Always make sure that you have exactly one instance of each @solana/* dependency in your project at any given time
2. Upgrade all of your @solana/* dependencies to v2.1.1 at minimum, even if their minor or patch versions differ.
3. Suppress the type errors using a comment like the following:
```
const myAddress = address('1234..5678'); // from @solana/addresses@2.0.0
const myAccount = await fetchEncodedAccount(
    // imports @solana/addresses@2.1.0
    rpc,
    // @ts-expect-error Address types mismatch between installed versions of @solana/addresses
    myAddress,
);
```
#433 41b679c Thanks @steveluscher! - Corrected a misspelling of readonlyIndexes in the AddressLookupTable type. This fixes the return type of the getTransaction RPC call.
#236 ca1d4ec Thanks @steveluscher! - The minimum TypeScript version is now 5.3.3
Updated dependencies [36a9dee, ca1d4ec]:
- @solana/codecs-numbers@2.1.1
- @solana/codecs-strings@2.1.1
- @solana/nominal-types@2.1.1
- @solana/codecs-core@2.1.1
- @solana/addresses@2.1.1
- @solana/errors@2.1.1

@solana/signers@2.1.1

Patch Changes

#473 36a9dee Thanks @steveluscher! - The identity of all branded types has changed in such a way that the types from v2.1.1 will be compatible with any other version going forward, which is not the case for versions v2.1.0 and before.
If you end up with a mix of versions in your project prior to v2.1.1 (eg. @solana/addresses@2.0.0 and @solana/addresses@2.1.0) you may discover that branded types like Address raise a type error, even though they are runtime compatible. Your options are:
1. Always make sure that you have exactly one instance of each @solana/* dependency in your project at any given time
2. Upgrade all of your @solana/* dependencies to v2.1.1 at minimum, even if their minor or patch versions differ.
3. Suppress the type errors using a comment like the following:
```
const myAddress = address('1234..5678'); // from @solana/addresses@2.0.0
const myAccount = await fetchEncodedAccount(
    // imports @solana/addresses@2.1.0
    rpc,
    // @ts-expect-error Address types mismatch between installed versions of @solana/addresses
    myAddress,
);
```
#236 ca1d4ec Thanks @steveluscher! - The minimum TypeScript version is now 5.3.3
Updated dependencies [36a9dee, 41b679c, 776e18d, ca1d4ec]:
- @solana/transaction-messages@2.1.1
- @solana/nominal-types@2.1.1
- @solana/instructions@2.1.1
- @solana/transactions@2.1.1
- @solana/codecs-core@2.1.1
- @solana/addresses@2.1.1
- @solana/errors@2.1.1
- @solana/keys@2.1.1

@solana/subscribable@2.1.1

Patch Changes

#473 36a9dee Thanks @steveluscher! - The identity of all branded types has changed in such a way that the types from v2.1.1 will be compatible with any other version going forward, which is not the case for versions v2.1.0 and before.
If you end up with a mix of versions in your project prior to v2.1.1 (eg. @solana/addresses@2.0.0 and @solana/addresses@2.1.0) you may discover that branded types like Address raise a type error, even though they are runtime compatible. Your options are:
1. Always make sure that you have exactly one instance of each @solana/* dependency in your project at any given time
2. Upgrade all of your @solana/* dependencies to v2.1.1 at minimum, even if their minor or patch versions differ.
3. Suppress the type errors using a comment like the following:
```
const myAddress = address('1234..5678'); // from @solana/addresses@2.0.0
const myAccount = await fetchEncodedAccount(
    // imports @solana/addresses@2.1.0
    rpc,
    // @ts-expect-error Address types mismatch between installed versions of @solana/addresses
    myAddress,
);
```
#236 ca1d4ec Thanks @steveluscher! - The minimum TypeScript version is now 5.3.3
Updated dependencies [36a9dee, ca1d4ec]:
- @solana/errors@2.1.1

@solana/transaction-confirmation@2.1.1

Patch Changes

#473 36a9dee Thanks @steveluscher! - The identity of all branded types has changed in such a way that the types from v2.1.1 will be compatible with any other version going forward, which is not the case for versions v2.1.0 and before.
If you end up with a mix of versions in your project prior to v2.1.1 (eg. @solana/addresses@2.0.0 and @solana/addresses@2.1.0) you may discover that branded types like Address raise a type error, even though they are runtime compatible. Your options are:
1. Always make sure that you have exactly one instance of each @solana/* dependency in your project at any given time
2. Upgrade all of your @solana/* dependencies to v2.1.1 at minimum, even if their minor or patch versions differ.
3. Suppress the type errors using a comment like the following:
```
const myAddress = address('1234..5678'); // from @solana/addresses@2.0.0
const myAccount = await fetchEncodedAccount(
    // imports @solana/addresses@2.1.0
    rpc,
    // @ts-expect-error Address types mismatch between installed versions of @solana/addresses
    myAddress,
);
```
#409 24a329d Thanks @mcintyre94! - Loosen lifetime constraint on sendAndConfirmTransaction to only require lastValidBlockHeight
#236 ca1d4ec Thanks @steveluscher! - The minimum TypeScript version is now 5.3.3
Updated dependencies [36a9dee, 41b679c, 41b679c, 776e18d, ca1d4ec]:
- @solana/transaction-messages@2.1.1
- @solana/rpc-subscriptions@2.1.1
- @solana/codecs-strings@2.1.1
- @solana/transactions@2.1.1
- @solana/addresses@2.1.1
- @solana/rpc-types@2.1.1
- @solana/promises@2.1.1
- @solana/errors@2.1.1
- @solana/keys@2.1.1
- @solana/rpc@2.1.1

@solana/transaction-messages@2.1.1

Patch Changes

#473 36a9dee Thanks @steveluscher! - The identity of all branded types has changed in such a way that the types from v2.1.1 will be compatible with any other version going forward, which is not the case for versions v2.1.0 and before.
If you end up with a mix of versions in your project prior to v2.1.1 (eg. @solana/addresses@2.0.0 and @solana/addresses@2.1.0) you may discover that branded types like Address raise a type error, even though they are runtime compatible. Your options are:
1. Always make sure that you have exactly one instance of each @solana/* dependency in your project at any given time
2. Upgrade all of your @solana/* dependencies to v2.1.1 at minimum, even if their minor or patch versions differ.
3. Suppress the type errors using a comment like the following:
```
const myAddress = address('1234..5678'); // from @solana/addresses@2.0.0
const myAccount = await fetchEncodedAccount(
    // imports @solana/addresses@2.1.0
    rpc,
    // @ts-expect-error Address types mismatch between installed versions of @solana/addresses
    myAddress,
);
```
#433 41b679c Thanks @steveluscher! - Deprecated the writableIndices/readableIndices spellings in transaction messages in favour of readonlyIndexes/writableIndexes. This will make this shape compatible with the output of the getTransaction API that uses those spellings for address lookup table data.
#193 776e18d Thanks @mcintyre94! - Strip the TransactionMessageWithDurableNonceLifetime type when prepending instructions to a TransactionMessage
#236 ca1d4ec Thanks @steveluscher! - The minimum TypeScript version is now 5.3.3
Updated dependencies [36a9dee, 41b679c, ca1d4ec]:
- @solana/codecs-data-structures@2.1.1
- @solana/codecs-numbers@2.1.1
- @solana/nominal-types@2.1.1
- @solana/instructions@2.1.1
- @solana/codecs-core@2.1.1
- @solana/functional@2.1.1
- @solana/addresses@2.1.1
- @solana/rpc-types@2.1.1
- @solana/errors@2.1.1

@solana/transactions@2.1.1

Patch Changes

#473 36a9dee Thanks @steveluscher! - The identity of all branded types has changed in such a way that the types from v2.1.1 will be compatible with any other version going forward, which is not the case for versions v2.1.0 and before.
If you end up with a mix of versions in your project prior to v2.1.1 (eg. @solana/addresses@2.0.0 and @solana/addresses@2.1.0) you may discover that branded types like Address raise a type error, even though they are runtime compatible. Your options are:
1. Always make sure that you have exactly one instance of each @solana/* dependency in your project at any given time
2. Upgrade all of your @solana/* dependencies to v2.1.1 at minimum, even if their minor or patch versions differ.
3. Suppress the type errors using a comment like the following:
```
const myAddress = address('1234..5678'); // from @solana/addresses@2.0.0
const myAccount = await fetchEncodedAccount(
    // imports @solana/addresses@2.1.0
    rpc,
    // @ts-expect-error Address types mismatch between installed versions of @solana/addresses
    myAddress,
);
```
#236 ca1d4ec Thanks @steveluscher! - The minimum TypeScript version is now 5.3.3
Updated dependencies [36a9dee, 41b679c, 41b679c, 776e18d, ca1d4ec]:
- @solana/codecs-data-structures@2.1.1
- @solana/transaction-messages@2.1.1
- @solana/codecs-numbers@2.1.1
- @solana/codecs-strings@2.1.1
- @solana/nominal-types@2.1.1
- @solana/instructions@2.1.1
- @solana/codecs-core@2.1.1
- @solana/functional@2.1.1
- @solana/addresses@2.1.1
- @solana/rpc-types@2.1.1
- @solana/errors@2.1.1
- @solana/keys@2.1.1

@solana/webcrypto-ed25519-polyfill@2.1.1

Patch Changes

#473 36a9dee Thanks @steveluscher! - The identity of all branded types has changed in such a way that the types from v2.1.1 will be compatible with any other version going forward, which is not the case for versions v2.1.0 and before.
If you end up with a mix of versions in your project prior to v2.1.1 (eg. @solana/addresses@2.0.0 and @solana/addresses@2.1.0) you may discover that branded types like Address raise a type error, even though they are runtime compatible. Your options are:
1. Always make sure that you have exactly one instance of each @solana/* dependency in your project at any given time
2. Upgrade all of your @solana/* dependencies to v2.1.1 at minimum, even if their minor or patch versions differ.
3. Suppress the type errors using a comment like the following:
```
const myAddress = address('1234..5678'); // from @solana/addresses@2.0.0
const myAccount = await fetchEncodedAccount(
    // imports @solana/addresses@2.1.0
    rpc,
    // @ts-expect-error Address types mismatch between installed versions of @solana/addresses
    myAddress,
);
```
#236 ca1d4ec Thanks @steveluscher! - The minimum TypeScript version is now 5.3.3

@solana/fast-stable-stringify@2.1.1

Patch Changes

#473 36a9dee Thanks @steveluscher! - The identity of all branded types has changed in such a way that the types from v2.1.1 will be compatible with any other version going forward, which is not the case for versions v2.1.0 and before.
If you end up with a mix of versions in your project prior to v2.1.1 (eg. @solana/addresses@2.0.0 and @solana/addresses@2.1.0) you may discover that branded types like Address raise a type error, even though they are runtime compatible. Your options are:
1. Always make sure that you have exactly one instance of each @solana/* dependency in your project at any given time
2. Upgrade all of your @solana/* dependencies to v2.1.1 at minimum, even if their minor or patch versions differ.
3. Suppress the type errors using a comment like the following:
```
const myAddress = address('1234..5678'); // from @solana/addresses@2.0.0
const myAccount = await fetchEncodedAccount(
    // imports @solana/addresses@2.1.0
    rpc,
    // @ts-expect-error Address types mismatch between installed versions of @solana/addresses
    myAddress,
);
```
#236 ca1d4ec Thanks @steveluscher! - The minimum TypeScript version is now 5.3.3

@solana/functional@2.1.1

Patch Changes

#473 36a9dee Thanks @steveluscher! - The identity of all branded types has changed in such a way that the types from v2.1.1 will be compatible with any other version going forward, which is not the case for versions v2.1.0 and before.
If you end up with a mix of versions in your project prior to v2.1.1 (eg. @solana/addresses@2.0.0 and @solana/addresses@2.1.0) you may discover that branded types like Address raise a type error, even though they are runtime compatible. Your options are:
1. Always make sure that you have exactly one instance of each @solana/* dependency in your project at any given time
2. Upgrade all of your @solana/* dependencies to v2.1.1 at minimum, even if their minor or patch versions differ.
3. Suppress the type errors using a comment like the following:
```
const myAddress = address('1234..5678'); // from @solana/addresses@2.0.0
const myAccount = await fetchEncodedAccount(
    // imports @solana/addresses@2.1.0
    rpc,
    // @ts-expect-error Address types mismatch between installed versions of @solana/addresses
    myAddress,
);
```
#236 ca1d4ec Thanks @steveluscher! - The minimum TypeScript version is now 5.3.3

@solana/promises@2.1.1

Patch Changes

#473 36a9dee Thanks @steveluscher! - The identity of all branded types has changed in such a way that the types from v2.1.1 will be compatible with any other version going forward, which is not the case for versions v2.1.0 and before.
If you end up with a mix of versions in your project prior to v2.1.1 (eg. @solana/addresses@2.0.0 and @solana/addresses@2.1.0) you may discover that branded types like Address raise a type error, even though they are runtime compatible. Your options are:
1. Always make sure that you have exactly one instance of each @solana/* dependency in your project at any given time
2. Upgrade all of your @solana/* dependencies to v2.1.1 at minimum, even if their minor or patch versions differ.
3. Suppress the type errors using a comment like the following:
```
const myAddress = address('1234..5678'); // from @solana/addresses@2.0.0
const myAccount = await fetchEncodedAccount(
    // imports @solana/addresses@2.1.0
    rpc,
    // @ts-expect-error Address types mismatch between installed versions of @solana/addresses
    myAddress,
);
```
#236 ca1d4ec Thanks @steveluscher! - The minimum TypeScript version is now 5.3.3

@solana/rpc-parsed-types@2.1.1

Patch Changes

#473 36a9dee Thanks @steveluscher! - The identity of all branded types has changed in such a way that the types from v2.1.1 will be compatible with any other version going forward, which is not the case for versions v2.1.0 and before.
If you end up with a mix of versions in your project prior to v2.1.1 (eg. @solana/addresses@2.0.0 and @solana/addresses@2.1.0) you may discover that branded types like Address raise a type error, even though they are runtime compatible. Your options are:
1. Always make sure that you have exactly one instance of each @solana/* dependency in your project at any given time
2. Upgrade all of your @solana/* dependencies to v2.1.1 at minimum, even if their minor or patch versions differ.
3. Suppress the type errors using a comment like the following:
```
const myAddress = address('1234..5678'); // from @solana/addresses@2.0.0
const myAccount = await fetchEncodedAccount(
    // imports @solana/addresses@2.1.0
    rpc,
    // @ts-expect-error Address types mismatch between installed versions of @solana/addresses
    myAddress,
);
```
#236 ca1d4ec Thanks @steveluscher! - The minimum TypeScript version is now 5.3.3

@solana/rpc-spec-types@2.1.1

Patch Changes

#473 36a9dee Thanks @steveluscher! - The identity of all branded types has changed in such a way that the types from v2.1.1 will be compatible with any other version going forward, which is not the case for versions v2.1.0 and before.
If you end up with a mix of versions in your project prior to v2.1.1 (eg. @solana/addresses@2.0.0 and @solana/addresses@2.1.0) you may discover that branded types like Address raise a type error, even though they are runtime compatible. Your options are:
1. Always make sure that you have exactly one instance of each @solana/* dependency in your project at any given time
2. Upgrade all of your @solana/* dependencies to v2.1.1 at minimum, even if their minor or patch versions differ.
3. Suppress the type errors using a comment like the following:
```
const myAddress = address('1234..5678'); // from @solana/addresses@2.0.0
const myAccount = await fetchEncodedAccount(
    // imports @solana/addresses@2.1.0
    rpc,
    // @ts-expect-error Address types mismatch between installed versions of @solana/addresses
    myAddress,
);
```
#236 ca1d4ec Thanks @steveluscher! - The minimum TypeScript version is now 5.3.3

@solana/nominal-types@2.1.1

Patch Changes

#473 36a9dee Thanks @steveluscher! - The identity of all branded types has changed in such a way that the types from v2.1.1 will be compatible with any other version going forward, which is not the case for versions v2.1.0 and before.
If you end up with a mix of versions in your project prior to v2.1.1 (eg. @solana/addresses@2.0.0 and @solana/addresses@2.1.0) you may discover that branded types like Address raise a type error, even though they are runtime compatible. Your options are:
1. Always make sure that you have exactly one instance of each @solana/* dependency in your project at any given time
2. Upgrade all of your @solana/* dependencies to v2.1.1 at minimum, even if their minor or patch versions differ.
3. Suppress the type errors using a comment like the following:
```
const myAddress = address('1234..5678'); // from @solana/addresses@2.0.0
const myAccount = await fetchEncodedAccount(
    // imports @solana/addresses@2.1.0
    rpc,
    // @ts-expect-error Address types mismatch between installed versions of @solana/addresses
    myAddress,
);
```

anza-xyz/kit v2.1.1 on GitHub

2.1.1 (2025-05-12)

@solana/addresses@2.1.1

Patch Changes

@solana/errors@2.1.1

Patch Changes

@solana/rpc-transport-http@2.1.1

Patch Changes

@solana/sysvars@2.1.1

Patch Changes

@solana/accounts@2.1.1

Patch Changes

@solana/assertions@2.1.1

Patch Changes

@solana/codecs@2.1.1

Patch Changes

@solana/codecs-core@2.1.1

Patch Changes

@solana/codecs-data-structures@2.1.1

Patch Changes

@solana/codecs-numbers@2.1.1

Patch Changes

@solana/codecs-strings@2.1.1

Patch Changes

@solana/compat@2.1.1

Patch Changes

@solana/instructions@2.1.1

Patch Changes

@solana/keys@2.1.1

Patch Changes

@solana/kit@2.1.1

Patch Changes

@solana/options@2.1.1

Patch Changes

@solana/programs@2.1.1

Patch Changes

@solana/react@2.1.1

Patch Changes

@solana/rpc@2.1.1

Patch Changes

@solana/rpc-api@2.1.1

Patch Changes

@solana/rpc-graphql@2.1.1

Patch Changes

@solana/rpc-spec@2.1.1

Patch Changes

@solana/rpc-subscriptions@2.1.1

Patch Changes

@solana/rpc-subscriptions-api@2.1.1

Patch Changes

@solana/rpc-subscriptions-channel-websocket@2.1.1

Patch Changes

@solana/rpc-subscriptions-spec@2.1.1

Patch Changes

@solana/rpc-transformers@2.1.1

Patch Changes

@solana/rpc-types@2.1.1

Patch Changes

@solana/signers@2.1.1

Patch Changes

@solana/subscribable@2.1.1

Patch Changes

@solana/transaction-confirmation@2.1.1

Patch Changes

@solana/transaction-messages@2.1.1

Patch Changes

@solana/transactions@2.1.1

Patch Changes

@solana/webcrypto-ed25519-polyfill@2.1.1

Patch Changes

@solana/fast-stable-stringify@2.1.1

Patch Changes

@solana/functional@2.1.1

Patch Changes

@solana/promises@2.1.1

Patch Changes

@solana/rpc-parsed-types@2.1.1

Patch Changes

@solana/rpc-spec-types@2.1.1

Patch Changes

anza-xyz/kit v2.1.1
on GitHub