Chains

What you’ll get here

Which blockchains Smart Engines runs on today, which come next, what each live chain can do natively, and how to pick between them.

You came to Smart Engines because you didn’t want to learn a stack of blockchains. Good: you won’t have to. You write to one API, pass a chain parameter, and the platform routes your request to that chain’s adapter. This page is the map of what’s behind that parameter.

🧠 For Normies

Every blockchain is its own country with its own language, money, and rules. Normally, supporting a handful of them means hiring a translator for each. Smart Engines is a single translator: you say what you want once, and it handles the local dialect.

---

What “supported” means here

A chain is live when the network runs its adapter: you can create accounts, move value, and (where the chain allows) issue tokens through the unified API, with authority enforced by native on-chain multisig.

Two chains are live today: Hedera and XRPL.

Stellar, Polkadot, Solana and Bitcoin come next. Their adapters are in the codebase, but the network does not run them yet. They will land in Smart Engines and in HSuite Wallet together.

The two EVM chains, Ethereum and Polygon, are postponed.

🧠 For Normies

“Live” = you can use it through the real network. “Coming next” = it’s built, and it switches on in a future release. “Postponed” = the code exists in a drawer and isn’t planned for now. We tell you which is which so you don’t build on a drawer.

---

The chains at a glance

flowchart TD
    API["One API<br/>chain = ?"] --> LIVE["Live today"]
    API -.coming next.-> NEXT["Stellar · Polkadot · Solana · Bitcoin"]
    API -.postponed.-> EVM["EVM: Ethereum, Polygon"]

    LIVE --> H["Hedera<br/>HCS consensus + governance<br/>HTS tokens"]
    LIVE --> X["XRPL<br/>HSUITE token + membership NFTs<br/>issued tokens"]

    H --> MS["Native on-chain multisig<br/>(no single key controls any entity)"]
    X --> MS

Chain	Status	Role
Hedera	Live	HCS consensus and governance backbone; HTS tokens for apps
XRPL	Live	Canonical for the HSUITE token and subscription NFTs; issued tokens for apps
Stellar	Coming next	Trustline-based custom assets
Polkadot	Coming next	Assets-pallet tokens
Solana	Coming next	SPL tokens
Bitcoin	Coming next	Bitcoin transfers (no token issuance)
Ethereum	Postponed	EVM
Polygon	Postponed	EVM layer 2

🧠 For Normies

• Hedera is the courthouse: it’s where the rules and the public record live.
• XRPL is the house bank: the HSUITE token and your membership NFTs are issued here.
• More rails for moving value are on the way.

---

Capability matrix: the live chains

What you can do with a token you create through the API on each live chain today. Every control is native: the chain itself enforces it, and the token’s authority is the entity’s on-chain multisig.

Capability	Hedera	XRPL
transfer	✅	✅
mint	✅	✅
burn	✅	✅
pause (all holders)	—	✅
restrict (one holder)	—	✅
compliant (approved holders only)	—	✅ chosen at creation
wipe (claw back)	—	✅ chosen at creation

On Hedera, a token created through the API carries an admin key and a supply key, both held by the entity’s multisig, and no pause, freeze, KYC or wipe key. If your token needs those controls, issue it on XRPL.

🧠 For Normies

• transfer: can you send it to someone?
• mint / burn: can the issuer create more or destroy supply?
• pause: can the issuer freeze everyone at once (e.g. during an incident)?
• restrict: can the issuer freeze one specific account?
• compliant: must an account be approved before it can hold the token?
• wipe: can the issuer claw tokens back out of an account?

Native method per capability

Capability	Hedera	XRPL
transfer	TransferTransaction	Payment
mint	TokenMintTransaction (supply key)	Payment from the issuer
burn	TokenBurnTransaction (supply key)	Payment back to the issuer
pause	—	AccountSet + asfGlobalFreeze
restrict	—	TrustSet + tfSetFreeze
compliant	—	AccountSet + asfRequireAuth, set when the token is created
wipe	—	Clawback, which needs asfAllowTrustLineClawback, set when the token is created

---

Choosing your chain

Regulated or compliance-heavy token?

Use XRPL. An issued token can require approved holders, freeze one holder or everyone, and claw tokens back, all natively on-chain. Hedera tokens created through the API support transfer, mint and burn.

Working with HSUITE or memberships?

That’s XRPL, the canonical ledger for the HSUITE token and subscription NFTs.

Need a public, ordered record?

That’s Hedera: the platform publishes its rules and governance on HCS topics.

Need another chain?

Stellar, Polkadot, Solana and Bitcoin are next. Code written against the unified API keeps the same shape: you change the chain parameter.

---

The two canonical roles

Two chains have fixed jobs in the platform. This is genesis architecture, not a limitation of the other chains.

XRPL is canonical for value

The HSUITE token and the membership/subscription NFTs are issued only on XRPL.

Hedera is canonical for consensus

Hedera’s genesis role is HCS only: topics for the validator registry, the public rules log, and consensus messaging. Apps can still create HTS tokens through the API; the platform itself issues no token on Hedera.

🧠 For Normies

Think of it as a company with one bank (XRPL) and one notary (Hedera). Money is issued at the bank; the official, public record of “what the rules are” is kept at the notary.

---

Every chain is multisig: zero single-sig

This holds on every live chain: after genesis, every account the network creates, including its own operator and treasury accounts, is native multisig, so no single key controls any entity. The one bootstrap exception is the genesis funding wallet: it funds the treasury once, controls no entity, and the step that deletes it is built but not yet enabled. See Zero single-sig.

An entity’s own keys come from a distributed key generation (DKG) ceremony across the validators and exist only as shares. To sign with one, a threshold of validators each sign with their own share (FROST threshold signing), and only the partial signatures are combined, so the whole key is never assembled.

Chain	Native multisig primitive	Who signs
Hedera	KeyList with a threshold	The entity’s own DKG keys, each signed by a threshold of validators with FROST.
XRPL	SignerList with a quorum	One signer key per validator; a quorum of validators must sign. The account’s own master key comes from DKG and is disabled once the SignerList is in place.

The coming-next chains will use their own native multisig in the same way.

See Network & Tiers for how validators jointly hold these keys, and the glossary for DKG, TSS and multisig definitions.

---

Per-chain documentation

Live

HederaHCS consensus and governance, HTS tokens

XRPLCanonical ledger: HSUITE, membership NFTs, issued tokens, trust lines, clawback

Coming next

StellarCustom assets on trustlines

PolkadotAssets-pallet tokens

SolanaSPL tokens

BitcoinBitcoin transfers

Postponed

EthereumEVM, postponed

PolygonEVM layer 2, postponed

---

Related

Network & Tiers

Three-Cluster Genesis

HSUITE token architecture

Glossary