Add experimental v1 transaction support

[macalinao]

Summary

Stacked on solana-foundation#169 (Upgrade to Kit v7) — base branch is upgrade-kit-v7, so this diff shows only the v1 additions. This PR lives on the fork; once solana-foundation#169 merges into solana-foundation:main, its base can be retargeted there.

Adds an experimental, opt-in foundation for Solana version 1 (v1) transactions.

Key finding: v1 is runtime-ready but type-gated in Kit v7

• MAX_SUPPORTED_TRANSACTION_VERSION === 1; v1 messages compile and encode to the wire (leading byte 0x81).
• But Kit v7 gates v1 out of its public types: createTransactionMessage is typed Exclude<TransactionVersion, 1>, and the low-level setTransactionMessageConfig / V1TransactionConfig are not re-exported.
• The per-field, v1-aware setters (setTransactionMessageComputeUnitLimit, setTransactionMessagePriorityFeeLamports, setTransactionMessageHeapSize, setTransactionMessageLoadedAccountsDataSizeLimit) are public.

So the only thing missing from the public API is a typed way to construct an empty v1 message — one isolated, documented assertion in createV1TransactionMessage. Everything else uses public, typed, v1-aware APIs.

What's included

• src/features/transactionsV1.ts:
  • createV1TransactionMessage() — the single documented cast.
  • setV1TransactionConfig(config, message) — compute budget written to the message's native config (not Compute Budget instructions). Note v1 uses total priorityFeeLamports, not a per-CU price.
  • buildV1TransactionMessage({ feePayer, lifetime, instructions, config }) — assembles a signable v1 message; rejects address-lookup-table instructions (v1 uses InstructionWithoutLookupTables).
• transactionsV1.test.ts — construction, config-in-message, wire encoding (0x81), no-ALT guard. (4 tests)
• V1-TRANSACTIONS.md — full scope + follow-up phases (wiring version: 1 into prepare(), priority-fee model, feature helpers, planner size accounting).
• Changeset: @solana/client minor, flagged experimental.

Why experimental

It depends on Kit's v1 gating not changing shape. Should be revisited once Kit publishes the official v1 API (expected on the 8.x line), at which point the internal assertion can be dropped.

Testing

• pnpm --filter @solana/client typecheck
• pnpm --filter @solana/client test (v1 suite: 4 passed)
• pnpm --filter @solana/client lint
• pnpm --filter @solana/client build

Summary by Sourcery

Add experimental, opt-in support for constructing and configuring Solana v1 transaction messages in the client package while keeping it behind a clearly documented, gated API.

New Features:

• Expose helpers and types to create, configure, and build signable Solana v1 transaction messages with native compute-budget fields and no address-lookup-table support.

Enhancements:

• Document the intended scope, limitations, and follow-up work for v1 transaction support in a dedicated V1-TRANSACTIONS guide.

Documentation:

• Add V1-TRANSACTIONS.md detailing the v1 transaction model, Kit v7 gating, and planned integration phases.

Tests:

• Add a test suite covering v1 message construction, native config behavior, wire encoding, and rejection of ALT-based instructions.

Chores:

• Add a changeset declaring an experimental minor release of @solana/client for v1 transaction support.

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 5cba5571-4d69-4235-8f40-e9a069a713ef

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch v1-transactions

---

_{Comment @coderabbitai help to get the list of available commands.}

[sourcery-ai]

Reviewer's Guide

Adds an experimental, opt-in foundation for Solana v1 transaction messages to @solana/client, exposing a typed way to construct, configure, and build signable v1 transaction messages while enforcing no-address-lookup-table constraints, along with tests, docs, and a minor changeset.

File-Level Changes

Change	Details	Files
Introduce an experimental transactionsV1 feature module providing typed v1 transaction message construction, configuration, and assembly helpers that rely on Kit v7’s v1-aware runtime APIs but work around its type-level gating.	Define V1TransactionMessage, V1BlockhashLifetime, V1TransactionConfig, and BuildV1TransactionMessageInput types to model v1 messages, their native config fields, and builder inputs. Implement createV1TransactionMessage() using a single, isolated type assertion on createTransactionMessage to permit { version: 1 } while keeping the rest of the module fully typed. Implement setV1TransactionConfig() to apply compute budget and related fields into the message’s native config using public v1-aware setter functions instead of Compute Budget instructions. Implement buildV1TransactionMessage() to construct a signable v1 message from fee payer, blockhash lifetime, instructions, and optional config, writing compute budget into the message and iteratively appending instructions. Add assertNoAddressLookups() to validate input instructions and throw when any lookup-table metadata is present, ensuring v1 messages only contain InstructionWithoutLookupTables semantics.	packages/client/src/features/transactionsV1.ts
Expose the new v1 transaction APIs from the @solana/client package entrypoint.	Export buildV1TransactionMessage, createV1TransactionMessage, setV1TransactionConfig, and the associated v1 types from the client index so consumers can opt into v1 support.	packages/client/src/index.ts
Document the scope, rationale, and follow-up plan for experimental v1 transaction support.	Add V1-TRANSACTIONS.md describing what v1 transactions are, how compute budget and address lookup table constraints work, details of Kit v7’s type gating, what this PR implements, and planned future integration steps (prepare wiring, priority-fee model, feature helpers, planner updates, and revisiting once Kit exposes v1 officially).	packages/client/V1-TRANSACTIONS.md
Add tests that validate v1 transaction message construction, native config behavior, wire encoding, and ALT rejection.	Add tests that ensure createV1TransactionMessage() produces an empty v1 message with the correct version and no instructions. Add tests that verify setV1TransactionConfig() writes compute-unit limit and priority fee into the native config fields and does not append Compute Budget instructions. Add tests that build a signable v1 message, compile it, and assert that the wire encoding has the expected versioned leading byte (0x81). Add tests that verify buildV1TransactionMessage() throws when given instructions containing address lookup table metadata.	packages/client/src/features/transactionsV1.test.ts
Register the change as an experimental minor release of @solana/client.	Add a changeset marking a minor version bump for @solana/client and summarizing the experimental v1 transaction support, its dependence on Kit v7’s gating, and the recommendation to treat it as experimental until Kit exposes v1 transactions officially.	.changeset/v1-transactions-experimental.md

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.