Solana Mobile developer documentation

const result = await signIn({ address: account?.address, chainId: chain,
  domain: "your-app-domain.com", statement: "Sign in to Your App", uri: identity.uri });
console.log("Signed in:", result.account.address);

this is the most-read entry point for React Native. It promises ownership verification but builds the payload on the client and only logs the result.

take the payload (nonce, issuedAt, expirationTime) from the backend and send the result back for verification. Link to the server flow in the Seeker detection recipe.

storePassword "your_keystore_password"
keyAlias "my-app-name"
keyPassword "your_key_password"

build.gradle is normally committed. Following the sample puts release-signing passwords into source control, and the dApp Store key cannot be rotated for a published app. Only the credentials.json variants carry a do-not-commit warning.

read the passwords from environment variables or an untracked gradle.properties, and add the warning.

SignInWithSolana.Payload("solana.com", "Sign in to Ktx Sample App")

the payload is built on the client with no nonce, issue time or expiry, and the domain is not the app's own. The verification advice at line 188 says only "verify that the message was correctly signed". A backend that follows it accepts a replayed or foreign sign-in result as proof of wallet ownership.

fetch the payload from the backend with a single-use nonce, issuedAt and expirationTime. Verify the result server-side, including the domain and nonce consumption. Copy the production warning that the React Native page has.

const input: SolanaSignInInput = { domain: window.location.host,
    statement: "Sign in to My Web App", uri: window.location.origin, }
const output = await signIn(input);

the input carries no nonce or expiry, and the output is never verified. The page is about UX, but developers copy the snippet as is.

obtain the nonce and expiry from the server and post the output back for verification.

sign_in_payload: { domain: "yourdomain.com",
  statement: "Sign into React Native Sample App", uri: "https://yourdomain.com", },

the warning at line 373 is correct but comes after the code. verifySIWS checks the signature only against the input the caller supplies, which is not an authentication check.

put a placeholder such as await fetchSignInPayloadFromBackend() in the sample, and label verifySIWS as an illustration that does not replace server verification.

const signInPayload = await consumeSignInPayload(nonce);
if (!signInPayload) { return null; }

a request that carries a valid nonce and a bad signature burns the nonce, so the real user's sign-in then fails and has to restart.

look up the payload without consuming it, verify the signature and domain, then mark the nonce used atomically.

Alternatively, you can request the wallet to just sign a transaction by issuing a `signTransactions` request.

android-native/using_mobile_wallet_adapter.md:331 marks the method deprecated under the current protocol version and recommends signAndSendTransactions. The React Native guide and its reference (get-started/react-native/mobile-wallet-adapter.md:480) carry no such note.

add the same deprecation warning to the React Native pages.

If, during the current session, the specified auth token was returned by the most recent call to authorize or reauthorize, ...

reauthorize and clone_authorization (lines 214, 313) are legacy methods. The page documents silent reauthorization as authorize with auth_token, so readers look for methods that are not there.

remove the legacy method names or mark them legacy-only.

The legacy `@solana-mobile/wallet-adapter-mobile` library will be deprecated and enter maintenance mode, and only receive updates for bug fixes.

integrators cannot plan the migration. Other pages still document the legacy API without a pointer to this notice.

give dates or version gates for maintenance mode and end of support, and link this notice from the legacy reference.

const signature = await signMessages(messageBytes);
console.log("Signature:", signature);

a user cancel becomes an unhandled promise rejection in every quickstart handler (connect, sign, sign in, send).

wrap the calls in try/catch and handle the declined case explicitly.

const { accounts } = await wallet.features[StandardConnect].connect();
console.log("connected as", accounts[0]?.address);

wallet comes from a find() that can return undefined, and a cancelled consent throws.

guard for a missing wallet, catch rejection, and require at least one account.

} catch (error) {
  console.error("Error verifying SGT ownership:", error.message);
  return null;

an RPC outage looks exactly like a user who owns no Seeker, so callers deny genuine users with no chance to retry.

rethrow, or return a distinct error result.

implementation("com.solanamobile:rpc-core:0.2.6")

get-started/kotlin/installation.md:32 pins 0.2.7, and two other pages use an undefined ${versions.KOTLIN_RPC_CORE_VERSION} placeholder. Mixed versions of the same stack cause subtle API mismatches.

publish one tested version set and reference it from every page.

Update `@solana-mobile/wallet-standard-mobile` to **v0.5.0 or later** to mitigate the issue.

dapp-store/build-and-sign-an-apk.md:171 and recipes/general/publishing-a-web-app.md:39 require v0.5.1. The install command at line 48 uses @latest.

state one floor, or explain the browser case against the shell case, and pin the version.

<Card horizontal title="React Native" icon="react" href="/get-started/react-native/invoke-mwa-sessions-directly" />

get-started/mobile-wallet-adapter.md:48 points to the Wallet UI hooks, while this page points to the low-level protocol. Readers end up mixing both in one app.

point both pages to one recommended entry point, and say not to mix the two stacks.

It is compatible with any web app using the `@anza/wallet-adapter` libraries.

every sample imports @solana/wallet-adapter-*, and AI tools copy the wrong scope into install commands.

use the real package scope.

registerMwa({ appIdentity: { name: "My app", uri: "https://myapp.io",

wallets reject non-HTTPS origins other than localhost without a clear error. We searched the web pages and found no mention of the requirement.

state that the web app must be served over HTTPS (localhost only for development), and show a protocol check with a clear error.

const HELIUS_RPC_URL = `https://mainnet.helius-rpc.com/?api-key=${HELIUS_API_KEY}`;

the Seeker detection recipe says this runs on the backend, but this page does not. Copied into an app bundle, the key leaks. HELIUS_API_KEY is never declared.

mark the script backend-only and read the key from server configuration.

await wallet.deauthorize({ auth_token: currentAccount.authToken });
AsyncStorage.clear();

AsyncStorage.clear() deletes every key the app ever stored, including user settings and other libraries' caches, not just the two authorization keys. A developer who copies this sample loses user data every time a user disconnects.

await AsyncStorage.multiRemove(["authToken", "base64Address"]).

if (cachedBase64Address && cachedAuthToken) {
  const pubkeyAsByteArray = toByteArray(cachedBase64Address);

on boot the cached account becomes the connected account with no reauthorization, and the connect handler never passes the cached token to authorize. After the user revokes access in the wallet, the app still shows them as connected, and the cache never takes up a refreshed token.

reauthorize with the cached auth_token inside the first session. On failure clear the cache, and on success store the returned token and accounts.

AsyncStorage.setItem("authToken", auth_token);
AsyncStorage.setItem("base64Address", firstAccount.address);

the two keys form a pair, but they are written by two unawaited calls and then state is set. A failure in between leaves storage and memory out of step.

use one saveAccount() and one clearAccount() helper that awaits a single multiSet (or one JSON value) and then sets state.

const STORAGE_KEY = "authorization-cache";

"authToken" and "authorization-cache" live in storage the whole app and other libraries share, which invites collisions.

prefix the keys with an owner name, such as <app>_wallet_authorization.

const STORAGE_KEY = "authorization-cache";

an authorization is issued per chain and identity. When a build switches from devnet to mainnet or changes identity, the old authorization is served as current.

include the chain and identity.uri in the key, or store them in the value and compare them on read.

const authorizationResult = await wallet.authorize({
  auth_token: storedAuthToken ? storedAuthToken : undefined,

the token that authorize returns can change, and nothing writes it back, so the next launch reuses a stale token.

show persistAuthToken(authorizationResult.auth_token) next to the read, and what to do when reauthorization fails.

// Pass in the prior auth token to invalidate it.
await wallet.deauthorize({ auth_token: previouslyStoredAuthToken });

the wallet invalidates the token but the app's stored copy survives, so the next launch sends a dead token.

clear the stored token in the same step as the deauthorize call.

val previouslyStoredAuthToken = maybeGetStoredAuthToken()
walletAdapter.authToken = previouslyStoredAuthToken

only the restore half is shown. Nothing persists the token after connect, and disconnect never clears the stored copy, so an invalidated token comes back on the next launch.

add a saveAuthToken() and clearAuthToken() pair backed by encrypted storage, and call it on connect, on token change and on disconnect.

"Connected" means your app holds a wallet-issued authorization token ... silently reauthorizes with the cached token

we searched the Seeker Connect and web pages for disconnect, deauthorize and clear, and found nothing. Readers do not know where the token lives or how to revoke it.

document where the token is cached, how disconnect clears it, and what happens when it is invalid.

the hook polls for confirmation afterwards and invalidates the counter query on settle

polling with no interval, timeout or backoff can hammer a public RPC endpoint. A subscription is available.

prefer a signature subscription, and give the poll interval, upper bound and backoff.

} while (paginationKey); // Continue until no more pages

the caller supplies the wallet address, so a wallet with very many token accounts keeps one backend request looping for a long time.

cap the page count and the elapsed time, and fail when either cap is reached.

To implement this, the app should check for 3 properties:

an eligibility check and seen-before ledger that run on the client can be bypassed.

state that all three checks and the mint ledger run on the server.

// Store the mint address to enforce uniqueness across transfers.
return await checkWalletForSGT(walletAddress);

when the check and the record are separate steps, two concurrent claims with the same token can both pass.

show an atomic insert-if-absent keyed on the mint address, for example a unique constraint.

return <Button title="Send Transaction" onPress={handleSendTransaction} />;

a double tap can start two wallet sessions or two sends.

disable the button or reuse the pending promise while a request is in flight.

const transactionSignatures = await wallet.signAndSendTransactions({
  transactions: [transferTransactionMessage],

quickstart.md:243 states that signAndSendTransactions requires minContextSlot, without saying the warning applies only to the hook. Readers cannot tell which contract is right.

align the two samples, or scope the warning to the hook.

npm create solana-dapp@latest

recipes/solana-development/anchor-integration.md:53 uses npx solana-mobile@latest create. Readers do not know which one is current.

document one canonical command, or explain when to use each.

| Mobile Web - Chrome (Android) | ✅ | Automatic integration if using `@solana/wallet-adapter-react`. |

recipes/mobile-wallet-adapter/migrating-to-wallet-standard.md:87-91 says @solana/wallet-adapter-react 1.0.0 and later no longer include MWA by default. A web developer who follows this page gets no mobile wallet option and no explanation. Line 70 also still lists Seed Vault Wallet as "Coming soon!".

update the table to say that registerMwa is required, and refresh the wallet list.

await connection.confirmTransaction(
  { signature, ...latestBlockhash }, "confirmed",
);

the confirmation's value.err is never read, so a transaction that failed on chain is logged as sent. invoke-mwa-sessions-directly.md:480 does check it.

capture the result and treat value.err as a failure.

* The APK is signed with the same Android signing key you used for your initial release.
* The `versionName` and `versionCode` value is properly incremented between each update.

submission uploads to Arweave and mints a release NFT before review. A wrong key or version code is found out late.

add apksigner verify --print-certs with a fingerprint comparison, and a versionCode check.

apksigner verify --print-certs app-release.apk

the build produces app-dappStore-release.apk. The page's critical requirement is a key that differs from the Google Play key, and printing certs does not check that.

use the real path, and compare the certificate fingerprint against the Play signing certificate.

Every dApp Store update needs a higher `versionCode`. Bump `SOLANA_MOBILE_VERSION_CODE` ...

the first release has Verify and Test steps, but the update path ends at the build command.

repeat the verify and test steps for updates, and add a check that the signing certificate matches the previous release.

dapp-store \
  --apk-file ./app/build/outputs/apk/release/app-release.apk \

the pipeline has no pre-publish signature check and no read-back of the release status.

add apksigner verify before publishing and a status check after.

dapp-store --apk-url https://example.com/your_apk_name.apk --keypair ./path/to/keypair.json ...

an APK fetched by URL goes into an on-chain release with no hash or signature check described.

document an expected-hash option or a verify step, or state plainly that the tool performs no check.

Because the shell loads your live site, changes you ship to the web app itself reach users without a new APK.

the verified APK is only part of what users run. A site release can break wallet flows inside the shell with no review step in between.

recommend re-testing connect, sign and send inside the shell for every site release.

Add an instruction to the program, then rebuild and regenerate:

changing the account layout breaks existing accounts, and nothing tells the reader to re-run the whole flow.

add a re-test step (initialize, increment, read) and a note on account-layout migration.

.setRecentBlockhash(blockhashResponse.result!!.blockhash)

the same "create client, fetch blockhash" block appears in five Kotlin pages with three different result shapes and versions.

define one canonical snippet with error handling and link to it.

# Publishing from Google Play to the dApp Store

compared with dapp-store/publishing-from-google-play.md, this copy uses different keystore and alias names and different Gradle syntax, and only the other copy has a verify step.

keep one page and link to it from the other.

it does not store a persistent keypair and the wallet is reset each time the app is exited.

recipes/general/test-with-any-android-device.md:34-38 describes key importing and a required secure lock screen. A developer who follows the setup page alone installs a wallet that fails without a lock screen.

describe the wallet in one place, including the lock-screen requirement.

# Seeker Release Notes

seeker/release-notes/index.md is identical, and neither lists MR4 to MR9.

keep one index and link the releases from it.

### 1. Install Mobile Wallet Standard

the old and new registrations can coexist, so stale call sites keep working silently and the wallet may be listed twice.

add a step to remove the legacy package and its imports, and a check that only one entry is listed.

npm run anchor:deploy:devnet

the funding step is checked, but the deploy is not, so a failed deploy surfaces later as a confusing app error.

add solana program show <id> --url devnet, or an initialize-and-increment check, after the deploy.

AsyncStorage.setItem("authToken", auth_token);
AsyncStorage.setItem("base64Address", firstAccount.address);

the page's own warning (lines 32-38) says AsyncStorage is unencrypted and readable from backups. The copy-paste sample does exactly that with a bearer token that lets the wallet reauthorize silently.

use the SecureStore cache from the same page, or repeat the warning inside the sample.

const handleConnectClick = () => {
    ... await connect();
} else if (mobileWalletAdapter) {

the samples use await in non-async handlers, and mobileWalletAdapter, select and SolanaSignInInput are never declared or imported. The recommended connect flow fails to build.

make the handlers async, take select from useWallet(), find the MWA wallet in wallets, and import the type.

addresses: [authorizationResult.address],

the documented result exposes accounts[].address, so the sample passes undefined as the signing address. authorizeSession is also undefined.

use authorizationResult.accounts[0].address and define the helper.

const messageBuffer = new Uint8Array(
  message.split("").map((c) => c.charCodeAt(0)),

charCodeAt returns UTF-16 units, and Uint8Array truncates them, so any character above U+00FF changes the signed bytes. The quickstart's own note says to use TextEncoder.

new TextEncoder().encode(message).

txSignatureBytes?.let {
    println("Transaction signature: " + Base58.encodeToString(signedTxBytes))

the main signing sample fails to compile.

Base58.encodeToString(it), as get-started/kotlin/quickstart.md:170 does.

.setRecentBlockhash(blockhashResponse.result!!.blockhash)

a rate limit or network error leaves result null, and !! throws in the middle of the open wallet session.

check blockhashResponse.error, handle null, and fetch the blockhash before opening the session.

val response = rpc.sendTransaction(transaction)
if (response.result) {

nullable objects are used as Boolean conditions, and the client is declared as rpcClient, not rpc.

use rpcClient, and test response.result != null and response.error != null.

val request = createBlockhashRequest(commitment, requestId)

commitment is undefined, the block-bodied function has no return, and it calls a suspending request from a non-suspending function.

add a commitment parameter, mark the function suspend, and return the value.

const result = return await transact(async (wallet: Web3MobileWallet) => {

the samples contain const x = return, a missing comma, an unbalanced }));, an unawaited authorize, and a cluster field the page does not document.

correct the syntax, await authorize, and use the documented chain parameter.

class Args_increment(val amount: UInt)

line 57 says the instruction takes amount: u64. UInt serialises as 4 bytes, so the program receives malformed data. amount is also undefined, while line 143 declares an unused incrementAmount.

use ULong, and pass the variable the sample defines.

implementation('io.github.funkatronics:kborsh:${versions.KOTLIN_KBORSH_VERSION}')

in build.gradle.kts, single quotes are a Char literal, so the dependency block fails to build.

use double quotes and a concrete, tested version.

Message.Builder()
    .addInstruction(
        incrementInstruction

the only account is the non-signer counter address, so the message has no fee payer. Line 158 says the fee payer must sign, and the keypair path signs with an arbitrary signer that is not bound to any account in the message. The transaction cannot be submitted as built.

add the user's wallet as fee payer and signer, and sign with that same account.

For signing, EAS can automatically generate and manage a keystore for you on your first build.

line 40 says a separate key is mandatory for apps also on Google Play. A project already built for Play with EAS reuses that project keystore, and the submission is rejected.

say that such projects must use local credentials with a dedicated keystore for the dApp Store profile, as the Google Play guide does.

secret in your CI environment and provide the signer keypair file via `--keypair`:

only the API key is treated as a secret. The keypair controls publishing for the app, and a repository path like ./path/to/keypair.json invites committing it. The ${{ secrets... }} expression also only works inside a workflow file, not in plain bash.

document injecting the keypair from a secret store into a temporary file that is deleted afterwards, preferably for a dedicated publisher wallet.

const latestBlockhash = await connection.getLatestBlockhash();
const txSignature = await transact(async (wallet: Web3MobileWallet) => {

the blockhash is fetched before the user sees the wallet, so a slow approval expires it. toPublicKey is never defined, and confirmation by signature alone cannot detect expiry.

fetch the blockhash with its context inside the session, pass minContextSlot, define the recipient, and confirm with the blockhash strategy.

const signedTx = await transact(async (wallet: KitMobileWallet) => {
  // Request to sign the transaction.
  const signedTxs = await wallet.signTransactions({

signing is privileged and needs authorize first in the session. As written, the wallet rejects the request.

call authorize (or reauthorize with a stored token) before signTransactions, as the web3.js tab does.

identity: {
  name: "My amazing app",
},

get-started/react-native/setup.md:104 says the protocol specification recommends that wallets decline authorization when the identity has no uri. Copied as is, the connect flow can fail on such wallets.

include an absolute uri and an icon, as the other samples do.

(no entry for android-native/*, marketing/*, mobile-wallet-adapter/mobile-apps, reference/typescript/mobile-wallet-adapter-legacy)

these pages exist and are linked from indexed pages, for example the Kotlin quickstart's "JSON RPC Requests" card. Search engines and AI tools that follow the indexes cannot reach them. FAQ is also listed twice, and the release-notes URL differs between index files.

regenerate all index files from the full page set, and remove the duplicate.

Linking.canOpenURL(url)
  .then((supported) => {

on Android 11 and later, canOpenURL returns false unless the scheme is declared under <queries>. Only the Kotlin tab mentions the manifest change, so the React Native button always logs "Unable to link". The Kotlin manifest snippet is also malformed (<manifest without >).

add the <queries> entry to the React Native tab (an Expo config plugin or AndroidManifest.xml), or call openURL directly and catch the error.

if url.scheme == "your-dapp-scheme" && url.host == "connect-response" {
    let connectData = parseConnectResponse(url)

any app can open a custom scheme. Without a per-request state value, a forged response can inject a wallet address or token. The surrounding text speaks of Universal Links, but the code uses a custom scheme.

bind each request to a random state value, check it on the response, and say so in the example.

const signedMessages = wallet.signMessages({
  addresses: [authorizationResult.accounts[0].address],

the promise is returned unawaited, unlike every other sample, so a wallet rejection is not handled where the reader expects.

await the call and show a try/catch for a declined request.

// If both extensions match then it is an SGT
if (hasCorrectMetadata && hasCorrectGroupMember) {
  return mint.address;

the program id is used only as a query filter, and the metadata pointer is a value any mint can set. Today the group-member field carries the guarantee, but the check documents no defence in depth for a gate on rewards.

also assert the mint's owning program, and check the mint and group authorities against published values.

* **Token type**: SPL Token

the SGT page uses Token Extensions, so "SPL Token" is ambiguous for anyone verifying SKR transfers.

give the owning program id next to the mint address.

Install APKs from local files, directories, or the built-in APK catalog.

catalog downloads are cached and installed with --grant, and the page describes no signature check.

document the check, or state that there is none.

The directory defaults to the current one. `--force` overwrites an existing directory.

readers cannot tell whether running the command against an existing project, emulator or directory is refused, merged or overwritten.

document the behaviour without --force, and what --force discards.

This generates a program keypair, writes the new address into `lib.rs` and `Anchor.toml` ...

a second run replaces the program address, and the earlier deployment loses its keypair reference.

say what happens on a re-run, and tell the reader to back up the program keypair.

HttpClient(Android).use { client ->
    client.request(request.url) {
        request.properties.forEach { (k, v) ->

inside the builder, request and this resolve to different objects than a reader expects, which invites mistakes when the snippet is adapted.

label the lambdas or extract the inner loop. Build the Intent first and then start it.