Your Kaspa universe. One secure wallet.

New Kaspire wallets use 24-word English BIP-39 recovery phrases. A phrase represents 256 bits of entropy plus its BIP-39 checksum. The entropy is generated inside the shared Rust security core using the platform cryptographic random source: Android's operating-system CSPRNG in the app and Web Crypto in the browser extension—not timestamps, device IDs or application-level pseudo-random values.

Before storage, Kaspire asks the user to verify randomly selected recovery words. Sensitive recovery screens use Android FLAG_SECURE to block normal screenshots and recent-app previews.

An optional BIP-39 passphrase becomes part of seed derivation and creates a completely different wallet. Kaspire follows the BIP-39 standard with PBKDF2-HMAC-SHA512 and 2,048 iterations. Every character, space and capitalization choice matters.

Modern accounts follow m/44'/111111'/account'/change/index. Imports also discover legacy coin type 972, receive and change branches, and multiple accounts. The Rust core supports account numbers 0 through 100.

Kaspire keeps BIP-44 accounts and address-index subwallets distinct. For example, …/0'/0/1 is Subwallet 1 inside Account 0, while …/1'/0/0 is the first address of a separate Account 1. This restores the layout used by KasWare without silently changing derivation paths.

Every signing wallet is encrypted at rest with AES-256-GCM and a randomized initialization vector. In the Android app, the non-exportable wrapping key is generated in Android Keystore. On supported devices Kaspire first attempts StrongBox, then falls back to the device's secure Keystore implementation.

The browser extension stores secrets in a versioned local vault protected by an Argon2id-derived key and AES-256-GCM. Decrypted vault material exists only in the extension's isolated session context while unlocked and is discarded on locking or browser-session end. AES-GCM authenticates as well as encrypts: modified ciphertext fails instead of silently yielding corrupted secrets.

In the Android app, recovery phrases and private keys stay out of Dart, WebViews, analytics and the clipboard. Creation, import, encrypted storage, HD derivation and signing are handled by Android's native layer and the Rust core. Only public addresses and reviewed transaction data return to Flutter.

In the extension, the encrypted vault and unlocked session are isolated inside extension-owned storage and background contexts; websites can reach only the bounded window.kaspireprovider. Seed generation, derivation, transaction review and signing use the packaged Rust WebAssembly core. Neither platform exposes private keys or recovery phrases to dApps.

In the app, sending assets, compounding UTXOs, signing messages, importing, exporting or deleting wallets require fresh biometric or Kaspire PIN approval. In the extension, value-moving and signing requests open an extension-owned review and require the unlocked encrypted vault. Connecting a dApp never pre-authorizes a later transaction on either platform.

The optional 4–8 digit PIN uses PBKDF2-HMAC-SHA256, a random salt and 210,000 iterations. Repeated failures trigger an escalating temporary lockout. The PIN is an authorization verifier; Android Keystore remains responsible for seed encryption.

Kaspire treats node and indexer responses as untrusted input. The Rust core verifies UTXO ownership, sender scripts, outpoints, amounts and coinbase state, then independently selects inputs, builds outputs and change, calculates mass and derives the fee.

The server never chooses the final signed recipient output, change output or fee. Watch-only addresses remain isolated and can never silently fall back to another stored signing wallet.

Preparation produces a canonical review containing network, sender, recipient, value, inputs, outputs, change, fee, mass, scripts, payload and token state. A SHA-256 review hash binds the user's approval to those exact fields.

The signer reconstructs everything and rejects any mismatch. After broadcast, the node-returned transaction ID must equal the ID calculated locally from the signed transaction.

KRC-20, KRC-721 and KNS operations use locally constructed canonical commit/reveal payloads with separate authorization. Reveal data is bound to the expected commit address, script, amount and outpoint.

KCC20 is deliberately typed rather than generic. Kaspire requires verified discovery and complete live-cell mapping, recompiles the vendored SilverScript template, enforces token and KAS conservation, checks ownership transitions and Toccata limits, and executes every signed input locally before broadcast.

Kaspire Mobile uses encrypted WalletConnect v2 sessions and advertises only a small, versioned Kaspa method set. The browser extension uses an origin-bound window.kaspire provider with an explicit, bounded method registry. Unknown methods, invalid chains, unauthorized origins and watch-only signing accounts are rejected.

Mobile pairing topics are one-use and memory-only, pairing secrets are redacted, and results return through the encrypted session—not an arbitrary callback. Extension permissions are stored per exact web origin and can be disconnected independently. Personal signatures on both platforms follow KIP-5 and require fresh review.

New kaspire-backup-v2 exports in the Android app and browser extension derive a 256-bit key with Argon2id v1.3, a random 32-byte salt, 32 MiB of memory, three passes and parallelism one. The backup is encrypted and authenticated with AES-256-GCM.

Older PBKDF2-SHA256 backup-v1 files remain importable. Restore checks the format, exact KDF parameters, salt, GCM authentication, recovered address and every registered HD path before accepting the wallet.

The ARM64 and ARMv7 signing core is compiled into the Android app; the browser extension includes the corresponding Rust WebAssembly core inside its reviewed package. Both are pinned to Rusty Kaspa v2.0.1 and locked dependencies. The extension executes no remote code.

Kaspire defaults to its own HTTPS gateway, pruned Kaspa node and local indexer infrastructure. Network timeouts are enforced, while all signing-relevant responses still pass local validation.