Kaspa is coming to SSP — and the library behind it is open source

Kaspa support is on its way to SSP. It will be the same 2-of-2 multisig you already use for Bitcoin, Ethereum and Solana: one key in SSP Wallet, one on SSP Key, and nothing moves unless both agree. Enterprise vaults will get Kaspa too.

Getting there meant building something that didn't exist. Today we can share the part that's already public: @runonflux/kaspa-core, an open-source TypeScript library for Kaspa transactions and multisig, released under the MIT licence.

Why we built a library first

When we looked at adding Kaspa, we surveyed every JavaScript Kaspa package we could find. None of them could actually build and sign a Kaspa multisig transaction end to end — the one thing SSP needs above everything else.

The official route is Kaspa's Rust code compiled to WebAssembly. It's excellent software, but it's a poor fit for SSP. SSP Key runs on React Native, where WebAssembly isn't available, and the browser extension has to stay lean — the WebAssembly bundle alone is more than 11 MB.

So we wrote Kaspa's transaction rules from scratch in plain TypeScript: addresses, scripts, M-of-N multisig, signature hashes, Schnorr signing, fee and "mass" calculation, and input selection. It has two runtime dependencies — the widely used, audited @noble cryptography libraries — and runs unchanged in browsers, extensions, Node and React Native.

How we checked it

For wallet code, "it seems to work" isn't a standard. The library is built to be provably identical to the Kaspa node itself:

• Checked against Kaspa's own code. The test suite runs every consensus-critical function against rusty-kaspa, the reference node implementation, and executes library-signed transactions through its real script engine — including every M-of-N combination from 1-of-1 up to 15-of-15.
• Real mainnet data. Existing mainnet transaction IDs and signatures are reproduced exactly.
• Funded mainnet transactions. Fifteen real transactions — among them SSP-style 2-of-2 spends, a 2-of-3, and enterprise-style 4-of-7, 6-of-10 and 10-of-15 multisigs — were built and signed with the library and accepted by the network. For every one, the node's calculation of the transaction's mass matched ours exactly.
• Adversarial review. Multiple rounds of security review looked specifically for ways to trick a signer or inflate a fee. No critical issues were found, and every finding was fixed with a regression test. The report is published alongside the code.

Open code is part of the same principle as reproducible builds: you shouldn't have to take our word for what signs your transactions.

What Kaspa in SSP will look like

Your Kaspa vault will be a Kaspa multisig address (it starts with kaspa:p), derived from both of your devices on SSP's usual derivation path. Sending works the way it does for other chains: SSP Wallet prepares and signs its half, SSP Key shows you the recipients, amount and fee, and only after you approve there does the transaction reach the network. It's the same 2-of-2 model, on a new chain.

A few Kaspa-specific details shaped the design:

• Each device checks the amounts itself. A Kaspa signature commits only to the amount of the input it signs, so a device that trusted amounts handed to it could be misled about the fee. In SSP, each device looks up the coins being spent on its own before signing, and signs only for its own vault.
• The transaction ID is known before signing. Kaspa's transaction ID doesn't include the signatures, so SSP can pin a transaction to its final ID before either key has signed it.
• Fee ceilings are built in. Fees are capped, so a bad fee estimate can't turn into an expensive mistake.

For businesses, SSP Enterprise vaults will support Kaspa with M-of-N approval, up to Kaspa's standard limit of 15 keys per vault.

What's not in the first release

We'd rather ship a small thing well than a large thing loosely. The first release covers KAS itself on mainnet. KRC-20 tokens, Kaspa testnet, Kaspa message signing and WalletConnect for Kaspa are not included at launch.

When

Kaspa support is implemented across SSP Wallet, SSP Key and SSP Enterprise, and is going through final testing now. We'll announce it here, with release notes, when it's available — until then, there's nothing to enable and nothing to download, and anyone telling you otherwise isn't us.

In the meantime, developers can use the library today: it's on npm as @runonflux/kaspa-core and on GitHub at RunOnFlux/kaspa-core.