registerSeekerConnect also accepts seekerLink, authorizationCache, and presenter overrides — see references/imperative-api.md.

Step 4: use it like any other wallet

After registration, "Seeker Connect" appears in the Wallet Standard registry, so wallet-adapter, ConnectorKit, @solana/react-hooks, or a raw @wallet-standard/app listing all pick it up with no further wiring. Existing connect buttons and signing code keep working.

Features exposed: standard:connect, standard:disconnect, standard:events, solana:signMessage, solana:signIn, and — depending on the wallet's reported capabilities after the first connect — solana:signTransaction and/or solana:signAndSendTransaction.

Working with the wallet directly:

import { SeekerConnectWalletName } from '@solana-mobile/seeker-connect-wallet-standard';
import { getWallets } from '@wallet-standard/app';
import { StandardConnect } from '@wallet-standard/features';

const seeker = getWallets()
  .get()
  .find((wallet) => wallet.name === SeekerConnectWalletName);
const { accounts } = await seeker.features[StandardConnect].connect();

Restore the session on page load with a silent connect — it reads the cache and never launches the wallet, resolving with zero accounts when there is nothing cached:

const { accounts } = await seeker.features[StandardConnect].connect({ silent: true });

Feature-detect the signing routes. Until the first connect, both transaction features are assumed; after it they are re-derived from the wallet's actual capabilities, announced via a standard:events change event. Check before calling:

import { SolanaSignAndSendTransaction } from '@solana/wallet-standard-features';

const feature = seeker.features[SolanaSignAndSendTransaction];
if (feature) {
  const [{ signature }] = await feature.signAndSendTransaction({
    account,
    chain: seeker.chains[0],
    transaction,
  });
}

chain is part of the Wallet Standard input, but this wallet ignores it — the network is the one passed to registerSeekerConnect, replayed from the cached authorization on every call. Nothing cross-checks the two, so a per-call solana:devnet against a mainnet registration submits on mainnet without complaint. Pass seeker.chains[0] so the two can never disagree, and change networks at registration.

Transactions cross the feature boundary as raw serialized bytes (Uint8Array), legacy and v0 both supported — serialize with whichever client library the app already uses. Sign-in follows the SIWS spec via solana:signIn; domain defaults to window.location.host.

When sign-in authenticates a user, the server is the authority, not the client: issue a single-use, short-lived nonce server-side, and verify the returned message and signature — including the expected domain and validity window — on the server before creating a session. The seeker-genesis-token skill walks through that server flow step by step.

Handle errors by code

Wallet outcomes reject with a SeekerConnectError carrying a code:

Code	Meaning
association-failed	No wallet completed the launch: timeout, relay unreachable or misconfigured, or not on a Seeker
authorization-declined	The user declined authorization. The cached token is wiped; the next connect prompts fresh consent
cancelled	The user dismissed the progress overlay. A normal outcome — never surface it as an error
request-declined	The wallet declined to sign or submit
session-closed	The session ended before the interaction completed. After signAndSendTransaction the transaction may still have landed, and the error carries no signature — never retry automatically — see references/troubleshooting.md
wallet-error	Any other wallet-reported error

Three failures are plain Errors instead, and they are misuse rather than wallet outcomes: signAndSendTransaction on a wallet that reported no support for it, any signing call before a successful connect, and a sign-in the wallet answered without a result.

That distinction decides who shows the error. The branded dialog fires for SeekerConnectError and nothing else — every code above except cancelled, which is a normal outcome and stays silent. The three plain Errors never reach the presenter, so if the app shows nothing they fail invisibly. Branch on the type first, then on .code:

import { SeekerConnectError, SeekerConnectErrorCode } from '@solana-mobile/seeker-connect-wallet-standard';

try {
  await seeker.features[StandardConnect].connect();
} catch (error) {
  if (error instanceof SeekerConnectError) {
    if (error.code === SeekerConnectErrorCode.cancelled) {
      return; // user closed the overlay; nothing to report
    }
    // The SDK has shown its dialog. Log, and leave the UI in the disconnected state.
    console.error(error);
    return;
  }
  // No dialog was shown for this one. Surface it yourself.
  showToast('Could not connect to the wallet.'); // your app's own error UI
  console.error(error);
}

Optional: the branded connect button

@solana-mobile/seeker-connect-ui ships a <seeker-connect-button> custom element in Shadow DOM (no host CSS needed). The SDK defines its elements on first use; call defineSeekerConnectElements() at startup to define them eagerly:

import { defineSeekerConnectElements } from '@solana-mobile/seeker-connect-ui';

defineSeekerConnectElements();

<seeker-connect-button theme="dark" variant="sign-in"></seeker-connect-button>

Attributes: disabled, theme="light" | "dark" (names the host page's theme), and variant="connect" (default) or variant="sign-in" for the label. Wire click to the connect or sign-in call yourself — the button is presentation only.

Reference material

• references/kotlin.md — the Kotlin SDK: Gradle setup, the SeekerConnect constructor, the client methods, the Compose button and dialogs, and SeekerConnectException codes
• references/react-native.md — the React Native package: install, https identity requirement, the client methods, and the native button
• references/imperative-api.md — the non-Wallet-Standard path via createNostrSeekerLink().transact, and the seekerLink / authorizationCache / presenter overrides
• references/troubleshooting.md — association failures, desktop testing, capability-derived features, cache behavior

Related skills

• seeker-domains — display .skr names instead of raw addresses
• seeker-genesis-token — verify Seeker device ownership after connecting
• solana-mobile — the CLI, templates, and toolchain behind solana-mobile create
• solana-mobile-wallet — wallet connection in React Native apps through Mobile Wallet Adapter directly, without Seeker Connect

Links

• MWA web docs: https://docs.solanamobile.com/get-started/web/installation
• Seeker Connect docs: https://docs.solanamobile.com/solana-mobile-stack/seeker-connect
• Seeker Connect quickstart (relay terms live here): https://docs.solanamobile.com/solana-mobile-stack/seeker-connect-quickstart
• Seeker Connect repository: https://github.com/solana-mobile/seeker-connect