Overview
There are two main approaches to detect Seeker users:- Platform Constants Check: A lightweight client-side check using React Native’s Platform API
- 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.Checking Platform Constants
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 thenonce, issuedAt, and expirationTime fields. The nonce must be single-use and short-lived — without it, a captured signInResult can be replayed to authenticate forever:
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.signInResult from the MWA response needs to be verified on your backend server. Verification must check three things:
- The
nonceis 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. - The signature is valid for the issued payload.
- The payload’s
domainis your domain — a signature obtained by a different dApp must not verify.
verifySIWS returns the verified wallet address:
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:
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), ornull 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
- 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.
