# IMD public website and API: verified QA findings

Investigation: 2026-09-25 UTC; recorded live HTTP probes ran from 07:22:31 to 07:33:11. Black-box, unauthenticated, read-only testing of the live public deployment. The control-plane commit was `01895a4a10413e69c80e38691c19d5561387ed85` ([version response](evidence/006.body)); the docs snapshot says it was last checked against `23659b86` on 2026-09-23. This report does not certify the whole service.

Five reproducible defects or documentation mismatches are recorded below, plus one verified security-hardening observation. No critical or high-severity vulnerability was established. Suspected issues and contract ambiguities are separated from verified defects.

## Evidence, method, and coverage limits

- [Request journal](evidence/requests.jsonl): exact URL, method, supplied headers, UTC start time, HTTP status, response headers, duration, and saved body for every recorded direct HTTP request. Unless specified, calls are **GET, no body, no authentication, no Origin header**. Reproduce them with `curl -i 'EXACT_URL'`; the journal retains even the full 8,192-character query.
- 270 recorded direct HTTP attempts, one additional web-reader open of the docs, and at most one interrupted in-flight probe: a conservative upper bound of **272 public HTTP requests**. Direct probes were serialized with at least 1.1 seconds after the previous response finished. Browser resource requests went through the same recorder or used saved responses; denied browser requests did not reach the public hosts. No parallel crawl, load test, POST, transaction, signature, enrollment, or credential guessing was performed.
- [GET route matrix](route-coverage.md) covers all **55 public documented GET table entries** plus the authenticated paid-order GET tested only for rejection. This means route-family coverage, not all IDs, nested fields, state transitions, or parameter combinations. Invalid pairing-code testing used the explicitly malformed string `qa-invalid-code`; no valid codes were searched for. Successful CCIP/ENS resolution, successful assessment-document retrieval, and a valid pairing-state read remain untested.
- All three `imd.fun` entry pages returned HTTP 200. **No Vercel checkpoint blocked imd.fun in this run.** Some linked third-party pages were blocked; exact URLs/statuses appear below. These are access limitations, not proven dead links.
- The docs' 34 fragment links and token page's `#swap` resolved to existing IDs in the retrieved HTML: [anchor checks](evidence/anchor-checks.json). Entry pages, the four main explorer listings, representative job/agent/oracle-job detail pages, filter links, second pages, and one published report/download flow were tested. Exhaustive traversal was impossible within 300 requests: `/agents` alone exposes 528 distinct hrefs. The [link inventory](evidence/link-inventory.json) contains 996 discovered URLs, including third-party-page links, and identifies the 40 exact linked URLs fetched; API and asset probes are additional journal entries. Untested inventory entries are not implicitly passing.
- Mobile: existing Chromium, viewport **390 × 844, device scale 1**, using public HTML/CSS/JS fetched by the recorder. [Initial browser results](evidence/browser-results.json), [repeat results](evidence/browser-offline-confirmation.json), and PNGs preserve observations. To isolate CSS, pagination was also reproduced with scripts disabled and saved HTML/CSS: [CSS confirmation](evidence/browser-css-confirmation.json), [bottom-of-page confirmation](evidence/browser-pagination-bottom.json). Third-party RPC, market-data, wallet requests, unsampled API requests, and RSC prefetches were blocked by the test harness. Wallet flows, live polling, and third-party widgets therefore are **not validated**, and harness-generated console failures are not product findings. Browser snapshots replay live responses from different recorded times, so numeric comparisons below use fresh direct HTTP responses instead.
- Raw bodies are response-decoded bytes (e.g. gzip removed by the HTTP client); original transport headers are in the journal. Browser timings include deliberate throttling and are not performance measurements. Evidence is public material, stored as data, not executed as local commands.

## VERIFIED defects and mismatches

### F01 — Malformed job and launch UUIDs cause 500s and expose SQL diagnostics

**Severity: medium.** Impact: a simple bad link or client typo becomes an apparent server outage and discloses database schema/query details to any unauthenticated caller.

Exact reproductions:

```sh
curl -i 'https://api.imd.fun/jobs/not-a-uuid'
curl -i 'https://api.imd.fun/launches/not-a-uuid'
```

Observed twice for each route: HTTP **500**, `error: "internal_error"`, and a `detail` string containing the SQL SELECT, table and column names, bound input, and PostgreSQL UUID conversion failure. The job response ends with:

```text
from "jobs" where "jobs"."id" = $1
params: not-a-uuid (cause: invalid input syntax for type uuid: "not-a-uuid")
```

The launch response similarly reveals the `launches` query. This is SQL/debug disclosure; no stack trace, secret, SQL injection, unauthorized record access, or denial-of-service exploit was demonstrated.

Expected: HTTP **400** with a stable invalid-ID error, without internal query diagnostics, following [docs → Errors](https://imd.fun/docs/#errors). The neighboring `/workflows/not-a-uuid` and `/oracle/requests/not-a-uuid` correctly return `400 {"error":"invalid_id"}`. A syntactically valid absent job UUID returns 404, so the defect is specifically malformed input.

Evidence: [160](evidence/160.body) — `2026-09-25T07:28:02.508498+00:00`, HTTP 500; [165](evidence/165.body) — `2026-09-25T07:28:09.066371+00:00`, HTTP 500. Independent repeat: [239](evidence/239.body) — `2026-09-25T07:31:24.470530+00:00`, HTTP 500; [240](evidence/240.body) — `2026-09-25T07:31:25.786759+00:00`, HTTP 500. Controls: [161](evidence/161.body), [162](evidence/162.body), [163](evidence/163.body).

Action: validate UUIDs before database access on both routes, share validation with other ID routes, and sanitize the public internal-error handler. Regression check: both exact calls above must be 400 with no SQL fragments.

### F02 — Mobile pagination escapes the list and overlays the header

**Severity: medium.** Impact: phone users reaching the bottom of a listing lose the expected Previous/Next controls and must discover unlabeled navigation at the top of the document.

Exact pages: [Jobs](https://explorer.imd.fun/), [Oracle](https://explorer.imd.fun/oracle), [Published](https://explorer.imd.fun/published), and [Jobs page 2](https://explorer.imd.fun/?page=2). Input: set the viewport to 390 × 844, load a page, then scroll to its pagination at the bottom.

Observed: the page-range label stays below the listing, but pagination elements with `.row-open` have `position:absolute; top:10px; right:10px`. On Published, the range is at approximately y=5,024 while Next is at x=348, y=10, width=32, height=28; its text is hidden. The disabled Previous text appears over the header's wallet area. The same displacement occurs on Jobs and Oracle; scrolling to the bottom leaves these controls outside the visible viewport.

Expected: pagination controls remain together with the range beneath the list, with readable labels and without overlapping header controls.

Evidence: [mobile screenshot, Published](evidence/mobile-css-published.png), [Published bottom](evidence/mobile-css-published-bottom.png), [Jobs page 2 bottom](evidence/mobile-css-jobs-page2.png). CSS confirmation UTC times: Jobs `2026-09-25T07:30:38.995Z`, Published `2026-09-25T07:30:41.637Z`, Oracle `2026-09-25T07:30:44.240Z`; exact rectangles and hit tests are in [browser-css-confirmation.json](evidence/browser-css-confirmation.json). Earlier script-enabled snapshots show the same displacement, although full client behavior was constrained by the harness.

Likely cause, supported by the public [stylesheet](evidence/141.body): the `max-width:640px` rule `.row-open:not(.is-primary)` applies absolute positioning and hides its first child span globally, including `.pages` controls. Action: scope card-specific mobile rules to card rows, or explicitly reset positioning/text visibility for `.pages .row-open`; recheck both page 1 and page 2 at 390px.

### F03 — Published shows two different totals for the same unfiltered listing

**Severity: low.** Impact: visitors cannot tell how many publications exist or whether pagination omits records.

Exact reproduction: `GET https://explorer.imd.fun/published`, no query or credentials. Observed in the **same response**: the selected All tab says **94**, while pagination says **1–20 of 90**. A subsequent `GET https://api.imd.fun/publications` returns `count:90`, `page:1`, `pageSize:20`, `totalPages:5`, and 20 items. The mismatch was present in both captures about eight minutes apart.

Expected: the All tab and pagination use the same count for the same filtered dataset, or clearly label different populations. No explanation for different populations is shown. This same-document disagreement does not depend on comparing asynchronously changing counts.

Evidence: [031](evidence/031.body) — `2026-09-25T07:23:57.561866+00:00`, HTTP 200; [248](evidence/248.body) — `2026-09-25T07:31:37.427667+00:00`, HTTP 200; API [250](evidence/250.body) — `2026-09-25T07:31:40.306553+00:00`, HTTP 200. Readable extracts: [first HTML text](evidence/031.visible-text.txt), [repeat HTML text](evidence/248.visible-text.txt).

Action: derive both UI counts from one publication query/definition. Whether this is a stale cache or divergent filtering is not established from outside.

### F04 — Oracle list omits documented panelSize and quorum fields

**Severity: low.** Impact: clients built from the list schema cannot display panel size/quorum without undocumented detail requests.

Exact calls: `GET https://api.imd.fun/oracle/requests` and `GET https://api.imd.fun/oracle/requests?limit=1`.

Observed: 200 responses with `count`, `attester`, and `requests`; all 100 members in the default sample omit `panelSize` and `quorum`. Repeated limit=1 samples also omit both fields. For the same first request, `GET https://api.imd.fun/oracle/requests/82d5e221-f953-479b-aba1-fdbaa5917022` does include them, so values are available on the detail route.

Expected: [docs → Oracle](https://imd.fun/docs/#oracle) explicitly includes both fields in each list entry. Its allowance for extra fields does not explain missing advertised fields.

Evidence: [011](evidence/011.body) — `2026-09-25T07:23:28.251138+00:00`, HTTP 200; [207](evidence/207.body) — `2026-09-25T07:29:11.935288+00:00`, HTTP 200; [246](evidence/246.body) — `2026-09-25T07:31:34.812865+00:00`, HTTP 200; [detail response](evidence/040.body). Expected schema: [docs snapshot](evidence/002.body), extracted entry in [documented routes](evidence/documented-get-routes.txt).

Action: return these fields on the list, or correct the list contract and show how to retrieve them.

### F05 — Publications filter enum in docs omits the supported media category

**Severity: low.** Impact: API consumers following the reference cannot discover the filter used by the explorer's Media view.

Exact calls:

```sh
curl -i 'https://api.imd.fun/publications?type=media'
curl -i 'https://api.imd.fun/publications?type=invalid'
```

Observed: `type=media` returns **200**, `type:"media"`, `count:6`, and six items. The invalid-type response is 400 and explicitly lists `media` among allowed values. The explorer links `/published?type=media`, which returns the media view successfully.

Expected: [docs → Publications](https://imd.fun/docs/#publications) should list all accepted type values; its explicit enum currently contains only `all|contracts|sites|research`.

Evidence: [242](evidence/242.body) — `2026-09-25T07:31:28.443466+00:00`, HTTP 200; [195](evidence/195.body) — `2026-09-25T07:28:52.524156+00:00`, HTTP 400; [explorer Media response](evidence/226.body). Docs: [002](evidence/002.body).

Action: add `media` to the documented enum and describe the media item fields.

## VERIFIED security-hardening observation

### F06 — Missing response hardening headers on public HTML/API surfaces

**Severity: info.** Impact: these responses lack some browser-enforced defenses, but no exploit or sensitive authenticated action was demonstrated.

Exact calls: `GET https://imd.fun/`, `/docs/`, `/token/`; `GET https://explorer.imd.fun/`; `GET https://api.imd.fun/health`. Inspect response headers in journal records 001–005 and repeats 243/249.

Observed: the three imd.fun pages send HSTS. Sampled explorer and API HTTPS responses do **not** send `Strict-Transport-Security`. Sampled HTML responses do **not** send `Content-Security-Policy`, `X-Frame-Options`, `X-Content-Type-Options`, or `Referrer-Policy`. HTTP explorer and API entry URLs return 301 redirects to HTTPS ([264](evidence/264.body), [265](evidence/265.body); Location is in the journal). Redirects do not themselves establish an HSTS policy. No HTTP subresource URLs were found in the inspected HTML resource attributes; this is not a full mixed-content test of every dynamic widget.

Expected: a team-defined response-header baseline appropriate to HTML, downloads, and API content. This is a hardening recommendation, **not a claim that the docs promised these headers**, nor proof that framing, MIME sniffing, or a first-visit downgrade is exploitable. Parent-domain policy, browser preload state, and framing behavior were not independently tested.

Evidence UTC: [001](evidence/001.body) — `2026-09-25T07:22:31.158813+00:00`, HTTP 200; [004](evidence/004.body) — `2026-09-25T07:22:34.756022+00:00`, HTTP 200; [005](evidence/005.body) — `2026-09-25T07:22:36.464692+00:00`, HTTP 200; [243](evidence/243.body) — `2026-09-25T07:31:29.772783+00:00`, HTTP 200; [249](evidence/249.body) — `2026-09-25T07:31:38.825156+00:00`, HTTP 200. Headers, including absent-field verification, are preserved in [requests.jsonl](evidence/requests.jsonl).

Action: evaluate an HTML CSP including `frame-ancestors`, HSTS for intended HTTPS-only subdomains, `nosniff`, and a referrer policy; test compatibility before deployment.

## SUSPECTED issues / unresolved contract questions

These are reproducible observations; the defect interpretation is not established. They should not be counted as verified bugs.

### S01 — The explorer and control plane disagree on accepted work in 24 hours

**Provisional severity: medium.** Potential impact: users may materially misjudge network throughput if these are intended to be the same metric.

Calls, observations, UTC evidence:

- `GET https://api.imd.fun/health`: `acceptedLastDay:32970`, `connectedDaemons:345`, `workingNow:4`; [243](evidence/243.body) — `2026-09-25T07:31:29.772783+00:00`, HTTP 200.
- `GET https://api.imd.fun/swarm`: `health.acceptedLastDay:32970`, `health.agentsOnline:345`, `counts.tasksInProgress:5`; [244](evidence/244.body) — `2026-09-25T07:31:31.135404+00:00`, HTTP 200.
- `GET https://explorer.imd.fun/published`: footer visible `24.0K steps in 24h`; its accessible label says exactly **23,974 steps accepted in the last 24 hours**; also 345 online, 4 working, 5 jobs; [248](evidence/248.body) — `2026-09-25T07:31:37.427667+00:00`, HTTP 200. The jobs page repeats that value, [249](evidence/249.body) — `2026-09-25T07:31:38.825156+00:00`, HTTP 200.
- `GET https://explorer.imd.fun/api/activity`: working=4, total=5; its 24 `steps` buckets sum to **24,583**; [247](evidence/247.body) — `2026-09-25T07:31:36.081469+00:00`, HTTP 200. This sum is a local calculation, not a separately returned total.

Expected **if the definitions are identical**: agreement within sampling/cache delay. Difference between 32,970 and 23,974 is 8,996; a similar gap appears in the earlier responses (32,969 vs 23,973). Definitions of accepted attempts, accepted steps, panels, deduplication, and hourly window boundaries are not specified sufficiently to identify which value is wrong. Online/working/current-job totals agree in the later samples. The swarm's `counts.jobs:100` is not compared as a global total against the explorer's 189, since the swarm also carries a bounded recent job sample.

Action: document metric populations/windows and compare query definitions; then either unify the totals or label their distinction.

### S02 — The error and timestamp examples are not a reliable strict wire schema

**Provisional severity: low.** Potential impact: clients treating documentation examples as strict types may fail to parse otherwise valid responses.

Observed calls and exact bodies:

- `GET https://api.imd.fun/workflows/not-a-uuid` → 400 `{"error":"invalid_id"}`, no `detail`; [162](evidence/162.body) — `2026-09-25T07:28:05.176957+00:00`, HTTP 400 and repeat [241](evidence/241.body).
- `GET https://api.imd.fun/publications?page=-1&pageSize=101` → 400 `error:"invalid_query"`, but `detail` is an **object** with `formErrors` and `fieldErrors`, not a string; [194](evidence/194.body) — `2026-09-25T07:28:51.209662+00:00`, HTTP 400.
- `GET https://api.imd.fun/requests/00000000-0000-0000-0000-000000000000`, header `Origin: https://example.org` → 403 `{"error":"origin_not_allowed"}`, no detail; [200](evidence/200.body) — `2026-09-25T07:29:02.721338+00:00`, HTTP 403.
- `GET https://api.imd.fun/feedback/batches` → 200, `chainId`, `collection`, `batches`, without the pagination guide's generic `count` field; [024](evidence/024.body) — `2026-09-25T07:23:46.848919+00:00`, HTTP 200. The route-specific table does not expressly promise count.
- `GET https://explorer.imd.fun/api/agents/174` → 200 with `lastAcceptedAt:"2026-09-25 05:29:38.02+00"`; [064](evidence/064.body) — `2026-09-25T07:25:06.565996+00:00`, HTTP 200. The docs' general time rule suggests ISO 8601, but this is a SQL-style string rather than the `T...Z` format used elsewhere. Strict-parser compatibility was not tested.

Expected only under a strict reading: the error example's two string fields and one consistently specified time representation. The docs do not explicitly declare `detail` required or define its type as a formal schema; they also allow different framework-generated errors. Therefore these are **observed documentation ambiguities**, not established API implementation defects. Action: publish a schema stating optional fields, detail's union type, route-specific pagination fields, and timestamp serialization.

### S03 — Overlength search and nonnumeric limits are accepted without documented policy

**Provisional severity: low.** Potential impact: users may believe a search/limit was applied exactly when it was normalized or ignored.

Exact inputs: `GET https://api.imd.fun/jobs?q=` followed by 201 `x` characters, and the same with 8,192 `x` characters. Both return **200 `{"count":0,"jobs":[]}`**. Evidence: [190](evidence/190.body) — `2026-09-25T07:28:45.898967+00:00`, HTTP 200; [191](evidence/191.body) — `2026-09-25T07:28:47.242552+00:00`, HTTP 200. Full URLs are in the journal; deterministic reproduction:

```sh
q=$(printf '%0201d' 0 | tr 0 x)
curl -i --get 'https://api.imd.fun/jobs' --data-urlencode "q=$q"
```

Also `GET https://api.imd.fun/jobs?limit=abc` returns 200 with count=100, and equivalent workflows/oracle/feedback calls return defaults ([176](evidence/176.body), [180](evidence/180.body), [184](evidence/184.body), [188](evidence/188.body); UTC values in the journal).

Expected under a reject-invalid reading: 400; the docs specify search max 200 and numeric bounds. But the docs do not say whether excess search characters are truncated or invalid limits fall back to defaults. Zero-result queries do not establish truncation or ignored filtering. No resource-exhaustion claim is made. Action: define and test reject/clamp/default behavior explicitly.

### S04 — A completed research panel has answers but no submissions/result files

**Provisional severity: low.** Potential impact: a client using only the generic result endpoint may miss a completed research answer.

For public job `4949d318-cb02-4dee-bdd6-f901ffcd38fa`, `GET /jobs/{id}/panel` returns an accepted panel with five answers; `GET /jobs/{id}/submissions` returns count=0; `GET /jobs/{id}/result` returns `state:"completed"`, `complete:true`, `source:[]`, `files:[]`. Exact host is `https://api.imd.fun`. Evidence: [254](evidence/254.body) — `2026-09-25T07:31:45.808946+00:00`, HTTP 200; [256](evidence/256.body) — `2026-09-25T07:31:49.332492+00:00`, HTTP 200; [259](evidence/259.body) — `2026-09-25T07:31:53.611809+00:00`, HTTP 200.

Expected **only if** the docs' generic “every attempt”/result description includes panel answers: the generic endpoints should expose them or document the exception. Panels may intentionally use separate storage and response routes, so data loss is not established. A normal completed report job successfully returned a submission and downloadable file ([262](evidence/262.body), [263](evidence/263.body), [266](evidence/266.body)). Action: clarify how panel consumers should retrieve completed output.

## Other checks and negative findings

**Paid routes and CORS:** no permissive paid-route CORS was found. Unauthenticated synthetic-ID GET with `Origin: https://example.org` returns 403 `origin_not_allowed` ([200](evidence/200.body)); without Origin it returns 401 `request_token_required` ([270](evidence/270.body)). Public capabilities with foreign Origin also returns 403 ([201](evidence/201.body)), whereas no-Origin capabilities is 200 ([025](evidence/025.body)). The price, four actions, token, atomic amount `500000000000000000`, decimals=18, and quote lifetime 600 seconds match the docs.

Read-only preflights used these exact headers:

```text
OPTIONS https://api.imd.fun/requests/quote
OPTIONS https://api.imd.fun/requests/00000000-0000-0000-0000-000000000000/submit
Origin: https://example.org
Access-Control-Request-Method: POST
Access-Control-Request-Headers: authorization,content-type
```

Both returned framework 404 and no access-control allow-origin header ([205](evidence/205.body), [206](evidence/206.body)); no POST was sent. A browser would not be authorized to proceed from those preflights. `/swarm` and oracle public reads returned wildcard CORS as documented ([202](evidence/202.body), [203](evidence/203.body)). ENS remained closed with 404 `member_sites_closed`; its successful CORS behavior remains untested. This proves only sampled origin/method handling, not all possible credentialed requests.

**Input handling:** malformed workflow/oracle/site UUIDs returned 400; malformed seat numbers, wallet addresses, device keys, and registration token IDs returned 400. A valid absent job UUID and absent seat returned 404. Invalid date cursors on jobs/workflows/oracle/feedback returned 400 `invalid_query`; invalid launch-number cursor returned 400. Limit=0 returned one item on the four cursor lists; limit=501 returned 500 jobs, 500 oracle requests, and 500 feedback batches. Only 32 workflows existed in the sample, so that route's upper clamp could not be proved. Research/fuzz limit probes had too few records to establish all upper bounds. Seat `work=0&reviews=0` returned empty work/review arrays; other seat data remains present. No volume or maximum-throughput testing was done.

**Links and explorer filters:** sampled `show=live|incomplete|completed`, agents `show=online|working|outdated`, oracle `show=open|signed|unsigned`, and all five Published type views returned HTTP 200 with corresponding listing content; second-page links returned 200. This checks server-rendered states, not every item classification or hydrated click. The empty jobs search displayed zero matches. `/agents?q=174` did not filter, but its rendered search form targets `/` rather than `/agents`; this probe is not evidence of a broken supported agent filter. Actual oracle listing detail links point to `/jobs/{jobId}` and the sampled one returned 200 ([260](evidence/260.body)). Guessed `/oracle/{id}` paths returned 404 but were **not linked URLs** and are not reported as broken links.

The sampled published “read the report” GitHub link, API artifact, source bundle, and canonical review all returned 200 ([266–269 in journal](evidence/requests.jsonl)); artifact byte count/hash and bundle hash are checked locally. Unknown bundle/artifact/review/work-record/document hashes returned 404. `/ens` returned 404 `member_sites_closed`, consistent with the docs allowing disabled features; no broken ENS service claim is made.

**Mobile exclusions:** no document-wide horizontal overflow was measured on the seven primary pages (scrollWidth=390). This does not exclude clipped descendants. Docs tables/code have their own scrolling/layout behavior; not every cell was visually reviewed. Explorer filter tabs and the footer intentionally scroll horizontally; scrolling the footer 214px made Health visible, so that was rejected as an unusable-control finding. Long oracle answer values and a few agent badges extend beyond their containing area; truncation/scroll affordance was not sufficiently established to call those bugs. No claim is made about wallet controls or dynamic market data while their providers were blocked by the harness.

### Third-party blockers, not verified broken links

The exact token/docs-linked pages below were attempted once; response bodies and headers were saved. No challenge bypass or repeated retry was attempted.

| URL | Observed result | UTC / evidence | Interpretation |
|---|---|---|---|
| https://basedbot.app/token/eth/0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7 | 403 challenge HTML | [230](evidence/230.body) — `2026-09-25T07:30:02.609792+00:00`, HTTP 403 | Browser/site availability unresolved |
| https://dexscreener.com/ethereum/0xD34a99Bc0f67aE1bbd63C660e6d0b0dd03E263B7 | 403 challenge HTML | [232](evidence/232.body) — `2026-09-25T07:30:05.066235+00:00`, HTTP 403 | Token/pair routing not verified |
| https://etherscan.io/address/0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7 | 403 challenge HTML | [233](evidence/233.body) — `2026-09-25T07:30:06.275034+00:00`, HTTP 403 | Docs external link unresolved |
| https://etherscan.io/token/0xD34a99Bc0f67aE1bbd63C660e6d0b0dd03E263B7 | 403 challenge HTML | [234](evidence/234.body) — `2026-09-25T07:30:07.465202+00:00`, HTTP 403 | Token-page destination unresolved |
| https://fomo.family/tokens/ethereum/0xD34a99Bc0f67aE1bbd63C660e6d0b0dd03E263B7 | 432 `{"error":"unauthorized"}` | [235](evidence/235.body) — `2026-09-25T07:30:08.660213+00:00`, HTTP 432 | Unusual access refusal observed; not proof the link is dead for users |
| https://www.defined.fi/token/eth/0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7/0xb07d640fd9e2eb9dc81b953c8e4fd006bdfeaf276010fb5418eb763ca15abfb3 | 429 Vercel Security Checkpoint | [238](evidence/238.body) — `2026-09-25T07:30:14.396354+00:00`, HTTP 429 | Explicit bot checkpoint; destination not validated |

Uniswap, Community Coins, OpenSea collection, and pool4/stake returned 200 HTML. HTTP success alone does not establish correct balances, chain selection, contract functionality, or full browser usability. All remain read-only observations.

## Local validation and remaining work

[Offline checks](evidence/local-checks.json) validate evidence integrity, request spacing, anchors, and the asserted snapshot properties. [SHA-256 manifest](evidence/sha256.json) identifies the saved evidence files. These are the investigator's checks, not an independent review or behavioral certification. The report and evidence require no network or installed dependencies to read.

Next useful team checks: fix F01 and F02 first; reconcile publication-count definitions; synchronize docs contracts; then independently reproduce the suspected metric/schema cases and retest hydrated mobile controls with normal third-party access. Exhaustive individual-record/link traversal, paid workflows, wallet signing, and mutation routes remain outside what was performed.