Stellar Integration

Coming next

Stellar is not live yet. It will land in Smart Engines and HSuite Wallet together. There is no date. This page describes what Stellar support will offer.

Overview

Stellar is a payments chain on which an issuer creates custom assets without smart contracts. Holders opt in to an asset with a trustline. Stellar entities will work the way XRPL entities work today: the payer funds a new account, then the validators install their multisig on it and lock its master key.

flowchart TD
    XLM["Stellar (coming next)"] --> ASSET["Custom asset<br/>(trustline)"]
    XLM --> COMP["Native issuer flags"]
    COMP --> AQ["AUTH_REQUIRED<br/>(compliant)"]
    COMP --> AR["AUTH_REQUIRED + AUTH_REVOCABLE<br/>(pausable)"]
    COMP --> CB["AUTH_CLAWBACK_ENABLED<br/>(wipeable)"]
    XLM --> MS["SetOptions signer weights<br/>(validator multisig)"]

Key Features

Custom asset issuance

Trustline assets with no smart contract. Mint is a payment from the issuer; burn is a payment back to it.

Native compliance flags

AUTH_REQUIRED, AUTH_REVOCABLE and AUTH_CLAWBACK_ENABLED on the issuer.

Payer-funded accounts

The payer funds each new entity account, sized from the ledger’s live base reserve.

Validator multisig

One SetOptions installs the validator signers and locks the master key.

Immutable rule anchor

A hash of the entity’s rule reference in the creation transaction’s memo.

Token Capabilities

Each capability will map to a Stellar issuer flag or operation:

Capability	Stellar implementation	Description
`pausable`	`AUTH_REQUIRED` + `AUTH_REVOCABLE` (issuer)	Revoke trustline authorization to pause
`restrictable`	Per-trustline authorization flags	Freeze one holder’s trustline
`compliant`	`AUTH_REQUIRED` (issuer)	Holders need the issuer’s authorization
`wipeable`	`AUTH_CLAWBACK_ENABLED` (issuer)	The issuer can claw tokens back
`mintable`	Payment from the issuer	Issue more supply
`burnable`	Payment back to the issuer	Remove supply

Only these three issuer flags will be accepted. AUTH_IMMUTABLE will be refused, because it locks the issuer’s flags permanently.

NFT Model

NFTs on Stellar are not part of the planned integration.

Transaction Sovereignty

A Stellar entity will be created and operated without the validators paying fees or any single key controlling it:

The validators run a DKG for the new entity. The entity’s account address is its own DKG key.
The payer signs and submits a CreateAccount that funds that address. The starting balance is the ledger’s live base reserve, plus fee headroom.
The validators threshold-sign one SetOptions on the new account. It installs the validator signers, sets the operation thresholds to the quorum weight, and either locks the master key (weight 0, full security) or weights it so that the owner’s signature and t validator signatures are both required (partial security).
Every later write is prepared by the validators, then signed and submitted by the payer.

The rule anchor is a SHA-256 of the entity’s canonical rule reference, stamped as the creation transaction’s Memo.hash. Stellar’s text memo is capped at 28 bytes, too short for the full reference, and a ManageData entry can be overwritten later, so neither is used as the anchor.

Genesis Services

Stellar takes no part in genesis. Genesis runs on Hedera (HCS topics) and XRPL (the HSUITE token and the membership NFTs) only.

Amount Handling

Unit	Decimals	1 XLM =
XLM	7	10,000,000 stroops
Stroop	0	Smallest unit