SEP-24 · LEDGER
GABC••••••••WXYZ
READING LEDGER STELLAR
Reading the Stellar ledger $0

Ledger-derived counterparty evidence

Know who you're paying.

Software can now pay software on Stellar without a human in the loop. Nothing tells it who is safe to pay — only the domain's own description of itself, which anyone can edit in ten seconds. Landfall answers from the public ledger instead: what a counterparty has actually settled, how concentrated it is, whether funds pass straight through. For a wallet, or for an agent about to sign an x402 payment.

Check an address →▶ See how it works
Built from public records
Open methodology
Agent-readable
STELLAR LEDGER · LIVE SEP-24
Inbound settlements indexed 15,168
All history, not a window 108 accounts
Dark anchors 65 of 108
No on-chain settlement >30 days
landfall.stellar View all →
L
Landfall network scanUpdated from Horizon
Live
Anchors observed 108 declared accounts
Settling under 48h—
Silent over 30 days—
View settlement details →
◉ Ledger verified
↗ Public data
Designed for the people moving value on Stellar
Wallets Anchors Payment agents Researchers
!

Current finding · —: Loading live settlement data…

See the data →

Live from the ledger

Not a status page.
A settlement record.

Anchors can publish a reassuring message. They cannot edit their public payment history. Landfall turns that history into a clear, independently verifiable signal.

⌁

Network coverage

108 declared anchor accounts monitored

Fast settlement

— of observed accounts active in 48 hours

What we measure

Every
payment. Activity, silence, volume and returns — with transactions behind every number. Open dashboard →

Built for evidence

See what the ledger actually says.

01

Discover

We resolve the public accounts each Stellar anchor declares in its SEP-1 stellar.toml. No anchor supplies us with anything, and none can opt out.

02

Read

We index payment history directly from the Stellar ledger via Horizon, with no self-reporting. Under SEP-24, both deposits and withdrawals leave on-chain traces.

03

Route smarter

Wallets and agents get a clear signal — liveness, volume, refund rate, concentration — before choosing where to send a payment.

The difference

Observed, not interrogated.

Existing anchor monitors ask anchors questions and record whatever answer they give. Landfall reads the public ledger and measures what the anchor actually did.

Status endpoints
  • Ping an endpoint
  • Validate a TOML
  • Record the anchor's self-reported answer
  • A TOML can be faked in ten seconds
Landfall
  • Read the public ledger retroactively
  • Years of history on the first run
  • No permission needed, no opt-out possible
  • You cannot fake two years of settlement history
Liveness

Cannot be faked — an account with no activity for three days is not operating, whatever its status endpoint says

Deposit fulfilment

The anchor's outbound payments, amounts and timing

Refund rate

Value returned to senders — the distress signal no anchor advertises

Concentration

How much of the flow is one counterparty

What's actually running

Six surfaces, one ledger underneath.

Every page below reads the same indexed Stellar data. None of it asks an anchor anything.

Shipping

Transactions

Every indexed payment per anchor, each row linked to its transaction hash on a block explorer.

 Shipping

Trust Check

Paste a Stellar address or transaction hash. Ledger-only signals — history, concentration, forwarding pattern — plus reports other people filed, kept separate from the score, never blended in.

 Partly real

Route Scout

Compare anchors by reliability, fees, and rate — plus a verified-routing mode that ranks evidence ahead of price. Fee and rate figures are live where an anchor publishes them, catalogue estimate otherwise, labelled either way.

 Shipping

Every anchor

One permanent record per anchor — 27 tracked, 9 with a state change in the last 14 days — with the observed history behind every figure.

 Shipping

Cross-chain evidence

Settlement evidence across Stellar, EVM/CCTP, Tron and Solana, every figure labelled PROVEN, ATTESTED or DERIVED — never blended into one score.

 Shipping

API, SDK & MCP

A read-only REST + GraphQL API, an MCP server for AI agents, and @landfall/sdk — packaged and tested, not yet on npm.

For builders

One signal before every route.

Landfall is building a simple interface for wallets and payment agents to factor real settlement quality into their routing decisions.

Build with us → 
// @landfall/sdk — packaged, tested, not yet published to npm.
// Real signature: packages/sdk/README.md
const ranked = pickAnchor([
  { anchorId: 'alpha.example', summary: derivedSummary },
  { anchorId: 'beta.example',  summary: provenSummary  },
])

// evidence tier decides, never a blended score
ranked[0].anchorId   // "beta.example" — 12 proven beats 900 derived
ranked[0].tierMix    // "PROVEN 12 · ATTESTED 0 · DERIVED 0"
ranked[0].rationale  // "Ranked on 12 ledger-proven settlement(s)."
What we can't see

A low return rate is not a clean bill of health.

A return is the honest failure mode. When an anchor can't complete the off-chain leg of a withdrawal, sending the asset back is what a good actor does — and that return is visible on the ledger.

An anchor that accepts value, fails to settle, and simply keeps it produces no return event at all. It scores a clean 0.00% — identical to an anchor that never fails.

So 0.13% isn't reassurance. It's the absence of one specific kind of evidence, and we'd rather say so than let a number flatter us. Closing that gap needs the fiat leg, which means signed settlement attestations. That's what we're building next.

FAQ

Questions people actually ask.

Where does the data come from?

Public Stellar ledger records, via Horizon. Anchor accounts are resolved from each domain's SEP-1 declaration. No anchor supplies us with anything, and none can opt out.

What if you get a figure wrong?

Every number ships with its transaction hashes, so a disagreement is settled by checking the ledger rather than by argument. We've already published two defects we found in our own tool during verification, including what the numbers were before and after.

What stops a wrong figure being published in the first place?

A scan is checked against the previously published one before it can replace it, and a failure withholds the update rather than shipping it. The checks reject an on-chain account claimed by two different anchors, rows belonging to no anchor, and payment counts that move implausibly between scans. They are the reason we caught crediting a shared stablecoin issuer to a single named business — the account was being attributed to two anchors at once, which is now a blocking error rather than something only luck finds. Stale data is visible to you; a misattributed figure is not, so we withhold rather than publish. The checks are in the open, as is what each anchor's accounts were verified against.

Is "dark" the same as "fraudulent"?

No, and we're careful never to imply it. Dark means the account has processed no on-chain settlement in over 30 days. That's a fact about the ledger. Why an anchor is quiet is not something we claim to know.

I run an anchor and I think you're wrong.

Get in touch. Bring the account and the scan date; we'll check it against the ledger together. If our method is at fault we fix it publicly and say so. Scores are not for sale, in either direction.

Is it open source?

MIT, entirely. Indexer, metrics, methodology and this site. A reputation system that can't be audited has no claim on anyone's trust.

What is the Soroban oracle?

A deployed Soroban contract on testnet that publishes a digest of each dataset plus a per-account liveness state, so other contracts can route on the same data a wallet reads from the API. It stores a digest rather than the dataset because anyone can re-derive the digest from the published data and check the two agree.

Early access

Help make settlement more visible.

Building on Stellar? We would love to hear what routing information would make your product safer and more useful.

Lagos, Nigeria
In the corridor we measure.

Opening a pre-filled GitHub issue with your message — press submit there to send it.

There is no mail backend, so this opens a pre-filled GitHub issue instead of pretending to send. Anchor disputes get priority. Security problems should go to a private advisory, not a public issue.