Skip to main content

​
The Mental Model Shift

If you’re coming from Aptos, Sui, or EVM-based chains, you’re used to a specific pattern: run a node, connect to it, and trust that the consensus mechanism guarantees validity. Spark works the same way—just with a different topology.
Traditional ChainSpark
Your node validates transactions locallySDK validates operator signatures locally
Your node gossips with validatorsCoordinator gossips with other operators
Validators run BFT/PoS consensusOperators run threshold signature consensus
Finality requires quorum of validatorsFinality requires threshold of operators
The security guarantee is equivalent: no single party can forge transactions or lie about state.

​
How the Client Connects to Operators

​
Operator Registry

Every Spark SDK is configured with the complete set of operators upfront—not just a single API endpoint. This is analogous to how your Aptos/Sui node knows about the validator set. The SDK ships with hardcoded knowledge of:
  • Each operator’s gRPC address
  • Each operator’s identity public key
  • The threshold required for finality (e.g., 2-of-3)
Operator 0: https://0.spark.lightspark.com
  Identity: 03dfbdff4b6332c220f8fa2ba8ed496c698ceada563fa01b67d9983bfc5c95e763

Operator 1: https://1.spark.lightspark.com
  Identity: 03e625e9768651c9be268e287245cc33f96a68ce9141b0b4769205db027ee8ed77

Operator 2: https://2.spark.flashnet.xyz
  Identity: 022eda13465a59205413086130a65dc0ed1b8f8e51437043161f8be0c369b1a410
This is not “just talking to an API.” The SDK knows every participant in the consensus set and can verify their cryptographic signatures.

​
Direct Verification

When the SDK performs a sensitive operation (like generating a deposit address), it doesn’t blindly trust the coordinator’s response. It verifies cryptographic proofs from all operators. Here’s what actually happens when you request a deposit address:
  1. SDK sends request to coordinator
  2. Coordinator forwards to all operators
  3. Each operator signs the address with their identity key
  4. Coordinator returns the address + all operator signatures
  5. SDK verifies every operator’s signature locally
If even one operator’s signature is missing or invalid, the SDK rejects the response. This is identical to how your Aptos node would reject a block without sufficient validator signatures.

​
How Operators Achieve Consensus

​
Coordinator-Based Fanout

Spark uses a coordinator pattern where one operator acts as the entry point. This is purely an optimization—it reduces network round-trips. The coordinator has no special trust privileges. When a transaction is submitted: 
User SDK → Coordinator → [All Operators in parallel]
              ↓
         Collects signatures
              ↓
         Returns to SDK
The coordinator calls ExecuteTaskWithAllOperators(), which spawns parallel gRPC requests to every operator. Each operator independently:
  • Validates the transaction
  • Checks its local state
  • Signs if valid, rejects if not

​
Threshold Signatures (FROST)

For Bitcoin-layer operations, Spark uses FROST (Flexible Round-Optimized Schnorr Threshold signatures). This is the same threshold signature scheme used by cutting-edge wallet infrastructure. The flow:
  1. Round 1: Each operator generates and shares signing commitments
  2. Round 2: Operators exchange partial signatures
  3. Aggregation: Partial signatures combine into a single valid Schnorr signature
No single operator can produce a valid signature alone. Exactly like a 2-of-3 multisig, but with a single on-chain signature.

​
State Replication

Every operator maintains its own complete database. There’s no “primary” database that others read from. When a transaction is finalized:
  1. Each operator writes to its local DB
  2. All operators have identical state (eventually consistent, with strong guarantees on finalized txs)
  3. The SDK can query any operator to verify state
This is how Aptos validators work—each has a full copy of state, and you can query any of them.

​
Token Transaction Consensus

​
The Three-Phase Protocol

Token transactions follow a strict protocol that requires participation from all (or threshold) operators: Phase 1: Start
  • User builds a partial transaction (inputs, outputs, amounts)
  • Sends to coordinator with their signature
  • Coordinator forwards to all operators
  • Each operator validates and reserves resources
  • Transaction enters STARTED state across all operators
Phase 2: Sign
  • User confirms by requesting signatures
  • Coordinator collects signatures from all operators
  • Each operator signs the transaction hash with their identity key
  • Transaction enters SIGNED state
Phase 3: Reveal & Finalize
  • Operators exchange revocation secret shares
  • Once threshold shares are collected, full secrets are recovered
  • Transaction enters FINALIZED state
  • State is now committed across all operators
At every phase, the transaction must pass validation on every operator independently. A malicious coordinator cannot forge consensus—it would need to compromise the threshold of operators.

​
Why You Can’t Run Your Own Operator (Yet)

This is a fair concern. Here’s the honest answer: Current state: The operator set is permissioned, run by Lightspark and partners. This is similar to how Aptos launched with a permissioned validator set before opening up. Why this exists:
  1. Coordination complexity: Operators must participate in DKG (Distributed Key Generation) ceremonies
  2. Uptime requirements: Unlike validators that can be slashed, missing operators can halt transactions
  3. Network effects: More operators means more latency (consensus fanout)
What you get instead:
  1. Cryptographic verifiability: Your SDK verifies all operator signatures
  2. Query any operator: You can hit any operator’s endpoint to verify state
  3. Unilateral exit: You can always withdraw to L1 using the revocation secrets (no operator cooperation required)
  4. Transparency: Operator identity keys are public, their signatures are verifiable

​
Comparison to Other Chains

​
vs. Aptos/Sui

AspectAptos/SuiSpark
ConsensusHotStuff BFTThreshold signatures
Validator/Operator count~100+3 (currently)
Can run your own nodeYesNot yet (planned)
Client verifies consensusVia Merkle proofsVia operator signatures
Finality~1 secondSub-second
Spark’s operator model is intentionally smaller for latency. The tradeoff is fewer independent parties, but with cryptographic guarantees that are mathematically equivalent.

​
vs. Lightning Network

AspectLightningSpark
CounterpartySingle channel partnerThreshold of operators
Fraud proofsOn-chain disputeRevocation secrets
Trust model1-of-12-of-3 (or n-of-m)
Exit pathForce-close on L1Unilateral exit on L1
Spark is strictly better than Lightning for counterparty risk—you’re not trusting a single entity.

​
vs. Rollups (Optimistic/ZK)

AspectRollupsSpark
Data availabilityOn L1/DA layerOperators + exit path
VerificationFraud proofs / ZK proofsThreshold signatures
Withdrawal time7 days (optimistic) / instant (ZK)Instant (cooperative) / ~1000 blocks (unilateral)
Sequencer centralizationOften single sequencerMultiple operators
Spark’s trust model is similar to a rollup with a decentralized sequencer set.

​
The Security Guarantees

Let’s be precise about what you’re trusting:

​
What a single malicious operator CAN’T do:

  • Forge your signature
  • Spend your tokens without your authorization
  • Create tokens out of thin air
  • Prevent your unilateral exit to L1
  • Lie about the state (your SDK verifies signatures)

​
What would require threshold collusion:

  • Censoring your transactions (but you can exit to L1)
  • Halting the network (liveness, not safety)

​
What’s cryptographically guaranteed:

  • All operator signatures are verified client-side
  • Transaction hashes are deterministic and verifiable
  • Revocation secrets enable unilateral exit

​
Practical Implications for Your Integration

  1. Your SDK is not blindly trusting an API. It’s verifying cryptographic proofs from a known set of participants.
  2. You can independently verify state by querying any operator directly. The SDK does this automatically for balance checks.
  3. Your users can always exit to L1. Even if all operators collude against a user, the revocation secret mechanism ensures funds are recoverable.
  4. The operator set is transparent. You know exactly who the operators are, and you can verify their signatures.
  5. This is the same trust model as early-stage L1s. Aptos, Sui, and even Ethereum started with small, permissioned validator sets.

​
Summary

Spark’s architecture is not fundamentally different from other chains. It’s a threshold signature consensus system where:
  • Multiple independent operators must agree on state changes
  • Clients verify consensus via cryptographic signatures
  • No single point of failure for safety (only for liveness)
  • Unilateral exit path to Bitcoin L1 guarantees fund safety
The main difference is topology, not security model. Instead of running your own validator that participates in block production, you run a client that verifies validator (operator) signatures. This is analogous to running a light client on Ethereum—you don’t produce blocks, but you verify that blocks are correctly signed. For an issuer, this means:
  • Your integration is verifying real cryptographic consensus, not just trusting an API
  • The security model is threshold-based, similar to multisig but more sophisticated
  • The path to further decentralization exists (more operators, possibly including you)
The architecture is sound. The operator set is small but growing. And the cryptographic guarantees are equivalent to what you’d expect from any other threshold-based system.