Skip to content
HSuite Docs

Glossary — every "For Normies" term in one place

This is a flat reference of every term explained with a “For Normies” box across the walkthrough. If you’re reading a chapter and lose the thread on a term, this is the page to keep open in another tab.

Terms are grouped by topic, not alphabetized, because related concepts make more sense together.

Sections in this glossary

Section titled “Sections in this glossary”

Core concepts

Section titled “Core concepts”

Smart Engines — A shared brain that knows how to talk to many different blockchains at once, run by a small cluster of computers (validators) that have to agree with each other before anything happens.

Validator — A computer in the Smart Engines network. Holds a share of each signing key and takes part in threshold signing. Several validators must cooperate to sign anything.

Smart Host — A “Firebase for blockchain apps” built on top of the validator. Provides auth, database, functions, and messaging to app developers.

Smart Gateway — The front-door router that decides which host to talk to. Handles custom domains, dynamic CORS, and gossip-based host discovery.

Tier — The three layers of the system: validator (chain runtime), host (BaaS), gateway (routing).

Sovereignty & security modes

Section titled “Sovereignty & security modes”

Sovereignty mode — How much control the validator cluster has over an entity’s keys:

  • none: validator has full control. Most convenient.
  • partial: validator and customer co-sign. Customer has a veto.
  • full: customer signs alone. Validator only prepares.

Token capabilities — Chain-agnostic features a token can have: mintable, burnable, pausable, freezable, wipeable, kycRequired, metadataMutable. Each adapter translates these to chain-native mechanisms.

Immutable token — A token with no admin key, so its configuration can never change. The most sovereign possible state.

Cryptography

Section titled “Cryptography”

Threshold cryptography — A family of techniques where a secret (a key) is split across many parties such that a threshold of them can use it together — but no individual party ever holds the whole thing.

DKG (Distributed Key Generation) — A protocol where multiple parties collaboratively generate a shared key without any single party ever knowing the full key.

TSS (Threshold Signature Scheme) — A protocol for producing signatures using a threshold of key-share holders, without reconstructing the full key.

Shamir Secret Sharing — The bottom-layer math: split a secret into n shares such that any t could reconstruct it but fewer than t are useless. Based on polynomials over a finite field. Smart Engines never reconstructs an on-chain signing key: signing combines signature shares instead (see FROST).

Lagrange interpolation — The math that recovers a polynomial’s value from a threshold of its points. In threshold signing it weights each validator’s signature share, so the shares combine into one signature without the key itself being rebuilt.

Feldman VSS (Verifiable Secret Sharing) — Shamir + public commitments so each participant can verify their share is consistent with the others, without trusting the dealer.

BLS12-381 — An elliptic curve well-suited for aggregatable signatures. Used for cluster-internal claims (System A DKG). It never signs on chain.

ed25519 — A widely supported elliptic curve used for on-chain keys by Hedera and XRPL (both live), and by Solana and Stellar (coming next). Used for the per-entity, per-slot DKG (System B). Polkadot uses the related sr25519 scheme.

secp256k1 — The curve used by Bitcoin and Ethereum. Bitcoin support is coming next; Ethereum is postponed.

FROST (Flexible Round-Optimized Schnorr Threshold) — A protocol for producing threshold Schnorr signatures without ever reconstructing the secret key. Two-round protocol: nonce commitments, then signature shares. Smart Engines signs on chain with FROST over ed25519 (RFC 9591).

Schnorr signature — A signature algorithm that’s a foundation for many threshold schemes. ed25519 is a Schnorr variant.

Chain-native multisig — When a blockchain itself understands “N-of-M signers”, we let the chain do the math. Hedera (KeyList) and XRPL (SignerList) are live; Polkadot (pallet_multisig) and Stellar (weighted signers) are coming next.

PBFT threshold — ⌊2n/3⌋ + 1. The classic Byzantine-fault-tolerant quorum. On Smart Engines it is the default signing threshold when an entity’s creator names none; any threshold from a strict majority of the committee up to n is accepted.

Byzantine fault — A failure where a participant can behave arbitrarily — including maliciously, including lying — rather than just crashing. Threshold cryptography is designed to be Byzantine-fault-tolerant.

KEK (Key Encryption Key) — A “key for keys”: a key used only to encrypt other keys and secrets. Smart Engines seals key shares and internal secrets under a KEK hierarchy, and secrets are mounted at runtime, never baked into images.

Per-entity isolation — The property that two entities with the same validator set have completely independent key material. Smart Engines achieves this by running fresh DKGs per entity per slot.

Operational concepts

Section titled “Operational concepts”

OpenTelemetry (OTel) — A standard for distributed tracing, metrics, and logs. Smart Engines emits OTel traces so you can follow a request through the system.

Trace ID — A unique ID assigned to each incoming request. Every log line and span related to that request carries the same trace ID.

CORS — Cross-Origin Resource Sharing. Browser policy controlling which websites can call this API from JavaScript. Different per tier.

JWT (JSON Web Token) — A self-contained, signed token used to represent a user session. No server-side session store needed.

Partition tolerance — A system’s ability to keep working when parts of it are unreachable. Smart Engines is partition-tolerant: one chain going down doesn’t take the whole system down.

Storage and messaging

Section titled “Storage and messaging”

IPFS (InterPlanetary File System) — A content-addressed, peer-to-peer storage network. Smart Host stores large value blobs in IPFS and references them by CID.

CID (Content Identifier) — IPFS’s hash-based address for content. Same content always gets the same CID, which means natural deduplication and verifiable retrieval.

HCS (Hedera Consensus Service) — Hedera’s ordered, tamper-evident message log. Smart Engines uses HCS topics for governance rules, audit events, and validator discovery. Hedera’s role on the platform is HCS only.

Mirror node — A read-only replica of a blockchain network. Smart Engines uses Hedera’s mirror node API for read operations (queries) that don’t need consensus.

Smart Host concepts

Section titled “Smart Host concepts”

BaaS (Backend-as-a-Service) — A hosted backend that handles auth, storage, functions, and messaging for application developers. Firebase is the canonical example. Smart Host is the BaaS tier of Smart Engines.

CRDT (Conflict-free Replicated Data Type) — A data structure designed so that concurrent updates from different replicas always converge to the same state, without coordination. Powers the host’s database.

Op-log — An append-only log of operations. To read state, you replay the log. Easier to replicate and verify than a mutable store.

Merkle proof — A cryptographic proof linking a single value to a root hash via a tree of hashes. Lets you prove “this value was in this dataset” without needing the whole dataset.

Merkle root — The top hash of a Merkle tree. A short string that uniquely identifies the entire state at a point in time. The host can anchor its database’s roots to HCS; that anchoring is optional and off by default.

Sandbox — An isolated runtime environment with strict resource limits and no general internet access. Smart Host functions run in sandboxes.

Pub/sub — Publish/subscribe messaging: a publisher sends a message to a topic; all subscribers receive it. Powers real-time features.

SDK and licensing

Section titled “SDK and licensing”

SDK (Software Development Kit) — A client library customers integrate into their apps to talk to Smart Engines. @hsuite/smart-engines-sdk is the TypeScript SDK.

Idempotency key — A unique header on a write request. If the same key is seen twice, the second request is a no-op. Prevents double-charging on retries.

HCS-based validator discovery — Instead of hardcoding validator URLs, the SDK reads a public on-chain topic for the current list. Validators can be added/removed without clients updating config.

NFT token-gating — Access controlled by ownership of a specific NFT on a chain. Burn or transfer the NFT → access revoked. On Smart Engines, an app’s XRPL subscription NFT decides a customer’s tier at login (see Token Gating).

Chain-specific concepts (Chapter 05)

Section titled “Chain-specific concepts (Chapter 05)”

Chain status — Live: Hedera and XRPL. Coming next: Stellar, Polkadot, Solana and Bitcoin. Postponed: Ethereum and Polygon (EVM). See Chains.

EIP-1559 — Ethereum’s two-part fee market: a base fee (burned) plus a priority tip (to the validator). Replaced the old “highest bidder wins” model.

UTXO (Unspent Transaction Output) — Bitcoin’s model where coins are individual “banknotes” rather than a balance. A transaction spends specific UTXOs and produces new ones.

PSBT (Partially Signed Bitcoin Transaction) — A standard envelope format that lets multiple Bitcoin signers each add their signature without seeing the others’.

P2SH / P2WSH — Bitcoin’s address types for native multisig (legacy and SegWit).

Taproot — A Bitcoin upgrade that added Schnorr signatures, making threshold Schnorr signing such as FROST possible natively on Bitcoin.

SPL Token — Solana’s canonical token program. Tokens are accounts managed by SPL.

ATA (Associated Token Account) — Solana’s per-holder token balance account.

Metaplex — Solana’s NFT standard layer.

Weighted signers — Stellar’s native multisig: signers have weights summing to a threshold.

SignerList — XRPL’s native multisig with a SignerQuorum.

pallet_multisig — Polkadot’s runtime-level multisig mechanism.

Gnosis Safe — An EVM smart contract suite that implements multisig on chain.

Cluster lifecycle (Chapter 07)

Section titled “Cluster lifecycle (Chapter 07)”

Genesis — The cluster’s “first boot” — when its keys are DKG’d, governance rules are published, and the cluster is ready to serve.

Chain-key bootstrap — Producing the cluster’s own per-chain operator keys via DKG so the cluster can sign for itself.

Share bundle — The encrypted set of cryptographic shares sent to a newly joining validator so it can participate in future ceremonies.

Resharing — Redistributing every key’s shares when a validator joins or leaves. The public keys and on-chain accounts stay the same, and the new member gets a share. Old shares do not stop working by themselves: enough old holders together could still sign, so a leaving member’s old shares have to be deleted.

Snapshot (cluster) — A periodic photograph of the cluster’s entity registry, membership, HCS sequence numbers, and pending ceremonies. Used for fast restart, DAO voting baselines, and audit material.

Networking (Chapter 08)

Section titled “Networking (Chapter 08)”

Gossip — Peer-to-peer broadcast of liveness and configuration inside a cluster. Hosts announce themselves, send heartbeats and announce departure; gateways build a live host map from it.

NOSTR — A decentralized event-relay protocol. Smart Engines uses it for public, censorship-resistant cluster discovery.

Relay pool — A NOSTR client construct: connect to many relays in parallel, dedupe events, rotate dead relays.

Cluster manifest — A signed, publicly-published document declaring a cluster’s identity, endpoints, and governance topic.

Trust root — The on-chain anchor (HCS topic) against which all other discovery mechanisms are cross-verified.

Gateway (Chapter 09)

Section titled “Gateway (Chapter 09)”

Authoritative DNS — A DNS server that owns the answers for specific zones (as opposed to a recursive resolver that asks other servers).

DNSSEC — Cryptographically signed DNS responses, verified through a chain of trust back to the DNS root.

KSK / ZSK — DNSSEC’s two keys: Key Signing Key (long-lived, signs the ZSK) and Zone Signing Key (rotated more often, signs records).

DS record — A DNSSEC record published in the parent zone that points to a child zone’s KSK, completing the chain of trust.

Dynamic CORS — CORS allow-list built per request based on the matched domain mapping.

Trustless Core (Chapter 10)

Section titled “Trustless Core (Chapter 10)”

Merkle tree — A binary hash tree producing a single root hash that summarizes a list of values. Inclusion proofs are log₂(n) in size.

Domain separation — Different hash prefixes for leaf and internal nodes, preventing a class of forgery attacks.

State transition — A signed record linking an old state root to a new one via an operation.

State anchoring — Publishing the current Merkle root to chain on a schedule so tampering becomes externally detectable. For the host database this is optional and off by default.

Host attestation — A signed challenge/response proving a host’s identity, code, and state freshness.

Code attestation — Proving the running code matches an approved fingerprint. Hardware-backed (TEE) attestation is planned.

TEE (Trusted Execution Environment) — Hardware-backed isolated execution (Intel SGX, AMD SEV, AWS Nitro Enclaves) that can produce signed attestations of running code.

Canary test — A continuously-running probe transaction designed to fail in specific ways if any system invariant is broken. Detects silent regressions.

Rules Engine (Chapters 11, 12)

Section titled “Rules Engine (Chapters 11, 12)”

Atom / Molecule / Organism — Three-tier composition pattern. Atoms are single checks; molecules combine atoms into features; organisms combine molecules into complete products. Each check answers allow, or deny with a reason.

Rule registry — The mapping from rule type names to concrete atom/molecule/ organism implementations, used to deserialize stored rules.

Hot reload — Refreshing in-memory rules when a new version is published to HCS, without restarting the validator.

Fluent builder — An API style where each method returns this, letting you chain configuration calls in any order.

Template — A ready-made rule set for a common use case (e.g. a DAO-governed token or a fair-launch token).

Genesis rules — The foundational rule set the cluster publishes about itself at genesis.

Smart Apps and Agents (Chapters 14, 15)

Section titled “Smart Apps and Agents (Chapters 14, 15)”

Smart App — A registered customer application with its own BLS identity, per-chain entities, rule binding and subscription.

App config CID — The IPFS content identifier of an app’s immutable configuration.

Runtime init — The flow where a deployed app calls home to fetch its config and rules at boot time, proving control via signature.

Smart App state machine — pending → deploying → active, then suspended or deleted.

Smart Agent — An autonomous actor with its own cryptographic identity, multi-chain wallets, and rule-bound action authority.

Agent state machine — pending, active, paused, stopped, awaiting_approval and revoked.

Pure delegation wallet — Sovereignty pattern where the cluster signs entirely for the agent.

Multisig agent wallet — Sovereignty pattern where the agent and cluster co-sign.

Agent-controlled wallet — Sovereignty pattern where the agent signs alone, cluster only audits.

Bridge, Settlement, Migration (Chapters 16, 17)

Section titled “Bridge, Settlement, Migration (Chapters 16, 17)”

Universal Token Bridge — One bridge engine for every chain pair, with per-chain adapters doing the chain-specific work. Today it covers Hedera and XRPL only, and it is switched on for no deployed network.

Port / Return — Move tokens forward / move them back. Bidirectional bridges support both.

Claim record — One cluster’s database record of a port/return. Across clusters, the claim’s registration on the public HCS claim registry decides which mint is valid: the earliest valid registration wins.

Trust level — owner-rekeyed | owner-verified | community — how token ownership was established when the bridge was created. Recorded; no limit reads it.

Lock-and-wrap — Bridge strategy for foreign tokens: lock the original in a wallet the validators hold, mint a wrapped version on the destination. Built for Hedera HTS → XRPL; every activation is refused until its unlock leg lands.

Burn-and-mint — Bridge strategy for cluster-controlled tokens: remove on the source, then mint on the destination. The HSUITE → HST bridge works this way, one-way.

Supply invariant — For the HSUITE bridge: HST minted on XRPL equals HSUITE removed on Hedera. A reconciler checks it and alerts on a violation; it does not pause anything.

Settlement — The pattern where an on-chain payment on chain A triggers a cluster action on chain B (mint receipt, payout, webhook).

Settlement obligation — The seller-declared expectation of an incoming payment, with attached action.

Token migration — Rotating an existing token’s admin/supply/etc. keys to TSS-managed ones, in place. Token ID unchanged.

Old admin key handling — The one-time use of the existing admin key during migration. In-memory only, wiped after use, canary-verified deactivated.

DAO Governance (Chapter 18)

Section titled “DAO Governance (Chapter 18)”

Proposal — A typed request for a cluster-authorized action: treasury-disburse, rule-update, admit-validator, parameter-change, etc.

Proposal state machine — pending or awaiting_signature, then active, then passed or failed, and finally executed, cancelled, expired or vetoed.

Snapshot weighting — Vote power is derived from a snapshot of holdings at proposal submission time. Prevents late vote-buying.

Quorum — Minimum participation (total voting weight) for a vote to count.

Approval threshold — Minimum yes / (yes + no) percentage for a passed proposal.

Membership model — How vote weight is computed: token-weighted, one-member-one-vote, or tier-weighted.

Free-form proposal — Advisory-only proposal type that records a sentiment but doesn’t trigger automatic action.

Prepare endpoints — DAO endpoints that return unsigned transactions for full sovereignty DAOs to sign themselves.

Pricing & Subscriptions (Chapter 19)

Section titled “Pricing & Subscriptions (Chapter 19)”

Credit — Abstract unit of pricing. Operations cost credits; subscriptions provide monthly + burst credits.

Subscription tier — builder | growth | scale | enterprise. Each tier has credits, rate limits, and feature flags. A customer with no subscription NFT for an app is on the free tier.

Subscription NFT — An NFT on XRPL that records a paid subscription. It is minted non-transferable, and only its issuer can burn it.

Accepted asset — A token listed in the pricing registry, with a price-oracle binding. Listing does not make it payable: subscriptions are paid in HSUITE on XRPL today, and other assets are planned (see Settlement & migration).

Rate sanity band — The HSUITE/USD rate has one source, HSUITE’s own market on the XRPL native DEX: a time-weighted AMM reading, else the order-book mid, else a configured fallback. A reading outside the sanity band is rejected and the next source is used rather than a guess. CoinGecko is no longer used (see Value flows).

Fee distribution — How collected fees are split: validators, hosts, gateways, DAO treasury, burn. DAO-tunable.

Operator-funding acknowledgement — Required step where operators confirm receipt of their share. Unclaimed shares are eventually redirected by DAO vote.

CLI (Chapter 22)

Section titled “CLI (Chapter 22)”

hsuite init — Generates an XRPL testnet wallet, funds it from the faucet, and writes .env.local.

hsuite subscribe — Registers a paid smart-app subscription on the cluster (lowest tier is builder).

hsuite deploy — Pushes a JSON manifest to the cluster for provisioning.

Manifest — The JSON file describing what to deploy: image, replicas, env, rules, ingress.

Service registry (Chapter 08 update)

Section titled “Service registry (Chapter 08 update)”

Service registry — A distributed catalog of { clusterId → endpoints } records, published by each validator as signed events and replicated across the cluster. Replaces operator-maintained endpoint lists and the implicit “ops team maintains DNS” workflow.

ClusterDiscoveryClient — SDK client that bootstraps from any known validator URL, fetches /api/v3/discovery/clusters, optionally cross-checks against the HCS validator-registry topic, and returns a random healthy cluster.

Decentralised DNS — Shorthand for the new state of affairs: there is no longer a single namespace (a DNS zone, a hosts file, a configuration file) that an attacker or operator can edit to redirect traffic. The authoritative answer to “who is in the network and where do I reach them” is a signed, replicated, on-chain-anchored data structure.

Harbor & content-addressed images (Chapter 23)

Section titled “Harbor & content-addressed images (Chapter 23)”

Harbor — An open-source container registry. Each Smart Engines cluster runs one to store customer smart-app images, one project per app.

Content addressing — Referring to a container image by the SHA-256 of its contents (@sha256:abc…) rather than by a mutable tag (:latest). Makes the registry’s tag-write capability irrelevant to runtime trust.

Anchor pubkey — The on-chain-registered BLS group public key used as the trust root for verifying signed events. Subscribers verify against this, not against the announcing node’s claimed pubkey.

Runtime arc (Chapter 14 update)

Section titled “Runtime arc (Chapter 14 update)”

APP_TOKEN — A JWT-shaped token (payload + signature) given to a smart-app’s backend at deploy time. It is signed by the validator quorum with threshold BLS, and is meant to be verified by the host against the app’s registered public key; that host check is built, not yet enabled. There is no shared symmetric secret, so no single operator can mint one.

Lifecycle effects (suspend/resume/update/rollback/delete) — The state-machine transitions of a deployed smart-app, each mapped to a real side-effect on the running deployment (scale, routing change, manifest reapply, removal).

New rules atoms (Chapter 11 update)

Section titled “New rules atoms (Chapter 11 update)”

Soulbound rule — A rule atom that denies a transfer under a token rule whose soulbound.enforced is true. It binds only the transfers decided under that token entity’s own rule; another holder’s transfer moves under that holder’s rule, or under none outside the platform. Mints, burns and wipes are decided by the rule’s own operations.

Soulbound NFT — A token meant to stay with its holder, typically representing identity, credentials, status, or membership. On this platform a token rule’s soulbound binds only the transfers decided under that rule (see the soulbound rule above); keeping a holder from transferring the token takes a ledger-level control, such as an XRPL NFT minted without tfTransferable.

Historical-balance rule — A rule atom that checks an account’s balance of a token at a past timestamp against a threshold. Used for flash-loan-resistant eligibility checks (voting, airdrops, gated mints).

Flash-loan attack — An attack where a voter briefly borrows tokens to qualify for a snapshot-less governance check, votes, and immediately returns them. Prevented by historical-balance and snapshot-based eligibility.

Governance extensions (Chapter 18 update)

Section titled “Governance extensions (Chapter 18 update)”

Wisdom-weight — Optional multiplier on a voter’s base weight, computed by a custom function the DAO registers. Encodes reputation, expertise, contribution scoring, or any DAO-defined signal.

Multi-hop delegation — Voting-power flow through a delegation graph, up to maxHops levels deep, with retention (1 - decayPerHop)^hops at each step. Prevents “delegation kings” via decay.

concentrationAlert — Optional threshold that triggers a warning when a voter’s effective weight (after delegation) exceeds a given fraction of total. Diagnostic, not enforcing.

Governance simulate — Public POST /api/v3/governance/simulate endpoint that re-runs a governance rule set against a provided context, returning the same result shape production would. Stateless, no persistence. Useful for proposal previews and CI checks.

Personhood (Chapter 24)

Section titled “Personhood (Chapter 24)”

Personhood — The property of being a unique human, orthogonal to wallet control. Closes the Sybil-attack gap that wallet signatures alone cannot.

Sybil attack — One actor spinning up many wallets to inflate their influence in a “one wallet = one vote” system.

Personhood verifier — A pluggable check that a wallet belongs to a unique human. Smart Engines ships a Web-of-Trust reference implementation; customers can plug in biometric, KYC, BrightID, or any other method behind the same contract.

Personhood certificate — The signed certificate returned by a successful verification. Carries the address, attestation method, issuer, issue and expiry times, a signature, and optional metadata. Portable — any relying party can verify it against the issuer’s public key.

Web of Trust (WoT) — The default personhood method: k allow-listed voucher addresses sign attestations within a time window. The verifier counts unique valid vouches and issues a certificate when the threshold is met. The voucher allow-list, the required number of vouches and the window are configurable.

HPP (Hedera Personhood Protocol) — A planned smart-app that builds on the personhood subsystem: a public directory of certificates, default WoT issuance, queryable by relying parties.

Where to learn more

Section titled “Where to learn more”
Walkthrough — Table of Contents
Architecture Overview
Security Overview
Protocols (TSS/DKG)
Chain Integrations