Skip to main content
Authorization is the mechanism that makes SocketFi wallets secure. It is distinct from authentication: authentication answers who are you?, while authorization answers are you allowed to do this right now? Every state-changing wallet operation — transfers, contract calls, policy updates, credential rotation, recovery — must carry a valid authorization before the wallet contract will execute it. Without a passing authorization check, the operation is rejected on-chain. No exceptions.

​
Authentication vs Authorization

It is easy to conflate these two concepts, but they serve different purposes in the SocketFi architecture: Authentication gives your application a session. Authorization gives the wallet contract proof that the current operation was explicitly approved by the wallet’s owner.

​
Authorization Message Structure

Before a wallet operation executes, an authorization message is constructed and signed by the user’s passkey. The message binds together everything relevant to the operation:
The user’s passkey signs this exact message. The wallet contract independently reconstructs the expected message from the transaction context and verifies that the signature matches. If any field differs — including the nonce or expiration — verification fails.

​
The Nonce System

The nonce is a sequential counter stored in the wallet’s on-chain state. It starts at 0 when the wallet is created and increments by 1 after every successfully executed state-changing operation. Its purpose is to prevent replay attacks. How nonces prevent replay attacks:
Without nonces, an attacker who intercepted a valid authorization signature could resubmit it repeatedly. With sequential nonces, each authorization is one-time-use: once a nonce is consumed, that exact authorization can never be reused. Nonce flow for every transaction:

​
Expiration Windows

Every authorization message includes a valid_until ledger number. The wallet contract checks the current Stellar ledger sequence against this value before executing. Authorizations that exceed their window are rejected even if the signature is valid.
Keeping expiration windows short (seconds to minutes, not hours) reduces the risk window if an authorization message is intercepted in transit.

​
What Requires Authorization

Every operation that changes wallet state requires a valid authorization. Read-only operations do not.

Asset Transfers

Sending any asset from the wallet to another address.

Contract Calls

Invoking any method on a Soroban smart contract through the wallet.

Policy Changes

Adding, removing, or modifying spending limits, contract allowlists, or other wallet policies.

Credential Updates

Rotating the passkey credential bound to the wallet (requires the current credential’s authorization).
Account recovery follows a separate authorization path — it does not require the current credential (which is lost), but instead requires identity verification through the recovery system. See Recovery for details.

​
Verification Pipeline

The wallet contract runs every authorization through this pipeline before execution:
Failure at any stage stops execution immediately. The wallet state is not modified.

​
Authorization Failure Reasons

When an authorization check fails, the wallet returns a specific failure reason:

​
Security Properties

The authorization system provides four concrete security guarantees:
Only operations signed by the wallet’s bound passkey credential are authorized. The wallet contract verifies the signature against the stored public key on every operation — there is no administrative override.
The sequential nonce system ensures each authorization is consumed exactly once. An authorization signed for nonce 42 cannot be replayed once the wallet’s nonce has advanced to 43.
The valid_until expiration window ensures that stale or intercepted authorizations cannot be submitted indefinitely. Authorization windows should be kept as short as practical for your use case.
Authorization is enforced by the Soroban wallet contract itself, not by SocketFi’s off-chain infrastructure. There is no intermediary that can bypass or override the on-chain verification logic.