Skip to main content
Before your agent pays an endpoint again, it can know whether that endpoint has actually delivered for it — not from a merchant’s claim, and not from a shared reputation score, but from your agent’s own settled payments. That reading is First-Party Transactability.
This is a Developer Preview signal. The reading and its meaning are stable; exact field paths may change during preview. The agent is the reader here — it consumes this at runtime to decide whether to spend. You own the wallet, the funds, and the ledger it is computed from.

​
The two tiers

First-Party Transactability is the authoritative half of a two-tier signal. Its sibling is the network-wide Transactability Index. Both are SELAT-observed settlement — never a merchant self-report. SELAT does not fetch a score from any merchant; the router emits the Index from SELAT’s own settlement-delivery data and strips any merchant-supplied index off the 402 challenge. So the two tiers differ by population and locus — all buyers in SELAT’s record versus your agent’s own payments in your own ledger — not by trustworthiness. When the two disagree, first-party wins — because it is your agent’s own usage (your inputs, your rails, your recency), not because the network reading is suspect. The network reading stays worth weighing as a broader prior.

​
How your agent reads it

First-Party Transactability appears in the same decision trace SELAT computes from the 402 challenge (plus your local ledger), under quote.transactabilityTrace. Inside it:
  • attribution.counterparty.firstParty is the reading from your own ledger — settled payments, 5xx delivery failures, and a deliveryRate.
  • primarySource names which reading drives the decision. It is first-party whenever your ledger has evidence, otherwise network. The two are never blended.
  • divergence compares the network-wide and first-party readings and marks whether they agree (it is present even when they do, with agree: true), rather than averaging them away.
Failures are attributed to whoever caused them, so first-party reliability reflects only the endpoint: a 5xx (the upstream captured payment and failed to deliver) counts against it, while your agent’s 4xx requests and 402 settlement failures are surfaced separately and never charged to the endpoint. See the Decision trace reference for the full trace shape.

​
Reading it today

Reading the network score is free — discovery and probing require no account, wallet, or spend. First-party data is different: it exists only after this wallet has settled calls to the endpoint. Until then a probe shows the network reading (or unmeasured), never a first-party one. Preview a pick with the SELAT CLI:
The dry run ranks a pick, probes it without paying, and prints the Transactability Score line — the network reading from the 402 challenge. For a generic intent the score is often unmeasured; to read a specific endpoint’s score, pin it (--endpoint, --method, --param) or copy the ready-made probe command selat search prints for a ranked pick. The first-party reading lives in the machine-readable decision trace, which SELAT computes from the 402 challenge plus your local ledger. Add --json to the same free dry run (selat-cli 0.16.12+) and it arrives as transactabilityTrace:
There primarySource names which tier drives the signal — first-party whenever your ledger has evidence, else network — and the two readings sit side by side, never blended. First-party evidence also shapes ranking directly: your own settled payments and charged failures weigh into every pick selat run and selat search make, even though the one-line score prints the network view.

​
Why it is the authoritative tier

  • It is your agent’s own usage. Same endpoint, but your inputs, your rails, and your recency — the closest available proxy for what your next call will actually get.
  • It cannot be forged or self-reported. It exists only once your agent has actually paid and SELAT recorded what settled.
  • It is private. Because your agent pays from the wallet you own, the ledger is yours, on your machine — SELAT never holds it.
  • It is attributed correctly. Only the endpoint’s 5xx counts against it; your agent’s 4xx are refundable (the upstream was never paid); 402 is a rail issue.

​
Honest limits

Cold start. Only endpoints your agent has already paid have first-party data. For everything else the network Transactability Index fills the gap — that is the point of the two-tier model, not a weakness to hide.
  • It is a signal, not a recommendation — your agent applies its own bar (a minimum sample, a deliveryRate floor, no recent 5xx).
  • Absence of first-party data means unmeasured, never bad: an endpoint your agent has not paid is simply one you have no first-party history for yet.
  • Memory and punishment run on separate clocks. Settled history informs the reading for the full 90-day evidence window, but pick-time exclusion (quarantine) is driven only by recent charged failures — an endpoint whose recent payments all burned is excluded until that record ages out of the quarantine window (default 30 days, tunable with selat setup-policy --quarantine-days) or a payment settles again. Older failures keep informing the rate; they just stop excluding.