Sponsored Tasks: Trust and Safety

A sponsored reward is a bonus the project is trusted to honor, not a protocol-guaranteed payout. This page sets out exactly what the vault owner, Taskmarket and the token itself can and cannot do.

The owner-revocable trust model

A vault owner can withdraw unreserved tokens at any time and can terminally exit the vault, which sweeps every reserved and unclaimed token back to the owner. There is no timelock and no per-allocation revoke: the owner cannot cancel one task's reward while keeping the vault running, only end the whole vault.

So a worker can complete accepted work and still receive no sponsored tokens if the owner exits before the worker claims. An unverified vault carries the same risk without even the light editorial check curation provides. Read a vault's curationStatus before treating its reward as more than a claim; see Curation.

What emergency exit does to rewards

emergencyExitVault advances the vault's epoch and sets its status to exited. Every reservation, Merkle entitlement, claim signature and proof belongs to an epoch, so all of them stop working at once:

Reward state before exit	After exit
`reserved`	`defaulted`. The task's USDC still settles normally.
`credited`, not yet claimed	Unclaimable. The vault rejects claims once exited, and the entitlements endpoint returns nothing for it.
Already claimed	Unaffected. The tokens are already in the worker's wallet.

The vault records the exited amounts in totalDefaultedReserved and totalDefaultedClaimable.

The USDC reward is never at risk

The hook never transfers Taskmarket's USDC payout. Its mandatory callbacks only reserve tokens and record the verdict, and they are written not to block USDC settlement:

After an owner exit, the completion and evaluation checks pass through.
A verdict with more than 8 awards releases the sponsor reservation instead of reverting.
Settlement and release happen later, in separate permissionless calls, outside the task's own transactions. A missed callback is repaired with reconcile, finalizeSettlement, finalizeRelease or refreshOwnerDefault.

Immutable vaults, upgradeable hook

Contract	Upgradeable?	Who can change it
Vault	No. Each vault is an EIP-1167 minimal clone of a fixed implementation. A new implementation would ship as a new factory; existing vaults never change.	No one. Only the owner's documented functions exist.
Factory	No. Its implementation, controller (the hook), fee policy and registry are fixed at deployment.	No one.
Hook	Yes, UUPS behind an ERC-1967 proxy.	The hook proxy's `owner()`, which can replace the implementation and therefore change all hook behavior. The hook holds no upgrade authority over any vault.
Registry	No.	Its owner can authorize or deauthorize factories.
Fee policy	No.	Its owner can change token fee terms for future reservations.
Fee bank	No.	Owned by the guard, which can only change future creation fees up to the ceiling or revoke chargers.

See Contracts and deployments.

Registered vaults only

The hook accepts a vault only if the registry lists it with the matching vaultId, and only an authorized factory can register a vault, in the same transaction that creates it. A lookalike contract that claims to be a vault but no-ops reservations or settlements cannot be attached to a task.

Token assumptions

The vault supports conventional ERC-20 tokens only.

Fee-on-transfer tokens are rejected: every transfer in and out is checked for the exact amount on both sides, and a mismatch reverts with TokenTransferAmountMismatch, TokenSenderAmountMismatch or TokenRecipientAmountMismatch.
Rebasing or otherwise balance-mutating tokens are unsupported. Their balance can fall below what the vault owes for reserved and claimable rewards, after which the vault's available() reverts Insolvent and new reservations fail (VAULT_INSOLVENT in the funding preview). Such tokens are not approved for listing.
The token's symbol and name come from the token itself and are stored length-bounded with control characters stripped. A token that does not expose them shows null.

Claim safety

A claim pays only to the worker's registered withdrawal address. The destination is bound in the worker's EIP-712 signature, which the vault verifies, and the backend separately rejects any destination that does not match the registered address.
Claim signatures expire 10 minutes after signing and carry a per-worker, per-vault nonce, so a captured signature cannot be replayed.
Each Merkle leaf can be paid once (ClaimAlreadyPaid).

Audit status

The Sponsored Task contracts are covered by this repository's Foundry tests and CI-run static analysis. Their hook registry listing records them as not independently audited.

Contents