Network & Tiers

What you’ll get here

the three apps that make up a Smart Engines deployment — what each one is responsible for, what it deliberately can’t do, and how they talk to each other.

A Smart Engines deployment is not one program. It’s three cooperating applications, layered so that the dangerous part — the cryptography and the chain keys — lives in exactly one place and everything else delegates to it. This separation is a security decision, not just an organizational one. The three tiers are the permanent architecture of the network.

🧠 For Normies

Think of a restaurant. The gateway is the host at the door who sends you to the right table. The host is the waiter who takes your order in plain English. The validator is the kitchen — the only place with the knives and the chefs, and it refuses to start cooking until enough chefs have signed off on the order. You never walk into the kitchen yourself.

---

The three tiers

Tier	Signs or submits chain transactions?	Holds chain key material?
Validator	Yes — the only tier that does	Yes — its shares of DKG keys plus its own key for each chain; never enough to sign for an entity alone
Host	No — delegates to the validator	No
Gateway	No	No

🧠 For Normies

“Delegates to the validator” means the host and gateway can’t sign a blockchain transaction themselves. When they need a chain operation, they ask the validator over an internal API. So even if someone broke into a gateway, there are no chain keys there to steal.

Validator — the brain

The validator is the only tier that signs and submits chain transactions. It holds the chain adapters — Hedera and XRPL today — runs DKG ceremonies, participates in TSS signing, and stores its cryptographic shares encrypted at rest. Every chain operation — create an account, mint a token, sign a transaction — funnels through here.

Validators run in a cluster of N nodes. They coordinate ceremonies over an internal message bus and publish governance and rules to Hedera HCS for a tamper-evident audit trail.

🧠 For Normies

DKG = Distributed Key Generation: the keys are created already split across the validators, and only the pieces are ever stored. TSS = Threshold Signature Scheme: a quorum of validators each contribute a piece, and the pieces combine into one valid signature — without the full key ever being assembled. See DKG & TSS.

Host — the BaaS platform

The host turns validators into a usable Backend-as-a-Service. It provides wallet-based auth, a database layer with trustless Merkle proofs, IPFS-backed storage, sandboxed functions, and real-time messaging. If the validator is the low-level chain runtime, the host is the “Firebase for blockchain apps” built on top of it.

The host holds no chain keys and signs no chain transactions. It reads some public ledger state directly, such as a customer’s subscription NFTs on XRPL. Any chain operation that needs a signature — preparing or submitting a transaction — it requests from the validator.

Gateway — the front door

The gateway is a thin routing layer in front of the host/validator clusters. It terminates TLS, discovers hosts, and load-balances requests across healthy, verified hosts. Certificate automation for custom domains is built, not yet enabled.

Host discovery is gossip, and gossip is only a hint: before a host gets any traffic, the gateway sends it a challenge that the host must sign with its identity key, and it repeats that check every 24 hours.

🧠 For Normies

The gateway is a smart traffic cop. It figures out which host should answer your request and routes you there, but it never makes the decision about whether a transaction is valid — that’s the validator’s job.

---

The master architecture

%%{init: {'flowchart':{'htmlLabels':true,'curve':'basis'}}}%%
flowchart TD
    Client["Client<br/>SDK / dApp"]

    subgraph Cluster["One Smart Engines cluster"]
        Gateway["smart-gateway<br/>TLS · load-balancing<br/>host discovery"]
        Host["smart-host<br/>auth · database · storage<br/>functions · messaging"]
        Validator["smart-validator<br/>DKG · TSS · chain adapters<br/>governance · subscriptions"]

        subgraph Adapters["Chain adapters (validator only)"]
            CH["Hedera (live)"]
            CX["XRPL (live)"]
            CO["Solana · Polkadot · Stellar · Bitcoin<br/>(coming next)"]
        end

        subgraph Infra["Per-cluster infrastructure"]
            Bus{{"Message bus<br/>DKG · TSS · gossip"}}
            DB[("Database<br/>encrypted shares")]
            Cache[("Cache")]
            IPFS[("IPFS storage")]
        end
    end

    Client --> Gateway --> Host --> Validator
    Validator --> CH & CX
    Validator -.-> CO
    Validator -.-> Bus
    Validator -.-> DB
    Validator -.-> Cache
    Host -.-> IPFS
    Host -.-> DB
    Gateway -.-> Bus

    CH --> HN[("Hedera")]
    CX --> XN[("XRPL")]

🧠 For Normies

Solid arrows are the request path: client → gateway → host → validator → blockchain. Dotted arrows are the supporting infrastructure each tier leans on, and the chains that come next. Notice the chain adapters and the encrypted-share store hang off the validator only — that’s the whole point.

---

How the tiers talk

There are two distinct conversations happening.

North-south: the request path (HTTP)

A request flows down the tiers and a result flows back up.

%%{init: {'sequence':{'showSequenceNumbers':true}}}%%
sequenceDiagram
    participant C as Client
    participant G as Gateway
    participant H as Host
    participant V as Validator
    participant Chain as Blockchain
    C->>G: HTTPS request
    G->>G: resolve which host (load-balance)
    G->>H: route to healthy host
    H->>H: authenticate, check subscription
    H->>V: delegate chain operation
    V->>V: collect threshold signatures (TSS)
    V->>Chain: submit signed transaction
    Chain-->>V: receipt
    V-->>H: result
    H-->>G: response
    G-->>C: HTTPS response

East-west: the coordination mesh

Validators don’t sign alone — a quorum coordinates over the cluster’s internal message bus. The same bus carries DKG ceremony messages, TSS partial-signature collection, and the gossip that tells gateways which hosts exist. Gossip is not trusted: a gateway routes to a host only after the host has passed the gateway’s signed challenge.

🧠 For Normies

“North-south” is you talking to the system top-to-bottom. “East-west” is the machines inside the system talking sideways to each other to agree on signatures and to keep track of who’s online. The message bus is the internal channel that carries the sideways chatter.

The gateway’s job in detail

The gateway picks a host using one of several load-balancing strategies — round-robin, weighted, geographic, least-connections, random, or IP-hash. It learns about hosts from gossip rather than a static config, then verifies each one itself before routing to it.

---

Why this separation matters

The tier boundary is a blast-radius boundary:

Compromise a gateway

You get a traffic router with no chain keys and no signing authority.

Compromise a host

You get a BaaS frontend with no chain keys and no signing authority.

Compromise one validator

You get single shares, and one member key per chain — below the threshold, so useless on their own (see DKG & TSS).

There is no single machine anywhere in the stack that, if breached, lets an attacker forge a signature.

🧠 For Normies

“Blast radius” = how much damage one break-in can do. Smart Engines is built so that breaking into any one box gives you almost nothing useful. You’d have to break into a quorum of an entity’s validators at once — which is what threshold cryptography is designed to make impractical.

---

Next steps

DKG & TSSSee how the cryptography makes “one share is useless” true.

Three-Cluster GenesisSee how the testnet bootstrapped from three of these clusters.

Entities & SovereigntySee what a client actually creates through this stack.

Decentralization ModelThe full trust model in one place.

GlossaryTerm definitions.