What is a Smart App?

What you’ll get here

a precise definition of a Smart App, the line between a Smart App and a Smart Agent, and the list of things you get for free the moment you mint one.

You’re about to mint an app and (later) deploy code into it. Before you do, it’s worth being exact about what you’re deploying into, because the guarantees you inherit depend on it.

---

The definition

A Smart App is an application — infrastructure — that is governed by mandatory on-chain rules and hostable on the Smart Host tier of a Smart Engines cluster. Crucially: 1 Smart App = 1 DKG entity = 1 subscription NFT, and the app is ACTIVE from the moment that NFT is minted — long before any code is deployed.

Concretely, minting a Smart App (by subscribing) gives it:

A cryptographic identity

Keys generated by a per-app DKG ceremony at mint and stored only as validator shares. No single validator can sign on the app’s behalf. The resulting entityId is the app’s id and its subscription id — one and the same.

An on-chain multisig account

A native multisig account on the chain you sign up with (XRPL when you use the CLI), held by the validators’ key shares and governed by your app’s rules. Your app can create more entities (accounts, tokens, topics) through the SDK.

A bound rule set

Subsequent operations on the app’s entities flow through the rules engine. The rules are mandatory and published on-chain.

An immutable, content-addressed config

Pinned to IPFS by the cluster. The returned CID is a content hash, so the config can be checked against it without trusting a database.

One deposit-backed subscription NFT

The proof of payment that flips the app to ACTIVE.

A metered runtime on the host tier is then attached later, by a separate hsuite deploy step. The app is fully ACTIVE with or without it.

🧠 For Normies

A Smart App is a registered identity (a public key) tied together by one app ID that’s also its DKG entity and its NFT: who owns it, what config it runs, what chain accounts it controls, what rules govern it. You mint it once, and it’s alive immediately. Running actual code on it is a second, optional step you do whenever you’re ready — it doesn’t mint anything new.

---

Smart App vs Smart Agent

People conflate these constantly. The distinction is infrastructure vs actor.

	Smart App	Smart Agent
Is a…	deployed application (infrastructure)	rule-bound autonomous actor with its own wallet
You get one when you…	subscribe (mint its DKG entity + NFT)	create one with the SDK’s two-phase agent create (see Deploy your first agent)
Holds	per-chain entities, a config, a runtime	a per-entity-DKG multisig wallet governed by AgentValidatorRules
Runs	your container(s) on the host tier	its declared capabilities, fired by its own schedule or event triggers
Authority	hosts the actors and serves traffic	acts only within its rules; a threshold of validators signs for it

The Smart App is the deployed thing; the Smart Agent is a rule-bound wallet the app creates and owns. The app funds the agent, sets its rules and approves what it parks for approval. The agent acts through its declared capabilities, on its own triggers, and every action passes the validators’ fail-closed rule check before any signature is produced.

flowchart TB
    subgraph App["Smart App (infrastructure)"]
      Code["Your backend"]
    end
    Code -->|creates, funds, sets rules| Agent["Smart Agent<br/>(DKG multisig wallet)"]
    Trigger["Agent trigger<br/>(schedule or event)"] -->|runs a capability| Agent
    Agent -->|all rules pass?| Gate["Validator rule check<br/>(fail-closed)"]
    Gate -->|yes → a threshold of validators signs| Signed["Signed transaction"]
    Gate -->|no| Deny["Denied — no signature"]

See Smart Agents for the actor side in depth.

---

What you get for free

The reason to build on Smart Engines rather than rolling your own:

Multisig you didn't have to design

Every entity your app owns is a native multisig (an XRPL SignerList, a Hedera KeyList) backed by distributed shares. Nothing moves without a threshold of validators signing.

Rule enforcement you can't bypass

Rules are bound at registration and evaluated on the validator before any signature is produced. Even your own compromised code can’t push an out-of-policy operation through.

Per-app key isolation

Because each app gets its own DKG ceremony (not a child key of some master), compromising one app’s shares reveals nothing about any other app.

Encrypted secrets by default

Each env value is sealed with a post-quantum hybrid envelope (ML-KEM-768 + AES-256-GCM) the moment the platform receives it (see Secrets).

Routing handled

An edge proxy runs beside your container, and the platform gateway routes your app’s traffic to it (see Deployment).

A marketplace to be found in

Once ACTIVE, you can optionally publish the app to the public marketplace — discovery, a trust score, featured placement, and a subscription offer wallets can act on (see Listing your app on the marketplace).

🧠 For Normies

The expensive, dangerous parts of any on-chain product — custody, multisig, access control, secret handling — are the cluster’s job. You write business logic. If your code gets hacked, it still can’t get an operation signed that your rules deny.

---

Lifecycle preview

A Smart App moves through a small set of states — and it’s ACTIVE from mint, not from deploy:

stateDiagram-v2
    [*] --> PENDING_SUBSCRIPTION : subscribe (DKG + deposit pending)
    PENDING_SUBSCRIPTION --> ACTIVE : deposit confirmed then NFT minted
    ACTIVE --> SUSPENDED : suspend / expire
    SUSPENDED --> ACTIVE : resume / renew
    ACTIVE --> RETIRED : retire
    RETIRED --> [*]

That’s the lifecycle axis (allowed to run?). Whether your container is actually up is a separate runtime axis (NOT_DEPLOYED → DEPLOYING → RUNNING, or FAILED / DEGRADED), driven by hsuite deploy. The next page covers the deploy manifest and walks both axes.

---

Next steps

Anatomy & lifecycleThe deploy manifest and what happens at each state.

TokenGateHow access is gated, both faces.

GlossaryDKG, BLS, entity, rule molecule defined.