chore(deps): bump the solana-deps group across 1 directory with 2 updates

[dependabot]

Bumps the solana-deps group with 2 updates in the / directory: @solana-name-service/sns-sdk-kit and @solana/webcrypto-ed25519-polyfill.

Updates @solana-name-service/sns-sdk-kit from 0.10.0 to 1.0.1

Commits

• See full diff in compare view

Updates @solana/webcrypto-ed25519-polyfill from 6.9.0 to 7.1.0

Release notes

Sourced from @​solana/webcrypto-ed25519-polyfill's releases.

v7.1.0

@​solana/kit

v7.1.0 (2026-08-14)

Minor Changes

• [@solana/errors, @solana/kit, @solana/react, @solana/subscribable] #1811 7022c26 Thanks @​mcintyre94! - Add bridgeStoreToAsyncIterable to @solana/subscribable

  bridgeStoreToAsyncIterable adapts a ReactiveStreamStore into the pull-based AsyncIterable contract that consumers like TanStack Query's experimental_streamedQuery expect. It is now a public export of @solana/subscribable (and re-exported from @solana/kit). It was previously an internal helper of @solana/react, but it is not React- or TanStack-specific and is useful to any consumer that needs to drive a stream store by for await-ing it.

  The bridge only observes the store — consistent with the rest of the ecosystem, the caller owns the store's lifecycle (connect() it yourself, bound to the same signal, and reset() it when done). The bridge subscribes, seeds from the store's current snapshot, yields values, and unsubscribes when iteration ends.

  It throws the new SOLANA_ERROR__SUBSCRIBABLE__STREAM_CLOSED_WITHOUT_ERROR when a store closes in an error state with a nullish payload. This is the error useSubscriptionQuery and useTrackedDataQuery now surface in that case; the SWR bridge is unaffected.

• [@solana/errors, @solana/offchain-messages] #1888 14a3e5b Thanks @​mcintyre94! - Add an assertOffchainMessageV1Equal helper that asserts that a version 1 offchain message you received from an untrusted signer (eg. a wallet) is the message you expected it to sign. Verifying a signature proves only that the signer produced it over the bytes it handed back, not that those bytes represent the message you asked for, so assert this before verifying signatures with verifyOffchainMessageEnvelope. The helper compares the content and the required signatories, and reports each kind of mismatch with its own error code: the new SOLANA_ERROR__OFFCHAIN_MESSAGE__CONTENT_DOES_NOT_MATCH_EXPECTED and SOLANA_ERROR__OFFCHAIN_MESSAGE__REQUIRED_SIGNATORIES_DO_NOT_MATCH_EXPECTED. Required signatories are compared without regard to order, since a decoded message lists them in the order the specification mandates while yours may be in any order. It accepts an OffchainMessageV1 rather than the OffchainMessage union that decoding produces, so narrow the decoded message to a version 1 message before calling it.

• [@solana/instruction-plans] #1915 9e7daea Thanks @​mcintyre94! - Let the createTransactionPlanExecutor callback return the context of a successful result

  The executeTransactionMessage callback may now return the context that a successful result should carry, instead of a Signature or a Transaction. When it does, that context is used as-is: nothing is derived from it, and in particular getSignatureFromTransaction is never called on your behalf.

  const transactionPlanExecutor = createTransactionPlanExecutor({
    executeTransactionMessage: async (context, message) => {
      const transaction = await signTransactionMessageWithSigners(message);
      context.transaction = transaction;
  +   const signature = getSignatureFromTransaction(transaction);
      await sendAndConfirmTransaction(transaction, { commitment: 'confirmed' });
  -   return transaction;
  +   return { signature, transaction };
    },
  });

  Since a successful result always carries a signature, a returned context must include one — a callback that declares a custom context and forgets a property of it now fails to compile, rather than producing a result whose context is typed but undefined at runtime. That signature is also how the executor tells a returned context apart from a returned Transaction, which keeps its signatures in a signatures map and therefore never has one.

  The mutable context argument is unchanged and still serves the failure path: whatever the callback stores on it before it throws is preserved in the resulting FailedSingleTransactionPlanResult. On success the two are merged, with the returned context taking precedence, so a property stored but not returned is still reported.

  Returning a Signature or a Transaction is deprecated. Both still behave exactly as before — a returned signature is stored as context.signature, and a returned transaction is stored as context.transaction with its signature derived from it — and IDEs now flag those call sites, because createTransactionPlanExecutor gained a deprecated overload that only matches callbacks returning those types. Note that a config declared as TransactionPlanExecutorConfig up front is not flagged, since that type permits either return style.

  Prefer returning a context, since deriving a signature from a transaction throws SOLANA_ERROR__TRANSACTION__FEE_PAYER_SIGNATURE_MISSING when the fee payer slot is empty. An executor that deliberately produces partially signed transactions — signed by an authority, to be paid for and submitted by a relayer later — can now succeed by returning its own signature alongside the transaction. Dropping the signature from a successful result's context altogether remains impossible, since SuccessfulSingleTransactionPlanResult guarantees one.

  Failure handling is unchanged, including the signature still derived from a transaction left on the context when the callback throws. Since the callback never returned anything in that case, there is nothing to bypass that derivation, so a callback working with fee-payer-unsigned transactions should avoid storing them on the context — otherwise deriving a signature from one replaces the error it meant to report.

• [@solana/kit] #1898 4a5f717 Thanks @​lorisleiva! - Add helpers to create client interfaces from a raw Rpc

  Add createClientWithGetMinimumBalanceFromRpc, createClientWithFetchAccountsFromRpc and createClientWithInterfacesFromRpc to @solana/kit. These convenience helpers let consumers that only have a raw Rpc object construct the corresponding client interfaces (ClientWithGetMinimumBalance and ClientWithFetchAccounts) without assembling a full Kit client. createClientWithInterfacesFromRpc fills in whichever interfaces the RPC supports and narrows its return type accordingly.

• [@solana/kit] #1824 b47feb6 Thanks @​mcintyre94! - Re-export @solana/promises from @solana/kit

... (truncated)

Commits

• 661554c Version Packages (#1830)
• 8c9eece Fix getBitArrayEncoder returning the wrong next offset (#1911)
• 9e7daea Let transaction plan executors return a result context (#1915)
• 80b3756 fix: stop upcasting token balance uiAmount and related numerics to bigint...
• 82c4ceb fix: stop upcasting transaction version to bigint (#1917)
• 03bd803 Add a note in CLAUDE.md about docs using published packages (#1916)
• 9d6be07 Stop inflating every release to a major via the @solana/react peer dependen...
• 0eff23c Bump jscodeshift from 17.3.0 to 17.4.0 (#1908)
• 7b52c7e Bump react-test-renderer from 19.2.7 to 19.2.8 (#1904)
• b2f9a3c Bump @​changesets/cli from 2.31.0 to 2.31.1 (#1903)
• Additional commits viewable in compare view

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
good-wallet-v2	Ignored	Preview	Aug 4, 2026 10:45am