The exact values entered on the sponsor form and on each Typeform submission, recorded so a reviewer can match a report to its evidence without asking. The written report is at huntstamp-findings.vercel.app; the captured screenshots and raw measurements are in the evidence locker.
Values as entered, so the sponsor can match the Typeform reports to this account.
Use this rather than the earlier draft. The reason for the change is set out directly below it.
All findings were first observed against deployment dpl_74W5o38E8FQjJUZ2DYo5PFDHEsLs on
3 September 2026, Chromium 148 on Windows 11, at 1440x900 and 375x812. Manic shipped a
newer build, dpl_C3bXHquKbKr1sjn9WpRtDt8MWfce, partway through the session, and every
finding was then re-checked against it by an automated Playwright pass. The screenshots
and raw measurements from that pass are published alongside the report.
Sixteen findings filed separately through the Typeform.
The two with the most weight, both re-confirmed on the newer build:
- A market marked Resolved, with its order book closed and a final score of 2-6 on
screen, still advertises Settlement Time: Sep 9, 3:00 PM UTC. The match was played
on 2 September, which the event slug itself records. A user checking when funds are
released is given a date with no relation to a settlement that already happened.
- /pm stops resolving to the market directory once any event has been opened. The cause
is localStorage 'pm-events-store', which restores the stored event and rewrites the
address bar. Removing that key restores the directory, so the root cause is isolated
rather than just the symptom. This is the entry point named in the bounty brief, so
anyone following a documentation link to /pm lands somewhere else.
Two findings were withdrawn rather than filed. Both withdrawals are documented in the
report rather than deleted:
- Mobile subcategory chips appeared non-functional. Re-testing showed the cause was my
automation harness, not the application.
- I measured the /pm load event at 94s and then 136s through an instrumented browser and
had written it up as a performance defect. An automated run on the same machine and
connection then loaded the same route with loadEventEnd at 1,581ms and TTFB at 57ms.
The slow figures were an artefact of my environment. The route does request 115 JS
chunks, but that is an observation, not a defect on this evidence.
One further finding is filed with its frequency answered honestly as "only happened
once": a settled market rendering two contradictory price sets, one pair summing to
101%. The capture is verbatim and the build id is recorded, but it did not reproduce on
re-test, so triage should expect that.
This session ran entirely as a logged-out guest. No funds were deposited and no orders
were placed. Deposits, order placement, positions, balances and settlement crediting all
require a funded account with real USDC at risk, and none of that was exercised. That is
where this programme's P0 weight sits, and it remains untested.
Testing was AI-driven browser automation rather than manual QA. Stated up front, because
every finding rests on reproduction steps your own team can run.
Report: https://huntstamp-findings.vercel.app
Evidence: https://huntstamp-findings.vercel.app/evidence.html
Ledger: https://huntstamp-findings.vercel.app/submission.html
The earlier draft led with a performance claim: loadEventEnd at 94s and then 136s, against a same-session control load of 1.3s. That measurement was real, but it was not measuring the application. An automated Playwright run on the same machine and the same connection loaded the same route with loadEventEnd at 1,581 ms and TTFB at 57 ms, with the same 115 chunks.
The programme excludes issues caused by the reporter's own device or network. Sending that bullet to a CTO invites them to measure it themselves, find a second and a half, and discount the rest of the report by association. Removing it costs one finding and protects the other sixteen.
Sixteen to file, two withdrawn. Status reflects the automated re-test against the newer build. The capture column names the screenshot backing it in the evidence locker.
| # | ID | Finding | Re-test | Capture |
|---|---|---|---|---|
| 01 | F-02 | Contradictory price sets on a settled market, one pair summing to 101% | Once only | — |
| 02 | F-01 | The /pm entry URL hijacked by a stored tab | Holds | F-01 |
| 03 | F-10 | Slow page load | Withdrawn | — |
| 04 | F-03 | Settlement date a week after the event it settles | Holds | F-03 |
| 05 | F-04 | Unpriced outcome with both buy buttons enabled | Transient | — |
| 06 | F-05 | Resolved market promoted in Trending with live controls | Holds | F-05 |
| 07 | F-12 | A category click silently discards the search query | Holds | F-12a, F-12b |
| 08 | F-14 | Empty state with no reset, and the filter off-screen on mobile | Holds | F-14 |
| 09 | F-15 | Inactive responsive layout stays focusable at zero size | Count varies | F-05 |
| 10 | F-07 | Prop labels repeat the event title and truncate identically | Holds, 48 rows | F-07 |
| 11 | F-16 | Nav still reads "August Rewards" in September | Holds | F-16 |
| 12 | F-06 | A whole-number price rendered as 100.0% | Not reproduced | — |
| 13 | F-08 | Zero volume renders as -- Vol rather than $0 | Holds, 13 rows | F-07 |
| 14 | F-09 | Landing-page hero preloaded on the trading route, warned 16 times | Holds | console.log |
| 15 | F-11 | The same candidate spelled two ways on two cards visible at once | Holds | F-05 |
| 16 | F-13 | Zero-count subcategories offered as selectable filters | Holds | F-14 |
| 17 | F-17 | Clipboard overwritten by a click on empty grid space | Once only | — |
| Field | Value |
|---|---|
| Device, browser | Desktop PC / Windows 11 build 26200 / Chromium 148 / no wallet connected, logged-out guest session |
| When | 3 September 2026, 04:00–09:48 UTC |
| No secrets, no disclosure | Accepted. Nothing secret was included, nothing was exploited repeatedly or disclosed publicly, and Manic is welcome to reproduce and follow up. |
| Created with AI, no manual testing | Accepted. AI-driven browser automation against the live application: real page loads, real DOM reads, real timings, no manual QA pass and no funded account. |
Deposits, order placement, order matching, positions, balances, withdrawal and settlement crediting all require a funded account with real USDC at risk. None of it was touched. On a real-money venue that is exactly where the severe defects live, so this report should be read as covering the surface a logged-out visitor can reach and nothing beyond it.
The screenshot upload on each Typeform submission is the one field that had to be filled by hand, from the captured PNGs. Producing an image of evidence that was never photographed would be fabricating evidence, which is the specific thing these programmes screen for.