The HSUITE Token

What you’ll get here

what HSUITE actually is, where it lives, what it’s used for, and the story of why it moved from Hedera to the XRP Ledger as its single canonical home.

HSUITE is the economic token of the Smart Engines network. It is the unit fees settle into, the asset node runners stake, and the weight behind DAO votes. Crucially, it lives on one chain — the XRP Ledger — even though the platform itself works with several.

🧠 For Normies

A “canonical” chain is the one true home for the token. The token is only ever issued and burned in one place. That keeps the accounting simple and the supply honest.

---

Token identity

HSUITE is issued as an XRPL-native asset (an “issued token”, in XRPL terms a trust-line currency).

Property	Value
Name	HSUITE (currency code HST on XRPL)
Ledger	XRP Ledger — canonical, sole issuance chain
Issuer	XRPL account controlled by a native multisig of validators (no single key)
Holding model	Trust lines — recipients opt in; no spam tokens
Transfer fee	0.25% on every transfer between holders, burned by the ledger itself
Issuer controls	None over holders: nobody, the DAO included, can freeze or claw back HSUITE. The issuer mints only through the bridge, which is built but not yet enabled.

HSUITE is not minted on any other chain. Built, not yet enabled Paying in other assets, which would settle into real HSUITE on XRPL, is built but not yet enabled (see Settlement & migration).

🧠 For Normies

A “trust line” is XRPL’s way of saying “I agree to hold this token.” You have to opt in before HSUITE can land in your wallet — which means nobody can spam you with junk tokens. And because the issuer can neither freeze nor claw back a line, nobody can lock or take the HSUITE you hold: not the protocol, not the DAO.

The 0.25% transfer fee is XRPL’s native TransferRate setting on the issuer. The ledger takes it out of every transfer between two holders and it simply ceases to exist, so it reduces supply; no account collects it. Payments to or from the issuer itself are not charged.

TSS-controlled issuer (no single key)

The issuer account is not controlled by one private key. Its own master key is disabled, and it is governed by XRPL native multisig: a transaction is only valid when a threshold of validators co-sign it. Each validator’s signing key for that account is created by a distributed key generation (DKG) ceremony and exists only as shares. To sign, a threshold of validators each produce a signature share from their own key share (two-round FROST), and the shares are aggregated into one signature; the whole key is never assembled, at rest or while signing. There is no admin who can unilaterally mint or burn.

🧠 For Normies

The “key” to the token is split across many validators, and a minimum number of them must agree before anything happens. No single party — not even the founding team — can mint HSUITE alone.

---

What HSUITE is used for

Utility	How it works
Settlement unit	All metered usage is paid and settled in real HSUITE on XRPL. Paying in other assets is built but not yet enabled. See Value flows.
Deflationary burn	40% of every settled subscription payment is burned, permanently reducing supply.
Node-runner rewards	40% of settled subscription payments goes to the runner pool in real HSUITE, for validators, hosts, and gateways; paying the pool out to node runners is built but not switched on yet. See Staking & node-runners.
Staking deposits	Node runners post HSUITE deposits into validator-multisig deposit accounts on XRPL.
Governance weight	HSUITE balances are the voting weight in the protocol DAO. See DAO governance.
Subscription payment	Subscriptions are priced in USD and paid in HSUITE on XRPL. XRP and other assets are built but not yet enabled. See Subscriptions & Memberships.

---

The Hedera → XRPL canonical pivot

HSUITE did not start on XRPL. It launched as an HTS (Hedera Token Service) token. The decision to make XRPL canonical — and keep Hedera for governance messaging only — is implemented in the platform’s genesis.

The layer separation that resulted

flowchart LR
    subgraph Value["XRPL — VALUE layer"]
        T["HSUITE token<br/>issue · burn · payments"]
    end
    subgraph Gov["Hedera — GOVERNANCE layer"]
        H["HCS topics<br/>rules · validator registry · proposals"]
    end
    subgraph Compute["Chain adapters — EXECUTION layer"]
        A["Threshold signing on each supported chain<br/>(Hedera and XRPL live, more coming next)"]
    end
    A -->|fees settle to| T
    H -.->|rules govern| T
    H -.->|rules govern| A

Each layer does what it is best at. XRPL holds the money, Hedera carries the ordered governance messages, and the chain adapters carry out signed work on each supported chain.

🧠 For Normies

The team realized one chain shouldn’t try to be everything. XRPL has very cheap transactions, so it became the “money” chain. Hedera’s consensus service is excellent for ordered, tamper-proof messages, so it stayed the “governance” chain. Hedera no longer carries the token — only the rules.

Why XRPL for value

The decisive reasons:

Cheap atomic burns

A burn is one XRPL payment back to the issuer, atomic and paid for with a small XRP network fee.

Open validator set

XRPL’s consensus runs on an open set of validators.

Why Hedera stays (HCS only)

After the pivot, Hedera remains in genesis for HCS consensus messaging only — the validator registry, rules storage, and governance proposals. The HSUITE token and all subscription/membership NFTs are XRPL. Hedera is not being removed; its role is narrowed to what its consensus service does best.

🧠 For Normies

“We’re not leaving Hedera — we’re letting each chain do what it’s best at.” Hedera keeps the public rulebook (HCS); XRPL keeps the wallet.

Migrating existing holders

Holders who still have HSUITE on Hedera will move to XRPL through a one-way, 1:1, supply-neutral bridge. The bridge is built but not yet enabled. The mechanism — and why the migration itself is risk-free for individual holders — is covered in Settlement & migration.

---

Supply and deflation

Total supply is computable from a single source:

Total Supply = sum of all holders' trust-line balances
             = the issuer's outstanding obligations (XRPL gateway_balances)

The circulating supply starts at zero. Genesis, as built today, mints no HSUITE on any network (mainnet included): it creates the HSUITE issuer and the protocol treasury’s trust line, and the issuer’s outstanding obligations are 0 when it finishes.

HSUITE (currency code HST) is minted only by the migration bridge, one-for-one against HSUITE removed on Hedera, and only after that removal (burn-first). No person, DAO vote or validator quorum can authorise a mint: each validator releases its share of the signature only after its own reads confirm the removal. Mints are capped at 1 billion per transaction, 2 billion per day and 50 billion in total.

The protocol treasury is funded the same way as any holder. See Settlement & migration. The bridge is built but not yet enabled, so it has minted no HST.

Every mint, burn, and transfer is on XRPL. There are no phantom balances and no cross-chain reconciliation.

The deflation mechanism is the 40% burn applied to every settled subscription payment (see Value flows), plus the 0.25% transfer fee. On XRPL a burn is executed by sending the HSUITE back to its own issuer: a self-issued IOU returned to the issuer simply ceases to exist, so the issuer’s on-chain obligations (the outstanding supply) fall by exactly that amount. The HSUITE issuer cannot claw tokens back: clawback is disabled on it by design.

🧠 For Normies

Because the token only exists on one chain, “how much HSUITE is there?” is a single query. And because 40% of every settled payment is destroyed, the total tends to shrink as the platform is used more.

---

Next steps

Value flowsSee the money move.

Staking & node-runnersHow node runners earn and stake.

XRPL chain pageXRPL specifics for builders.