Value Flows

What you’ll get here

the complete money path, from a single API call to node runners getting paid — every step that turns usage into real HSUITE and splits it across burn, node runners, and treasury.

A platform that gives away unbounded compute doesn’t survive. Smart Engines meters every request, prices it, settles the payment into real HSUITE on XRPL, and distributes it. This page follows one unit of value all the way through.

🧠 For Normies

This is “follow the money.” Someone uses the platform, that use is counted and priced, they pay in HSUITE (other currencies are built but not yet enabled), and that HSUITE is split three ways. No hidden subsidies, no made-up balances.

---

The full flow

flowchart TD
    Req["1 · Request<br/>(API call / signature / chain op)"] --> Guard["2 · Rate limit<br/>pre-flight: within quota?"]
    Guard --> Work["3 · Work performed"]
    Work --> Meter["4 · Metering<br/>record usage, charge the prepaid balance"]
    Meter --> Sub["Subscription<br/>(tier + prepaid balance)"]
    Pay["Payment<br/>(HSUITE on XRPL; other assets built, not yet enabled)"] --> Oracle["5 · HSUITE/USD rate<br/>XRPL native DEX"]
    Oracle --> Settle["6 · Subscription settle-in<br/>deposit account on XRPL"]
    Settle --> Split{"7 · Fee distribution<br/>40 / 40 / 20"}
    Split -- "40% burn" --> Burn["Return to issuer<br/>supply reduced"]
    Split -- "40% runners" --> RunnerPool["Runner pool<br/>(payout not yet switched on)"]
    Split -- "20% treasury" --> Treasury["Protocol treasury (XRPL)"]
    RunnerPool -.->|"50%"| V["Validators"]
    RunnerPool -.->|"30%"| H["Hosts"]
    RunnerPool -.->|"20%"| G["Gateways"]

---

Step 1–4 · Metering usage

Every request passes two checkpoints, both keyed to the app’s subscription tier:

• A rate limit (pre-flight): refuses over-quota requests before doing work.
• Metering (post-success): records the call against the app’s subscription after it succeeds. On hosts and gateways the priced cost is then charged against the subscription’s prepaid balance. A per-operation fee on validator calls is built but not yet enabled.

Prices live in a set of focused price lists, one per dimension (validator op price, host op price, gateway op price, harbor, IPFS, subscription tiers, accepted assets, volume discounts, fee distribution). Each line is authored in USD and converted to HSUITE at charge time (see Step 5).

🧠 For Normies

Two gates per request: one before (“are you allowed this call?”) and one after (“count it, and charge it”). The price list is a set of small tables — each priced in dollars and converted to HSUITE when you’re charged.

The price lists are part of the software release, so changing a price means shipping a new release; they are not set by DAO vote. The one exception is marketplace pricing, which a passed DAO proposal can override (see DAO governance). Pricing decisions are also hashed and signed with a post-quantum (ML-DSA) attestation when the attestation stream is available, so a price applied to a charge can be checked later.

Who pays a platform-sponsored write — the app, never the protocol

Metering a subscription API call is one path. Some operations also make the platform perform a real chain write on an app’s behalf — creating a token, account or topic, publishing a rule, or registering an agent. Every such successful platform-paid write is charged back to the app (never the protocol, never the treasury), through the host’s existing charge path, priced from the same price lists:

• The charge fires after the handler succeeds, keyed exactly-once per write. A refused, failed, or ambiguous (post-debit failure) write charges nothing.
• Charging is fail-soft: a billing hiccup never fails the underlying chain write.
• An HCS message is billed per 1 KiB chunk, capped at the 20-chunk HCS maximum, so a rule publish can never be over-billed.
• A chain with no price line for an operation is left uncharged.

🧠 For Normies

When the platform does on-chain work for an app — minting a token, writing a record — the app pays for it, at the same published prices, and only when the work actually succeeds. The protocol never foots that bill, and a glitch in the billing never blocks the work itself.

---

Step 5 · Pricing in HSUITE

Price lines are authored in USD; charges settle in HSUITE. To convert a USD price into HSUITE the platform reads the HSUITE/USD rate from the XRP Ledger’s own native DEX — HSUITE is XRPL-canonical, so its on-chain market is the rate source. The validators read it directly from the ledger and resolve the HSUITE issuer from the network’s genesis configuration on every call.

The rate is derived, in order, from:

1. AMM pool reserve ratio (depth-backed, the canonical path) — first an HSUITE/RLUSD pool (RLUSD ≈ $1), else an HSUITE/XRP pool combined with the XRP/USD rate.
2. Order-book mid (best-bid/best-ask average) when no AMM pool exists for the pair.
3. Configured fallback when no pool exists, the book is thin, or the ledger can’t be read. Until HSUITE liquidity exists on XRPL, the fallback is the path in use — by design, not an error.

The AMM path is not read as a single spot value. The reserve ratio is sampled as a time-weighted average price (TWAP): the same pool is read at several evenly spaced historical ledger indices across a short window (default 5 samples over ~75 ledgers, ~5 minutes), each sample independently required to clear a minimum-liquidity floor (a floor on the quote-side reserve) before it is trusted. If too few samples clear the floor, the whole pool is rejected and derivation falls through to the next strategy — a thin pool can never produce a rate. Surviving samples are outlier-trimmed against their median before being averaged, so a single manipulated ledger cannot drag the result. The order-book path has no per-ledger reserve state to sample, so instead it requires the top-of-book offer on each side to clear a minimum XRP-depth floor before its quality is used.

A sanity band rejects absurd values (corrupted reserves, a near-empty pool, a one-sided book) and degrades to the next strategy. The result is cached briefly. No third-party price feed is used: a degraded boot where no rate source is available uses the configured fallback, never an outside price.

Both ends of the catalog use this rate the same way. A subscription tier price is a monthly USD figure: GET /api/v3/subscription/tiers returns that priceUsd and, when a rate is available, an indicative HST quote of ceil(priceUsd / rate) whole HST (HST on XRPL has no fractional unit), tagged with the rate’s source (amm / book / fallback). Marketplace subscription sub-offers are likewise authored in USD and settled in HST at the live rate, not carried as a fixed HST amount. In both cases the USD figure is the stable catalog price; the HST that changes hands is whatever that figure converts to at payment time.

🧠 For Normies

To charge a dollar-priced line in HSUITE, the system needs “what’s HSUITE worth right now?” It reads that from HSUITE’s own market on the XRP Ledger — the real on-chain pools and order books — rather than an outside price website. To stop anyone nudging that market for a moment to get a cheaper price, it doesn’t take one instantaneous reading: it averages several readings across a few minutes, ignores outliers, and refuses to trust a pool that’s too shallow to be a real market. If there’s no live market yet, it uses a fixed fallback figure instead of guessing.

---

Step 6 · Settling into real HSUITE

This is the heart of the model: no internal credits, no IOUs. A subscription payment is real HSUITE that sits in an on-chain deposit account and is split from there.

Live today: HSUITE on XRPL

Live

The builder pays HST to the subscription’s deposit account against a price-locked order; the account is then settled 40/40/20.

Built, not yet enabled: XRP

Built, not yet enabled

Converted to HST inside the deposit account by an all-or-nothing, validator-multisig-signed XRPL Payment.

Built, not yet enabled: other assets

Built, not yet enabled

BTC, ETH, SOL, HBAR and so on, swapped to XRP by a fixed-rate swap provider that pays the deposit account directly, then the XRP path.

The order, the price lock and the settle-in are detailed in Settlement & migration.

🧠 For Normies

Today you pay in HSUITE and the money never touches a personal wallet: it goes to a locked account whose rule limits where it can ever be spent, and the 40/40/20 split pays only the burn, the runner pool and the treasury. Paying in other coins, where the system would swap them for you, is built but not switched on yet.

---

Step 7 · Distribution — 40 / 40 / 20

Every settled subscription payment is split by a fixed default model:

40% · Burn

The HSUITE is sent back to its own issuer, which destroys the returned IOU. Permanently removed from supply. (The HSUITE issuer has no clawback.)

40% · Runner rewards

Paid as real HSUITE into the runner pool. Paying the pool out to node runners is built but not switched on yet (see Staking & node-runners).

20% · Protocol treasury

Held in the validator-multisig XRPL treasury account.

The 40% runner pool is itself split, once its payout is switched on:

50% · Validators

Share of runner pool.

30% · Hosts

Share of runner pool.

20% · Gateways

Share of runner pool.

These percentages are the defaults, and both splits must sum to 100%. The burn / runners / treasury split applied at settlement is read from the deposit account’s own published rule, so it changes only when that rule is amended. A deployment’s configuration can change the defaults.

🧠 For Normies

Of every payment: nearly half is destroyed (permanently removed from supply), nearly half is set aside for the people running the infrastructure, and a fifth funds the protocol’s shared treasury. Within the node-runner share, the validators (who do the heaviest, most security-critical work) get the largest cut.

The same split for every revenue stream

Subscription usage is not the only revenue that runs through this split. Marketplace listing and featured-slot fees settle the same way: once a developer’s on-chain HSUITE payment into the fee wallet is confirmed, each credit is settled through the same settlement path — the same 40 / 40 / 20, the same governed split, the same burn / runners / treasury destinations. There is deliberately no second distribution implementation to drift.

One amount rides alongside the split without being part of it: a reserve surcharge. When the protocol Treasury fronts the small XRP reserve needed to open a customer’s XRPL deposit account, that outlay is read back off the ledger, priced in HSUITE at the AMM rate, and reimbursed 100% to the Treasury — outside the 40 / 40 / 20 split (never burned, never to runners). It is a cost reimbursement, not revenue, and it is settled first, before the base amount is split.

🧠 For Normies

Marketplace fees get carved up by the exact same rule as everything else — no special-case accounting. The one extra line is a reimbursement: if the treasury had to put up a little XRP to create your on-chain account, it gets that exact cost back (in HSUITE), and that reimbursement isn’t counted as a fee to be split.

---

Why settling to a real token matters

Without real settlement	With real settlement (Smart Engines)
Node runners paid in internal credits	The node runners’ share is real HSUITE
Burns are bookkeeping entries	Burns are on-chain, auditable
Usage settled as internal credits / IOUs	Every payment is real HSUITE on XRPL, held in an on-chain deposit account
Supply tracked across ledgers	One ledger, one query

🧠 For Normies

Lots of platforms hand out “points” that never touch a real market. Here, usage is paid in the real token on a public ledger, and the node runners’ share is that same token — so the mechanics are on-chain and auditable rather than internal bookkeeping.

---

Next steps

Staking & node-runnersWhere node runners fit.

Settlement & migrationThe order, the price lock and the settle-in in detail.

DAO governanceHow rules get changed.

Subscriptions & MembershipsBuilder-facing pricing.