Developer & Wallet API

// Click "Run Live Check" above to test against the live ledger

Fetch Corridors Matrix ⚡

// Click above to fetch cross-asset corridors

Regenerated by scripts/cross-chain-scan.ts on the scheduled scan (cron asks hourly; GitHub runs it best-effort, measured median ~2.8h). Each anchor carries its tier mix, a per-chain state (observed / empty / unresolved / failed — kept distinct, because "no address curated for this anchor on Base" is not the same claim as "it settled nothing there"), per-asset volumes, and sample STP attestations with a reproducible SHA-256 digest.

One anchor's complete record: every declared account with its current state, how that attribution was established, per-account observation history, and the caveats that apply. Rendered for humans at /anchor/{domain}.

The network time series — one observation per scan of how many tracked accounts were settling, slow, dark, or without payment history. Points are appended, never rewritten. A scan that failed verification leaves a gap rather than an interpolated value, because a missing hour is honest and an invented one is not.

Which on-chain accounts each anchor declares as its own, and on what basis. Attribution comes from the anchor's own SEP-1 stellar.toml; an account cited there only as a currency issuer is included solely when that issuer account's own on-chain home_domain confirms the claim. Every scan is additionally checked for an account claimed by two anchors before it can be published — a check added after a shared stablecoin issuer was found credited to a single named business.

The dataset root for the current scan, the record count, and the methodology id — a hash over every parameter that changes the numbers without the ledger changing (record cap, dust floor, refund window and tolerance, liveness thresholds). When that id moves, the method moved, so you can tell "the anchor changed" from "they changed how they measure".

One account's record, its index, and the sibling path proving it sits under the dataset root. Verification is four steps and needs only SHA-256 — canonicalise the record per RFC 8785, hash the leaf as SHA-256(0x00 || namespace || 0x00 || bytes), walk the path with SHA-256(0x01 || left || right), compare to the root. The steps ship in the response.

Every SEP endpoint each tracked anchor declares, and whether it answered when asked — with latency and the reason for any failure. One unauthenticated GET per declared endpoint, to the public /info path each SEP defines. SEP-10 is judged on answering a bare challenge request at all, since HTTP 400 is the correct response there and scoring it as a failure would punish correct behaviour.

The question a wallet actually has: "my user is in Nigeria and wants naira — who can do that, and which of them is working right now?" Joins three things that previously had to be joined by the caller: the currencies an anchor declares, whether its endpoints answered, and whether it has settled on-chain lately. Routes are ordered by evidence — endpoints answering plus a recent settlement outranks endpoints answering plus a long silence, which outranks a declared corridor with a dead API. Each route carries that evidence inline, so a consumer who disagrees with the ordering can impose its own.

A stellar.toml is mutable and unsigned. An anchor can rotate its declared accounts, repoint a transfer server, or change the issuer behind a currency code at any moment — and every wallet reading SEP-1 will follow, because following is the point of the standard. Nothing else records that it changed. This keeps a snapshot per anchor and reports the difference, with a Horizon lookup on any newly declared account so an account with years of history and one created yesterday can be told apart. A diff cannot distinguish a routine rotation from a hostile one and never claims to; severity reflects what a change could cost someone who follows it.

Settlement per asset instead of per anchor. An anchor can be settling hourly in one currency and dark in another, and a single per-anchor verdict hides it — zeam.money is currently settling in ZARZ and GBPZ while USDZ, EURZ and USDC are dark. Counts, volumes and counterparty spread are measured; per-asset liveness is inferred from the account carrying the asset, because the scan timestamps activity per account rather than per asset, and every liveness object says so in its basis field.

The result of every pre-publication check, written whether it passed or failed, naming the rule that tripped and the accounts involved. Blocked runs matter most: the site keeps serving the previous figures, so without this the only public evidence that anything happened is an hour of unchanged numbers. Withholding an update is itself a claim about the data, and it should be as inspectable as the data would have been.

Submits a claim: { chain, reference, respondent, outcome, reportedAmount?, note? }. Returns eligible immediately for the two rules that don't depend on the transfer's own timestamp — a sender's own report, or a "not received" outcome, can never bind, and this says so right away rather than accepting the submission silently. The timing rules are checked later, when the next cross-chain scan processes the transfer. 409 if this transfer already has a confirmation — there is no update path, by design.

Reads back what was submitted for one transfer, if anything.

Per anchor, per corridor: ok with the sampled price when the anchor runs SEP-38 and its own /info lists that corridor; otherwise no-sep38, unreachable, unsupported-corridor, or unsupported-asset, each with a reason. As of this writing, most tracked anchors fall into the first category — SEP-38 adoption among them is genuinely close to zero, which this endpoint states rather than papering over with the catalogue figure and no disclosure. Route Scout falls back to the catalogue spread exactly where this reports anything other than ok, and the card says which one it used.

Accepts a Stellar public key directly, or a transaction hash (resolved to its source account). Returns observed account age — a lower bound only, since Horizon does not retain full history forever — counterparty concentration, a pass-through/fast-forwarding signal, a transparent 0–100 score built from fixed, documented per-flag deductions, a risk level, and a confidence rating that overrides the score when there simply isn't enough observed history to say anything ("unknown" beats a number computed from three payments).

// Click "Run Live Check" above to test against the live ledger

Body: { from, to, basis: "send"|"receive", amount, midRate, candidates[], sortBy?, minGrade?, requirePricedTerms? }.

What the caller supplies, and what it cannot. Commercial terms — rate spread, fees, payout speed — come from the caller, because they are each anchor's own published figures, not Landfall's; the tracked anchors' current ones are republished at /api/v1/anchor-fees.json and /api/v1/anchor-quotes.json for exactly this. The reliability grade is overwritten from Landfall's ledger scan on every request, whatever the caller sent. A route-ranking API where the ranked party supplies its own score is not a ranking API — that asymmetry is the point of the endpoint. midRate is required rather than defaulted: Landfall carries no FX feed and will not invent one.

Body: { subject, evidenceTxHash, category, note, reporterAddress? }. Categories: did_not_receive, wrong_amount, impersonation, unauthorized_debit, other. Returns 400 if the cited transaction does not exist or does not involve the subject; 409 if you have already filed on that transaction.

Reports filed about one address, with the disclaimer attached to the payload rather than left to the client to remember. Withdrawn and rejected reports are excluded. Zero reports is reported as absence of evidence, explicitly not as a clean record.

Per account: current run (state, observations, days, and everChanged — which separates "dark for 26 days" from "dark for as long as anyone has been looking"), every observed transition with its date, and a volume direction derived from the delta in cumulative counters rather than their size.

It does not forecast. Across every account and every stored scan, zero transitions into the dark state have been observed — every dark account was already dark when first seen. A "this anchor is about to go dark" warning needs examples of anchors going dark, and this dataset contains none. What is reported is what happened.

Add Landfall to your Claude Desktop or Cursor configuration:

{
  "mcpServers": {
    "landfall": {
      "command": "node",
      "args": ["scripts/mcp/server.mjs"],
      "env": {
        "LANDFALL_API": "https://landfall-chi.vercel.app"
      }
    }
  }
}