Skip to main content

Overview

There are two main approaches to detect Seeker users:
  1. Platform Constants Check: A lightweight client-side check using React Native’s Platform API
  2. Seeker Genesis Token Verification: A secure on-chain verification method

Method 1- Platform Constants Check

The Platform Constants method checks device information using React Native’s built-in Platform API. This is a quick, lightweight check suitable for UI treatments and non-critical features.
SECURITY CONSIDERATIONThe Platform Constants API can be spoofed and should not be used for use cases where you need a guaranteed Seeker user.For use cases where you need a guarantee that you are interacting with a Seeker user, see Method 2: Seeker Genesis Token Verification instead.

Checking Platform Constants

When running on a Seeker device, the above code outputs something like:
To check if the user is on a Seeker, you can check the Model constant:

Use Cases

  • UI Treatments: Show special welcome messages, themes, or layouts for Seeker users
  • Feature Flags: Enable/disable certain features based on device type
  • Analytics: Track usage patterns by device type
  • Marketing: Display device-specific promotional content

Limitations

The main limitation is that this method is spoofable - rooted devices or modified apps can change the Platform constants to mimic a Seeker device. See the next method for a guaranteed way to check for interaction with a Seeker user.

Method 2 - Seeker Genesis Token Verification

For use cases where you need a guarantee that you are interacting with a Seeker user, verify that the user’s wallet contains the Seeker Genesis Token (SGT). The SGT is a unique NFT that is minted to a user’s wallet only once per Seeker device. Owning an SGT represents verified ownership of a Seeker device. Learn more about the Seeker Genesis Token.

Genesis Token Verification Process

The verification process has two main steps:
1

SIWS to prove wallet ownership

Use Sign-in-with-Solana to prove the user owns the wallet
2

Check the wallet contains an SGT

Once wallet ownership is proven, verify that the wallet contains a Seeker Genesis Token

Step 1 - Prove Wallet Ownership with SIWS

Server-side: Issue the sign-in payload Generate the SIWS payload on your backend so you control the nonce, issuedAt, and expirationTime fields. The nonce must be single-use and short-lived — without it, a captured signInResult can be replayed to authenticate forever:
Client-side: Sign the SIWS Payload Fetch the payload from your backend, then use Mobile Wallet Adapter to request the user to sign it:
This flow only authorizes and signs, so it uses no Solana library primitives. Apps on @solana/web3.js can import transact from @solana-mobile/mobile-wallet-adapter-protocol-web3js instead — the rest of the code is unchanged.
Server-side: Verify the SIWS signature The signInResult from the MWA response needs to be verified on your backend server. Verification must check three things:
  1. The nonce is one you issued, has not expired, and has not been used before — load the payload you stored for it rather than trusting a client-supplied copy.
  2. The signature is valid for the issued payload.
  3. The payload’s domain is your domain — a signature obtained by a different dApp must not verify.
On success, verifySIWS returns the verified wallet address:
For complete SIWS verification details, see the Phantom SIWS spec.

Step 2 - Check SGT Ownership

Server-side: Query an RPC to verify SGT ownership On your backend, use the @solana-mobile/skr-genesis-token package to check if the user’s wallet contains a Seeker Genesis Token:
See Verifying Seeker Genesis Token Ownership for more.

Step 3 - Combine SIWS Verification and SGT Check

On your backend server, combine the SIWS verification and SGT ownership check together to confirm the user is a verified Seeker owner. The function returns the mint address of an SGT that has not claimed yet, so you can record it for uniqueness checks (see the warning below), or null if verification fails. A wallet can hold more than one SGT, so it checks every mint rather than only the first. RPC errors are thrown, not returned as null, so handle them separately from a failed check:

Use Cases

WARNINGSGTs are transferrable between a user’s wallet, so you must verify uniqueness by checking the SGT’s unique mint address.For full details and best practices, see the Transferability documentation.
  • Gated Content: Restrict certain features or content to verified Seeker users.
  • Rewards Programs: Distribute exclusive rewards to Seeker owners.
  • Anti-Sybil Measures: Prevent multiple claims or actions per device.

Code samples on this page are subject to the Apache 2.0 license.

Last modified on October 13, 2026