Transactability Index

The Transactability Index publishes a narrow signal on the payment challenge before your agent decides whether to spend: what SELAT observed after captured payments on calls it routes. It is not a merchant self-assessment, and it is not proof that the response body was correct, complete, or useful. Posture: make the index auditable, not believed. Nothing structural stops a buy-side observer (SELAT included) from selective sampling. Prefer your own ledger and a direct probe / native Credential→Receipt path when you need an independent check. A network score is not a reason to skip native rails.

This is a Developer Preview signal. Field paths under selatTransactabilityIndex may change during preview. Read for meaning, not as a frozen wire contract.

Claim surface (tiers)

Tier	Predicate	May say
1 (ships today)	2xx-after-capture — HTTP status after payment captured	`successRate` / paid+acked proxy
2	Receipt-referenced capture (MPP `Payment-Receipt` / equivalent settlement `reference` on a named hop)	payment ack + dispute handle — still not body quality
3	Settle-after-delivery + signed delivery artifacts	”delivery” language

Until tier 3 exists, docs and agents must not say delivery %, delivered, or failed to deliver. Today’s numerator is tier 1. If only one successRate appears on the 402, treat it as LP→merchant payment-layer telemetry (tier-locked) unless the payload names another hop. Buyer→SELAT/LP clearing reliability is a separate credit exposure and may be unpublished.

Where it appears

Each endpoint’s score rides the inbound 402 Payment Required challenge that the SELAT Router returns to your agent, under extensions.selatTransactabilityIndex. The same extension shape can appear on x402- and MPP-routed challenges; evidence quality is rail-specific. Abstracting both rails down to status codes is a weaker proxy than MPP’s Credential→Receipt chain — not “works the same.”

Wire example (illustrative — not a reliability teaching exhibit)

successRate is a fraction string: "1" means 1.0 (100%), not a count of ones. Always read it with paidNum. Thin n stays low-confidence even at 100%.

"extensions": {
  "selatTransactabilityIndex": {
    "info": {
      "description": "payment-layer outcome telemetry for agent payment",
      "version": "1",
      "docs": "https://selat.ai/docs/transactability",
      "healthStatus": {
        "endpointUrl": "https://.../example/endpoint",
        "timestamp": "1787470911",
        "lastPaid": { "status": "200", "timestamp": "1787462218" },
        "stats": {
          "24h": { "successRate": "0.96", "paidNum": "25" },
          "7d":  { "successRate": "0.98", "paidNum": "180" },
          "all": { "successRate": "0.97", "paidNum": "900" }
        }
      }
    }
  }
}

Treat windows with very small paidNum as insufficient evidence, not a green light — even if successRate is "1". A window with no data is omitted; empty stats / lastPaid means unmeasured on that surface. Wire vs ranking: the challenge may carry 24h / 7d / all. SELAT discovery’s ranking parser currently prefers 7d → 1w → 24h and does not read all, and caps index paidNum weight at 50. Do not tell agents that ranking “prefers all / unbounded larger n” — that is not what the spend path consumes today.

What each reading means

Paths are relative to info.healthStatus.

Field	What it tells you
`lastPaid.status`	HTTP status of the most recent payment attempt on this endpoint — captured or not.
`lastPaid.timestamp`	Unix time of that most recent attempt.
`stats.<window>.paidNum`	Payments that captured inside the window. Not requests attempted.
`stats.<window>.successRate`	Share of those captures answered with a `2xx` (tier-1 proxy). Wire value `"1"` = 1.0 (100%).
window keys	`24h`, `7d`, and/or `all` when present.
`endpointUrl` / `timestamp`	Endpoint described, and when the reading was generated.

Forthcoming (may not be on every challenge yet): named hop + whose reference, coverage (e.g. pct_with_reference for tier 2), status (unmeasured | insufficient | scored), intervals/posteriors, methodology_version / as_of, and three readings (network / firstParty / divergence) on the challenge itself. Until those ship, use the decision trace + local ledger for first-party and divergence.

How to read it safely

Unmeasured ≠ bad. An endpoint with no score has not been observed settling through SELAT. It remains visible and payable in the federated catalog — it simply has no risk score yet. Never treat a missing signal as a negative one.

successRate is transport-level after capture. It does not mean the payload was correct, complete, or useful.
Read successRate with paidNum. Never treat bare 100% on tiny n as a reliability signal.
A 5xx after capture is a counterparty-side payment-layer failure (money out, non-2xx). A 4xx usually means the request was rejected and often that the upstream was never paid — see attribution in the decision trace; do not charge that to the endpoint’s network rate.
The score reports what was observed. It does not recommend an action or substitute for your policy.

How discovery uses it (and how it doesn’t)

selat search "…" --top N ranks primarily by intent match, price, and source-count — not by sorting the catalog on Transactability. Unmeasured endpoints stay in the list. Separately, the CLI may apply a soft reliability factor (and optional pick-time quarantine) from cached Index observations + your local ledger. Primary rank weights stay semantic 0.65 / price 0.25 / source-count 0.10; then combined *= factor when evidence exists.

factor = (successes + 3) / (trials + 3) shrinks toward 1.0. No evidence → factor 1.0 — mathematically the same as “perfect” for demotion purposes. Thin all-success histories barely move the score; only failures pull it down. This is not a calibrated posterior of delivery or body quality.
Own-ledger trials weigh 2× network index trials. Ledger settled-body-lost (money out, body gone) is not a success: as of selat-discovery#157 it increments chargedFails / can quarantine. That is buyer-protective attribution — on mediated/two-leg paths the loss may be path/SELAT/LP, not proof the merchant returned empty. Do not read this as body-quality or delivery scoring.
The factor is hop-blind (capture+status / settled vs 5xx) — it does not name buyer→SELAT/LP vs LP→merchant.
Quarantine demotes/skips on strong failure patterns (floor 0.05) — not delisting. See First-Party Transactability.

selat search "web search" --top 3 --explain
selat run "web search" --dry-run --live-probe

Reading the network score is free (no wallet). A live probe may invoke the target — only probe endpoints you have confirmed are safe to call. Any HTTP client can decode the block from the Router’s payment-required header:

curl -si "https://router.selat.ai/proxy?target=https://x402.alchemy.com/prices/v1/tokens/by-symbol" \
  | grep -i '^payment-required:' | cut -d' ' -f2 | base64 -d \
  | jq '.extensions.selatTransactabilityIndex.info.healthStatus'

Authorship and audit

Prefer scores from the SELAT Router (router.selat.ai or another SELAT-owned origin). The Router strips merchant-supplied selatTransactabilityIndex blocks so agents are not fed self-attested perfection. That is authorship hygiene, not proof the index cannot be wrong or selectively sampled. Trust boundary (discovery): by default a non-SELAT / non-authoritative index is condemn-only (can demote, cannot exonerate above your own ledger). Two-way trust requires the router envelope header x-selat-index-authoritative (selat-router | sole | true | 1), a SELAT-owned origin, or an explicit env override (SELAT_INDEX_ROUTER_SOLE_AUTHOR). Sole-author is a deployment claim, not a protocol guarantee. Index paidNum used in ranking is capped at 50. When you curl yourself, treat a block served straight off a merchant endpoint as non-authoritative unless you have an independent verify path.

As structured data

For logging, gating, and audit, use quote.transactabilityTrace (network vs first-party, never blended; attribution buckets). See Decision trace and First-Party Transactability.

Why it exists

Every paid call is a small credit decision: the buyer commits value before knowing the payment-layer outcome. Payment rails price and settle; they do not, by themselves, publish comparable buyer-side histories of capture→response-status (or Receipt-referenced) outcomes. This Index supplies a narrow input to that decision on SELAT-routed calls. It does not supply delivery proof, content-quality scores, or an ungameable reputation monopoly.

Overview

Agentic payments