Settlement & Migration

What you’ll get here

how a subscription payment is split 40/40/20 on XRPL, what is live today and what is built but not yet enabled, plus the one-time pipeline that moves HSUITE from Hedera to XRPL.

Two related primitives sit at the center of the economy:

Settlement

A subscription’s payment lands in a per-subscription deposit account on XRPL and is split 40% burn / 40% runners / 20% treasury.

Migration

The one-time, supply-neutral move of existing HSUITE holders from Hedera to XRPL.

Both are grounded in the HSUITE token architecture and the Universal Token Bridge.

🧠 For Normies

Settlement is “you paid for a subscription in HSUITE; the network splits it: burned, node-runners, treasury.” Migration is the one-time “your old HSUITE on Hedera becomes new HSUITE on XRPL, one-for-one.” This page is about both.

---

What you can pay with

Status	Payment	How
Live	HSUITE (HST) on XRPL	A subscription order locks the price at quote time; you pay HST to the subscription’s deposit account with the order’s DestinationTag; the account is then settled 40/40/20 (below).
Built, not yet enabled	XRP	The deposit account converts the XRP to HST with a validator-multisig-signed, all-or-nothing cross-currency Payment.
Built, not yet enabled	BTC, ETH, SOL, HBAR and other assets	A fixed-rate swap provider (ChangeNOW) delivers XRP to the deposit account, then the XRP path above runs.

Both payment options are switched off by default, so asking to pay in any asset other than HSUITE is answered with “not yet supported” today, before anything is created.

The price lock

A quote fixes the USD price, the HSUITE/USD rate snapshot and the HSUITE amount due, and holds them until the order’s deadline (30 minutes by default). A payment that arrives in time and in full settles at the locked price even if the market has moved. A late or short payment is re-quoted at the rate of its arrival, or the order is marked underpaid; a subscription never activates at a stale price. Each validator verifies the payment from the ledger on its own (meta.delivered_amount, never the transaction’s Amount) against the replicated order.

🧠 For Normies

The price you are quoted is frozen for a short window. Pay on time and in full and you get exactly that deal; pay late or short and you are quoted again. Nobody gets to wait and see whether the coin gets cheaper before paying.

The burn leg is a real burn

The burn leg is a real on-XRPL destruction: the burned HSUITE is sent back to its own issuer, where a self-issued IOU returned to the issuer ceases to exist and the issuer’s outstanding obligations drop by exactly that amount. Sending it to an inert “blackhole” account instead would only relocate supply, so that is not done.

---

Subscription-deposit settle-in

This is the live settlement path. When a developer subscribes, their tier payment lands in a per-subscription deposit account: a protocol-held DKG-multisig account that holds real HST on XRPL.

The deposit is a prepaid float, swept in batches

The deposit is not drained the moment it is confirmed. It is treated as a prepaid float: on activation the full deposit becomes the subscription’s spendable balance and stays in the account. As the developer uses the platform, each metered charge plus the up-front monthly fee accrues against that balance. Accrued-but-unsettled charges are then settled 40/40/20 in batches — when the accrued amount crosses a threshold, or on a periodic backstop — rather than draining the whole deposit up front.

The float and the on-chain balance track each other: remainingBalance = fundedAmount − settledAmount, clamped at zero and hard-blocked when exhausted (no credit), so pay-per-use can never charge HST that has already left the account.

🧠 For Normies

Your subscription payment works like a prepaid balance, not a coin-op. It lands in a locked account and stays there; as you use the platform, your usage is tallied against it and periodically swept into the 40/40/20 split in batches. The system never charges you for money that has already left the account.

Every settled amount uses the same canonical rule and the same 40/40/20 split. The deposit account’s canonical rule is not advisory — it is the sign-time authority over the money. The rule declares three primitives for a subscription deposit:

Primitive	What it pins
assetRestriction	The exact asset that may leave the account (HST, by currency + issuer).
destinationAllowlist	The only roles it may pay: burn, runners, treasury.
distribution	The account’s own split policy — an enforced snapshot of the burn / runners / treasury percentages (40/40/20 by default) and its policy version. This is the rule the settle-in reads to decide the split; an entity carrying a governed policy settles to its split, not a hardcoded one.

A subscription deposit account cannot be created without all three: the account-creation step rejects a placeholder rule. The rule is also published to HCS as a ruleRef, so the account’s governing rule is an auditable on-chain record.

sequenceDiagram
    autonumber
    participant Sub as Subscription
    participant Dep as Deposit account<br/>(DKG multisig on XRPL)
    participant Eval as Canonical rule (sign-gate)
    participant Roles as Role accounts<br/>(issuer / runner-pool / treasury)
    participant HCS as HCS audit

    Sub->>Dep: accrued usage crosses sweep threshold
    Dep->>Eval: settle accrued 40/40/20 (3 legs)
    Eval->>Eval: asset is HST AND destination is a resolved role?
    Eval-->>Dep: allow only the 3 role destinations
    Dep->>Roles: 40% burn / 40% runner-pool / 20% treasury
    Dep->>HCS: signed settlement record

The sign-gate makes the rule real

When the deposit account tries to spend, every validator independently evaluates the account’s canonical rule. On an account.transfer it refuses the spend unless the asset matches assetRestriction and the destination is one of the resolved role addresses. It is deny-by-default and fail-closed: an unresolved role, a missing role map, or an undefined destination all deny. The 40/40/20 legs pass precisely because their three destinations are the resolved roles; any other destination is refused.

🧠 For Normies

The deposit account can only ever pay three pre-approved addresses, and only in HST. There is no path for it to send money anywhere else — the validators that co-sign its transactions check that on every spend, and refuse anything that doesn’t fit.

Where each leg lands

The settle-in resolves the three role destinations and spends the deposit via the DKG-multisig quorum:

Leg	Destination role	Resolves to
40% burn	burn	The HSUITE issuer (return-to-issuer permanently removes it from supply).
40% runners	runners	The protocol runner-pool account (see Staking & node-runners).
20% treasury	treasury	The protocol treasury account.

The split percentages default to 40/40/20. The settle-in resolves the split per-entity from the deposit account’s own canonical rule: if the deposit account carries an enforced distribution policy in its canonical rule, that governed split is used; otherwise it falls back — fail-closed — to the 40/40/20 default. Only a deposit account the platform itself created may set the split; any other entity’s rule is ignored for this purpose. The split is computed on integer smallest-units, so the three legs sum back to the source amount exactly — no rounding drift, no created or lost units (the burn leg absorbs any remainder). The settle-in is idempotent and fail-closed: an atomic per-sweep claim with a time-to-live guards against double-spend (a node that throws mid-spend self-expires and the work is redelivered, no manual clear), each role address is validated, and if any of the three role destinations can’t be resolved it does not perform a partial spend.

🧠 For Normies

When you pay for a subscription, that payment isn’t sitting in a wallet someone can touch. It lands in a locked multi-signature account whose only allowed move is to split itself 40/40/20 — burned, sent to the node-runner pool, sent to the treasury. Same split as every other fee on the platform.

Note for builders

only the settle-in is live. It splits a confirmed deposit into the three role accounts (burn / runner-pool / treasury). The distribute-out that pays the accumulated runner-pool share to individual operators is built (it splits a pool amount pro-rata by each registered node’s staked weight and transfers to each operator’s own payout wallet, sign-gated and idempotent) but nothing triggers it: the live sweep pays the runners leg into the runner-pool account without fanning it out. Until a payout trigger is built, the pool accumulates and operators are not paid from it. See Staking & node-runners → Distribute-out for the mechanics.

---

The HSUITE migration (Hedera → XRPL)

The reference instance of the Universal Token Bridge is the HSUITE migration itself: HSUITE was originally an HTS token on Hedera, and XRPL was made canonical. The migration moves holders across, one-for-one.

Genesis, as built today, mints no HST on any network. HST enters XRPL only through this bridge, 1:1 against HSUITE removed from circulation on Hedera. So every HST on XRPL is backed by HSUITE that left Hedera, and both ledgers show it.

Status: built, not yet enabled

The whole flow is built: the Hedera removal, the cross-cluster claim registry, each validator’s own evidence check, the mint executor and the conservation reconciler. None of it is switched on for any network, so the bridge has minted no HST. See what holds it back.

The migration runs burn-first: the HSUITE leaves Hedera before any HST is minted.

flowchart TD
    A["The holder picks an amount<br/>and an XRPL address"] --> R["HSUITE is removed on Hedera<br/>(the holder co-signs as payer;<br/>the memo commits to the claim)"]
    R --> Reg["The claim is registered on the<br/>HCS claim registry"]
    Reg --> V{"Each validator re-checks<br/>the removal with its own reads"}
    V -->|"a check fails"| W["Its signature share is withheld:<br/>no mint"]
    V -->|"a threshold agrees"| M["HST is minted 1:1<br/>to the committed XRPL address"]

Burn-first and one-way

The validators’ key removes the HSUITE on Hedera: a wipe of the holder’s balance, or a burn for the token treasury’s own HSUITE. The account being debited co-signs the removal as its fee payer, and Hedera runs no transaction without its payer’s signature, so the removal cannot happen without that account’s consent. The removal’s memo commits to the claim (the bridge, the claimant and the XRPL address), so nobody can redirect it to another address.

The bridge is one-way, so a mint that fails is never refunded on Hedera. The claim stays open until its mint lands; a claim that keeps failing is parked with an alert, and an operator can return it to the queue, where every check runs again. The amount is 1:1 at HSUITE’s full four-decimal precision; an amount HST cannot hold exactly is refused, never rounded.

No person authorises a mint

Each validator releases its share of the XRPL mint signature only after its own reads confirm the removal. A mint therefore needs a threshold of independent confirmations. No person, DAO vote or validator quorum can authorise one, and once the bridge is enabled, anyone can bridge.

🧠 For Normies

You hand in your Hedera HSUITE first, and the network then mints the same amount on XRPL to the address you chose. No single operator can mint, or send your HST somewhere else: every validator checks your removal on its own before it signs.

Why the migration involves no price

The bridge is a direct 1:1 conversion: what leaves Hedera is minted on XRPL. No price is involved, and a holder ends up with exactly the same amount on XRPL.

Replay protection and supply cap

One removal backs at most one claim, across every cluster: the claim key is derived from the removal transaction, the claim’s registration is the earliest valid record for it on the HCS claim registry, and the XRPL mint carries that key as its InvoiceID. Mints are capped at 1 billion HST per transaction, 2 billion per day and 50 billion in total, the whole HSUITE supply. The caps are frozen in the HST issuer’s rule, so no vote can raise them.

🧠 For Normies

One removal on Hedera can be minted on XRPL only once, and there can never be more HST on XRPL than HSUITE ever existed on Hedera.

Conservation is checkable from the chains

The invariant is public: the HST the bridge has minted on XRPL equals the HSUITE it has removed on Hedera. Anyone can check it from the two ledgers, without trusting the validators’ own records. A reconciler that checks it continuously is built: it raises an alert on a violation and does not pause anything by itself. Like the rest of the bridge, it is not enabled on any network yet.

---

Settlement vs migration vs bridge

Goal	Use
Split a subscription’s HSUITE payment 40/40/20	Settlement
Move existing HSUITE holders Hedera → XRPL	Migration (a one-way bridge instance, built, not yet enabled)
Move a Hedera HTS token to XRPL (built, not yet enabled)	Universal Token Bridge

All three share the same infrastructure: threshold signing, the rules engine, HCS audit, and chain adapters.

---

Next steps

Universal Token BridgeThe generic engine behind migration.

Value flowsWhere settled HSUITE goes.

HSUITE tokenThe token model.