Clerk: Sign in with Solana for app auth

Clerk (clerk.com) is app user management: hosted or embedded sign-in, sessions, organizations, billing hooks, Backend API. For Solana apps the useful bridge is Sign in with Solana — a first-class Web3 auth strategy so a wallet address becomes a Clerk user (or links to an existing one), while you keep the same session and org model as email or OAuth.

This piece is specifically about that Solana path. For the broader Clerk product surface see Clerk: user management for builders.

Click to zoom

What shipped

Clerk announced Sign-in with Solana on 13 January 2026 (contributor Kenton Duprey). Docs live at Web3 → Solana.

Clerk’s other Web3 strategies (MetaMask, Coinbase Wallet, OKX, Base) all resolve to an Ethereum address and are tied to those wallet apps. Solana is different on purpose: the user picks a preferred Solana wallet provider and authenticates with a Solana wallet address. The flow is not locked to a single wallet brand — any Solana wallet that can sign messages is in scope (SolanaWeb3Provider = 'solana' in the SDK types).

Enable and smoke-test

1. Dashboard → User authentication → Web3
2. Enable Solana in the provider list
3. Open your Account Portal sign-in URL (dev: *.accounts.dev/sign-in) and confirm Solana appears
4. In-app: keep using <SignIn /> / <SignUp /> — Solana shows up as a strategy once enabled

No separate Solana “API key” for SIWS itself: the wallet proves ownership by signing Clerk’s challenge; Clerk issues a normal session afterward.

How verification works

Same two-step Web3 pattern as Clerk’s other wallet factors, documented on Web3Wallet:

1. prepareVerification / first-factor prepare — Frontend API returns a nonce the wallet must sign
2. Wallet signs → signature on Verification.message
3. attemptVerification with that signature → wallet attached / session established

User picks Solana wallet
  → Clerk Frontend API: prepare (nonce)
  → Wallet signs message
  → Clerk: attemptVerification(signature)
  → Session JWT (short-lived) + user record
  → Backend: authenticateRequest / verifyToken as usual

On the user object, Solana identities are still Web3Wallet rows. The web3Wallet string is either an EVM 0x… address or a base58-encoded ed25519 public key for Solana. Backend helpers include deleteUserWeb3Wallet() and the Backend Web3Wallet type.

Web2 fields on a wallet user

Pure wallet identity is private and fine for some products. Most Solana consumer apps still want email (receipts, recovery, support). Clerk documents the bridge explicitly:

• Dashboard → User & authentication → enable attributes to collect at sign-up (email, phone, username, …)
• Users can connect Solana later from Account Portal profile or <UserProfile />

MFA, profile enrichment, and organizations apply to Web3 users the same way as other factors — that is the point of using Clerk’s abstraction instead of a one-off SIWS middleware.

What SIWS is not

Production pattern for many dapps: Clerk for app identity + session, wallet-standard / adapter for onchain actions, optionally require that the connected tx wallet matches the SIWS address on sensitive routes.

Builder checklist

• Enable Solana under Dashboard Web3; test on Account Portal first
• Backend: treat session like any Clerk session — authenticateRequest / JWT verify; read wallet from user Web3 wallets when you need the base58 pubkey
• Decide at design time: wallet-only users vs email required at sign-up
• Do not store seed phrases; never treat a client-supplied address as proof without Clerk’s verified wallet (or your own signature check)
• Mobile / extension: confirm your Clerk SDK version supports the Solana Web3 strategy in your target environment before promising SIWS in the UI

Related Clerk people (public)

Not a full org chart — public faces useful for DevRel / product questions:

• Colin Sidoti — cofounder / leadership (@tweetsbycolin)
• Kenton Duprey — Sign-in with Solana changelog contributor
• Akriti Keswani — DevRel (@AkritiKeswani)
• Company / product: @clerk (also historically @ClerkDev)

Directory entries for these people are on devrels.xyz/directory?search=clerk.

Resources

• Docs: Solana Web3 strategy
• Changelog: Sign-in with Solana
• Web3Wallet type reference
• Clerk on DevRels · Clerk overview article

Summary

Clerk’s Solana support is real product surface, not a blog demo: enable Solana under Web3, users sign a nonce with any message-capable Solana wallet, Clerk stores a base58 wallet identity and issues a normal app session. Use it when you want wallet login and Clerk’s session/org/billing stack; keep wallet adapters for actual chain transactions.