@solana/kit

v6.6.0 (2026-04-01)

Minor Changes

• [@solana/errors, @solana/transaction-messages] #1496 7f02d23 Thanks @mcintyre94! - compileTransactionMessage now enforces four Solana protocol limits at compile time, throwing a typed SolanaError instead of silently producing a transaction that would be rejected by the network:

  • More than 64 unique account addresses → SOLANA_ERROR__TRANSACTION__TOO_MANY_ACCOUNT_ADDRESSES
  • More than 12 unique signer addresses → SOLANA_ERROR__TRANSACTION__TOO_MANY_SIGNER_ADDRESSES
  • More than 64 instructions → SOLANA_ERROR__TRANSACTION__TOO_MANY_INSTRUCTIONS
  • More than 255 accounts in a single instruction → SOLANA_ERROR__TRANSACTION__TOO_MANY_ACCOUNTS_IN_INSTRUCTION

  All four error codes (and their context types / human-readable messages) are exported from @solana/errors.

• [@solana/instruction-plans, @solana/transactions] #1499 742ffca Thanks @mcintyre94! - Add version-aware transaction size limits. Version 1 transactions now allow up to 4096 bytes, while legacy and v0 transactions continue to use the existing 1232-byte limit. Two new helper functions are exported from @solana/transactions: getTransactionSizeLimit for compiled Transaction objects, and getTransactionMessageSizeLimit for TransactionMessage objects.

  The existing TRANSACTION_SIZE_LIMIT, TRANSACTION_PACKET_SIZE, and TRANSACTION_PACKET_HEADER constants are now deprecated in favour of getTransactionSizeLimit and will be removed in a future major version.

• [@solana/plugin-core] #1480 9c4fd6e Thanks @mcintyre94! - Add withCleanup function to @solana/plugin-core. Plugin authors can use it to register teardown logic (e.g. closing connections or clearing timers) on a client, making it Disposable. If the client already implements Symbol.dispose, the new cleanup function is chained so both run on disposal.

Patch Changes

• [@solana/instruction-plans] #1497 f055201 Thanks @mcintyre94! - The transaction planner now handles the four new transaction compilation constraint errors (TOO_MANY_ACCOUNT_ADDRESSES, TOO_MANY_SIGNER_ADDRESSES, TOO_MANY_INSTRUCTIONS, TOO_MANY_ACCOUNTS_IN_INSTRUCTION) gracefully. When adding an instruction to an existing candidate transaction would violate a constraint, the planner splits it into a new transaction — the same behaviour it already had for transactions that exceed the byte size limit. If even a fresh transaction cannot accommodate the instruction, the constraint error propagates to the caller.

• [@solana/signers] #1492 0fa54a4 Thanks @lorisleiva! - Allow deduplicateSigners to handle structurally equivalent signers (e.g. two createNoopSigner calls with the same address) instead of throwing.