Ryntra for Stellar
Understand the asset. Control the action. Prove the outcome.
Stellar gives issuers real power over what a holder owns — permission to hold at all, freeze, clawback — and real obligations to disclose. Ryntra reads both, prepares one exact action against them, has it authorized in the holder's own wallet, and produces a receipt anyone can recompute.
- Live · Stellar Mainnet, read-only
- Live · Freighter Connect
- Testnet verified · one signed testnet payment
- Non-custodial · no key reaches Ryntra
A ticker is not an asset explanation
Many assets share a code on Stellar. Two called USDC can have different issuers with completely different powers over a holding, and nothing in a balance says which one it is. Answering the questions that actually decide the outcome means visiting seven surfaces that do not share a vocabulary.
What has to be assembled
Seven surfaces- Issuer documents, on the issuer's own domain
- Trustline state, per holder
- Authorization flags, set independently of each other
- Clawback, enabled or not, on the same account
- A liquidity route, priced somewhere else
- A wallet prompt that shows bytes
- An explorer result, after the fact
What this collapses it into
One workflow- One Asset Passport, with each field's source attached
- One exact intent, checked before a signature is spent
- One authorization, given in the holder's own wallet
- One reconciliation of expected against actual
- One receipt anyone can recompute without trusting Ryntra
Stellar already provides the assets, the wallets, the liquidity and the settlement. What is missing is the one thing a holder or a treasury needs before acting: the facts that decide a specific decision, in one place, each carrying which source answered and when.
One real asset, read from Stellar Mainnet
Etherfuse USTRY, resolved from public ledger state and the issuer's own SEP-1 document. It reports what it reads rather than printing a template: USTRY's issuer can neither freeze nor claw back, while Circle's USDC on the same page shape shows freeze enabled.
- Exact identity
- Classic, Stellar Asset Contract or SEP-41, with the issuer and contract address that belong to it. A code on its own is a 404 rather than a guess at which issuer was meant.
- Issuer controls
- Permission to hold, freeze, clawback, and whether those powers can still change — read from the issuer’s account and reported separately rather than collapsed into one verdict.
- Holding requirement
- Whether a trustline is required, whether the issuer must authorize it, and the XLM reserve it locks, read from the ledger rather than memorised as a constant.
- Redemption and eligibility
- Backing claim, reserve attestation and redemption path from the issuer’s own document, carrying a standing note that this is the issuer describing itself.
- What is not known
- Computed from the sections above, permanent, and never empty by default. It grew from three entries to four on the USDC page without anyone editing it.
Etherfuse is demonstrated, not integrated. The Passport calls no Etherfuse surface — it resolves USTRY from the public Stellar ledger and the issuer’s published stellar.toml. There is no score and no rating: five evidence states across a dozen fields is the honest shape of what is known, and one number would be an invention wearing a progress bar.
Eight stages, and the one that is not built stays visible
Each stage produces something the next one consumes, and each is separately checkable. Policy is registered work rather than a shipped stage — hiding it would make this diagram shorter and the product harder to believe.
- Passportidentity · issuer controls · holding requirementBuilt
- Preflightrefuse what the ledger would rejectBuilt
- Policynot built — every receipt records policyVersion: nullPlanned
- Human authorizationthe exact intent, stated in wordsBuilt
- Wallet signatureinside Freighter; no key reaches RyntraBuilt
- Stellar settlementbrowser to the public endpointBuilt
- Reconciliationexpected against actual, movement by movementBuilt
- Receiptintent → authorization → transaction → effects → itselfBuilt
- Evidence is not policy
- Reading an issuer’s powers states a fact. Deciding whether those powers are acceptable for a given holding is a separate judgement, and this product does not make it yet.
- Policy approval is not a signature
- An approved plan moves nothing. Only a signature inside the holder’s own wallet does, and it is theirs to give or refuse.
- Confirmation is not reconciliation
- A transaction that succeeded is not evidence that what was authorized is what happened. Reconciliation compares them movement by movement and records the difference when there is one.
Built around Stellar-native semantics
Three building blocks, each with the state the capability registry records for it rather than a logo.
Stellar RPC and Horizon
LiveAsset identity, issuer flags, trustlines, account state and network pulse. Every read records which source answered and when, and a read that fails states why instead of returning a default.
Stellar · USTRY · CETES · USDC · EURC
Read-only. The browser is not permitted to reach Stellar Mainnet at all.
Freighter Connect
LiveUser-controlled address, network and transaction signing through the official @stellar/freighter-api client, behind a provider-neutral adapter. Ryntra never requests a key or a seed phrase.
Stellar · XLM
Signing is refused outside Stellar Testnet, enforced in the header the site serves.
Soroswap Routing API
PlannedRoute discovery, quote and liquidity evidence for supported Stellar actions. No route provider is called today and no quote is fetched.
Stellar · XLM
Not integrated. Ryntra builds no router and would execute nothing on it.
What works now, and what is next
Four states, each read from the capability registry. Code complete, deployed, signed, settled, reconciled and verified are six different things, and this page keeps them apart.
Mainnet Asset Passport
Deployed and serving, read-only, over real Stellar Mainnet assets.
Owner-signed payment
One classic XLM payment on Stellar Testnet, reconciled against the ledger with balances moving exactly as authorized.
Verifiable receipt
That run’s receipt recomputes from a minified copy and re-reads the ledger from scratch.
Route evidence
Soroswap route and liquidity evidence. Nothing is called today, and no quote is fetched.
- Transaction
- 1cf2324346b95d8b350f8316e5aec76063bc827c45819bb7d8cecd4c1a45c95c
- Ledger
- 4,126,028 · closed 2026-08-13 · reconciled across four checks
- Scope
- One owner-signed classic XLM payment on Stellar Testnet: transaction 1cf23243…, ledger 4,126,028, closed 2026-08-13, txSuccess and paymentSuccess, reconciled MATCHED across four checks with balances moving exactly as authorized. Ryntra holds no key — the signature happens inside the owner's wallet and the submission goes from the browser to the public Stellar endpoint. Mainnet is not claimed and no other operation, asset or amount is proven. The submission path's ERROR branch is still unobserved: every refusal so far happened at the ledger, not at submission.
- Not claimed
- Mainnet execution, any other operation, amount or asset, and policy evaluation — which is why every receipt this product writes carries
policyVersionas null with the reason named.
One product, three ways in
The same evidence, the same lifecycle and the same receipt. What changes is the question being asked of it.
Understand what a token represents, which issuer powers apply to it, what holding it requires, and what stays unverified. Read-only and without connecting anything.
See issuer power, holding requirements and stated redemption before authorizing anything. The engine that turns those facts into an automatic decision is registered work and is not shipped.
The same Passport, preflight and receipt model over one evidence kernel. Every read, its source and what the adapter refuses are published in the workspace.
The decision trail, on a real asset and a real transaction
Nothing on this page needs an account, and the two things worth checking take a minute each.