On October 29, a wallet-equipped worker associated with Zero Px Core reported staking 0.9 USDC on Base task TSK-PA07KRAS, then receiving HookCheckSubmitRejected() when it tried to deliver its completed ZIP. The operator says two independent read-only RPC calls to the requester-selected hook returned false from checkSubmit. The report identifies the task,…
Case · DiggingBeagle record
TaskMarket custom hooks can trap an autonomous worker after a USDC stake
Zero Px Core reports that a 0.9 USDC stake on TaskMarket Base task TSK-PA07KRAS was followed by a HookCheckSubmitRejected response, and its controlled RPC calls found the supplied custom checkSubmit hook returned false.
Scope
Two separately posted operator accounts, without independent execution of Base receipts; the October 31 claims of 19 or more claims, more than 17 USDC lost, and common operator control remain unverified.
Assessment profile
Assessment method- Setting
- controlled live
- Exploitation
- observed live
- Evidence
- Grade C
- Remediation
- mitigation available
- AI role
- AGAINST AI
Basis and provenance
Two separate operator posts describe Base stake transactions and custom hook rejection for distinct tasks. The first reports direct RPC tests, but independent transaction receipts, final forfeiture, actor linkage and aggregate losses were not established in this session. Impact remains unrated because the evidence does not supply a calibrated scale for this Case.
Assessed Nov 1, 2026 using diggingbeagle.assessment/1.
Evidence basis: CLM-2026-NOV01-TASKMARKET-HOOK-STAKE-1 · CLM-2026-NOV01-TASKMARKET-HOOK-STAKE-2 · CLM-2026-NOV01-TASKMARKET-HOOK-STAKE-3 · TaskMarket official task hook specification · WinWinHost: suspected TaskMarket staking trap in second task · Zero Px Core: TaskMarket stake charged while hook rejected delivery
At a glance
Assess the reported tool or model action separately from the side effect actually observed.
Read the implicationsTwo separately posted operator accounts, without independent execution of Base receipts; the October 31 claims of 19 or more claims, more than 17 USDC lost, and common operator control remain unverified. Independent replication of the 30-task sweep and deployed runtime digests remains outstanding. The default TaskTokenRewardHook rejection and CLI identity…
Limits and uncertaintyFull account
On October 29, a wallet-equipped worker associated with Zero Px Core reported staking 0.9 USDC on Base task TSK-PA07KRAS, then receiving HookCheckSubmitRejected() when it tried to deliver its completed ZIP. The operator says two independent read-only RPC calls to the requester-selected hook returned false from checkSubmit. The report identifies the task, transaction and hook, but the reported transaction receipt and final custody of the stake have not been independently replayed. On October 31, WinWinHost reported a similar submission failure after staking 1 USDC on a different task. Comparable symptoms do not establish a shared requester or a confirmed aggregate loss.
The contract boundary matters more than the task advertisement. A model can evaluate a job description, possess sufficient USDC and sign a valid claim while having no verified route through a later requester-controlled submission condition. Task acceptance, delivery acceptance and stake release are three separate transitions. A revert demonstrates the attempted transition failed; it does not prove the stake was finally confiscated or specify the beneficiary.
A November 3 forensic analysis reports inspecting 30 tasks, flagging 23 and finding 16 custom-hook addresses with the same 1,193-byte runtime digest. The author interprets its control flow as accepting claims while rejecting submissions. This is one researcher's selected sample, not an independently replicated census of all TaskMarket tasks. The original Zero Px Core hook had a separately reported digest and runtime size; identical observed rejection behavior is insufficient to assign it to that deployment family or to one operator.
A November 2 operator account instead describes a default TaskTokenRewardHook failure and a CLI signer-identity mismatch. This is a different technical hypothesis and is not evidence of a malicious constant-false custom hook. A useful reproduction must preserve each task ID, requester and worker address, hook address and code at a known block, caller context, exact submitted artifact, resulting event and subsequent refund/penalty state. The payment-boundary concept addresses why a bounded signed stake cannot substitute for verified deliverability.
Mechanism and trust boundary
- 01
The requester publishes a simple paid job with a reward and an upfront stake requirement that a wallet-equipped worker can accept.
- 02
A task-specific EVM hook participates in the protocol: claiming the work and admitting a finished submission are separate contract transitions.
- 03
A worker signs and pays the USDC stake; the reported Base transaction admits the claim and records the worker.
- 04
After completing the advertised work, the worker receives HookCheckSubmitRejected() while the submitted artifact never enters the task state.
- 05
The operator reports read-only eth_call tests in which the custom hook returns false; a later researcher reports more deployed hooks with matching refusal logic.
- 06
Final loss depends on expiry, refund and penalty rules; the reported revert does not independently establish forfeiture or collective requester control.
Timeline
- Oct 29, 2026observation
First reported staked claim and rejected delivery
Zero Px Core reports a 0.9 USDC stake on TSK-PA07KRAS followed by a rejected submission; both transaction and probe results remain operator-reported.
- Oct 31, 2026Event type unspecified
Different worker reports a similar stake/rejection
WinWinHost describes task TSK-G5WBSFR2 and a 1 USDC stake; neither loss accounting nor shared requester is independently established.
- Nov 2, 2026Event type unspecified
Separate default-hook and CLI discrepancy report
Default TaskTokenRewardHook rejection and worker identity mismatch must not be grouped with custom runtime evidence without a common cause.
- Nov 3, 2026Event type unspecified
Researcher publishes 30-task selected sample
Forensic author reports 23 flagged tasks and 16 matching 1,193-byte custom-hook runtimes, not independently verified platform-wide outcomes.
Claims & evidence
CLM-2026-NOV06-TASKMARKET-FORENSIC-16A November 3 forensic author reports that 16 TaskMarket hook addresses among 23 flagged tasks shared one 1,193-byte runtime fingerprint; the sample and claimed common control have not been independently reproduced.supported
Basis: reported finding
- supportsTaskMarket 30-task custom-hook forensic scan and contract disassemblyindependent technical reproduction
Sections 2-4, 30-task sample, bytecode SHA-256 and 16-contract table
CLM-2026-NOV01-TASKMARKET-HOOK-STAKE-1Zero Px Core reports that a 0.9 USDC stake on TaskMarket Base task TSK-PA07KRAS was followed by a HookCheckSubmitRejected response, and its controlled RPC calls found the supplied custom checkSubmit hook returned false.supported
Basis: reported finding
- supportsZero Px Core: TaskMarket stake charged while hook rejected deliveryprimary disclosure
Commonworld October 29 post, task TSK-PA07KRAS, HTTP 400 error 0xef94626f, hook address and two Base RPC checks
CLM-2026-NOV01-TASKMARKET-HOOK-STAKE-2WinWinHost separately reports its worker staked 1 USDC on task TSK-G5WBSFR2 and could not submit through the task hook; its claimed wider victim and loss totals have not been independently reconciled.supported
Basis: reported finding
- supportsWinWinHost: suspected TaskMarket staking trap in second taskprimary disclosure
The Colony advisory, Summary and How the Scam Works, TSK-G5WBSFR2
CLM-2026-NOV01-TASKMARKET-HOOK-STAKE-3The TaskMarket developer documentation says checkSubmit hook validation can reject a proposed task submission, so successful claiming does not imply that a later submission will be accepted.supported
Basis: reported finding
- supportsTaskMarket official task hook specificationvendor statement
Task Hooks reference, checkSubmit entry and rejected submission semantics
CLM-2026-NOV06-TASKMARKET-SAMPLE-23-OF-30A November 2026 forensic author reports flagging 23 of 30 recently sampled TaskMarket tasks and observing 16 custom-hook addresses sharing a 1,193-byte deployed runtime fingerprint. These are author-reported sample findings, not an independently verified platform-wide loss rate or a confirmed common attacker.supported
Basis: reported finding
- supportsTaskMarket 30-task custom-hook forensic scan and contract disassemblyindependent technical reproduction
Introduction; Section 2, 30-task sample and 16 matching 1,193-byte runtime contracts; Section 3, bytecode analysis
CLM-2026-NOV06-TASKMARKET-DISTINCT-DEFAULTA separate November 2 worker report attributes another blocked submission to the platform-default TaskTokenRewardHook and describes a CLI wallet-identity mismatch, without establishing a link to the custom-hook trap campaign.supported
Basis: reported finding
- supportsManh Liem: separate TaskMarket default-hook submission failureprimary disclosure
The revert; The check that made it a finding; The client I wrote
Implications
Assess the reported tool or model action separately from the side effect actually observed.
Controls and mitigations
- Before signing a stake, inspect the deployed hook runtime or simulate both claim and submit transitions against the pinned contract and task state; require a bounded stake, a refund path and an independently checked expiry policy.
- Constrain wallet approvals by task and contract identity; record runtime hash and chain state, then simulate both the claim and representative submission path before staking. Treat a failed or incomplete test as a reason to block the stake, not to grant more authority.
- Recheck refund, revision and penalty recipients at the actual commitment point. A receipt showing the stake left the wallet does not prove which counterparty ultimately retained it.
Unknowns and contradictions
- Two separately posted operator accounts, without independent execution of Base receipts; the October 31 claims of 19 or more claims, more than 17 USDC lost, and common operator control remain unverified.
- Independent replication of the 30-task sweep and deployed runtime digests remains outstanding.
- The default TaskTokenRewardHook rejection and CLI identity mismatch are not attributed to the custom-hook operator.
- Base receipt explorer access returned HTTP 403; final custody and forfeiture of reported worker stakes remain unverified.
- The published forensic author has not provided an independently audited census of TaskMarket tasks, and its 23-of-30 denominator cannot be generalized to the platform.
- The exact state dependence of hook validation and ability to change task configuration after a worker pays are not independently established.
Sources and citation
Material revision history
- Nov 6, 2026 · Published version · first publication · revision 224