Report a signed transaction hash
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.
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.
Path Parameters
The request id the hash belongs to.
Request Body
application/json
The hash the caller signed with.
TypeScript Definitions
Use the request body type in TypeScript.
Response Body
application/json
application/json
application/json
application/json
application/json
application/json
curl -X POST "https://example.com/tx/string/submitted" \ -H "Content-Type: application/json" \ -d '{ "txHash": "string" }'{ "id": "string", "ownerId": "string", "chainSlug": "ethereum", "unsignedTx": { "chainId": 0, "to": "string", "data": "string", "value": "string" }, "summary": [ "string" ], "simulation": { "ok": true, "balanceChanges": [ { "token": "string", "symbol": "string", "delta": "string" } ], "events": [ "string" ] }, "fees": [ { "label": "string", "bps": 0 } ], "delivery": "dashboard", "status": "pending", "txHash": "string", "dependsOn": "string", "createdAt": "string", "expiresAt": "string"}Read a signing request GET
Returns one `TxRequest` by id, so either kind of caller can poll the status of a request they created. A request owned by another user answers with the same 404 as a request that does not exist, and the two response bodies are identical — a caller cannot probe for the existence of someone else's request.
What this deployment can verify GET
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.