Replace priorityFees with TransactionPlannerConfig in transaction planner plugins

[lorisleiva]

This PR replaces the inline priorityFees config on rpcTransactionPlanner and litesvmTransactionPlanner with a new TransactionPlannerConfig type that supports microLamportsPerComputeUnit and version. The all-in-one plugins (solanaRpc and litesvm) gain a transactionConfig option for passing this configuration through.

This prepares us for v1 transactions, which will configure priority fees in a completely different way (flat lamport amount instead of micro-lamports per compute unit). The TransactionPlannerConfig type gives us a place to provide per-version configuration — e.g. a future { version: 1, priorityFees: lamports(100n) } variant — without breaking the existing API surface.

[changeset-bot]

🦋 Changeset detected

Latest commit: 55f154d

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 5 packages

Name	Type
@solana/kit-plugin-rpc	Minor
@solana/kit-plugin-litesvm	Minor
@solana/kit-client-rpc	Minor
@solana/kit-plugins	Minor
@solana/kit-client-litesvm	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[lorisleiva]

• Replace priorityFees with TransactionPlannerConfig in transaction planner plugins #193 👈 (View in Graphite)
• Remove payer config option from transaction planner plugins #192
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[lorisleiva]

@trevor-cortex

[trevor-cortex]

Summary

Clean refactor that replaces the inline priorityFees option on rpcTransactionPlanner and litesvmTransactionPlanner with a new TransactionPlannerConfig type supporting microLamportsPerComputeUnit and version. The all-in-one plugins (solanaRpc / litesvm) gain a transactionConfig passthrough option. This sets up a nice extension point for future v1 transaction support with different priority fee semantics.

Notes

• The TransactionPlannerConfig type is defined identically in both kit-plugin-rpc and kit-plugin-litesvm transaction-planner modules. The barrel export in kit-plugins correctly disambiguates by explicitly re-exporting from kit-plugin-rpc. This is fine for now, but worth noting that the two definitions need to stay in sync manually (the TODO comments help here).
• kit-client-rpc still exposes a priorityFees field on its ClientConfig type and maps it to microLamportsPerComputeUnit internally — this is the right call since createClient/createLocalClient are already deprecated.
• The RPC transaction planner still includes fillTransactionMessageProvisoryComputeUnitLimit in its pipeline while the LiteSVM planner does not — this is pre-existing and intentional (LiteSVM doesn't need CU estimation), just noting for subsequent reviewers.
• Test coverage is thorough: version default, legacy version, compute unit price presence/absence.

Looks good to me 👍

[trevor-cortex]

Nit: since this type is identical to the one in kit-plugin-rpc/src/transaction-planner.ts, would it make sense to extract it into a shared package (e.g. kit-plugin-instruction-plan or a new shared types package) to avoid the manual sync + the explicit disambiguation in kit-plugins/src/index.ts? Not blocking — the TODO comments and barrel re-export handle it fine for now.

[lorisleiva]

I did that on purpose to allow the two config objects to grow independently of each other.

[trevor-cortex]

Good catch exporting LiteSvmConfig from the browser entry point so consumers can still reference the type even when the runtime function throws.

[mcintyre94]

This looks great! It'll be really nice to get the simpler priority fees in v1 here too.