| Actor | Non-delegable responsibilities |
|---|---|
| User | 1. Signs an intent that encodes the desired state change. 2. Funds the on-spark address referenced in the intent. 3. Chooses a fee and nonce, retaining unilateral ability to cancel by spending these funds elsewhere before execution. |
| Validator₁…Validatorₙ | 1. Hold one Shamir shard Shardᵢ for every on-spark Seed, with threshold m ≤ n required for reconstruction.2. Independently verify every incoming intent: signature, nonce freshness, expiry, fee correctness, and required on-spark balance. 3. If valid, emit an attestation {intent_hash, sigᵢ, enc(Shardᵢ, TEE_pk)} and forward it to the TEE.4. Slashable for withholding shards or signing invalid intents. |
| TEE | 1. Publishes a verifiable remote-attestation quote proving the expected enclave software. 2. Runs the deterministic Spark state-transition logic. 3. Creates a new Seed when persistent state is required and secret-shares it to validators.4. Waits for m distinct attestations. Only then reconstructs the Seed, claims funds, and emits the resulting Spark transaction + event. |
Why the Split Works
- Custody stays with the user until the very moment all validators agree the intent is valid; the TEE cannot act without the shards, and validators cannot act without the enclave.
- m-of-n secret sharing permits liveness with up to
n − moffline or malicious validators while preventing sub-threshold collusion. - Deterministic enclave code + remote attestation constrains the TEE to a publicly auditable state machine.
- Accountability means that any validator who withholds shards or signs a bad intent can be proven dishonest and penalised.
Security Assumptions
- The enclave’s hardware isolation (e.g. SGX or Nitro) prevents key extraction; compromised hardware would be detected via failed remote attestation.
- At least m validators are honest and responsive; liveness requires this quorum.
- Spark finality ensures that once the tx is signed the state transition is immutable and can be sequenced to Bitcoin.
Failure Scenarios
- Validators offline (< n − m) – Execution proceeds once a quorum
mattestations are collected. - Validators offline (≥ n − m) – Execution pauses until governance replaces missing validators or rotates the pool.
- TEE downtime – Validators keep collecting attestations; nothing can be executed until the enclave restarts and proves freshness via attestation quote.