Public evidence index › ERC-8004 endpoint observation
See what an outside archive actually observed about your ERC-8004 endpoint.
For an agent developer or small protocol team that controls one ERC-8004 identity and wants a dated record instead of a badge. The proposed pack reads our existing sealed census; it does not probe your infrastructure for the order.
ERC-8004 Endpoint Observation Pack is a proposed $249 one-time demand test: an archived HTTP response proves only that an endpoint responded at a point in time, never its controller, identity, capability, safety, uptime, ownership, reputation, or endorsement.
UNKNOWN.The proposed scope
$249 one time
One customer-named ERC-8004 identity; registry-event lookup across the chains already represented in our sealed census; registered URI history where observed; and a bounded appendix of existing transport observations. Delivery would be one dated PDF, its underlying CSV, and a file-integrity manifest.
What the three files would contain
Dated observation PDF
The cover names the supplied identity, the resolution performed, every chain checked, the requested observation window, and the archive gaps that apply. A table cell carries a dated observation or the literal word UNKNOWN with a reason. It never turns a missing row into zero, down, or pass.
Underlying CSV
One machine-readable row per retained observation, with the same dates, source class, transport outcome, and gap labels as the PDF. Column definitions travel with the file. The CSV contains no response body, credential, inferred controller, score, or ranking.
SHA-256 manifest
A list of the delivered filenames and their digests lets a recipient check that the files did not change after delivery. A matching digest proves byte identity only. It does not prove that a registry event is complete, an endpoint is trustworthy, or a statement inside a file is true.
The acceptance contract
Each row separates an observation that can pass from a question the archive cannot answer. The pack would not contain an overall pass score, liveness percentage, trust mark, or green verdict.
| Check | PASS means | UNKNOWN means | Always out of scope |
|---|---|---|---|
| Identity resolution | The supplied reference maps to one retained ERC-8004 registry record on a named covered chain. | No retained match exists, or public data cannot disambiguate multiple candidates. | Guessing which record is really yours or identifying a human controller. |
| Registry-event lookup | Dated events for that record are present in the sealed census on the named chain. | A provider-retention gap overlaps the relevant period, or the chain is outside the existing census. | Adding a chain or reconstructing history that the archive did not observe. |
| Registered URI history | One or more URI values were retained with observation dates. | No URI value was retained for the requested period or a change may fall inside a gap. | Inferring an unobserved transition, domain ownership, or authorization from a URI. |
| Transport appendix | Existing probe rows record a transport outcome on specific dates. | No row exists, the host was outside that day's bounded panel, or the probe could not produce an HTTP status. | New probing, continuous monitoring, an uptime calculation, or a present-tense liveness claim. |
| File integrity | Every delivered file digest matches the supplied manifest. | A missing file prevents the comparison. | Treating a matching digest as proof that the contents are correct or complete. |
A transport row records the observation as retained: for example, an HTTP status, a transport failure with no status, or a missing observation. It does not translate a 404 into a business-status judgment, a 5xx into an agent-capability judgment, or a 200 into proof that the advertised software performed useful work.
Archive and coverage boundary
Our public aggregate ERC-8004 endpoint archive is the proof-of-method surface for this offer. It explains the registry-event and daily transport-observation process, the deterministic daily host cap, and known chain-history gaps. The proposed pack would read the same retained corpus for one authorized identity. It would not create a private monitoring lane or bypass the cap.
Daily coverage is bounded
A host can be absent from a day's probe panel because the deterministic cap was reached. That date is UNKNOWN for the requested endpoint. It is not a timeout and not evidence of downtime. The pack would list covered dates and missing dates separately instead of calculating a misleading availability rate.
Chain history can be partial
A successful current chain read does not repair an older provider-retention gap. The suitability check names the chains and known gaps that overlap the requested window before an order can be accepted. If the identity is only on an uncovered chain, or the relevant history is unavailable, the request is declined.
URI history is observed state, not reconstructed intent
The pack can report URI values present in retained registry events and the dates attached to those observations. It cannot infer a change that fell between observations, prove that the registrant controlled the linked host, or conclude that a URI described an operating agent.
The standard is a source, not an endorsement
The identity vocabulary follows the public ERC-8004 specification. Linking the specification does not mean its authors reviewed this offer, our archive, or any delivered observation pack.
Data, authorization, and safety limits
Your identity only
The requester must control the named identity or hold written authorization from its controller. The service is not offered for competitor research, third-party surveillance, reputation dossiers, marketplace screening, or bulk lists of identities. Ambiguous control is a decline.
No new network activity
No endpoint request, port scan, vulnerability scan, fuzzing, authentication attempt, access-control bypass, load test, or continuous monitor is performed for an order. The endpoint appendix is a bounded read of rows that already existed in the archive before the scope request.
No keys or on-chain action
We do not accept a seed phrase, private key, signed challenge, wallet signature, bearer token, or API credential. The pack does not sign a message, submit a transaction, spend gas, mutate a registry, or claim proof of control. Public retained events are read only.
No private or personal content
Do not submit a private URL, response body, customer record, personal identifier, or nonpublic document. The proposed files contain transport metadata and public registry observations, not copied endpoint content. A URI that exposes personal data makes the scope unsuitable.
This is not a certification, assurance engagement, identity verification, legal opinion, security assessment, compliance report, uptime report, or marketplace endorsement. It is not designed to be presented as any of those. A buyer who needs proof of endpoint control should use a cryptographic challenge-response process instead.
Fit and no-fit
A reasonable fit
- You develop or operate one ERC-8004 identity and can confirm control or authorization.
- You want an outside, dated view of the registry and probe rows already retained.
- You can use explicit gaps and
UNKNOWNresults in an engineering record. - Your relevant chain and date window overlap the existing census.
- You want PDF and CSV evidence whose delivered bytes can be checked.
Not this service
- You want a verified badge, trust score, identity conclusion, ranking, or endorsement.
- You need real-time liveness, uptime monitoring, incident alerts, or an SLA.
- You need a penetration test, vulnerability review, or authenticated endpoint test.
- You want observations about an identity you do not control.
- You need an uncovered chain, reconstructed history, or a guaranteed complete archive.
A current HTTP check would answer a different, narrower question than this archive pack. A cryptographic challenge would answer another. A security assessment would answer another. Keeping those products separate is what prevents a dated transport row from turning into a false statement about identity or trust.
How the no-payment scope check works
- Name one public identity. Provide its exact identifier, the chain or chains you believe matter, the desired date window, and whether you control it or hold written authorization. Do not paste the authorization document into the form.
- We check archive suitability. A read-only preflight asks whether the identity can be resolved, the chains are represented, the window overlaps retained data, and enough observations exist to avoid selling a mostly empty pack. No new probe runs.
- You receive a scope answer. An acceptable scope names the chains, dates, deliverables, and known
UNKNOWNsections. An unsuitable scope is declined with the limiting coverage class. A request that needs clarification remains a question, not a pass. - Only a written scope can become an order. The proposed price is $249 for one identity. Payment is not available on this page. No file is promised and no delivery clock starts until both sides accept the written scope and payment clears.
- Acceptance stays mechanical. The PDF and CSV must contain the agreed identity, chain list, window, observation rows, and gap labels; all three file digests must match the manifest. Acceptance never depends on receiving a favorable result.
Frequently asked questions
Does PASS mean my agent is live?
No. PASS belongs to one row of the acceptance table and means the named observation exists. It does not describe the current moment and cannot establish who controlled the endpoint or what the software did.
Will you probe my endpoint for the pack?
No. The order creates zero new network requests to the endpoint. If the retained archive has no suitable rows, the transport appendix remains UNKNOWN and the request will usually be declined.
Why not call this verification?
Because a registry lookup plus an HTTP status does not verify a controller, capability, identity, or claim. The narrower word observation describes the evidence without inviting a buyer to treat it as a credential.
Can you cover an identity I do not control?
No. Control or written authorization is a scope requirement. We do not turn this archive into third-party surveillance or a competitive-intelligence report.
Does the manifest prove the observations are true?
No. It proves that the files a recipient checks are byte-identical to the delivered files. Source coverage, observation meaning, and completeness remain separate questions disclosed in the PDF.
What if a chain or date is missing?
It is named as UNKNOWN with the coverage reason. A missing source never becomes a zero, a down verdict, or a pass. If the missing portion defeats the requested purpose, the suitability check declines the scope.