Sigil’s security model is layered. Each layer has an explicit threat surface and an explicit recovery path. This page summarises the model; the full audit material lives under Operate → Security.

​
Threat surface by layer

LayerAsset at riskPrimary defenceRecovery
IdentityDID private keyHardware-isolated keystore, FROST threshold for MHRRecovery ceremony with guardian threshold
ConsensusChain liveness and safetyMACA 2f+1 quorum, Tower epoch lockTower checkpoint + operator restart
ExecutionState integrityNative typed executor, deterministic WasmtimeSlashing of equivocating validators
SettlementState durabilityWAL, fsync-tight commits, content-addressed snapshotsSnapshot restore + WAL replay
OperationalValidator and RPC infrastructurePer-host hardening, segmented network, monitoringIncident runbooks under Operate tab

​
Validator economics

Validators are economically bound through three mechanisms:
  1. Bonded stake. Required to be in the active set. Slashed for misbehaviour.
  2. Publisher bond. Posted per block proposal. Refunded on finalisation, slashed on invalid blocks.
  3. Generation decay. Agent-operated validators earn at β = 0.85^d of the human-operated rate, concentrating reward and accountability at the human root.
Slashing rates:
OffencePenaltyNotes
Equivocation5.0% + 30-day jailProvable from own signatures.
Invalid block1.0% + jail until next epochDetected by state-root mismatch.
Downtime0.01% per epoch over thresholdThreshold is >5% of rounds missed.
Long-range attack (Tower)100% of bonded stakeAccountable safety via Tower evidence.

​
Key isolation

Validator signing keys are held in hardware-isolated keystores (HSM, Nitro Enclaves, or AWS KMS-backed signers). The validator process exposes a thin signing API; the raw key material never enters the process. Recommended hardware:
  • AWS Nitro Enclave with KMS integration.
  • YubiHSM 2 connected over the validator’s air-gapped management plane.
  • Google Cloud HSM (FIPS 140-2 Level 3).
See key custody and the validator program documentation.

​
RPC security

Public RPC endpoints expose a sanitised, profile-restricted method table. Internal methods (block production, peer management, log inspection) are not reachable from the public surface. The RPC profile system is enforced in node/sigil-rpc/src/profiles.rs and exercised by node/sigil-node/tests/rpc_conformance.rs. Rate limits and DDoS posture are documented in the RPC endpoints runbook and DDoS protection.

​
Recovery posture

FailureRecovery path
Lost user keyRecovery ceremony with guardian threshold under 30-day timelock.
Slashed validatorRe-bond after jail; balance is reduced by slashing percentage.
State corruptionSnapshot restore at the last finalised epoch.
Long-range forkTower evidence + governance-coordinated restart.
RPC outageDirect (no-middlebox) endpoint remains available.

​
Out-of-scope threats

The current security model does not protect against:
  • 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.
The full known-limitations matrix is at known limitations.