This page is the entry point for Sigil’s security review material. Operators should read the threat model, known limitations, and test matrix before deploying production validators.

​
Hard rules

These are the security invariants the documentation and the code enforce. Any violation is a launch blocker:
  1. T3 settlement is fail-closed. Every well-formed-but-not-pinned attestation rejects. Every malformed attestation rejects. Every missing-feature build rejects.
  2. Synthetic test fixtures are not production trust. All synthetic builders are gated under #[cfg(all(test, feature = "tee-verify-*"))] and unreachable from release binaries.
  3. MACA does not finalise chain blocks. Block finality is in sigil-consensus; MACA per-claim attestation is a separate concern.
  4. Self-declared provider capabilities are informational. Compute tier is derived from on-chain stake and attestation. T3 settlement requires cryptographic attestation, not declarations.
  5. The GAL resolver runs all seven rules. No path skips Rule 7. OrgRootMissing for an org-scoped DID is a hard fail, not a silent accept.
  6. Currency naming is canonical. Currency is MINT (mainnet), BITS (canary), test SIGIL (testnet). Protocol and network is Sigil.

​
L0 / subnets are out of scope for v1

Sigil v1 ships as a sovereign chain. L0 framing, hub-and-spoke architecture, and “Sigil subnets” are explicitly out of scope and not marketed. The architectural decision lives in docs/architecture/no-l0-for-v1.md. Rationale:
  • The chain ships a credible v1 first; widening scope before that is unhelpful.
  • L0 framing requires solving cross-zone consensus before the single-zone case is proven.
  • The agent-native primitive set fits poorly with sovereign subnets that fork policy.
  • IBC integration in v1.1 covers the legitimate cross-chain use cases.
L0 framing is forbidden in public marketing for at least 18 months post-mainnet and not built into the protocol until demand is validated.

​
Audit packet

The security packet maps every public claim to a code path, a test, and a known-limitation entry where appropriate. The full packet is checked into the Sigil repository under docs/security/:
DocumentPurpose
THREAT_MODEL.mdActors, assets, attack scenarios, trust boundaries. Mirrored at threat model.
CONSENSUS-REALITY-AUDIT.mdWhat MACA is and is not. Where chain finality actually lives.
TEE-TRUST-BOUNDARY.mdFail-closed posture per vendor with test mapping.
HARDWARE-ATTESTATION-AUDIT.mdProvider hardware claim flow; where self-declaration cannot become “verified”.
GAL-LINEAGE-AUDIT.mdSeven-rule sigil_guard mapping.
DUPLICATE-LOGIC-AUDIT.mdDuplicate-inventory and decisions for security-critical primitives.
PUBLIC-CLAIMS-AUDIT.mdEvery public claim mapped to code path, test, and limitation.
KNOWN_LIMITATIONS.mdExplicit deferred-work list. Mirrored at known limitations.
TEST_MATRIX.mdExact commands and pass counts. Mirrored at test matrix.

​
How the packet is maintained

Each audit document is produced by:
  1. Searching the codebase for the relevant patterns.
  2. Mapping findings to specific file and line references.
  3. Writing regression tests where the audit reveals a gap.
  4. Documenting deferred items as explicit known limitations.
The packet is committed as part of the same change that adds the regression tests, so reviewers can verify each audit against the code at a single commit hash.

​
Reporting a vulnerability

Email security@sigil.ml with a PGP-encrypted report. The Sigil Foundation operates a coordinated-disclosure programme with the following targets:
  • Acknowledgement within 24 hours.
  • Initial triage within 72 hours.
  • Fix in development within 14 days for critical issues.
  • Public disclosure 90 days after the fix or 30 days after the patch ships, whichever is sooner.
A bug-bounty programme is in setup; see security.sigil.ml.