Turnkey now supports Spark signing natively

Turnkey now natively supports Spark, the rails for instant, near-zero-cost Bitcoin payments, with every Spark operation signed inside secure enclaves.

Signing on Spark can be complex compared to other L2 chains. It has its own address format, a non-standard BIP-32 derivation path, and a protocol-specific Schnorr requirement that differs from Bitcoin Taproot. Spark signing is also not a single-key signing process, adding another layer of complexity.

Getting those details wrong can mean deriving the wrong wallet, applying the wrong signing scheme, or pushing sensitive key operations into application code. Turnkey handles that complexity behind the scenes, making Spark signing simple for developers.

Now Turnkey handles those details by default. Developers can create Spark addresses, sign Spark payloads, and route Spark operations through Turnkey without stitching together custom signing logic or managing raw keys themselves.

The problem: Spark signing is hard

Building on Bitcoin’s Layer 2 ecosystem means dealing with signing complexity that most wallet infrastructure was not built to support.

Spark transfers rely on FROST threshold signing, which requires coordinating key tweaks, encrypting shares, preventing nonce reuse, and deriving new keys when funds are claimed. Turnkey handles this securely behind the scenes, so developers do not have to manage sensitive cryptographic operations in their application code.

Spark also uses plain BIP-340 without the Taproot key tweak, while Bitcoin Taproot uses a tweaked Schnorr variant under BIP-341. The signatures look related from a distance, but they are not interchangeable.

For developers, this creates unnecessary surface area. A team building on Spark may need to support token transactions, Bitcoin transactions on Spark, and settlement flows back to the Bitcoin network. Without native infrastructure support, that often means custom crypto code, manual path configuration, and more room for operational mistakes.

Turnkey now handles Spark’s signing challenges out of the box

Turnkey now supports Spark address derivation and plain BIP-340 Schnorr signing for real application workflows. Instead of configuring Spark-specific signing logic by hand, developers can route Spark operations through Turnkey and get the correct behavior by default.

This includes:

• Automatic Spark address derivation: Developers select the Spark address format in Turnkey, and the correct non-standard BIP-32 path is applied automatically. No manual configuration. No custom path logic. No chance of deriving the wrong wallet account.
• The right signing scheme for each Spark operation: Spark token transfers use plain BIP-340 Schnorr, while deposits, withdrawals, and L1 transfers rely on FROST threshold signing. Turnkey identifies the operation and applies the correct signing flow automatically.
• Signing for Spark transactions: Turnkey supports signing for token transactions on Spark, Bitcoin transactions on Spark, transactions that settle from Spark back to the Bitcoin network, and deposits into Spark from the Lightning Network.
• FROST signing and Lightning preimage generation: Spark signing workflows run inside Turnkey’s enclave, keeping secret material out of application code for most operations. Static deposit flows are the exception because their design requires certain secrets to be exported. Turnkey still handles the protocol-specific signing, key management, and preimage generation required across Spark workflows.

Turnkey’s Spark support is built around the same principle as the rest of Turnkey’s signing infrastructure: private key material should not live in application code.

Spark operations can be routed through Turnkey for signing while keys remain protected inside Turnkey’s infrastructure. Developers can build payment apps, wallets, and token flows on Spark without implementing their own raw key handling or signing service.

Pass a Spark address. Turnkey handles the signing.

Turnkey: Built for teams shipping on Spark

Lightspark’s Spark protocol is designed for instant, low-cost bitcoin and stablecoin payments. As more teams build on Spark, the signing layer needs to become simple, secure, and protocol-aware.

Native Spark support gives developers the right defaults from the start. Address derivation follows Spark’s path requirements. Schnorr signing uses the correct variant. Signing behavior changes automatically based on the address type. Developers can focus on the product instead of maintaining protocol-specific crypto logic.

For payments teams, that means faster integration. For wallet teams, it means fewer edge cases around address generation and signing. For token applications, it means Spark operations can be signed through the same secure Turnkey infrastructure used across other networks.

How to get started with the SDK

The Turnkey SDK includes a runnable Spark example that covers the full range of supported flows, with signing routed through Turnkey. Developers can use it to initialize a wallet and test deposits from Bitcoin, Bitcoin transfers on Spark, token transfers on Spark, Lightning deposits, and withdrawals back to Bitcoin.

The example also covers static deposits, static deposit claims, and Lightning receives, giving teams an end-to-end reference for building with Spark.

Ship instant payment apps, build wallets, and launch tokens securely on Bitcoin with Turnkey.

Learn more about Turnkey Spark support in our docs, and get started with Turnkey today.