Spark (Lightspark)

Spark is an off-chain scaling solution that builds on top of Statechains to enable instant, extremely low fee, and unlimited self-custodial transactions of Bitcoin and tokens while also natively enabling sending and receiving via Lightning.

Spark is not a rollup, nor a blockchain. There are no smart contracts nor VM. Spark is native to Bitcoin and its payments-focused architecture, enabling on-chain funds to be transacted at any scale, with near-instant speeds, and at virtually zero cost.

At its core, Spark is a simple shared signing protocol on top of Bitcoin. It operates as a distributed ledger. There are no bridges, external consensus, or sequencers. Users can enter and exit the network freely, with funds always non-custodial and recoverable on L1 via a unilateral exit which depends on Bitcoin and no one else. Transactions on Spark happen by delegating on-chain funds via the shared signing protocol.

Like the Lightning Network, Spark transactions work by delegating ownership of on-chain UTXOs between parties. The key difference: Spark introduces a set of signers, called Spark Operators (SOs), responsible for helping sign transactions as they happen. SOs cannot move funds without the users, who are required participants in any transfer. On L1, Spark state appears as a chain of multi-sigs, secured by users and SOs. On L2, it operates as a tree structure, mapping transaction history and balances in real time. Simple, fully native to Bitcoin, and open-sourced.

For a system that scales Bitcoin as effectively as Spark does, it achieves the maximum possible level of trustlessness. Specifically, it maintains 1/n trust assumptions or minority/n depending on the setup. To learn more about the trust assumptions, read our trust assumptions page.

For more information about Spark, please visit https://www.spark.money/.

Spark’s codebase can be found at https://github.com/buildonspark.

Documentation and further resources can be found on https://docs.spark.money/home/welcome.

Spark provides rewards in USDC on ETH, denominated in USD. For more details about the payment process, please view the Rewards by Threat Level section further below.

This bug bounty program will have a hard cap of USD 1,000,000. If multiple bug reports are submitted that exceed this amount, the rewards will be provided on a first come first served basis until that cap is reached.

KYC Requirement

Spark will be requesting KYC information in order to pay for successful bug submissions. The following information will be required:

• Full name
• Date of birth
• Proof of address (either a redacted bank statement with address or a recent utility bill)
• Copy of Passport or other Government issued ID

Eligibility Criteria

Security researchers who wish to participate must adhere to the rules of engagement set forth in this program and cannot be:

• On OFACs SDN list
• A contracted technical contributor who is being directly compensated by the project or directly compensated by a contracted organization providing technical services to the project.
• A former contracted technical contributor who, for the past year from the date of the bug report submission, was directly compensated by the project or was compensated by a contracted organization to the project. In the case of the latter, the status of the organization’s contract with the project is irrelevant.

Responsible Publication

Spark adheres to Category 3: Approval Required. This Policy determines what information researchers are allowed to make public from their submitted bug reports. For more information about the category selected, please refer to our Responsible Publication page.

Primacy of Impact vs Primacy of Rules

Spark adheres to the Primacy of Impact for the following impacts:

• Blockchain/DLT — Critical - Direct loss of funds

Primacy of Impact means that the impact is prioritized rather than a specific asset. This encourages security researchers to report on all bugs with an in-scope impact, even if the affected assets are not in scope.

For more information, please see Best Practices: Primacy of Impact

When submitting a report on Immunefi’s dashboard, the security researcher should select the Primacy of Impact asset placeholder. If the team behind this project has multiple programs, those other programs are not covered under Primacy of Impact for this program. Instead, check if those other projects have a bug bounty program on Immunefi.

If the project has any testnet and/or mock files, those will not be covered under Primacy of Impact.

All other impacts are considered under the Primacy of Rules, which means that they are bound by the terms and conditions set within this program.

Proof of Concept (PoC) Requirements

A PoC, demonstrating the bug's impact, is required for this program and has to comply with the Immunefi PoC Guidelines and Rules.