Flashnet executes complex actions (AMM pool creation, swaps, CLOB, escrow, etc.) without a general-purpose VM by combining three independent actors. The model deliberately splits authority so that no single party can move funds or mutate state.
ActorNon-delegable responsibilities
User1. 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.
TEE1. 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

  1. 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.
  2. m-of-n secret sharing permits liveness with up to n − m offline or malicious validators while preventing sub-threshold collusion.
  3. Deterministic enclave code + remote attestation constrains the TEE to a publicly auditable state machine.
  4. Accountability means that any validator who withholds shards or signs a bad intent can be proven dishonest and penalised.

​
Security Assumptions

  1. The enclave’s hardware isolation (e.g. SGX or Nitro) prevents key extraction; compromised hardware would be detected via failed remote attestation.
  2. At least m validators are honest and responsive; liveness requires this quorum.
  3. 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 m attestations 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.