The Mental Model

What you’ll get here

the whole platform in five minutes — tiers, clusters, entities, DKG, and rules — assembled into one coherent picture you can carry around in your head.

Once these five concepts click together, the rest of the docs stop feeling like a pile of jargon and start feeling like a map. Read this once, slowly.

---

The five pieces

Each piece, with its one-line meaning:

Tiers

The three kinds of program that run: Validator, Host, Gateway.

Clusters

Genesis is 3 independent clusters, arranged for Byzantine fault tolerance.

Entities

Every account/token/app/agent is an “entity” with its own keys and rules.

DKG

How an entity’s keys are created: split across machines, and never assembled.

Rules

Public, mandatory policy on HCS, checked before every signature.

---

1. Tiers — the three programs

Smart Engines is three deployable applications, each a layer in the stack:

Smart Validator

The brain. It’s the only tier that knows about blockchains. It runs the DKG ceremonies, holds key shares, performs threshold signing, and talks to the chains.

Smart Host

The Backend-as-a-Service (BaaS) runtime. Auth, database, storage, functions, messaging. It delegates every chain operation down to validators.

Smart Gateway

The front door. Routing, DNS, load balancing, host verification. No chain code; it routes traffic to the right host.

🧠 For Normies

Think of a restaurant:

• Gateway = the host at the door who seats you.
• Host = the waiter who takes your order in plain language.
• Validator = the kitchen, where a quorum of chefs must agree before any dish (transaction) is made.

2. A decentralized, permissionless network

Smart Engines is designed to be decentralized, trustless, and permissionless. Membership is dynamic: nodes join and leave, and the network reshares its keys to match, with no single party ever in control.

To cold-start, genesis stands up an initial set of three independent clusters, the smallest configuration that gives Byzantine fault tolerance from day one. HSuite runs these genesis validators today. That’s the starting seed, not the shape of the network: after mainnet goes live and the bootstrap and genesis are secured, the network opens to node runners who stake HSUITE and run the software. “Three clusters” is how the network is born, not what it is.

🧠 For Normies

“Byzantine fault tolerance” is a fancy way of saying the system keeps working correctly even if some of its own parts lie, fail, or get hacked, as long as enough honest parts remain. Three is just the smallest number that gives that guarantee at birth; the network is built to grow far beyond it.

3. Entities — everything is an entity

A user, an app, an autonomous agent, a token, an account: each is an entity. Each entity runs its own DKG, so its keys are fresh and fixed for that entity — and visibly multisig on-chain. One compromised entity tells an attacker nothing about any other.

Each entity carries a security mode:

• partial — co-control: your key and the network’s threshold signature are both required.
• full — native multisig governed by the network’s threshold signature, no single controller.

4. DKG — how keys are born

When an entity is created, the validators run a Distributed Key Generation ceremony. Each validator ends up holding one share of the key, and the whole key never exists anywhere. Signing needs a threshold of validators: each signs with its own share, and only those partial signatures are combined into one valid signature (FROST threshold signing). The shares themselves never leave their validators.

🧠 For Normies

Imagine a vault that opens only when enough guards each turn their own key at the same time. No guard ever hands their key to anyone, and there is no master key anywhere, so stealing one key, or bribing one guard, opens nothing.

5. Rules — public and mandatory

Every entity is governed by rules published on Hedera Consensus Service. They’re public (anyone can read them), tamper-evident (HCS is an immutable log), and checked by the validators before they sign. A transaction that violates the rules doesn’t get signed.

---

The whole picture, one diagram

flowchart TB
    Client["Client<br/>SDK / app / agent"]

    subgraph Genesis["Validator network · BFT<br/>(genesis seed: 3 clusters, opens to node runners after mainnet)"]
        direction LR
        subgraph Tiers["Each cluster runs all 3 tiers"]
            G["Gateway<br/>routing / DNS"] --> H["Host<br/>BaaS runtime"] --> V["Validator<br/>keys + signing"]
        end
    end

    Client --> G

    V -- runs --> DKG["Per-entity DKG<br/>keys only as shares"]
    V -- threshold-signs --> Chains["Live: Hedera · XRPL<br/>next: Stellar · Polkadot ·<br/>Solana · Bitcoin"]
    V -- reads/enforces --> Rules["Public rules<br/>on Hedera HCS"]

    Chains -. native multisig<br/>(zero single-sig) .-> Entities["Entities<br/>partial | full"]
    DKG --> Entities
    Rules --> Entities

---

Put it in one sentence

Three tiers, running across a Byzantine-fault-tolerant validator network (genesis-seeded by three clusters), create per-entity keys via DKG that are never assembled, threshold-sign as native on-chain multisig on Hedera and XRPL (with more chains next), and obey public rules anchored on HCS.

That’s the platform. Everything else is detail.

---

Next steps

The Trustless CoreGo deeper on key custody.

ConceptsUnderstand entities and sovereignty.

Build Your First Smart AppSee it run end-to-end.

Choose Your PathNot sure where to go?