Skip to main content
Every SocketFi wallet is a Soroban smart contract, not a traditional externally owned account (EOA). That distinction matters. A traditional wallet is just a private key that can sign anything — it has no logic, no rules, and no built-in safety nets. A SocketFi smart wallet is a programmable account that verifies passkey signatures, enforces spending policies, manages its own nonce state, supports credential rotation, and enables account recovery — all enforced on-chain by the contract itself, not by any off-chain service.

Traditional Wallet vs Smart Wallet

Five Wallet Capabilities

A SocketFi smart wallet is composed of five capabilities that work together to process every request:

Authorization Engine

Verifies that every state-changing operation is accompanied by a valid passkey signature, a correct sequential nonce, and a non-expired authorization window. If any check fails, execution stops immediately.

Policy Engine

Evaluates the wallet’s configured policies — spending limits, allowed contracts, time windows — after authorization passes but before execution. All policies must pass; any single failure blocks the transaction.

Fee Engine

Manages transaction fee calculation, collection, deferred fee tracking, and settlement. Supports fee abstraction so users are not required to hold XLM to pay for operations.

Recovery Engine

Handles the credential replacement logic for account recovery flows. Enforces identity verification requirements and authorization rules before updating the wallet’s bound credential.

Wallet State

Maintains the on-chain state that all other engines read and write: the bound credential, policy configuration, nonce counter, recovery configuration, and fee state.

How Authorization Flows Through the Wallet

When your application calls requestTransaction(), the request travels through each engine in sequence:
Failure at any stage stops execution and returns an error to your application. The wallet state is only updated after successful execution.

Requesting a Transaction

Submitting a transaction through the SDK requires only the contract target, method name, and arguments. The SDK handles authorization message construction, prompts the user for their passkey signature, and submits the authorized transaction to the network.
Your application never constructs or handles raw passkey signatures. The SDK manages the full authorization flow internally — building the authorization message, invoking the passkey prompt on the user’s device, and submitting the signed transaction.

Wallet Lifecycle and State

Smart wallet state evolves over the wallet’s lifetime. Here is how state changes across key lifecycle events: The wallet address — CDXXXXX... — is set at deployment and never changes across any of these events.

Contract Awareness

Because SocketFi wallets are themselves Soroban contracts, they can participate in contract-to-contract interactions with full authorization awareness. When your wallet invokes another contract, the wallet contract propagates authorization context through the call chain:
The wallet verifies authorization before forwarding execution to any downstream contract. This means complex multi-step interactions are as secure as simple transfers — the wallet remains the enforcement layer throughout.