Skip to main content
This glossary defines the terminology used across SocketFi documentation, SDK reference pages, and error messages. Terms are grouped alphabetically and written to be useful whether you’re a developer integrating the SDK, a product team evaluating the platform, or a security team reviewing an integration.

​
A – C

Access Token — A short-lived credential issued after a successful authenticate() call. Your frontend includes it in API requests as Authorization: Bearer <token>, and your backend validates it with verifyAuth(). Never log or expose access tokens. Authentication — The process of verifying that a user is who they claim to be. In SocketFi, authentication is performed using passkeys through a hosted flow triggered by socketfi.authenticate(). A successful authentication returns an AuthSession containing the access token and user profile. AuthSession — The object returned by authenticate(). It contains socketfiAccessToken (the access token string) and userProfile (which includes the user’s id and wallet address). Authorization — The process of determining whether an authenticated user is permitted to perform a specific action. Authentication answers “Who are you?” — authorization answers “What are you allowed to do?” In SocketFi integrations, authorization decisions should always be made server-side using the verified identity from verifyAuth(). clearKeyCache() — A utility function exported by @socketfi/server that flushes the SDK’s internal public key cache. Useful in automated test environments to ensure each test starts with a fresh key fetch. Not needed in production code — the cache refreshes automatically. Client ID — A unique identifier that ties your application to a SocketFi project. You pass it to new SocketFi({ clientId }) during SDK initialization. Store it in an environment variable, not in source code. Contract — A Soroban smart contract deployed on the Stellar network. Contracts can manage tokens, governance, DeFi logic, and application-specific on-chain state. You interact with contracts through requestTransaction() (write) and readContract() (read). Credential Rotation — The process of replacing a user’s current passkey with a new one while they still have access to the old one. Credential rotation is the right tool when a user gets a new device or wants to upgrade their authenticator. The wallet address and all assets remain unchanged.

​
D – F

Deep Linking — A URL scheme mechanism that returns a mobile user from a hosted authentication or transaction flow (in the system browser) back into your native app. Required for React Native / Expo integrations. Configured via a custom URL scheme (e.g. myapp://). Embedded Wallet — A wallet that lives inside your application’s user experience rather than in a separate wallet app. Users don’t install anything extra — the wallet is part of your product. SocketFi provides embedded smart wallets that are created and accessed through the SocketFi SDK. Fee Abstraction — The ability to sponsor or abstract blockchain transaction fees so users never need to hold a native token (like XLM) to pay for gas. SocketFi smart wallets support fee abstraction, making blockchain interactions invisible to mainstream users.

​
G – L

Hosted Authentication — The SocketFi-managed UI flow that opens when you call socketfi.authenticate(). It handles passkey prompting, wallet creation or loading, and session creation, then returns the AuthSession to your application. Hosted Approval Screen — The SocketFi-managed UI that opens when you call socketfi.requestTransaction(). It displays the contract address, method name, arguments, and estimated fees for the user to review and sign with their passkey before the transaction is executed.

​
M – R

Middleware — A function that runs between receiving a request and executing a route handler. In SocketFi backend integrations, authentication middleware extracts the Bearer token from each request, calls verifyAuth(), and attaches the verified user identity to req.user (Express) or its equivalent. Non-Custodial — A design principle where users retain full ownership and control of their assets. SocketFi is non-custodial: the platform provides infrastructure, but users’ wallets are owned by their passkey credentials and on-chain smart wallet contracts — not by SocketFi. Passkey — A cryptographic authentication credential stored in a device’s secure enclave and backed by WebAuthn / FIDO2. Passkeys authenticate users via device biometrics (Face ID, Touch ID, fingerprint) or hardware security keys. They are phishing-resistant, domain-scoped, and replace passwords entirely. SocketFi uses passkeys as the sole authentication mechanism. Policy — A configurable rule that controls what a smart wallet is allowed to do. Examples include per-transaction spending limits and restricted contract interactions. When a transaction violates a policy, requestTransaction() throws a POLICY_VIOLATION error. Protected Route — A backend endpoint that only accepts requests from verified, authenticated users. In an Express integration, a protected route is one that has authMiddleware applied before its handler. Recovery — The process of restoring a user’s access to their smart wallet after their passkey credential has been lost or their device is unavailable. Recovery updates the wallet’s authentication credential to a new passkey without changing the wallet address, balance, or any on-chain state. Users initiate recovery through a configurable identity-verification flow.

​
S – Z

Session — The authenticated state that exists after a user successfully calls authenticate(). Represented as an AuthSession object. Sessions should be persisted to localStorage (web) or SecureStore (mobile) so users remain signed in across app restarts. Session Persistence — Storing the AuthSession object in durable local storage so users don’t need to re-authenticate on every page load or app launch. See the React Authentication example for the recommended implementation pattern. Smart Wallet — A blockchain account implemented as a Soroban smart contract rather than a simple key pair. Smart wallets support programmable features including account recovery, credential rotation, spending policies, and custom authorization rules. Every SocketFi user gets a smart wallet. Soroban — Stellar’s smart contract platform. Soroban contracts are WebAssembly programs deployed on the Stellar network. SocketFi smart wallets are Soroban contracts, and all on-chain operations use Soroban’s execution environment. Stellar — A public blockchain network optimized for fast, low-cost payments and asset transfers. SocketFi is built on Stellar and uses Soroban for smart contract functionality. Transaction Hash — A unique identifier assigned to a confirmed blockchain transaction. After a successful requestTransaction() call, SocketFi returns { success: true, transactionHash: "…" }. Store transaction hashes server-side for transaction history, support lookups, and analytics. verifyAuth() — The primary server-side verification function exported by @socketfi/server. It accepts a socketfiAccessToken string and returns { valid: boolean, user: { id: string }, wallet: string }. Every protected backend endpoint must call verifyAuth() before trusting any identity claim.
Wallet Address — The unique on-chain identifier for a user’s smart wallet, formatted as a Stellar account ID (e.g. CDXXXXXXXXXXXXXXXX). The wallet address is stable — it never changes across sessions, credential rotations, or account recovery. Access it via session.userProfile.wallet. WebAuthn — The W3C web authentication standard that enables passkey-based authentication in browsers. WebAuthn requires a secure context (HTTPS or localhost). SocketFi relies on WebAuthn-capable environments for all authentication operations.