Smart Apps

What you’ll get here

the builder’s mental model for shipping an application on Smart Engines — what a Smart App actually is, how it gets deployed, how it’s gated and how its secrets stay safe — ending with an end-to-end tutorial you can follow.

You came to Smart Engines because you want to build something — a gated community app, an AI agent that moves real value. The reason most of that is hard elsewhere is that you’d have to assemble identity, key custody, multi-chain accounts, access control, and a runtime yourself, and get every one of them right. A Smart App hands you all of that as infrastructure. You write your code; the cluster gives it an identity, chain accounts, rule-bound policy, encrypted secrets, and a metered runtime.

🧠 For Normies

A “Smart App” is the thing you’re actually paying Smart Engines for. It’s your application, registered on the validator network, that gets its own cryptographic identity, its own chain accounts, its own database, its own quota — and runs on top of the multi-chain infrastructure. You deploy code; the cluster does the hard, dangerous parts.

---

The mental model

flowchart LR
    Dev["You<br/>(builder)"] -->|"1 mint (subscribe)"| Validator["Smart Validator<br/>(mints, governs, meters)"]
    Dev -->|2 deploy runtime| Host["Smart Host<br/>(runs your pod)"]
    Validator -->|app is ACTIVE from mint| Host
    Host -->|serves| Customer["Your customers"]
    Validator -. "binds" .-> Rules["On-chain rules<br/>(mandatory)"]
    Validator -. "owns shares of" .-> Entities["Per-chain entities<br/>(multisig wallets)"]

Three ideas carry the whole track:

A Smart App is infrastructure governed by rules — minted once, ACTIVE from mint

1 Smart App = 1 DKG entity = 1 subscription NFT; subscribing mints that identity and makes it ACTIVE, and a later hsuite deploy only attaches runtime (it allocates nothing). Mandatory on-chain rules decide what it’s allowed to do — you can’t deploy your way around them.

The cluster holds the keys, not you

Your app’s identity and its chain accounts are created by distributed key generation (DKG) and exist only as shares. A signature needs a threshold of validators, each signing with its own share, and the whole key is never assembled. Neither you nor any single validator can sign on the app’s behalf. An operation the rules deny is never signed.

You stay thin

Identity, rules enforcement, on-chain signing, secret custody, routing — all on the cluster. You ship a container that proposes actions.

---

Page index

What is a Smart AppThe precise definition, and how a Smart App (infrastructure) differs from a Smart Agent (actor). What you get for free.

Anatomy & lifecycleThe deploy manifest and the mint → deploy → run → retire lifecycle, with its state machine — plus listing your app on the marketplace (publish, listing and featured fees, bundles, trust score).

DeploymentHow your app lands on the host tier: trusted deploy, the runtime your container gets, and the app's platform token.

TokenGateThe double-faced access-control model — Face A (you → validator) and Face B (your customers → your app).

SecretsHow your env values are encrypted at intake and delivered to your container, and what never to do with a key.

Build your first Smart AppStart from the boilerplate: run it locally, connect it to the testnet with the hsuite CLI, then deploy and redeploy.

---

Next steps

GlossaryNew to the platform vocabulary? Skim the Glossary first.

Smart AgentsWant to know what the actor inside your app looks like? See Smart Agents.

Ready to build? Jump straight to:

Build your first Smart App