Endpoint

B

scvd.store/api/buy/attestation_bundle

· score 77/100 · recomputed 48m ago

Task: Prove a whole run of payments settled, one signed receipt per transaction. Returns: Two to twenty signed JSON observations, one per Base transaction hash supplied, each carrying the same fields and independent signature as the single settlement attestation — plus a certificate binding a sha256 digest of the sheaf's evidence hashes, so one verify URL answers for all of them. Instant. Price: $0.05 USDC (x402 v2; network from the current quote). Latency: delivered in the purchase response, same request. Verify: GET /api/verify/{id} — free, unlimited, forever (live sample: cert_4dww28dx5j). Constraints: Give 2 to 20 Base transaction hashes in the tx_hashes query parameter, comma-separated, no duplicates; Each hash is observed once and signed on its own; the bundle is a purchase shape, not a different artifact; Observes settlement only, never delivery; One read per hash at one moment; no polling, no retry, no second look; Per-hash narrowing (payer, recipient, nonce, amount) is the single attestation's feature; the sheaf takes hashes only. A Sheaf of Attestations, Up to 20 settlement attestations in one purchase. Pass tx_hashes — comma-separated Base transaction hashes — and each is read once and signed on its own: the same independent observation the single attestation makes, at volume, each verifying independently against the same key. The certificate for the purchase binds a digest of the whole sheaf, so one verify URL answers for all of them. Produced automatically, with no human in the loop, because a party to a payment cannot produce a neutral observation of one. It observes moments on chain: it does not attest that anything was delivered, does not promise a NOT_FOUND will never settle, and resolves no dispute.

NEW_UNKNOWN
First seen
5d ago
Probes stored
3

Score

B
77 of 100
recomputed 48m ago

The score is built from observations we collect ourselves: how the endpoint responds, what the envelope contains, how stable the price and the recipient are, who pays and how often. It is deterministic — the same input always produces the same result.

We do not publish the exact methodology yet. If you own this endpoint, write to us and we will show you, item by item, what drags the score down.

Recent probes

WhenCodeLatencyScheme and network RecipientPriceFindings
4h ago 402 40 ms exact
eip155:8453
0xDD35…9bd0 0.050000 clean
4d ago 402 26 ms exact
eip155:8453
0xDD35…9bd0 0.050000 clean
4d ago 402 27 ms exact
eip155:8453
0xDD35…9bd0 0.050000 clean

Reference

URLhttps://scvd.store/api/buy/attestation_bundle
Sourceswell-known
Recipient per catalogue0xDD350976B8cfFc65938C0464d39A2C78BE079bd0
Price per catalogue0.050000
Machine access/v1/endpoint · /full · badge

Is this your endpoint?

The score is built only from public observations. If something we recorded is wrong — say our prober hit you during maintenance — write to us. We will recheck and publish your reply next to the score.

We do not delete accurate observations. The prober makes at most one request per second per host and only asks for the payment challenge — it never pays and never takes content.

Next

Market overview →

Payments, median ticket, who pays whom, who settles.

Wallets →

Payers, recipients and facilitators, listed separately.

Facilitators →

Who actually settles — including those in no public registry.

API →

Verdict before payment, seller and wallet scores, market aggregates.