[metamask-ci]

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package	Change	Age	Confidence
@solana/addresses (source)	^2.3.0 → ^8.6.0

---

Release Notes

anza-xyz/kit (@​solana/addresses)

v8.6.0

Compare Source

@​solana/kit

v8.6.0 (2026-10-28)

Minor Changes

• [@solana/errors] #​2155 f7e4ad2 Thanks @​mcintyre94! - Add the SOLANA_ERROR__WALLET__FEATURE_VERSION_UNSUPPORTED error code, thrown when an app requires a newer version of a wallet feature than the connected wallet supports (for example, a solana:signIn option that was introduced in v1.1.0 of the feature). Its context carries the featureName, the requiredVersion, the wallet's actualVersion and the walletName.

• [@solana/signers] #​2128 94d20bc Thanks @​amilz! - Add getSignersFromInstructionPlan, which extracts and deduplicates the TransactionSigners attached to the instructions of an InstructionPlan, alongside the existing getSignersFromInstruction and getSignersFromTransactionMessage helpers. This lets callers that compile and sign transactions themselves, instead of using a transaction plan executor, collect signers created internally by helpers that return instruction plans. Message packer plans are skipped since their instructions only exist once packed into a transaction message.

• [@solana/transaction-messages] #​2132 905b19a Thanks @​amilz! - decodeTransactionFromRpcResponse now decodes the transactionConfig of a version 1 json RPC response into the compiled message's configMask and configValues, so it matches the base64 and base58 decodes. getTransactionConfigMask and getTransactionConfigValues are now exported from @solana/transaction-messages.

• [@solana/transaction-messages] #​2134 c1d1fc8 Thanks @​amilz! - Export decompileTransactionConfig so a v1 compiled message's config can be read without decompiling the whole message.

• [@solana/transactions] #​2133 84ab269 Thanks @​amilz! - Export LEGACY_TRANSACTION_SIZE_LIMIT and V1_TRANSACTION_SIZE_LIMIT constants

Patch Changes

• [@solana/codecs-core] #​2125 22ef182 Thanks @​Iamsohungrynow! - addEncoderSentinel now throws SOLANA_ERROR__CODECS__ENCODED_BYTES_MUST_NOT_INCLUDE_SENTINEL when the encoded bytes end with the start of the sentinel, instead of writing bytes the decoder cuts short.

• [@solana/rpc-subscriptions] #​2121 5c8effc Thanks @​amilz! - Fix the channel pool removing an unrelated, healthy channel when the last subscriber of a channel that already errored or failed to construct aborts. The removed channel stayed open for its existing subscribers but was never vended to new subscriptions, and its own eventual teardown removed yet another healthy channel from the pool.

• [@solana/transaction-introspection] #​2132 905b19a Thanks @​amilz! - decodeTransactionFromRpcResponse now decodes the transactionConfig of a version 1 json RPC response into the compiled message's configMask and configValues, so it matches the base64 and base58 decodes. getTransactionConfigMask and getTransactionConfigValues are now exported from @solana/transaction-messages.

v8.5.0

Compare Source

@​solana/kit

v8.5.0 (2026-10-13)

Minor Changes

• [@solana/addresses] #​2115 e59ed8b Thanks @​lorisleiva! - Allow getAddressEncoder() and getAddressCodec() to encode any address-bearing object (HasAddress) in addition to plain Address values, so that signers and framework wrapper classes can be encoded directly without unwrapping them first. Decoders still return a plain Address. As a result, the encoder input type of codecs composing an address codec (e.g. a struct with an address field) is now inferred as Address | HasAddress instead of Address.

  const addressEncoder = getAddressEncoder();
  addressEncoder.encode(signer); // Same bytes as `addressEncoder.encode(signer.address)`.

• [@solana/codecs-data-structures, @solana/errors] #​2089 de1c63f Thanks @​latent-9! - Fix an infinite loop in the array, set, and map codecs' sentinel and remainder decoding strategies: a zero-byte item codec (e.g. getStructCodec([])) can never advance past a sentinel boundary or the end of the byte array, so decoding used to push elements until the process ran out of memory. Zero-byte fixed-size item codecs are now rejected on both the encoding and decoding sides when used with the sentinel or remainder strategies, throwing a new error instead: SOLANA_ERROR__CODECS__UNEXPECTED_ZERO_FIXED_SIZE_ITEM_FOR_ARRAY_LIKE_SIZE_STRATEGY. They remain allowed when the collection size is explicit.

• [@solana/errors] #​2111 0be380e Thanks @​mcintyre94! - Add the SOLANA_ERROR__WALLET__INVALID_MESSAGE_SIGNATURE and SOLANA_ERROR__WALLET__INVALID_SIGN_IN_OUTPUT error codes, thrown when a wallet returns a message signature or a sign-in output that fails verification. Their context carries the signing account's address and the walletName.

  Also add the SOLANA_ERROR__WALLET__INVALID_NUMBER_OF_OUTPUTS error code, thrown when a wallet feature returns a different number of outputs than the number of inputs it was given. Its context carries the expected and actual number of outputs, the featureName and the walletName.

• [@solana/errors, @solana/keys, @solana/webcrypto-ed25519-polyfill] #​2095 cfe1d62 Thanks @​mcintyre94! - verifySignature() now verifies strictly, regardless of whether the underlying WebCrypto implementation does so itself (Node.js, for instance, does not). It returns false when either the public key or the R component of the signature is a point of small order. Previously, trivially forged signatures could verify against small-order public keys such as 11111111111111111111111111111111.

  BREAKING CHANGES

  verifySignature() throws unless given an extractable public key. Checking the public key requires reading its bytes, so a non-extractable public key now causes it to throw a SolanaError with code SOLANA_ERROR__KEYS__VERIFICATION_REQUIRES_EXTRACTABLE_PUBLIC_KEY. The same error is thrown for a key that is not a public key, which WebCrypto never accepted for verification anyway (it threw an InvalidAccessError). Every public key produced by Kit is extractable; if you import one yourself, set extractable to true.

  - const publicKey = await crypto.subtle.importKey('raw', bytes, 'Ed25519', false, ['verify']);
  + const publicKey = await crypto.subtle.importKey('raw', bytes, 'Ed25519', true, ['verify']);
    await verifySignature(publicKey, signature, data);

  getPublicKeyFromPrivateKey() always returns an extractable public key. Public keys are not secret, so this mirrors the behavior of crypto.subtle.generateKey(). The extractable argument is deprecated and ignored.

  - const publicKey = await getPublicKeyFromPrivateKey(privateKey, true);
  + const publicKey = await getPublicKeyFromPrivateKey(privateKey);

  The Ed25519 polyfill now also rejects public keys and signature R components of small order, and opts out of @noble/ed25519's default ZIP-215 semantics.

• [@solana/wallet-account-signer] #​2112 9021e99 Thanks @​mcintyre94! - createMessageSignerFromWalletAccount now verifies each signature returned by the wallet against the account's address and the message the wallet signed, and modifyAndSignMessages rejects with SOLANA_ERROR__WALLET__INVALID_MESSAGE_SIGNATURE if any of them is invalid. It also rejects with SOLANA_ERROR__WALLET__INVALID_NUMBER_OF_OUTPUTS if the wallet returns a different number of signed messages than it was asked to sign. The returned message content and signatures are copies of the wallet's output, so the wallet cannot change them after they are verified. Verifying signatures requires Ed25519 support in the WebCrypto API; in environments without it, install @solana/webcrypto-ed25519-polyfill.

Patch Changes

• [@solana/codecs-strings] #​2117 7ea5132 Thanks @​Iamsohungrynow! - getBase16Encoder no longer drops the last digit of odd-length strings longer than one character: 'abc' now encodes to [0xab, 0x0c] instead of [0xab, 0x00], and write advances by the size getSizeFromValue reports.

• [@solana/errors, @solana/sysvars, @solana/transaction-messages] #​2110 f47f025 Thanks @​mcintyre94! - Type-check SolanaError contexts in projects whose TypeScript lib does not include ES2022.Error. The SolanaError constructor referenced the global ErrorOptions type, which is unresolved without that lib, so with skipLibCheck enabled its context parameter silently became any and any context was accepted. Fixes the error contexts this was hiding: compileTransactionMessage and decompileTransactionMessage now report the unsupportedVersion in SOLANA_ERROR__TRANSACTION__VERSION_NUMBER_NOT_SUPPORTED, and the SlotHistory sysvar decoder now provides the expected context for SOLANA_ERROR__CODECS__INVALID_BYTE_LENGTH and SOLANA_ERROR__CODECS__ENUM_DISCRIMINATOR_OUT_OF_RANGE, so their messages no longer contain unfilled placeholders.

• [@solana/fixed-points] #​2102 d7a1d10 Thanks @​lorisleiva! - Allow binary fixed-points whose fractionalBits exceed their totalBits, e.g. an unsigned 8-bit value with 12 fractional bits representing values in [0, 1/16), consistently with decimal fixed-points whose decimals may already exceed their totalBits. The SOLANA_ERROR__FIXED_POINTS__FRACTIONAL_BITS_EXCEED_TOTAL_BITS error is no longer thrown.

• [@solana/plugin-interfaces] #​2104 41896b7 Thanks @​lorisleiva! - Fix ClientWithTransactionPlanning, ClientWithTransactionSending and ClientWithTransactionSigning rejecting the maxInstructionsPerTransaction option that transaction planners support per call. Their planning, sending and signing functions now accept it, making it possible to override the maximum number of instructions per transaction for a single request. Sending and signing functions only use it when their input needs to be planned first.

  await client.planTransactions(instructions, { maxInstructionsPerTransaction: 8 });
  await client.sendTransactions(instructions, { maxInstructionsPerTransaction: 8 });
  await client.signTransactions(instructions, { maxInstructionsPerTransaction: 8 });

• [@solana/rpc-graphql, @solana/rpc-parsed-types] #​2101 abfded6 Thanks @​ara-stock! - Fix the parsed epochRewards sysvar type to match what Agave returns. The jsonParsed info has active, distributedRewards, distributionStartingBlockHeight, numPartitions, parentBlockhash, totalPoints and totalRewards, and the reward amounts and points are strings. The old type described a distributionCompleteBlockHeight field that Agave does not return, and typed the amounts as bigint.

• [@solana/sysvars] #​2116 534ea5e Thanks @​Iamsohungrynow! - The SysvarSlotHashes and SysvarRecentBlockhashes encoders/decoders now use the u64 length prefix that these sysvar accounts actually have, instead of a u32 one. Previously every decoded entry was shifted by four bytes, so the slots, hashes and fees came back wrong.

v8.4.0

Compare Source

@​solana/kit

v8.4.0 (2026-09-28)

Minor Changes

• [@solana/codecs-data-structures, @solana/errors] #​2061 0e76741 Thanks @​lorisleiva! - Add a sentinel size strategy to the array, set, and map codecs. Passing a { __kind: 'sentinel', sentinel, strategy? } object as the size option ends the collection when the bytes at the next item position match the given sentinel, compared at item boundaries only. The optional strategy ('required' by default, or 'optional' / 'omitted') controls whether the sentinel is written when encoding and required when decoding. This provides codec support for Codama's sentinelCountNode.

  Two new errors accompany this: SOLANA_ERROR__CODECS__SENTINEL_MISSING_AT_END_OF_BYTES (thrown under the 'required' strategy when the byte array ends without the sentinel) and SOLANA_ERROR__CODECS__SENTINEL_MUST_NOT_BE_EMPTY (thrown when constructing a codec with an empty sentinel).

• [@solana/errors, @solana/instruction-plans] #​2073 5be269c Thanks @​lorisleiva! - Add helpers for writing custom message packers. resolveMaxInstructionsPerTransaction, assertMaxInstructionsPerTransaction and assertMessageCanAccommodateSize enforce the instruction-count and size limits the built-in packers rely on, and a new SOLANA_ERROR__INSTRUCTION_PLANS__MESSAGE_REJECTED_BY_PACKER error lets a packer refuse a transaction message for any other reason by providing a reason. The transaction planner treats this error like the existing capacity errors and opens a new transaction message. Use isMessagePackerErrorThatRequiresNewCandidate to identify every error that calls for a new transaction message.

Patch Changes

• [@solana/codecs-numbers] #​2067 56b4960 Thanks @​latent-9! - Fixed getShortU16Decoder() silently accepting malformed input: a truncated buffer decoded to garbage with an offset past the end of the byte array, and continuation chains longer than the documented three-byte encoding decoded to values outside the u16 domain. Malformed input now throws SOLANA_ERROR__CODECS__INVALID_BYTE_LENGTH, and decoded values above 65,535 now throw SOLANA_ERROR__CODECS__NUMBER_OUT_OF_RANGE, matching the guards every other number decoder already uses.

• [@solana/instruction-plans] #​2071 75653e9 Thanks @​lorisleiva! - Fix getReallocMessagePackerInstructionPlan producing a 0-byte instruction when totalSize is an exact multiple of the realloc limit (10,240 bytes), which left the account one chunk short of the requested size.

v8.3.0

Compare Source

@​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

v8.2.0

Compare Source

@​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.

v8.1.0

Compare Source

@​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.

v8.0.0

Compare Source

@​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

v7.1.1

Compare Source

@​solana/kit

v7.1.1 (2026-08-18)

Patch Changes

• [@solana/codecs-strings] #​1926 1d074ed Thanks @​latent-9! - Fix getBaseXDecoder returning an offset of 0 instead of the buffer length when there are no bytes left to decode, which corrupted the offset of any decoder composed after it.

• [@solana/instruction-plans] #​1924 769da66 Thanks @​mcintyre94! - Deprecate transaction plan result APIs being removed in v8

  Both of the following are deprecated and will be removed in the next major version.

  successfulSingleTransactionPlanResultFromTransaction derives the transaction signature on your behalf by calling getSignatureFromTransaction, which throws when the transaction's fee payer has not signed it. Construct results with successfulSingleTransactionPlanResult instead, passing the context explicitly:

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

  `

❗ Important

✂ PR body was truncated to here.

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Mend Renovate CLI.

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	@​solana/​addresses@​2.3.0 ⏵ 8.6.0			+1

View full report

[metamask-ci]

Edited/Blocked Notification

Renovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR.

You can manually request rebase by checking the rebase/retry box above.

⚠️ Warning: custom changes will be lost.

[github-actions]

🛑 Files requiring codeowner review

To merge this PR, you'll need to get approvals from the following owner groups.
For files with multiple owners, approval from one owner is sufficient.

@MetaMask/accounts-engineers or @MetaMask/core-platform or @MetaMask/metamask-assets (2 files)

• packages/multichain-network-controller/CHANGELOG.md
• packages/multichain-network-controller/package.json