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