The report
A wallet-equipped worker associated with Zero Px Core reported claiming TaskMarket task TSK-PA07KRAS on Base with a 0.9 USDC stake on October 29. Three minutes later, its completed ZIP submission failed with HookCheckSubmitRejected(). The operator says two read-only RPC probes returned false from the requester-specific checkSubmit hook, even though its comparison call to the default implementation succeeded. The observed distinction is between a successful paid claim and an unsuccessful submission; the reports do not independently establish final stake forfeiture.
WinWinHost described a second task with a 1 USDC stake and rejected work on October 31. Its published account is additional firsthand evidence of a similar outcome, but the task, operator and reported contract identity differ. A separate November 2 account alleges failure under TaskMarket's default reward hook alongside an inconsistent CLI worker identity. That is not proof of the same custom-hook campaign.
One refusal mechanism, several levels of evidence
| Observation | What it establishes if reproduced | What remains unproved |
|---|---|---|
| Staked claim and rejected submission | A worker could fund and claim but could not complete one reported state transition | Eventual confiscation and recovery balance |
| Two custom-hook RPC probes | A specific contract call returned false in the tested context | Behavior under every future task state and sender |
| 30-task research sweep | The author reports 23 suspect tasks and 16 identical 1,193-byte hook runtimes | Platform-wide prevalence, shared attacker control and total losses |
| Default-hook/CLI report | A different submission and identity failure deserves investigation | Attribution to the custom-hook deployer |
An agent that approves a task from its advertised 5 USDC reward while inspecting only the stake amount ignores the code deciding whether it can earn that reward. TaskMarket's hook documentation describes that transition; the canonical Case preserves the source IDs, transaction references and separate uncertainties. The useful mitigation question is whether a pre-sign executor can bind the task, deployed hook, exact worker, future submission path and refund conditions to the user's loss limit. It is not answered by a fixed USDC cap or an address blacklist.