Anza Ships Solana Kit v7 With @solana/react Hooks and Transaction Introspection

Anza released Solana Kit v7 on July 15, shipping two new packages that address different parts of the Solana development workflow. @solana/react is a React hook layer that handles data fetching, subscriptions, and async actions without the manual wiring that Kit previously required. @solana/transaction-introspection solves a quieter but persistent problem: the gap between what the getTransaction RPC call returns and what program clients can actually parse.

Kit is Anza's TypeScript SDK for Solana, developed as the successor to the legacy @solana/web3.js library. Both new packages are available in the open-source anza-xyz/kit repository.

@solana/react Removes Boilerplate from Data Fetching and Subscriptions

The package's core layer ships four hooks. useRequest fetches a value on mount and exposes a refresh function. useSubscription surfaces the latest data from an RPC subscription and provides a reconnect function. useTrackedData combines both, starting with a fetched value and keeping it current through a live subscription. useAction wraps any async function with a dispatch call, a running flag, and an error state: the pattern that appears in nearly every wallet interaction.

For teams already using TanStack Query or SWR, the package ships sub-imports at @solana/react/query and @solana/react/swr. Each sub-import exposes query variants of the three data hooks: useRequestQuery, useSubscriptionQuery, and useTrackedDataQuery. Both sets plug into their respective library's caching, request deduplication, and devtools without adding a custom layer on top.

That last clause matters for teams not using React. Every RPC method in Kit now exposes a .reactiveStore() method returning a {data, error, status} object with subscribe and getState functions. The React hooks consume those stores; developers using Angular, Vue, Svelte, or SolidJS can consume them directly. The hooks are an optional convenience layer on top of an architecture that was designed to be framework-independent.

The hooks are also SSR-safe. Data fetching runs only on the client, meaning server-side rendering passes in Next.js or Remix will not trigger RPC calls during the server phase.

@solana/transaction-introspection Decodes Confirmed Transactions for Program Clients

The transaction introspection package targets a different kind of friction. When you call getTransaction on the Solana RPC, the response is shaped around wire-format conventions that are efficient to transmit but awkward to work with in application code. Instruction data arrives as an encoded string. Account references inside each instruction are integer indices into the transaction's account array, not public keys. Inner instructions from cross-program invocations are stored under a separate metadata field rather than alongside the outer instruction that triggered them.

None of that is a bug. It reflects how Solana serializes transaction data on the wire. But it means that anyone building an explorer, an indexer, or a transaction history view ends up writing the same decoding and resolution logic from scratch, every time.

@solana/transaction-introspection handles all three steps. It decodes instruction data based on the encoding format the RPC returns. It resolves account indices against the transaction's static key array and, where address lookup tables are involved, against the ALT-loaded addresses stored in meta.loadedAddresses. The package also normalizes inner instructions from meta.innerInstructions into the same structure as outer instructions. The resulting Instruction objects conform to the Kit format that Codama-generated program clients expect, making them usable directly in existing parsing code.

The package was contributed by @a_milz from the Solana Foundation. The Anza announcement thread framed the target audience plainly: "If you build explorers, indexers, or anything that reads confirmed transactions, @solana/transaction-introspection closes the gap between the shape of transaction that an RPC returns and what your program clients can parse."

Solana Kit v7 Extends the TypeScript SDK From Primitives to Application-Layer Tooling

Both packages extend Kit's scope beyond raw cryptographic primitives and transaction construction. The SDK began as a lower-level, tree-shakeable successor to @solana/web3.js, giving developers typed building blocks without the monolithic design of the original library. v7 builds opinionated layers on top: one for reactive UI, one for reading what confirmed transactions actually did.

The release lands the day after LiteSVM v0.14.0 shipped CPI call-tree debugging and aligned the local testing environment with Agave 4.1. The two releases cover opposite ends of the development cycle: Kit v7 helps developers build and read live Solana state in production; LiteSVM helps them understand CPI execution before deployment.

Full documentation for both packages is available on the official Anza blog.