Skip to main content
Before your agent pays an endpoint again, it can weigh whether that endpoint has produced acceptable payment-layer outcomes for it — not from a merchant’s claim, and not only from a shared network rate, but from your agent’s own ledger of captured payments and HTTP statuses (tier-1 proxy today). That reading is First-Party Transactability.
This is a Developer Preview signal. 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.
Posture: auditable telemetry, not belief. Prefer first-party when present; treat network as a broader prior; use divergence rather than blending.

​
The two tiers

First-Party Transactability is the authoritative half of a two-tier signal when your ledger has evidence. Its sibling is the network-wide Transactability Index. Both are SELAT-observed payment-layer outcomes (capture + status) — never a merchant self-report. The Router strips merchant-supplied index blocks. The tiers differ by population and locus, not by magical trustworthiness. When they disagree, first-party wins because it is your usage (inputs, rails, recency) — not because the network reading is forged by default. Keep weighing network as a broader prior.

​
How your agent reads it

First-party appears in quote.transactabilityTrace:
  • attribution.counterparty.firstParty — your ledger: settled captures, counterparty 5xx after capture, and a success / capture rate (not delivery proof).
  • primarySource — first-party when your ledger has evidence, else network. Never blended.
  • divergence — compares the two (present even when they agree).
Attribution: charge the endpoint for 5xx after capture; do not degrade its rate for your 4xx or pure 402/settlement failures. See Decision trace.

​
Reading it today

Network score reading is free. First-party exists only after this wallet has paid the endpoint.
There primarySource names the driving tier. First-party evidence also feeds the CLI’s soft reliability factor and optional pick-time quarantine — demotion/skip, not delisting from the catalog. Unmeasured endpoints stay visible and payable. Note: settled-body-lost is charged as a failure (not success) for that factor after selat-discovery#157 — conservatively against the endpoint today; may be path/SELAT/LP on mediated rails. The factor remains a ranking prior (Bayesian shrink to 1.0), not a calibrated delivery posterior.

​
Why first-party is authoritative when present

  • Closest proxy for your next call (your inputs, rails, recency).
  • Exists only after you actually paid and SELAT recorded the payment-layer outcome.
  • Private ledger on your machine.
  • Correctly attributed: endpoint 5xx vs your 4xx vs rail 402. Refunds follow capture, not the status code — see Decision trace.

​
Honest limits

  • Cold start. No first-party until you have paid. Network fills the gap; unmeasured ≠ bad.
  • Signal, not recommendation. You set gates (minimum n, rate floor, quarantine policy).
  • Split clocks. Evidence informs the rate for 90 days; pick-time quarantine uses recent charged failures only (default 30 days, selat setup-policy --quarantine-days). Older failures can still move the rate without excluding the endpoint forever.
  • Tier-1 numerator. Until Receipt-bound or settle-after-delivery attestation ships, rates remain 2xx-after-capture proxies, not body-quality or delivery proof.