@solana/kit

v8.3.0 (2026-09-09)

Minor Changes

• [@solana/addresses, @solana/transaction-messages] #2025 7a14614 Thanks @lorisleiva! - Add a new HasAddress type representing any object exposing a Solana address through an address property — e.g. a TransactionSigner, an AccountMeta or a framework's address wrapper class. The fee payer of a transaction message is now typed using HasAddress (a structurally identical change).

• [@solana/codecs-core] #2030 a5267b3 Thanks @lorisleiva! - Add tap codec helpers for observing values and bytes without modifying them. The value family (tapEncoder/tapDecoder/tapCodec) observes the input value before encoding and the decoded value after decoding, whilst the bytes family (tapEncoderBytes/tapDecoderBytes/tapCodecBytes) observes the raw bytes after encoding and before decoding. Any tap may throw to abort the operation, making these helpers ideal for adding validation guards to existing codecs without an identity transformEncoder. For example, tapDecoderBytes(getBooleanDecoder(), (bytes, offset) => { if (bytes[offset] > 1) throw new Error('Expected a 0 or a 1 for booleans'); }).

• [@solana/codecs-data-structures] #2042 cd2776e Thanks @lorisleiva! - Add a requireSizePrefix option to the array, map and set codecs. By default, decoding an exhausted byte array yields an empty collection so that collections can be appended to existing data layouts; with requireSizePrefix: true, a missing size prefix throws instead.

• [@solana/codecs-numbers] #2029 3206678 Thanks @lorisleiva! - Add u256 and i256 number codecs (getU256Codec/getU256Encoder/getU256Decoder and getI256Codec/getI256Encoder/getI256Decoder), extending the number codecs beyond 128-bit integers. Both support little- and big-endian serialization via the endian option and, as with the other large-integer codecs, always decode to a bigint.

• [@solana/codecs-strings, @solana/errors] #2041 cae725c Thanks @lorisleiva! - Add fatal, ignoreBOM and removeNullCharacters options to the UTF-8 codec. With fatal, lone surrogates when encoding and malformed byte sequences when decoding throw a SolanaError instead of being replaced with U+FFFD. With ignoreBOM: true, a leading byte order mark is preserved instead of being stripped. With removeNullCharacters: false, null characters are preserved in decoded strings instead of being stripped as padding. On React Native, a leading byte order mark is now stripped by default, consistent with other platforms.

• [@solana/errors, @solana/program-client-core] #2025 7a14614 Thanks @lorisleiva! - Widen the accepted inputs of instruction accounts in generated program clients. The new InstructionAccountInput type accepts an Address, any address-bearing object (HasAddress) — including framework wrapper classes — a ProgramDerivedAddress or an AccountNonSignerMeta used to override the role declared by the program's IDL. Similarly, the new InstructionSignerInput type accepts a TransactionSigner or an AccountSignerMeta role override. In addition, ResolvedInstructionAccount now carries an optional isSigner flag describing the IDL's signer requirement: when set to false, TransactionSigner values act as plain address carriers instead of being upgraded to signers, and when set to true, a missing signer throws a helpful error pointing at createNoopSigner. Finally, new ResolvedInstructionAccountMeta and InstructionAccountInputAddress type helpers mirror this runtime logic at the type level so that generated instruction builders can accurately type the account metas they return.

• [@solana/instructions] #2025 7a14614 Thanks @lorisleiva! - Add a new AccountNonSignerMeta type representing an AccountMeta whose role is guaranteed not to be a signer role — i.e. ReadonlyAccount | WritableAccount. It is the counterpart of the AccountSignerMeta type from @solana/signers. Additionally, the role member of WritableAccount, ReadonlySignerAccount and WritableSignerAccount is now marked readonly, consistently with ReadonlyAccount and AccountMeta. Note that code mutating the role of these types will now fail to compile — which was already contrary to AccountMeta's contract and would throw at runtime on frozen account metas.

• [@solana/rpc-api, @solana/rpc-transport-http] #2016 1dd83c6 Thanks @mcintyre94! - Added support for the getAgGenesisCert RPC method, which returns the Alpenglow genesis certificate from nodes that have one

• [@solana/signers] #2031 8af3229 Thanks @lorisleiva! - Add createLazyKeyPairSignerFromBytes, a synchronous counterpart to createKeyPairSignerFromBytes. It derives the signer's address directly from the public key half of the 64-byte secret key and defers the asynchronous CryptoKey import until the first message or transaction is signed (memoising the result). This is useful when a signer must be created in a synchronous context whilst signing can remain asynchronous. Because the key import is deferred, the returned signer implements both MessagePartialSigner and TransactionPartialSigner but does not expose a keyPair property, and the cryptographic validation of the secret key happens on the first signing attempt rather than at creation time. The internal copy of the secret key is zeroed once the import succeeds, and a failed import is not cached so signing can be retried.

Patch Changes

• [@solana/rpc-transport-http] #2016 1dd83c6 Thanks @mcintyre94! - Fixed a bug where responses to getTransactionsForAddress requests were parsed without bigint support, risking precision loss on large integer values

@solana/kit

v8.2.0 (2026-08-29)

Minor Changes

• [@solana/instruction-plans] #2013 26edd3b Thanks @mcintyre94! - Align createTransactionPlanExecutorWithConcurrentLeaves with createTransactionPlanExecutor by giving both the same TransactionPlanExecutorConfig. Its executeTransactionMessage callback now receives a mutable per-leaf context object and returns the context of a successful result, instead of building a whole SingleTransactionPlanResult itself. The executor builds the results: on success it merges the returned context over the stored one, and when the callback throws — or the abort signal fires before it settles — it preserves the stored context on the failed result, matching the partial-context behaviour of createTransactionPlanExecutor. The ConcurrentLeafTransactionPlanExecutorConfig type is removed. This is a breaking change to the createTransactionPlanExecutorWithConcurrentLeaves API introduced in 8.1.0.

Patch Changes

• [@solana/signers] #2006 d385ce3 Thanks @amilz! - Relaxed the parameter type of the signer type guards (isMessagePartialSigner, isTransactionSigner, isKeyPairSigner, their siblings, and the assertIs* variants) so that class instances implementing a signer interface can be passed without casts. The guards now accept any TValue extends { address: Address } and narrow to TValue & Signer, whereas the previous parameter type required an implicit index signature, which TypeScript never grants to class instances.

@solana/kit

v8.1.0 (2026-08-27)

Minor Changes

• [@solana/errors, @solana/transaction-messages] #1972 7d56e29 Thanks @skyyycodes! - Validate compute unit limit and heap size when they are set on a transaction message

  setTransactionMessageComputeUnitLimit, setTransactionMessageHeapSize and setTransactionMessageConfig now reject values the runtime will not honor as written, throwing SOLANA_ERROR__TRANSACTION__COMPUTE_UNIT_LIMIT_OUT_OF_RANGE or SOLANA_ERROR__TRANSACTION__INVALID_HEAP_SIZE at the point the value is set. An invalid heap size fails the transaction on-chain; a compute unit limit above the maximum is instead clamped down by the runtime, so the transaction quietly runs with a budget other than the one requested. A compute unit limit must be an integer in the range [0, 1,400,000]; a heap size must be an integer multiple of 1 KiB between 32 KiB and 256 KiB inclusive.

  Decoding is unaffected: decompileTransactionMessage still returns messages carrying out-of-range values so that callers can inspect any transaction that reaches them.

• [@solana/instruction-plans] #1995 95a2788 Thanks @mcintyre94! - Add createTransactionPlanExecutorWithConcurrentLeaves to concurrently transform every transaction plan leaf while preserving the plan's result shape.

Patch Changes

• [@solana/codecs-core] #1970 be30e32 Thanks @koriyoshi2041! - Fix toArrayBuffer slicing SharedArrayBuffer-backed views from a non-zero byte offset.

• [@solana/codecs-data-structures] #1971 c51b9f6 Thanks @shin4141! - Preserve the literal fixedSize type for single-field fixed-size struct codecs.

• [@solana/codecs-strings] #1979 6852054 Thanks @amilz! - Fixed getBase64Decoder() throwing RangeError: Maximum call stack size exceeded in browser builds when decoding byte arrays larger than roughly 65KB. The bytes are now converted to a binary string in chunks rather than spread into a single String.fromCharCode call.

• [@solana/rpc, @solana/transaction-confirmation] #1994 490ac9e Thanks @matusbalascak! - Fix transaction confirmation and coalesced RPC request cancellation in environments where abort events have a null target.

@solana/kit

v8.0.0 (2026-08-21)

Major Changes

• [@solana/instruction-plans] #1913 80368eb Thanks @mcintyre94! - Stop writing to the execution context in createTransactionPlanExecutor

  The executeTransactionMessage callback can no longer return a Signature or a Transaction. Those return values were deprecated when the callback gained the ability to return the context that a successful result should carry, and they are now gone: that context, a complete TContext, is the only thing the callback returns. Nothing is written to it on your behalf.

  const transactionPlanExecutor = createTransactionPlanExecutor({
    executeTransactionMessage: async (context, message) => {
      const transaction = await signTransactionMessageWithSigners(message);
      context.transaction = transaction;
  +   const signature = getSignatureFromTransaction(transaction);
      await sendAndConfirmTransaction(transaction, { commitment: 'confirmed' });
  -   return transaction;
  +   return { signature, transaction };
    },
  });

  The mutable context argument is still there, and still serves the failure path: whatever the callback stores on it before it throws is preserved in the resulting FailedSingleTransactionPlanResult. The two channels differ only in which outcome they feed. Mutating the context makes a value available to a failed result; returning it makes a value available to a successful one. On success the two are merged, with the returned value taking precedence, so a property stored but not returned is still reported.

  Note that the callback cannot simply return the context it was given — every property on it is optional, so it does not satisfy TContext. Build the return value from the values you have instead. This is the point of the return type: a callback that declares a context with a required signature and never produces one now fails to compile, rather than yielding a successful result whose context.signature is typed but undefined at runtime.

  This unblocks executors that never obtain a fee payer signature. Previously the executor derived context.signature by calling getSignatureFromTransaction on a returned transaction, and on any transaction found on the context while handling a failure. That call throws SOLANA_ERROR__TRANSACTION__FEE_PAYER_SIGNATURE_MISSING when the fee payer slot is empty, so an executor that deliberately produces partially signed transactions — signed by an authority, to be paid for and submitted by a relayer later — could not succeed, and one that stored such a transaction before failing had its original error replaced by that one. Neither derivation exists any more, so both cases now work. Declare a context type that does not require a signature and store just the transaction:

  const transactionPlanExecutor = createTransactionPlanExecutor<{ transaction: Transaction }>({
      executeTransactionMessage: async (_context, message) => {
          return { transaction: await signTransactionMessageWithSigners(message) };
      },
  });

  Signatures are no longer added behind your back. An executor whose TContext requires a signature — including the default TransactionPlanResultContextWithSignature — must now produce one itself, and the compiler holds it to that. Failed results carry only what the callback stored on the context before it threw; a signature is no longer recovered from a stored transaction.

  BaseTransactionPlanResultContext is removed. It described the fields the executor used to write on your behalf, and nothing writes them any more — what a context holds is entirely TContext's business. Use TransactionPlanResultContextWithSignature where you want the signature guarantee, or declare the optional message / signature / transaction fields your own context actually needs.

  successfulSingleTransactionPlanResultFromTransaction is removed. It was the last place that derived a signature on your behalf — by calling getSignatureFromTransaction, with the same fee-payer-signature requirement described above — and the executor no longer uses it. Construct results with successfulSingleTransactionPlanResult instead, passing the context explicitly:

  - successfulSingleTransactionPlanResultFromTransaction(message, transaction);
  + successfulSingleTransactionPlanResult(message, {
  +   signature: getSignatureFromTransaction(transaction),
  +   transaction,
  + });

• [@solana/instruction-plans, @solana/kit, @solana/rpc-transformers, @solana/transactions] #1948 34568a9 Thanks @mcintyre94! - Remove APIs that were deprecated in previous versions: the compute-unit-limit estimation helpers in @solana/kit, the getBigIntDowncastRequestTransformer in @solana/rpc-transformers, the fixed transaction size constants in @solana/transactions, and the SuccessfulBaseTransactionPlanResultContext type in @solana/instruction-plans.

  BREAKING CHANGES

  estimateComputeUnitLimitFactory removed from @solana/kit. Use estimateResourceLimitsFactory instead. The resource-limits estimator returns both the compute unit limit and (for version 1 transactions) the loaded accounts data size limit from a single simulation call.

  - const estimateComputeUnitLimit = estimateComputeUnitLimitFactory({ rpc });
  - const computeUnitLimit = await estimateComputeUnitLimit(transactionMessage);
  + const estimateResourceLimits = estimateResourceLimitsFactory({ rpc });
  + const { computeUnitLimit } = await estimateResourceLimits(transactionMessage);

  estimateAndSetComputeUnitLimitFactory removed from @solana/kit. Use estimateAndSetResourceLimitsFactory instead, which additionally sets the loaded accounts data size limit for version 1 transactions.

  - const estimateAndSet = estimateAndSetComputeUnitLimitFactory(estimateComputeUnitLimitFactory({ rpc }));
  + const estimateAndSet = estimateAndSetResourceLimitsFactory(estimateResourceLimitsFactory({ rpc }));
    const updatedMessage = await estimateAndSet(transactionMessage);

  fillTransactionMessageProvisoryComputeUnitLimit removed from @solana/kit. Use fillTransactionMessageProvisoryResourceLimits instead, which additionally reserves space for the loaded accounts data size limit on version 1 transactions.

  - const filledMessage = fillTransactionMessageProvisoryComputeUnitLimit(transactionMessage);
  + const filledMessage = fillTransactionMessageProvisoryResourceLimits(transactionMessage);

  getBigIntDowncastRequestTransformer removed from @solana/rpc-transformers. This transformer was no longer used by the default Solana RPC request transformer. The Solana RPC transport serializes bigint values losslessly as large integer literals, and Agave parses JSON integers across the full u64 range without precision loss, so downcasting bigints to (potentially lossy) numbers is unnecessary. If you still need this behavior, recreate it with getTreeWalkerRequestTransformer.

  TRANSACTION_PACKET_SIZE, TRANSACTION_PACKET_HEADER, and TRANSACTION_SIZE_LIMIT removed from @solana/transactions. Transaction size is no longer constant, as version 1 transactions have a larger size limit. Use getTransactionSizeLimit to get the size limit for a specific transaction based on its version, or the LEGACY_TRANSACTION_SIZE_LIMIT and V1_TRANSACTION_SIZE_LIMIT constants for a specific version.

  - const numFreeBytes = TRANSACTION_SIZE_LIMIT - getTransactionSize(transaction);
  + const numFreeBytes = getTransactionSizeLimit(transaction) - getTransactionSize(transaction);

  SuccessfulBaseTransactionPlanResultContext removed from @solana/instruction-plans. Use TransactionPlanResultContextWithSignature instead as the context type argument.

  - function processResult(result: SuccessfulSingleTransactionPlanResult<SuccessfulBaseTransactionPlanResultContext>) {
  + function processResult(result: SuccessfulSingleTransactionPlanResult<TransactionPlanResultContextWithSignature>) {

• [@solana/instruction-plans] #1910 7b983ba Thanks @mcintyre94! - Let TContext decide what a transaction plan result context contains

  The context attached to a transaction plan result was never entirely controlled by the executor. SuccessfulSingleTransactionPlanResult hardcoded it as SuccessfulBaseTransactionPlanResultContext & TContext, and createTransactionPlanExecutor mixed further properties into both the callback's context and the executor's result type. Because intersections only ever narrow, no choice of TContext could relax the required signature — which made it impossible to type an executor that partially signs transactions for a relayer to submit later.

  TContext is now the only thing that says what a context contains. The signature guarantee moved out of the structure of the result types and into the default value of TContext, so every zero-type-argument spelling behaves exactly as it did before.

  A new context type. TransactionPlanResultContextWithSignature guarantees a signature and is the new default everywhere. SuccessfulBaseTransactionPlanResultContext is deprecated in favour of it.

  Explicit context types must be migrated. Intersect the new default to keep the signature guarantee:

  - SingleTransactionPlanResult<{ startedAt: number }>
  + SingleTransactionPlanResult<TransactionPlanResultContextWithSignature & { startedAt: number }>

  The executor callback now receives Partial<TContext>. A fresh, empty context is created for every transaction message and filling it in is the callback's job, but its properties used to be typed as required — so a callback could read one before writing it, be told a value was there, and get undefined at runtime. Everything is optional on entry now. Writing still narrows, so a read after context.custom = 'value' gives the non-optional type.

  One consequence is that a callback can no longer annotate its own parameter with required properties, which was a common way to infer a custom context. Use a type argument instead:

  - createTransactionPlanExecutor({
  -     executeTransactionMessage: async (context: { startedAt: number }) => { /* ... */ },
  - })
  + createTransactionPlanExecutor<TransactionPlanResultContextWithSignature & { startedAt: number }>({
  +     executeTransactionMessage: async context => { /* ... */ },
  + })

  A returned context no longer has to carry a signature. The executeTransactionMessage callback may return the context that a successful result should carry, and that context used to need a signature because the result type hardcoded one. TContext decides now: the default still requires it, and a custom TContext that omits it is accepted — which is what makes the relayer case above expressible end to end, rather than merely possible at runtime. Consequently the executor no longer tells a returned context apart from a returned Transaction by looking for a signature on it, since a context may not have one; it looks for the signatures map that only a Transaction has.

  Failed and canceled results type their context as Readonly<Partial<TContext>>. Those branches never guaranteed custom properties at runtime — the context is built incrementally and the callback may throw at any point — so the types now say so.

  Inference from object literals is narrower, since the result constructors no longer add properties you did not pass. successfulSingleTransactionPlanResult(message, { signature }) infers Readonly<{ signature: Signature }> rather than a context that also carried optional message and transaction fields plus an index signature, so reading result.context.message off it is now an error. On the failed and canceled constructors the Partial goes further: even a field you did pass comes back optional, so failedSingleTransactionPlanResult(message, error, { transaction }).context.transaction is Transaction | undefined. Pass an explicit type argument wherever you need a field to type as required. Relatedly, successfulSingleTransactionPlanResultFromTransaction's optional context parameter changes from Omit<BaseTransactionPlanResultContext, 'signature' | 'transaction'> & TContext to TContext; signature and transaction are still derived from the transaction argument and intersected into the result's context type.

  Helpers that consume results now accept any context. passthroughFailedTransactionPlanExecution, createFailedToSendTransactionError, createFailedToSendTransactionsError and createFailedToExecuteTransactionPlanError were non-generic, so they implicitly demanded the default signature-guaranteeing context and rejected results parameterised with anything else. They are now generic over TContext and preserve it. Where they read a signature to build an error message they narrow it at runtime, so a result without one simply omits it from the message.

  Execution behaviour is unchanged. The executor still populates context.signature from the signature or transaction your callback returns, and still recovers one for failed results from a transaction left on the context. Those writes just no longer show up in the result type unless your TContext asked for them. The behavioural changes are the two described above: an error message built from a context whose signature is absent, or is not a string, now omits it rather than interpolating whatever was there, and a returned context is recognised by the absence of a signatures map rather than the presence of a signature.

Minor Changes

• [@solana/errors, @solana/instruction-plans] #1902 cb09af6 Thanks @mcintyre94! - Add SOLANA_ERROR__FAILED_TO_SIGN_TRANSACTION and SOLANA_ERROR__FAILED_TO_SIGN_TRANSACTIONS error codes, together with the createFailedToSignTransactionError and createFailedToSignTransactionsError factories that raise them. These are the signing counterparts to the existing failed-to-send codes and factories, intended for high-level wrappers that sign transactions without submitting them: such a wrapper can now translate the low-level SOLANA_ERROR__INSTRUCTION_PLANS__FAILED_TO_EXECUTE_TRANSACTION_PLAN thrown by an executor into a user-facing error, exactly as the sending wrappers already do.

  The signing errors carry the same context as their sending counterparts, including the non-enumerable transactionPlanResult and the optional simulation logs and preflightData. Those simulation fields are populated for signing too, because executors typically estimate resource limits by simulating before they sign, so a failed estimation reaches the error the same way it does when sending.

  They differ from the sending errors in one respect: the message carries no indicator of where the failure happened. That indicator exists to locate a failure relative to network submission — (preflight) before it, or the transaction signature after it — and signing never submits, so neither applies. A signature would be particularly misleading, since quoting one implies the transaction reached the network when it never did. The logs and preflightData context properties are still populated whenever a simulation was responsible, and those logs still appear in the message, so only the prefix is dropped.

• [@solana/plugin-interfaces] #1899 82a88d8 Thanks @mcintyre94! - Add a ClientWithTransactionSigning interface providing signTransaction and signTransactions. These accept the same flexible inputs as their ClientWithTransactionSending counterparts, but hand back the signed transactions instead of submitting them. The interface is parameterised over the context attached to its results and makes no default guarantees about that context: what it contains is entirely decided by the plugin providing the capability — typically a context.transaction on successful results.

  ClientWithTransactionSending now also accepts an optional TContext type parameter that flows through to the results of sendTransaction and sendTransactions. Unlike the signing interface, it defaults to TransactionPlanResultContextWithSignature for backward compatibility, so existing usage keeps the required context.signature on successful results.

• [@solana/rpc-api, @solana/rpc-graphql, @solana/rpc-transformers, @solana/rpc-types, @solana/transaction-messages] #1951 94adb60 Thanks @amilz! - Fill in several gaps in transaction v1 (SIMD-0385) support.

  @solana/transaction-messages now exports its v1-transaction-config module, so setTransactionMessageConfig, the V1TransactionConfig type and the transaction config bit-mask helpers are importable. Previously the module was built and shipped but omitted from the package index, forcing consumers onto the four single-field setters and to derive the config type by hand.

  The V1TransactionConfig.computeUnitLimit docstring incorrectly described the legacy fallback of 200,000 compute units per instruction. On version 1 an unset computeUnitLimit resolves to zero and the transaction fails at execution, so the docstring now says so, as does the one for loadedAccountsDataSizeLimit.

  @solana/rpc-types transaction message types now carry the transactionConfig that the server returns for version 1 transactions, so reading a transaction's compute budget no longer requires a cast. Its three u32 fields are typed and transformed as number rather than being upcast to bigint, leaving priorityFee as the only Lamports among them. @solana/rpc-api carries the same field on the message shape it uses for the json and jsonParsed encodings of getTransaction and getTransactionsForAddress. The same field is exposed on the TransactionMessage type in @solana/rpc-graphql.

• [@solana/transaction-messages] #1950 ca01807 Thanks @mcintyre94! - Add support for version 1 transaction messages to createTransactionMessage. You can now pass { version: 1 } to create an empty v1 transaction message.

  This means that code using version 1 transaction messages will now type check.

Patch Changes

• [@solana/codecs-core] #1957 1b30374 Thanks @mcintyre94! - Fix toArrayBuffer returning the entire backing buffer when given a Uint8Array view that starts at byte offset zero but is shorter than its underlying ArrayBuffer. This caused signBytes and verifySignature to operate on the wrong bytes — and getBase64Decoder().decode() to include trailing data — for such views, most notably the messageBytes of a decoded version 1 transaction, whose wire envelope places the message first and the signatures last

• [@solana/transactions] #1958 5d526f7 Thanks @mcintyre94! - Fix getTransactionSizeLimit misclassifying single-signer legacy transactions as version 1. A legacy message has no version byte, so its first byte is the number of required signatures — 1 for every single-signer transaction — which was mistaken for a v1 version byte. As a result, isTransactionWithinSizeLimit, assertIsTransactionWithinSizeLimit, and assertIsSendableTransaction accepted legacy transactions of up to 4096 bytes that the network rejects at 1232 bytes. The version flag (high bit) of the first message byte is now required to be set before treating a transaction as version 1