Tokenomics

Overview

The HSUITE token powers the Smart Engines ecosystem through an XRPL-canonical economic model. XRPL serves as the single value layer for token issuance, burns, payments and settlement, while Hedera provides governance messaging via HCS and the chain adapters carry out signed work on each supported chain.

This architecture was adopted in revision 3 (April 2026), replacing the earlier model that minted HSUITE natively on all supported chains.

⚠️ Risk warning

HSUITE is a utility token — it grants access to network services and confers no profit, dividend, equity, or repayment rights. Its value may be volatile and you may lose your entire holding; crypto-assets may be illiquid and are largely not covered by investor-compensation or deposit-insurance schemes. Not investment advice. Full risk disclosures.

Token Identity

Property	Value
Name	HSUITE
Currency Code	HST (XRPL standard currency code)
Ledger	XRP Ledger (canonical, sole issuance chain)
Issuer	XRPL account under native multisig (SignerList); each validator’s signature is produced by FROST threshold signing over DKG key shares, and the issuer’s master key is disabled
Precision	XRPL issued-currency precision (15 significant digits). Bridged amounts keep HSUITE’s four decimals; subscription prices are quoted in whole HST
Transfer fee	0.25% on every transfer between holders, burned by the ledger
Trust Lines	Recipients opt-in. The issuer can neither freeze a line nor claw HSUITE back: nobody, the DAO included, can lock or take a holder’s HSUITE

HSUITE is not minted on any other chain. Subscriptions are paid in real HSUITE on XRPL; paying in other assets is built but not yet enabled (see Paying for a Subscription).

Layer Separation

flowchart TB
    XRPL["XRPL = VALUE LAYER<br/>Token issuance, burns, payments, staking deposits"]
    Hedera["Hedera = GOVERNANCE LAYER<br/>HCS topics, validator registry, rules"]
    All["Chain adapters = EXECUTION LAYER<br/>Threshold signing on each supported chain"]

Each layer does what it is best at. No single chain does everything.

Supply and Deflation

Single-Ledger Audit Trail

Total supply is computable from one source:

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

Every mint, burn, and transfer is recorded on XRPL. There are no phantom balances, no cross-chain reconciliation issues, and no multi-ledger supply tracking. Any observer can verify supply by querying the XRPL issuer account.

Genesis, as built today, mints no HSUITE. HST enters circulation only through the migration bridge, which is capped at 1 billion per transaction, 2 billion per day and 50 billion in total, and is built but not yet enabled.

Burn Mechanics

Burns are executed as payments back to the HSUITE issuer on XRPL, where a returned token ceases to exist and the issuer’s outstanding obligations drop by exactly that amount. Each burn is one atomic XRPL transaction, paid for with a small XRP network fee. The 0.25% transfer fee is a second, continuous burn: the ledger removes it from every transfer between holders.

Fee Distribution (40 / 40 / 20)

Every settled subscription payment is real HSUITE on XRPL, and it is split as follows:

Allocation	Recipient	Mechanism
40%	Burn	Payment back to the HSUITE issuer on XRPL. Permanently removed from supply.
40%	Runner rewards	Paid in real HSUITE into the protocol runner pool on XRPL, for node operators. The intended role weighting is 50% validators, 30% hosts, 20% gateways. Paying the pool out to each operator is built but not yet triggered, so the pool accumulates until it is.
20%	Protocol treasury	Held in the validator-multisig XRPL treasury account.

Every payment is real HSUITE from the start: the developer pays HSUITE into the subscription’s deposit account, and the split moves that same HSUITE. The runner share is real tokens, not internal credits. Burns are real on-chain burns, fully auditable.

Paying for a Subscription

A subscription is priced in USD and paid in HSUITE on XRPL. A quote locks the price: it fixes the USD price, the HSUITE/USD rate (read from HSUITE’s own market on the XRPL native DEX, or from a configured fallback while that market has no liquidity) and the HSUITE amount due, and holds them until the order’s deadline (30 minutes by default). The developer pays that HSUITE to the subscription’s own deposit account, a DKG-multisig account on XRPL, and each validator checks the payment on the ledger on its own. A payment that arrives late or short is quoted again at the current rate, or the order is marked underpaid, so a subscription never activates at a stale price.

The deposit then works as a prepaid balance: usage is charged against it and swept 40 / 40 / 20 in batches. The account’s published rule lets it pay only HSUITE, and only to the burn, the runner pool and the treasury.

What You Can Pay With

Status	Payment	How
Live	HSUITE (HST) on XRPL	Paid straight into the subscription’s deposit account at the locked price.
Built, not yet enabled	XRP	The deposit account converts the XRP to HSUITE in one all-or-nothing XRPL payment, signed by the validators’ threshold key. Switched off by default.
Built, not yet enabled	BTC, ETH, SOL, HBAR and other assets	The developer pays a fixed-rate swap provider, which delivers XRP to the deposit account; the XRP path above then runs. Switched off by default.

flowchart LR
    HST["Developer pays HSUITE<br/>(live)"] --> Dep["Subscription deposit account<br/>DKG multisig on XRPL"]
    Swap["Developer pays BTC, ETH, SOL, HBAR ...<br/>to a fixed-rate swap provider<br/>(built, not yet enabled)"] -.->|"provider pays XRP"| XRP["XRP paid to the account<br/>(built, not yet enabled)"]
    XRP -.->|"converted to HSUITE<br/>inside the account"| Dep
    Dep --> Split["Swept in batches<br/>40% burn / 40% runners / 20% treasury"]

Today a request to pay in anything other than HSUITE is refused before anything is created. The platform receives payment on XRPL only: in the swap path the developer pays the provider directly and only XRP reaches the deposit account. No EVM chain (Ethereum, Polygon) takes part; EVM support is postponed. The full detail is in Settlement & Migration.

Staking Requirements

Node operators deposit real HSUITE held in validator-multisig deposit accounts on XRPL. These are the default requirements; node-runner slots are not open to the public yet.

Role	Deposit Requirement
Validator	10,000,000 HSUITE
Host	5,000,000 HSUITE
Gateway	2,000,000 HSUITE

Each deposit is locked for a 365-day term. Deposits are HSUITE only, paid directly on XRPL, and held as real HSUITE in deposit accounts on XRPL, not as internal accounting entries.

Slashing (Bonded Escrow)

HSUITE has no freeze and no clawback. The HSUITE issuer never enables XRPL clawback, and its published rule disables both clawback and freeze and locks them, so no vote can turn them back on. Slashing therefore cannot take HSUITE from anyone’s own account.

Slashing works on bonded escrow:

1. A validator’s stake sits in its own membership deposit account, controlled by the validators’ DKG keys, which the validator cannot withdraw from on its own. The deposit is locked for its term.
2. When the validators vote to ban a validator, with evidence attached, its whole deposit is forfeited: a threshold-signed payment moves it from the escrow to the Protocol Treasury.
3. A slash moves bonded stake only. It never touches a holder’s balance outside the bond.

Partial slashes, and returning a deposit after its term, are not built yet.

Hedera Migration Bridge

Existing HSUITE holders on Hedera will move to XRPL through the HSUITE bridge, which is one-way and burn-first. Genesis mints no HST: HST is minted only by this bridge.

1. HSUITE is removed on Hedera first: a wipe of the holder's balance by the
   validators' threshold key, paid by the holder's own account (its consent).
   The removal's memo commits to the holder's XRPL address.
2. The claim is registered on a public HCS claim registry; the earliest
   valid registration for each removal wins.
3. Each validator re-reads the removal on its own and releases its share of
   the signature only if it checks out.
4. HST is minted on XRPL 1:1, at HSUITE's four-decimal precision, to the
   committed address. Nothing is refunded: a claim stays open until it mints.

Built, not yet enabled The bridge is built but switched on for no network yet (see Universal Token Bridge). The mechanism is supply-neutral for individual holders: the HST minted on XRPL equals the HSUITE removed on Hedera. Market risk exists only in the project’s own LP positions on Hedera during the migration window.

Adding a New Chain

New chain integrations extend the platform without creating a new chain-native token: a chain adapter and its threshold-signing path are deployed, and usage on the new chain is paid for in the same canonical HSUITE on the XRP Ledger as every other chain. There is no separate chain-native HSUITE token.

NFT Subscription Model

Subscription Tiers

The monthly price is a prepaid credit that funds the subscription’s balance; usage is charged against it per operation. The allowances are caps, and they may still change.

Tier	Validator transactions / month (cap)	Monthly price	Use Case
Builder	250,000	$49	Small projects
Growth	2,500,000	$199	Growing apps
Scale	25,000,000	$999	Large apps
Enterprise	Negotiated	$2,500	Large scale

Revenue Flow

flowchart TB
    P["Developer pays HSUITE on XRPL<br/>at the locked quote"]
    Dep["Subscription deposit account"]
    DepNote["DKG multisig on XRPL<br/>each validator verifies the payment"]
    Mint["Mint NFT on XRPL"]
    MintNote["Access granted via token gate"]
    Dist["Sweep usage charged against the deposit"]
    DistNote["40% burn / 40% runners / 20% treasury"]
    P --> Dep
    Dep -.-> DepNote
    Dep --> Mint
    Mint -.-> MintNote
    Mint --> Dist
    Dist -.-> DistNote

Economic Benefits by Stakeholder

For Token Holders

• Deflationary supply: 40% of every settled payment burned on a single auditable ledger, plus the 0.25% transfer fee
• Real settlement: Every subscription is paid in real HSUITE on XRPL and settled from an on-chain deposit account, not credited internally
• Governance rights: HSUITE-weighted DAO voting

For Developers

• Predictable costs: Fixed subscription pricing in USD terms
• Pay in HSUITE: Subscriptions are paid in HSUITE on XRPL at a locked quote; paying in XRP and other assets is built but not yet enabled

For Node Operators

• Real token rewards: 40% of all settled payments goes to the runner pool as real HSUITE, not credits (paying the pool out to operators is not yet triggered)
• Multi-chain income: Usage on every supported chain is paid for in HSUITE, so it all feeds the same runner pool
• Staking deposits: Held as real HSUITE on XRPL with transparent on-chain accounting
• No freeze, no clawback: Nobody can lock or take an operator’s HSUITE; a slash can take only the stake a validator bonded, and only after the validators vote to ban it

Treasury Management

The protocol treasury is a single validator-multisig account on XRPL, receiving 20% of all settled payments in real HSUITE. It is an autonomous protocol fee-payer, not a DAO-controlled fund.

What the Treasury Can Pay

The Treasury’s published rule is the only authority over it:

1. Protocol destinations only: itself, cluster operators, the token issuer, the testnet faucet, deposit accounts, the runner pool and bridge lock wallets. Any other destination is denied.
2. Caps and a floor: every asset has a spending cap per monthly period, and the account keeps a minimum balance.

A single-chain treasury avoids managing balances across multiple chains.

---

Continue to RoadmapImplementation timeline.

Revision 3 — April 2026. XRPL-canonical model.