Skip to main content
SocketFi is entirely non-custodial. When you deploy an application on SocketFi, your users own their wallets — not you, and not SocketFi. Every asset a user holds lives in a Soroban smart contract that only they can authorize operations on, because the contract verifies a passkey signature before executing anything. This section explains what that means in practice: what SocketFi can and cannot do, what your application is responsible for, and how to use the wallet address as a reliable user identity in your backend.

What Non-Custodial Means

In a custodial model, a third party holds private keys and can move funds on users’ behalf. SocketFi is the opposite: SocketFi infrastructure routes requests and verifies authorization, but it never holds signing material that could authorize wallet operations. The passkey credential that authorizes the wallet lives on the user’s device and nowhere else.

What SocketFi Can and Cannot Do

SocketFi can:
  • Deploy wallet contracts on behalf of your application
  • Route authentication challenges to the user’s device
  • Verify WebAuthn responses and issue sessions
  • Provide recovery infrastructure when a user loses their passkey
  • Help your application read wallet state and submit authorized transactions
SocketFi cannot:
  • Sign transactions on a user’s behalf
  • Access, freeze, or move user assets
  • Execute operations on a wallet without a valid passkey signature from the user’s device
  • Override wallet policies

Users Authorize Everything

Every state-changing wallet operation requires an explicit passkey signature from the user. The wallet smart contract enforces this on-chain — authorization is not a policy layer that can be bypassed at the application level. This means:
If the signature is missing or invalid, the wallet contract rejects the operation. Your application code cannot bypass this.

Wallet Address as User Identity

Because the wallet address is stable, globally unique, and owned exclusively by the user, it is the most reliable identity anchor available in your system. Use it as the canonical user identifier in your backend.
The wallet address returned by verifyAuth() is stable across logins, device changes, credential rotations, and account recovery. It will never change for a given user.

Verifying Identity on Your Backend

When your frontend sends a wallet address to your backend, you must verify it server-side before trusting it. Never accept a wallet address from the client without verification — a malicious client could claim any address.
Never trust a wallet address provided directly by the client. Always verify the user’s session token using verifyAuth() on your backend, and extract the wallet address from the verified token payload. An unverified wallet address from the client could belong to any user.

Communicating Ownership to Users

Users often do not realize they own their wallet in the same way they would own a seed-phrase wallet. Consider surfacing this clearly in your application:
  • Show the wallet address (or a truncated version) somewhere accessible in account settings
  • Explain during onboarding that their assets belong to them and are protected by their passkey
  • When prompting for transaction approval, reinforce that only they can authorize this action
Users who understand they own their wallet are more likely to engage with recovery setup, keep their passkeys up to date, and trust your application with higher-value transactions.

Developer Responsibilities

While SocketFi handles wallet infrastructure, your application is responsible for: