Skip to content

Releases: anza-xyz/kit

v4.0.0

08 Oct 22:14
322edac

Choose a tag to compare

@solana/kit

v4.0.0 (2025-10-08)

Major Changes

  • [@solana/react, @solana/signers] #927 c035ab8 Thanks @mcintyre94! - Update the signer API to return Transaction & TransactionWithLifetime

    The modifyAndSignTransactions function for a TransactionModifyingSigner must now return a Transaction & TransactionWithLifetime & TransactionWithinSizeLimit. Previously it technically needed to return a type derived from the input TransactionMessage, but this wasn't checked.

    If you have written a TransactionModifyingSigner then you should review the changes to useWalletAccountTransactionSigner in the React package for guidance. You may need to use the new getTransactionLifetimeConstraintFromCompiledTransactionMessage function to obtain a lifetime for the transaction being returned.

    If you are using a TransactionModifyingSigner such as useWalletAccountTransactionSigner, then you will now receive a transaction with TransactionWithLifetime when you would previously have received a type with a lifetime matching the input transaction message. This was never guaranteed to match at runtime, but we incorrectly returned a stronger type than can be guaranteed. You may need to use the new isTransactionWithBlockhashLifetime or isTransactionWithDurableNonceLifetime functions to check the lifetime type of the returned transaction. For example, if you want to pass it to a function returned by sendAndConfirmTransactionFactory then you must use isTransactionWithBlockhashLifetime or assertIsTransactionWithBlockhashLifetime to check its lifetime first.

  • [@solana/rpc-graphql, @solana/rpc-subscriptions-api, @solana/rpc-types] #550 ce7f91c Thanks @steveluscher! - Removed rentEpoch from the AccountInfoBase type. This property is no longer relevant post SIMD-215. Developers whose applications rely on this property being numeric should either eliminate it or hardcode it to 18_446_744_073_709_551_615n.

Minor Changes

Patch Changes

  • [@solana/codecs-core, @solana/errors] #944 22f18d0 Thanks @mcintyre94! - Add a function to create a decoder that checks the size of the input bytes

  • [@solana/compat] #906 eabeb3a Thanks @guibescos! - Fixed a bug where calling fromVersionedTransaction() with a VersionedTransaction that uses address table lookups would result in a runtime fatal

  • [@solana/errors, @solana/transactions] #918 5408f52 Thanks @mcintyre94! - Add a function to extract the lifetime from a CompiledTransactionMessage

  • [@solana/errors, @solana/transaction-messages, @solana/transactions] #871 cb11699 Thanks @mcintyre94! - Do not allow decoding transactions with an unsupported version

  • [@solana/errors] #873 9fa8465 Thanks @steveluscher! - When you use the @solana/errors CLI you will now always get version 5.6.2 of chalk and version 14.0.0 of commander, which themselves are zero-dependency.

  • [@solana/errors, @solana/react] #919 c87cada Thanks @mcintyre94! - Update useWalletAccountTransactionSigner to return a LifetimeConstraint for the updated transaction

  • [@solana/keys] #901 f591dea Thanks @guibescos! - Added assertion (assertIsSignatureBytes), guard (isSignatureBytes), and coercion (signatureBytes) methods to make it easier to work with callsites that demand a SignatureBytes type

  • [@solana/kit] #521 98bde94 Thanks @tao-stones! - Add loadedAccountsDataSize to simulateTransaction response

  • [@solana/rpc-subscriptions] #904 9e8bfe4 Thanks @steveluscher! - yExported all of the channel creators that form part of createDefaultSolanaRpcSubscriptionsChannelCreator() so that developers can configure their own custom channels

  • [@solana/transaction-confirmation] #793 cfc1d92 Thanks @steveluscher! - Fixed a bug where transaction errors discovered during recent transaction confirmation might not be thrown

  • [@solana/transaction-messages] #951 54d8445 Thanks @tanmay5114! - compressTransactionMessageUsingAddressLookupTables() will no longer convert an account to a lookup table account, if the address of that account is used as a program address anywhere in the transaction.

  • [@solana/transactions] #925 af01f27 Thanks @mcintyre94! - Add functions to narrow a TransactionWithLifetime to a specific lifetime

  • [@solana/webcrypto-ed25519-polyfill] #806 f254415 Thanks @steveluscher! - The Ed25519 polyfill now correctly returns ArrayBuffer from exportKey() and sign() rather than Uint8Array

v3.0.3

11 Sep 03:53
27da24a

Choose a tag to compare

@solana/kit

v3.0.3 (2025-09-11)

Patch Changes

  • [@solana/errors] #874 a085209 Thanks @github-actions! - When you use the @solana/errors CLI you will now always get version 5.6.2 of chalk and version 14.0.0 of commander, which themselves are zero-dependency.

v3.0.2

03 Sep 16:57
ed21791

Choose a tag to compare

@solana/kit

v3.0.2 (2025-09-03)

Patch Changes

v3.0.1

29 Aug 20:17
ab2a13c

Choose a tag to compare

@solana/kit

v3.0.1 (2025-08-29)

Patch Changes

  • [@solana/transaction-confirmation] #803 eb0a122 Thanks @github-actions! - Fixed a bug where transaction errors discovered during recent transaction confirmation might not be thrown

v3.0.0

27 Aug 15:31
f990cee

Choose a tag to compare

@solana/kit

v3.0.0 (2025-08-27)

Major Changes

  • [@solana/codecs-data-structures] #691 771f8ae Thanks @lorisleiva! - BREAKING CHANGE: Removes the following deprecated functions: getDataEnumEncoder, getDataEnumDecoder, getDataEnumCodec, getScalarEnumEncoder, getScalarEnumDecoder and getScalarEnumCodec.

  • [@solana/instructions] #691 771f8ae Thanks @lorisleiva! - BREAKING CHANGE: Removes the following deprecated types: IAccountMeta, IAccountLookupMeta, IInstruction, IInstructionWithAccounts and IInstructionWithData.

  • [@solana/kit, @solana/transactions] #482 00d66fb Thanks @lorisleiva! - BREAKING CHANGE: Transactions must now satisfy the SendableTransaction type before being provided to helper functions that send transactions to the network. On top of ensuring the transaction is fully signed, this type also ensures the transaction is within size limit.

  • [@solana/kit, @solana/transaction-messages] #594 733605d Thanks @lorisleiva! - Extract lifetime token from CompiledTransactionMessage. CompiledTransactionMessage & CompiledTransactionMessageWithLifetime may now be used to refer to a compiled transaction message with a lifetime token. This enables CompiledTransactionMessages to be encoded without the need to specify a mock lifetime token.

  • [@solana/kit, @solana/signers, @solana/transactions] #462 a74ea02 Thanks @lorisleiva! - BREAKING CHANGE: The FullySignedTransaction no longer extends the Transaction type so it can be composed with other flags that also narrow transaction types. This means, whenever FullySignedTransaction is used on its own, it will need to be replaced with FullySignedTransaction & Transaction.

  • [@solana/kit] #691 771f8ae Thanks @lorisleiva! - BREAKING CHANGE: Removes the getComputeUnitEstimateForTransactionMessageFactory deprecated function.

  • [@solana/rpc-spec-types] #732 81c83b1 Thanks @nonergodic! - BREAKING CHANGE: Rename stringifyJsonWithBigints to stringifyJsonWithBigInts for consistency with the rest of the API.

  • [@solana/signers, @solana/transactions] #574 0bd053b Thanks @lorisleiva! - Add the TransactionWithLifetime requirement when signing transactions. This is because, whilst a lifetime may not always be required before compile a transaction message, it is always required when signing a transaction. Otherwise, the transaction signatures will be invalid when one is added later.

  • [@solana/signers] #691 771f8ae Thanks @lorisleiva! - BREAKING CHANGE: Removes the following deprecated types: ITransactionMessageWithSigners, ITransactionMessageWithFeePayerSigner, ITransactionMessageWithSingleSendingSigner, IAccountSignerMeta and IInstructionWithSigners.

  • [@solana/transaction-messages] #691 771f8ae Thanks @lorisleiva! - BREAKING CHANGE: Removes the following deprecated types and functions: CompilableTransactionMessage, ITransactionMessageWithFeePayer, assertIsDurableNonceTransactionMessage and isDurableNonceTransaction. Removes the deprecated readableIndices and writableIndices properties from the AddressTableLookup type — use readonlyIndexes and writableIndexes respectively instead.

  • [@solana/transactions] #691 771f8ae Thanks @lorisleiva! - BREAKING CHANGE: Removes the assertTransactionIsFullySigned deprecated function.

  • [@solana/transactions] #581 55d6b04 Thanks @lorisleiva! - Allow transaction messages with no lifetime constraints to be compiled. Renames TransactionFromCompilableTransactionMessage and SetTransactionLifetimeFromCompilableTransactionMessage type helpers to TransactionFromTransactionMessage and SetTransactionLifetimeFromTransactionMessage respectively, to reflect that they can now be used with transaction messages that do not have a lifetime constraint.

Minor Changes

  • [@solana/errors, @solana/instruction-plans] #664 9feba85 Thanks @lorisleiva! - Add createTransactionPlanExecutor implementation for the TransactionPlanExecutor type.

  • [@solana/errors, @solana/instruction-plans] #648 01f159a Thanks @lorisleiva! - Add createTransactionPlanner implementation for the TransactionPlanner type.

  • [@solana/instruction-plans] #543 358df82 Thanks @lorisleiva! - Add new TransactionPlanResult type with helpers. This type describes the execution results of transaction plans with the same structural hierarchy — capturing the execution status of each transaction message whether executed in parallel, sequentially, or as a single transaction.

  • [@solana/instruction-plans] #546 12d06d1 Thanks @lorisleiva! - Add a TransactionPlanner function type that defines how InstructionPlans gets planned and turned into TransactionPlans.

  • [@solana/instruction-plans] #547 24967d1 Thanks @lorisleiva! - Add a TransactionPlanExecutor function type that defines how TransactionPlans get executed and turned into TransactionPlanResults.

  • [@solana/instruction-plans] #533 7d48ccd Thanks @lorisleiva! - Add a new @solana/instruction-plans package offering a new InstructionPlan type that aims to describe a set of instructions with constraints on how they should be executed — e.g. sequentially, in parallel, divisible, etc.

  • [@solana/instruction-plans] #542 f79d05a Thanks @lorisleiva! - Add new TransactionPlan type with helpers. This type defines a set of transaction messages with constraints on how they should be executed — e.g. sequentially, in parallel, divisible, etc.

  • [@solana/kit] #725 ce8f9db Thanks @lorisleiva! - Re-export @solana/instruction-plans from @solana/kit.

  • [@solana/signers] #582 93ae6f9 Thanks @lorisleiva! - Allow transaction messages with no lifetime constraints to be signed using the Signer API helpers such as signTransactionMessageWithSigners and partiallySignTransactionMessageWithSigners. This is because some TransactionSigners such as TransactionModifyingSigners have the ability to update the transaction before signing it, meaning that the lifetime constraint may not be known until the transaction is signed.

  • [@solana/signers, @solana/transaction-messages] #581 55d6b04 Thanks @lorisleiva! - Allow transaction messages with no lifetime constraints to be compiled. Renames TransactionFromCompilableTransactionMessage and `SetTransactionLifetimeFromCompilableTransacti...

Read more

v2.3.0

09 Jul 23:54
15c044c

Choose a tag to compare

2.3.0 (2025-07-08)

@solana/[email protected]

Minor Changes

  • #488 810d6ab Thanks @lorisleiva! - Remove the I prefix on the following types: IInstruction, IInstructionWithAccounts, IInstructionWithData, IInstructionWithSigners, IAccountMeta, IAccountLookupMeta and IAccountSignerMeta. The old names are kept as aliases but marked as deprecated.

Patch Changes

@solana/[email protected]

Minor Changes

  • #426 b7dfe03 Thanks @lorisleiva! - Deprecate the I prefix of four transaction message types to stay consistent with the rest of them. Namely, the following types are renamed and their old names are marked as deprecated:
    • ITransactionMessageWithFeePayer -> TransactionMessageWithFeePayer
    • ITransactionMessageWithFeePayerSigner -> TransactionMessageWithFeePayerSigner
    • ITransactionMessageWithSigners -> TransactionMessageWithSigners
    • ITransactionMessageWithSingleSendingSigner -> TransactionMessageWithSingleSendingSigner

Patch Changes

  • #566 363e3cc Thanks @steveluscher! - The unitsConsumed property in simulation result errors was incorrectly marked as a number when it is in fact a bigint

  • #567 eeac21d Thanks @steveluscher! - Added replacementBlockhash to the simulation result type. This field materializes in cases where simulation was performed with the replaceRecentBlockhash param set to true.

  • #425 93609aa Thanks @lorisleiva! - Add a variety of types, constants and functions to help with transaction sizes and their limits

@solana/[email protected]

Minor Changes

  • #488 810d6ab Thanks @lorisleiva! - Remove the I prefix on the following types: IInstruction, IInstructionWithAccounts, IInstructionWithData, IInstructionWithSigners, IAccountMeta, IAccountLookupMeta and IAccountSignerMeta. The old names are kept as aliases but marked as deprecated.

Patch Changes

@solana/[email protected]

Minor Changes

  • #426 b7dfe03 Thanks @lorisleiva! - Deprecate the I prefix of four transaction message types to stay consistent with the rest of them. Namely, the following types are renamed and their old names are marked as deprecated:

    • ITransactionMessageWithFeePayer -> TransactionMessageWithFeePayer
    • ITransactionMessageWithFeePayerSigner -> TransactionMessageWithFeePayerSigner
    • ITransactionMessageWithSigners -> TransactionMessageWithSigners
    • ITransactionMessageWithSingleSendingSigner -> TransactionMessageWithSingleSendingSigner
  • #488 810d6ab Thanks @lorisleiva! - Remove the I prefix on the following types: IInstruction, IInstructionWithAccounts, IInstructionWithData, IInstructionWithSigners, IAccountMeta, IAccountLookupMeta and IAccountSignerMeta. The old names are kept as aliases but marked as deprecated.

Patch Changes

@solana/[email protected]

Minor Changes

  • #468 6ccbf01 Thanks @lorisleiva! - Add, remove and forward the TransactionMessageWithinSizeLimit and TransactionWithinSizeLimit types in all helpers that may affect the size of a transaction or transaction message.

  • #426 b7dfe03 Thanks @lorisleiva! - Deprecate the I prefix of four transaction message types to stay consistent with the rest of them. Namely, the following types are renamed and their old names are marked as deprecated:

    • ITransactionMessageWithFeePayer -> TransactionMessageWithFeePayer
    • ITransactionMessageWithFeePayerSigner -> TransactionMessageWithFeePayerSigner
    • ITransactionMessageWithSigners -> TransactionMessageWithSigners
    • ITransactionMessageWithSingleSendingSigner -> TransactionMessageWithSingleSendingSigner
  • #488 810d6ab Thanks @lorisleiva! - Remove the I prefix on the following types: IInstruction, IInstructionWithAccounts, IInstructionWithData, IInstructionWithSigners, IAccountMeta, IAccountLookupMeta and IAccountSignerMeta. The old names are kept as aliases but marked as deprecated.

Patch Changes

Read more

v2.2.1

08 Jul 18:55
f920312

Choose a tag to compare

2.2.1 (2025-07-08)

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

@solana/[email protected]

@solana/[email protected]

@solana/[email protected]

@solana/p...

Read more

v2.2.0

08 Jul 18:54
c86f457

Choose a tag to compare

2.2.0 (2025-07-07)

@solana/[email protected]

Minor Changes

  • 85925d6 Thanks @nickfrosty! - Added an OffCurveAddress type to represent addresses for which there is no associated private key. These are addresses that can not be signed for by keyholders, only by programs. An example of such an address is the address of an associated token account, for which only the Token Program can sign transactions that seek to modify its contents.

    Also added an offCurveAddress() function that you can use to assert and coerce an Address to an OffCurveAddress, as well as an isOffCurveAddress() guard function, and a assertIsOffCurveAddress() assertion function.

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

  • 85925d6 Thanks @nickfrosty! - Added AffinePoint; a nominal type that you can use to tag a value as representing an affine point over some field that is either valid or invalid from the perspective of some curve. Typically this will be used to tag an address as either on or off curve.

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

  • ...
Read more

v2.1.1

15 May 21:32
10b159b

Choose a tag to compare

2.1.1 (2025-05-12)

@solana/[email protected]

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/[email protected] and @solana/[email protected]) 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/[email protected]
      const myAccount = await fetchEncodedAccount(
          // imports @solana/[email protected]
          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/[email protected]

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/[email protected] and @solana/[email protected]) 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/[email protected]
      const myAccount = await fetchEncodedAccount(
          // imports @solana/[email protected]
          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/[email protected]

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/[email protected] and @solana/[email protected]) 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/[email protected]
      const myAccount = await fetchEncodedAccount(
          // imports @solana/[email protected]
          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/[email protected]

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/[email protected] and @solana/[email protected]) 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/[email protected]
      const myAccount = await fetchEncodedAccount(
          // imports @solana/[email protected]
          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/[email protected]

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/[email protected] and @solana/[email protected]) 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/[email protected]
      const myAccount = await fetchEncodedAccount(
          // imports @solana/[email protected]
          rpc,
          // @ts-expect-error Address types mismatch between installed versions of @solana/addresses
          myAddress,
      );
  • #236 ca1d4ec Thanks [@steveluscher](https://github....

Read more

v2.1.0

28 Feb 18:14
a164c87

Choose a tag to compare

2.1.0 (2025-02-27)

🎉 @solana/kit is the new name for the 2.x line of @solana/web3.js.

This should make it easier to adopt in projects that will continue to depend on the legacy 1.x line of web3.js for the time being. It will also prevent confusion for new developers who might install the 2.x line while following a legacy 1.x tutorial.

In time, more guide-based content will be released; in the meantime take a look at the READMEs, the examples/ directory, and https://tsdocs.dev/docs/@solana/kit. If you have questions, please post at https://sola.na/sse.

@solana/[email protected]

Minor Changes

  • #117 0c577eb Thanks @beeman! - Add getPublicKeyFromAddress to derive public keys from addresses

Patch Changes

@solana/[email protected]

Minor Changes

  • 5af7f20 Thanks @steveluscher! - When the HTTP transport throws an error, you can now access the response headers through e.context.headers. This can be useful, for instance, if the HTTP error is a 429 Rate Limit error, and the response contains a Retry-After header.

    try {
        const { value: latestBlockhash } = await rpc.getLatestBlockhash().send();
    } catch (e) {
        if (isSolanaError(e, SOLANA_ERROR__RPC__TRANSPORT_HTTP_ERROR)) {
            if (e.context.code === 429 /* rate limit error */) {
                const retryAfterHeaderValue = e.context.headers.get('Retry-After');
                if (retryAfterHeaderValue != null) {
                    // ...
                }
            }
        }
    }

Patch Changes

  • 1adf435 Thanks @leantOnSol! - A two-versions-old version of Node LTS is now specified everywhere via the engines field, including the one in the root of the pnpm workspace, and engine-strictness is delegated to the .npmrc files.

  • #130 c7b7dd9 Thanks @lorisleiva! - Gracefully handle JSON RPC errors that do not provide a code attribute in their response

  • 704d8a2 Thanks @mcintyre94! - Change data field of transaction message instructions to use ReadonlyUint8Array

@solana/[email protected]

Minor Changes

  • 5af7f20 Thanks @steveluscher! - When the HTTP transport throws an error, you can now access the response headers through e.context.headers. This can be useful, for instance, if the HTTP error is a 429 Rate Limit error, and the response contains a Retry-After header.

    try {
        const { value: latestBlockhash } = await rpc.getLatestBlockhash().send();
    } catch (e) {
        if (isSolanaError(e, SOLANA_ERROR__RPC__TRANSPORT_HTTP_ERROR)) {
            if (e.context.code === 429 /* rate limit error */) {
                const retryAfterHeaderValue = e.context.headers.get('Retry-After');
                if (retryAfterHeaderValue != null) {
                    // ...
                }
            }
        }
    }

Patch Changes

@solana/[email protected]

Minor Changes

  • c880687 Thanks @steveluscher! - Removed the fees sysvar which has been disabled on the network for a year, and has now been removed from the test validator in Agave 2.0

    % solana feature status JAN1trEUEtZjgXYzNBYHU9DYd7GnThhXfFP7SzPXkPsG
    Feature                                      | Status                  | Activation Slot | Description
    JAN1trEUEtZjgXYzNBYHU9DYd7GnThhXfFP7SzPXkPsG | active since epoch 483  | 208656004       | disable fees sysvar
    

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

@solana/[email protected]

Patch Changes

  • 1adf435 Thanks @leantOnSol! - A two-versions-old version of Node LTS is now specified everywhere via the engines field, including the one in the root of the pnpm workspace, and engine-strictness is delegated to the .npmrc files.

  • Updated dependencies [1adf435, [c7b7dd9](https://github.c...

Read more