Skip to main content
Security in SocketFi isn’t a feature layered on top — it’s a foundational design constraint that shapes every part of the platform. The core objective is straightforward: users own their wallets, users own their assets, and no action executes without their explicit authorization. SocketFi never takes custody of funds, never holds private keys, and never executes transactions automatically. Every state-changing operation is authenticated, authorized, policy-checked, and cryptographically verified before it reaches the network.

​
Security philosophy

SocketFi’s security model is built on four principles that guide how every component is designed and how responsibility is distributed across users, applications, and the platform.

User Ownership

Users own their wallets and their assets. SocketFi is infrastructure, not a custodian. The user’s smart wallet address is their identity — it persists across credential rotations and device changes.

Explicit Authorization

Nothing executes automatically. Every state-changing action requires a verifiable cryptographic authorization from the user’s passkey credential. There is no silent approval path.

Defense in Depth

Security is enforced through multiple independent layers. An attacker who bypasses one control still faces authentication, authorization, policy enforcement, nonce validation, and time-bound expiry checks.

Least Privilege

Applications only receive the access required to operate. Wallet policies restrict which contracts can be called, what amounts can be moved, and which operations are permitted. The wallet remains the security boundary.

​
Security architecture

Every SocketFi transaction passes through a layered security stack. Each layer independently validates the request — a failure at any layer stops execution:
Authentication answers “who are you?” — it verifies device possession via WebAuthn. Authorization answers “can you do this?” — it verifies that the authenticated identity is the authorized controller of the wallet. Policy enforcement asks “does your wallet allow this?” — it evaluates rules that are encoded in the smart wallet contract. Only requests that pass all layers reach the network.

​
Security layers in detail

SocketFi authenticates users through the WebAuthn standard. The user’s device holds a private key that never leaves the secure hardware. Authentication produces a cryptographic signature over a server-issued challenge — no password, no seed phrase, no shared secret.Authentication alone does not authorize any action. It proves identity, not permission.
After authentication, every state-changing action must be explicitly authorized against the smart wallet. The wallet verifies that the credential used to sign the request matches the registered credential for that wallet. An authenticated user who doesn’t control the wallet is rejected.
Wallet policies are programmable rules encoded in the smart wallet contract. They evaluate before every transaction execution and can enforce spending limits, contract allowlists, authorization requirements, and time-based controls. Policies cannot be bypassed by the application layer.
Every transaction authorization includes a nonce. The wallet maintains a sequential nonce counter and rejects any authorization with an unexpected or previously-used nonce. This prevents replay attacks — an intercepted authorization cannot be re-submitted to execute the same action again.
Authorizations include a ledger-based expiry window. Requests that arrive after the expiry ledger are rejected, even if the signature is valid. This limits the window in which a captured authorization could be misused.

​
Cryptographic security

SocketFi’s security guarantees are grounded in verifiable cryptography, not trust:

​
Shared responsibility model

Security is a shared responsibility. SocketFi provides robust infrastructure, but the overall security posture depends on all three parties doing their part.
  • Protect their devices with biometric authentication or a strong PIN
  • Review transaction approval screens before approving
  • Monitor for unexpected credential change or recovery notifications
  • Keep their operating system and browser updated
  • Communicate transaction intent clearly in user-facing UI
  • Validate inputs before calling requestTransaction()
  • Always verify authentication with verifyAuth() on your backend before granting access
  • Never trust client-provided wallet addresses without backend verification
  • Handle authentication and transaction failures gracefully
  • Use HTTPS exclusively — never transmit tokens over unencrypted connections
  • Never log access tokens or session credentials
  • Maintain secure authentication infrastructure
  • Enforce smart wallet authorization at the contract level
  • Provide recovery mechanisms that update credentials without transferring ownership
  • Monitor and audit security-sensitive events across the platform
  • Maintain and publish security disclosures

​
Security guarantees

The following guarantees hold for every transaction processed through SocketFi:
  • No unauthorized execution — transactions require cryptographic proof of wallet ownership
  • No custody — SocketFi never holds private keys or user funds
  • No replay — nonce validation ensures each authorization is single-use
  • No stale execution — time-bound expiry prevents delayed attacks
  • No policy bypass — wallet policies are enforced at the contract level, not the application layer
  • No silent actions — every state-changing operation requires explicit user approval
SocketFi’s security model protects against unauthorized transactions, replay attacks, and custody risk. It does not protect against users approving malicious applications or signing transactions without reviewing the approval screen. Clear UX and transparent intent disclosure on your part are essential complements to SocketFi’s technical security guarantees.