@solana/kit

@solana/kit

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.

@solana/kit

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.

@solana/kit

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

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.