What this deployment can verify
The three labels and their meanings, the seven checks with their titles and stated blind spots, whether this deployment can read a contract's owner or run a project's tests and fork simulation, and how many vetted templates are compiled here. **Public, and unauthenticated on purpose.** A client reads this before it runs anything, and a page that has to log a reader in to find out what the verdict means has already lost them. `liveReads` is the field worth reading twice. A deployment with no owner read and no sandbox will report `unknown` for every privileged function and skip the tests-and-fork check, which caps the label at `experimental` however clean the contract is. `templates.compiled` decides whether `verified template` is reachable at all. Both are facts about THIS deployment, which is why they are served rather than assumed. `checks[].blindSpot` is served from the same constants the checks use, so what a client tells a user about a check's limits cannot be more generous than the check itself is.
The three labels and their meanings, the seven checks with their titles and stated blind spots, whether this deployment can read a contract's owner or run a project's tests and fork simulation, and how many vetted templates are compiled here. Public, and unauthenticated on purpose. A client reads this before it runs anything, and a page that has to log a reader in to find out what the verdict means has already lost them. liveReads is the field worth reading twice. A deployment with no owner read and no sandbox will report unknown for every privileged function and skip the tests-and-fork check, which caps the label at experimental however clean the contract is. templates.compiled decides whether verified template is reachable at all. Both are facts about THIS deployment, which is why they are served rather than assumed. checks[].blindSpot is served from the same constants the checks use, so what a client tells a user about a check's limits cannot be more generous than the check itself is.
Response Body
application/json
application/json
curl -X GET "https://example.com/verify/methods"{ "labels": [ { "label": "verified template", "explanation": "string" } ], "checks": [ { "id": "template_match", "title": "string", "blindSpot": "string" } ], "liveReads": { "owner": true, "testsAndFork": true }, "templates": { "compiled": 0, "uncompiled": 0, "names": [ "string" ] }}Report a signed transaction hash POST
Records the hash of a transaction the **caller** signed, and moves the request to `submitted`. This is how an external agent that signed with its own wallet keeps launch status and the Onchain page accurate; the dashboard's sign-request modal posts here after the user's Privy wallet returns a hash. The worker then confirms the receipt onchain and moves the request to `confirmed` or `failed`. Reporting a hash twice is accepted and keeps the first one — a client that retried after a timeout must not rewrite the row. A request owned by another user answers with the same 404 as one that does not exist.
Verify a contract and get a verdict POST
Runs all seven checks — template match, static analysis, permission diff, hook permission read, tests + fork, invariants, plain-English readback — and answers with the report and the one label it earned. **Free, and no bearer token.** This is Verify lite from §3.7: paste a contract and get the permission diff and the readback. No credits are charged and none can be — the route never calls the credit ledger at all. **What you must send.** `chain` and `abi` are the only required fields, and they are the minimum because a report is only as honest as the evidence it was given. Omit `bytecode` and the template match **skips**; omit `source` and static analysis **skips**; omit `address` and the owner read is `unknown` and the hook read **skips**; send an empty `abi` and the permission diff **skips**. Those are the module's honest answers, not refusals: a check that could not run is reported as `skipped` with a `reason` and caps the label at `experimental`, because a check that did not run has verified nothing. **What comes back.** `label` is one of exactly three values and `labelExplanation` is the sentence that must be shown beside it — `verified custom` means every check passed and putty has NOT had the contract externally audited. `clearedForMainnet` is always `false`; the schema declares it as the literal `false` for exactly that reason. `checks` always carries seven entries in plan order, so `summary.passed + summary.failed + summary.skipped === summary.total` always holds and a check can never quietly go missing. `blockingChecks` names what to fix first.