Skip to content
HSuite Docs

Security

Security on Smart Engines is not a feature layer bolted onto a blockchain backend. It is the shape of the architecture. The platform was built around a single refusal — no single key controls anything on chain — and every other control on this page is downstream of that decision.

If you are an enterprise buyer or auditor, start here. If you are a builder, this section tells you exactly what the platform guarantees so you know what you don’t have to build yourself.

The four headline guarantees

Section titled “The four headline guarantees”
# Guarantee What it means Where it’s enforced
1 No whole signing keys Every on-chain signing key is born split across validators by a distributed key generation (DKG) ceremony, and only shares are ever stored. Signing runs the two-round FROST protocol: each validator contributes a signature share, so the key is not assembled at creation or at signing. TSS / MPC, DKG & TSS concept
2 Zero single-sig after genesis After cold-start, every on-chain authority is a native chain multisig with the master key disabled. There is no master key to steal. Zero Single-Sig, Threat Model
3 Public, mandatory rules Authorization policy is published on Hedera HCS — publicly readable, mandatory, enforced per transaction. The quorum will not sign what the rules forbid. Rules Engine, Token Gating
4 Post-quantum evidence and encryption Validators sign platform records with FIPS 204 ML-DSA-87 quorum certificates that customers can verify offline, and internal secrets are sealed with FIPS 203 ML-KEM key encapsulation. Certificates are minted today for a few internal record types only, and a missing certificate is logged rather than rejected. Post-Quantum

The security model in one diagram

Section titled “The security model in one diagram”
%%{init: {'flowchart':{'htmlLabels':true,'curve':'basis'}}}%%
flowchart TB
    Req["Inbound request<br/>(SDK / customer / smart-app)"]

    subgraph AccessControl["Access control layer"]
      Auth["Web3 auth<br/><i>signature challenge</i>"]
      Gate["TokenGate<br/><i>rules-engine molecule</i>"]
    end

    subgraph Policy["Policy layer"]
      Rules["Rules Engine<br/><i>public on HCS, mandatory</i>"]
    end

    subgraph KeyLayer["Distributed key layer — no whole signing key exists"]
      DKG["Per-entity DKG<br/><i>keys born split</i>"]
      TSS["Threshold signing<br/><i>FROST signature shares</i>"]
      MS["Native chain multisig<br/><i>master key disabled</i>"]
    end

    subgraph Evidence["Evidence layer"]
      PQC["PQC attestation<br/><i>ML-DSA-87 quorum cert</i>"]
    end

    Req --> Auth --> Gate --> Rules
    Rules -->|"only what rules allow"| TSS
    DKG -.->|shares| TSS --> MS --> Chain["Blockchain ledger<br/><i>verifies quorum natively</i>"]
    MS -.->|"planned for on-chain transactions"| PQC

The flow reads top-to-bottom: a request is authenticated, gated by token ownership where a gate is configured, checked against public rules, and only then routed to the distributed-key layer — where a quorum of validators produces a signature the blockchain verifies with its own native multisig rules. The design also attests each on-chain result with an ML-DSA-87 quorum certificate; today those certificates are minted for a few internal record types, not yet for on-chain transactions.

Pages in this section

Section titled “Pages in this section”
Page Read it for
Threat Model Adversary classes (rogue validator, compromised host, stolen device, quantum adversary, malicious smart-app) × exactly what stops each — and the honest residual risks.
Formal Verification What we proved about the protocols that survive validators joining and leaving — checked with Quint and Apalache, the 13 defects the models found in our own code, and the one command that reproduces the results.
TSS / MPC Threshold signatures, Distributed Key Generation (DKG), the two-cryptosystem ceremony, FROST signing, resharing, and recovery.
Post-Quantum The PQC posture: ML-DSA-87 signatures, ML-KEM encryption, the PqcCertV1 attestation, offline verification, and what is minted, enforced or only logged today.
Token Gating The TokenGate molecule, where it is evaluated, and which gates are in effect today.

Key security principles

Section titled “Key security principles”
  • Zero single points of trust — on-chain signing keys are never held whole; signing needs a threshold of validators that is at least a strict majority of the committee.
  • Least privilege by default — see the standing posture: the decentralized, revocable, per-tenant-isolated option is always the default; convenience trades require explicit sign-off. Recent hardening makes this concrete: new apps get a strict, customer-scoped SDK client (an SDK call made on behalf of a customer sees only that customer’s rows, not the whole tenant); the validator’s envelope decrypt surface is bound per calling service to only the secrets that service’s job needs; and every per-app resource route is owner-scoped, so one tenant can never read another’s usage data.
  • Defense in depth — auth, token gating, public rules, distributed keys, native multisig, and attestation are independent layers; breaking one does not break the chain of custody.
  • Verify, don’t trust — the platform’s attestations are designed so you verify them offline, against on-chain state, without trusting Smart Engines’ word.
  • Secrets never baked into images — runtime secrets use envelope encryption under a key-encryption-key (KEK) hierarchy and are mounted at runtime, never compiled into container images (see Threat Model).

Next steps

Section titled “Next steps”