docs/security/THREAT_MODEL.md.
Actors
| Actor | Capabilities |
|---|---|
| Honest validator | Holds validator key, sees its own consensus messages, produces and validates blocks per BFT rules. |
| Honest provider | Holds provider key, registers as compute provider, runs jobs, signs receipts. |
| Honest consumer | Holds consumer key, funds escrow, dispatches jobs, settles receipts. |
| Malicious validator | Same primitives plus may equivocate, withhold, or sign conflicting messages. |
| Malicious provider | Same primitives plus may forge attestations, claim hardware they do not have, spoof receipts, refuse work. |
| Malicious consumer | Same primitives plus may dispute valid receipts, double-spend escrow, abandon jobs. |
| Network attacker | Can drop, delay, reorder, or replay messages. Cannot forge Ed25519 signatures. |
| Operator | Controls chain-build feature flags, genesis params, vendor trust anchors. Trusted as far as launch posture allows; misconfiguration is a documented threat. |
| Reviewer | Reads docs and code, runs tests. Must be able to verify every public claim against the code. |
Assets
| Asset | Where it lives | Protection |
|---|---|---|
| MINT balances | Chain state, derived from typed transactions | BFT consensus + Ed25519 sender signatures + nonce gates |
| Provider stake and bond | Chain state, locked under Stake* transactions | Same as above |
| Compute escrow | Chain state, frozen on ComputeEscrowFund | Released only by ComputeReceiptSettle after the verification gate passes |
| Receipts (T1 / T2 / T3) | Chain state, persisted on settle | Receipt hash verified; settlement gated by tier |
| Identity records (HMR / MHR / ENR / ATR / OrgRoot) | Chain state, anchored via GAL transactions | Anchor-only; off-chain documents proven via signatures and Merkle proofs |
| TEE attestations | Embedded in receipts | Per-vendor cryptographic verifier; fail-closed if material missing |
| Genesis trust anchors | Genesis JSON, not mutable on-chain at launch | Operator integrity; reviewers should diff-audit every chain’s genesis before joining |
| Validator agent keys | Validator-side only; corresponding pubkeys on-chain | Ed25519; rotation via on-chain RotateValidatorAgent (reserved for follow-on release) |
Attack scenarios
Forged T3 attestation
Attack: provider submits a forged TEE report claiming GPU plus TEE. Defence: T3 settle requires the report to verify against operator-pinned trust anchors and the report’s MEASUREMENT to be on the operator allowlist. Forged reports either fail the cryptographic check or carry a measurement the operator never approved. Settlement rejects. Tested across the four TEE vendor verifiers incompute_phase14*_tests.
Fake hardware claim (no T3 path)
Attack: provider declares “H100 GPU” in theircapabilities JSON and runs CPU-only jobs on T1Optimistic.
Defence today: challenge window. Any party can dispute the receipt; arbitration via ChallengeResolution. Limitation: if no party challenges, T1 settles. T1 is by design optimistic; consumers should price T1 accordingly. T2 and T3 require redundant agreement or cryptographic attestation respectively.
Validator equivocation
Attack: validator agent attestsConfirmed and Inconclusive on the same claim, hoping to manipulate the quorum.
Defence: MACA’s per-claim aggregation rejects conflicting attestations from the same validator at the same epoch. The validator is slashed. Tested in compute_phase12_tests::maca_equivocation_rejected.
Double-spend escrow
Attack: consumer funds escrowE, then tries to spend the underlying balance through a parallel transaction in the same block.
Defence: the escrow debits the balance at admission. Any concurrent transaction sees the post-debit state. The nonce gate prevents replay.
Long-range fork
Attack: an adversary controlling >1/3 of historical stake reconstructs a fork from an older checkpoint. Defence: Tower (Casper FFG) accountability. Any validator who signed the alternate chain is detectable from the on-chain evidence and is slashed for full bonded stake. Honest nodes prefer the canonical chain via the latest Tower checkpoint.Public RPC denial of service
Attack: adversary floodsrpc.sigil.ml with low-cost requests.
Defence: Cloudflare DDoS protection at L3/L4, WAF rules at L7, edge rate limit (1,000/min/IP), application-layer rate limit (25/100 rps), and per-method body caps. The direct endpoint trades broader access for a stricter rate limit (10/25 rps). See DDoS protection.
Validator key compromise
Attack: validator’s signing key is exfiltrated. Defence: signing material is hardware-isolated (HSM, Nitro Enclave, KMS). The validator process never holds raw key material. If the key is compromised through a hardware attack, the validator is jailed at the next equivocation and slashed by the protocol; the operator must rotate to a new validator DID.Out of scope for v1
- Side-channel attacks on validator hardware (out-of-band power, timing, EMI).
- Validator collusion exceeding 1/3 of stake. Tower’s accountable safety attributes blame but cannot prevent.
- Off-chain Weave-pinned content censorship by storage providers (mitigated by the storage marketplace’s challenge mechanism).
- Cross-chain bridge security. Bridges are an explicit non-goal for v1.0.