Anchors, and why an asset is a claim
Stellar assets other than XLM are issued by accounts. A US dollar token on Stellar is a liability of whoever issued it, redeemable with that issuer — the anchor — for actual dollars.
This means the identity of the issuer is not a detail, it is the asset. Two tokens both called USDC, issued by different accounts, are entirely different things with entirely different backing. One may be redeemable; the other may be worthless.
StellarExpert maintains a directory of known issuers and flags assets accordingly. Given how trivially an asset code can be reused — anyone can issue a token called anything — that directory is doing real protective work.
The practical rule, which mirrors token checking on every other chain: verify the issuer account, not the asset code. On Stellar the stakes are slightly higher, because the asset code is prominent and the issuer is easy to overlook.
Path payments: the feature nothing else has
A Stellar path payment lets you send one asset and have the recipient receive a different one, with the conversion happening atomically through the network's built-in order books and liquidity pools.
Send euros, the recipient receives dollars, and the route — possibly through several intermediate assets — is found and executed in a single operation. If no route exists at an acceptable rate, the whole thing fails and nothing moves.
This is the feature Stellar was designed around, and it explains the architecture. There is no smart contract involved; the conversion is protocol machinery.
StellarExpert shows the full path taken. That matters because the rate you received depends on the route, and the route is chosen at execution time. A payment that cost more than expected has its explanation in that path, and nowhere else.
Trustlines and reserves
As on the XRP Ledger, you must explicitly open a trustline before you can hold a Stellar asset. Unsolicited token spam is therefore structurally impossible — a genuine advantage over account-model chains where anyone can push anything into your address.
Each trustline consumes part of your account's reserve requirement. Stellar requires a base reserve to keep an account alive plus an additional reserve per entry — trustlines, offers, data entries, signers. That XLM is not spendable while those entries exist.
StellarExpert separates total from available balance and lists the entries consuming reserve. When a transfer of your "full balance" fails, this page is the explanation.
Memos deserve the same warning as XRP destination tags: exchanges use a shared deposit address and distinguish customers by memo. Send without it and recovery means a support ticket. StellarExpert shows the memo field prominently, which is the right decision.
API and Horizon
StellarExpert offers a public API without a key, built on top of Horizon — Stellar's own API server, which anyone can run and which several public instances expose free.
That layering is worth knowing. For raw ledger data, query Horizon directly; the documentation is good and public instances need no key. For enriched data — issuer directories, asset ratings, aggregated statistics — StellarExpert adds a layer Horizon does not have.
Running your own Horizon instance is realistic. Stellar's ledger is considerably smaller than Bitcoin's or Ethereum's, and Horizon is designed to be operated by anyone. For an application with meaningful volume that is the sensible path, and it removes the third party entirely.
What our reference tests showed
Our Stellar reference items were a plain XLM payment, a payment with a memo, a path payment converting between two assets, an asset from a known anchor, and an account holding several trustlines against its reserve.
All five rendered correctly. The memo appeared as its own prominent field rather than buried in transaction details, which is the presentation decision that prevents the most expensive user error on this network.
The path payment was the interesting one. StellarExpert showed the full route taken, including the intermediate asset, and the rate achieved at each hop. Working out from that why the received amount differed from a naive expectation took about twenty seconds. On a multi-chain explorer that merely indexes Stellar, the same transaction appears as a transfer with a slightly odd amount and no explanation available anywhere on the page.
The anchor directory correctly identified the known issuer and flagged a deliberately-chosen lookalike asset with the same code from a different issuer as unrecognised. That is exactly the protective behaviour the directory exists for, and it worked without us having to know what to look for.
The reserve accounting was clear: total balance, reserved amount, available amount, and the list of entries consuming reserve. We confirmed the arithmetic against the protocol's current base and per-entry reserve values, which the page also showed rather than assuming a figure that may have changed by validator vote.
The gap, consistent with our verdict, was historical. Asking how an asset's supply or an anchor's issuance had moved over the preceding year is not a question this interface answers well.