Your First Wallet

Overview

In this module, you'll learn how to create BSV wallets using the TypeScript SDK. We'll cover two distinct approaches: backend wallet management (server-side key management) and frontend wallet integration (browser-based using WalletClient).

Understanding these two paradigms is crucial for building secure and user-friendly BSV applications.

Learning Objectives

By the end of this module, you will be able to:

  • Understand the difference between backend and frontend wallet paradigms

  • Generate and manage private keys securely on the backend

  • Implement HD wallets using BRC-42 key derivation

  • Follow security best practices for key storage

  • Understand when to use WalletClient for frontend applications

  • Create production-ready wallet implementations

What is a Wallet?

A BSV wallet is software that:

  • Manages private keys securely

  • Generates addresses for receiving payments

  • Signs transactions to send payments

  • Tracks UTXOs (Unspent Transaction Outputs)

  • Maintains transaction history

Important: A wallet doesn't "store" BSV. It stores the private keys that control UTXOs on the blockchain.

Backend vs Frontend Wallet Paradigm

Backend Wallet (Custodial/Server-Side)

Use Case: When your application controls funds on behalf of users

Characteristics:

  • Private keys stored server-side

  • Application signs transactions

  • Full control over key management

  • Requires robust security infrastructure

  • Examples: Exchanges, payment processors, custodial services

Pros:

  • Simplified user experience

  • No wallet setup required for users

  • Can implement complex business logic

Cons:

  • You're responsible for security

  • Single point of failure

  • Regulatory implications (you custody funds)

Frontend Wallet (Non-Custodial)

Use Case: When users control their own funds

Characteristics:

  • Private keys stored in user's browser/device

  • User signs transactions via wallet extension

  • No server-side key storage

  • Uses WalletClient SDK integration

  • Examples: DApps, web3 applications

Pros:

  • Users control their own keys

  • No custody liability

  • Better privacy

Cons:

  • Requires user to have wallet setup

  • More complex UX

  • Limited control over transaction signing

This Module: We'll focus on backend wallet implementation. For frontend wallet integration using WalletClient, see the Wallet Client Integration module.

Backend Wallet Implementation

Understanding Wallet Types

1. Simple Wallet

Single private key controlling one or more addresses.

Pros: Simple to understand and implement Cons: Must backup each key separately, not scalable

2. HD Wallet (Hierarchical Deterministic)

One master seed generates unlimited keys deterministically using BRC-42.

Pros:

  • One backup for all keys

  • Deterministic key derivation

  • Can generate keys without exposing master key

  • Supports key hierarchy and organization

Cons: Slightly more complex implementation

Recommendation: Always use HD wallets for production applications.

Creating a Simple Wallet

Step 1: Generate a Private Key

Output Example:

Security Note: Never log private keys in production. This is for educational purposes only.

To run this example:

Step 2: Derive Public Key and Address

Key Concepts:

  • Private Key: Secret number (256 bits). Must be kept secure.

  • Public Key: Derived from private key via ECDSA. Can be shared publicly.

  • Address: Hash of public key. Used for receiving payments.

To run this example:

Step 3: Create a Basic Wallet Class

Creating an HD Wallet with BRC-42

HD wallets provide a scalable, hierarchical key management system. The SDK uses BRC-42 for deterministic key derivation.

Understanding BRC-42 Key Derivation

BRC-42 defines how to derive child keys from a master key using:

  • Protocol ID: Identifies the application/protocol

  • Key ID: Identifies the specific key purpose

  • Counterparty: Optional, for key exchange protocols

This creates a hierarchy: Master Key → Protocol → Key ID → Derived Key

Step 1: Generate Mnemonic Seed Phrase

Mnemonic Standards:

  • 12 words = 128 bits of entropy (standard, secure)

  • 15 words = 160 bits of entropy

  • 18 words = 192 bits of entropy

  • 21 words = 224 bits of entropy

  • 24 words = 256 bits of entropy (maximum security)

Security: The mnemonic phrase is the root of all keys. Protect it like the master password to all funds.

Step 2: Derive Master Private Key

Step 3: Implement HD Wallet with BRC-42

Advanced: Using KeyDeriver for Complex Hierarchies

For more complex key derivation needs, the SDK provides the KeyDeriver class:

UTXO Management and Balance Tracking

Important: In modern SDK-based applications, you should NOT manually track UTXOs by querying external APIs. The SDK provides built-in UTXO management.

How UTXO Tracking Works

When you create transactions using the SDK:

  1. Backend Applications: Use Transaction class which handles UTXO selection automatically

  2. Frontend Applications: WalletClient manages UTXOs through wallet integration

  3. ARC Integration: Submit transactions to ARC, which provides status and confirmation

  4. No Manual Fetching: Don't query blockchain explorers for UTXOs

Transaction Creation (Basic Pattern)

Key Point: Your application should maintain its own UTXO state in a database. When transactions are created/confirmed, update your UTXO set accordingly. See the Transaction Management module for details.

Secure Key Storage Best Practices

Security is paramount when managing private keys on the backend. Follow these practices:

1. Never Hard-Code Keys

NEVER DO THIS:

2. Environment Variables (Development Only)

For development and testing, use environment variables:

.env file (NEVER commit to version control):

.gitignore:

3. Production Key Storage

For Production, Use:

Option A: Hardware Security Modules (HSM)

Option B: Encrypted Database Storage

Option C: Secret Management Services

4. Security Checklist

Key Storage:

Access Control:

Operational Security:

Development vs Production:

5. Key Rotation Example

Complete Production Wallet Example

Here's a complete example demonstrating production-ready patterns:

Frontend Wallet Alternative: WalletClient

For frontend applications where users control their own keys, use WalletClient instead of managing keys directly.

When to Use WalletClient

  • Building a DApp (decentralized application)

  • Users need to control their own funds

  • Non-custodial architecture

  • Browser-based applications

  • Need wallet extension integration

WalletClient Quick Example

Key Difference: With WalletClient, the user's browser wallet handles all key management and signing. Your application never touches private keys.

Learn More: See the Wallet Client Integration module for complete frontend wallet implementation.

Testing Your Wallet

Unit Tests Example

Integration Testing on Testnet

Practice Exercises

  1. Simple Wallet: Create a simple wallet and derive 10 addresses

  2. HD Wallet: Create an HD wallet with BRC-42 and generate addresses

  3. Encryption: Implement mnemonic encryption and decryption

  4. Backup & Restore: Export wallet backup and restore it

  5. Key Derivation: Derive specialized keys for signing, encryption

  6. Production Setup: Configure encrypted key storage with environment variables

Summary

What You Learned:

  • Difference between backend and frontend wallet paradigms

  • How to create simple and HD wallets using the SDK

  • BRC-42 key derivation for hierarchical key management

  • Security best practices for production key storage

  • When to use WalletClient for frontend applications

Key Takeaways:

  • Backend wallets: You control keys, you're responsible for security

  • Frontend wallets: Users control keys via WalletClient

  • Always use HD wallets for production (BRC-42)

  • Never expose private keys in logs, APIs, or UI

  • Use HSM/encryption for production key storage

  • Test on testnet before deploying to mainnet

Next Steps

Now that you understand wallet management, let's create and broadcast transactions!

Continue to: Your First Transaction

Security Reminders

Critical Security Rules:

  1. Never share your private key or mnemonic phrase with anyone

  2. Always backup your mnemonic in a secure location

  3. Use testnet for learning and development until you're confident

  4. Encrypt all private keys stored in databases or files

  5. Use HSM/KMS for production environments

  6. Never commit keys to git - use .gitignore

  7. Implement key rotation policies for long-running services

  8. Test with small amounts before moving to production

  9. Audit your security practices regularly

  10. Have incident response plans for key compromise

Your mnemonic phrase is the master key to all derived keys. Treat it like the password to your bank account - because it is!

Last updated