Sponsored Tasks: Managing a Vault
Everything an owner can do with a vault after setup. All write commands here need
TASKMARKET_RPC_URL and native gas; see
Setting up a vault.
Contents
- Who can do what
- Funding more tokens
- Managers and spend caps
- Withdrawing available tokens
- Emergency exit
- Ownership
- What the owner cannot do
Who can do what
| Action | Contract function | Caller | Vault must be active | CLI |
|---|---|---|---|---|
| Fund | fund(amount) | Anyone | Yes | sponsored-task fund |
| Add, change or deactivate a manager | configureManager(manager, cap, active) | Owner | Yes | sponsored-task managers add / remove |
| Withdraw available tokens | withdrawAvailable(recipient, amount) | Owner | Yes | sponsored-task withdraw |
| Exit the vault | emergencyExitVault(recipient) | Owner | Yes | sponsored-task exit --yes |
| Reserve, release, install settlement | reserveTask, releaseTask, installSettlement | The hook (controller) only | Yes | none |
| Claim an entitlement | claim or claimTo | The worker, or a relayer with the worker's signature | Yes | sponsored-task claim |
| Claim the token fee | claimFee(allocationId, destination) | The snapshotted fee recipient | Yes | none |
Funding more tokens
taskmarket sponsored-task fund --vault <vault address> --token <token> --chain-id <id> --amount <base units>Funding is permissionless: any address can fund an active vault, not only the owner. The vault
accepts only exact transfers; a token that delivers less than amount reverts with
TokenTransferAmountMismatch or TokenSenderAmountMismatch.
Managers and spend caps
A manager account on a vault has four fields:
| Field | Meaning |
|---|---|
cap | Lifetime token allowance in base units. |
reserved | Tokens currently reserved for this manager's unsettled tasks. |
spent | Tokens distributed to winners of this manager's settled tasks. |
active | Whether the manager can reserve new tasks. |
The manager can reserve up to cap - reserved - spent more tokens. Released reservations come off
reserved and free up capacity; distributed tokens stay in spent for good. To let a manager keep
going, raise the cap.
Add a manager, or change an existing manager's cap:
taskmarket sponsored-task managers add --vault <vault address> --chain-id <id> \
--manager <address> --cap <base units>The vault rejects a cap below the manager's current reserved + spent with InvalidManagerCap.
Deactivate a manager:
taskmarket sponsored-task managers remove --vault <vault address> --chain-id <id> --manager <address>remove reads the manager's current reserved + spent and sets the cap to exactly that with
active false. It does not reclaim tokens already reserved: the manager's open tasks still settle
or release normally. Running managers add again reactivates the manager.
List a vault's managers as Taskmarket has indexed them:
taskmarket sponsored-task managers list --vault-id <vaultId>Each entry has vaultId, managerAddress, spendCap, spent and active.
Withdrawing available tokens
taskmarket sponsored-task withdraw --vault <vault address> --chain-id <id> --amount <base units> \
[--recipient <address>]The owner can withdraw up to the vault's available balance at any time, with no timelock. Tokens
reserved for live tasks and tokens owed to winners who have not claimed yet are not available.
Asking for more reverts with InsufficientAvailable. The recipient defaults to your own wallet.
Emergency exit
taskmarket sponsored-task exit --vault <vault address> --chain-id <id> --yes [--recipient <address>]Exit is terminal and cannot be undone. In one transaction the vault:
- Sets its status to exited and advances its epoch.
- Moves every reserved and every claimable token into the defaulted totals.
- Sends the vault's entire token balance to the recipient (your own wallet by default).
After exit, every reservation, entitlement, claim signature and Merkle proof from the old epoch is
void. Workers who had earned but not claimed rewards receive nothing, and the rewards show as
defaulted on their tasks. Each task's USDC reward is not affected. An exited vault accepts no
funding, no new managers, no withdrawals and no claims, and a manager on it reads as inactive.
Without --yes the command stops with This is irreversible. Re-run with --yes to confirm the exit. See Trust and safety for what this means for workers.
Ownership
The vault uses two-step ownership: the current owner proposes a new owner, and the new owner must
accept. renounceOwnership always reverts with OwnershipRenunciationDisabled, because an
ownerless vault would have no one able to recover its tokens. The CLI has no ownership-transfer
command.
What the owner cannot do
- Upgrade the vault. Vaults are non-upgradeable clones.
- Revoke one task's reservation or one worker's entitlement while keeping the vault running. The only revocation is the whole-vault exit.
- Withdraw reserved or claimable tokens while the vault is active.
- Change the fee terms of a task already reserved. The fee rate and recipient are snapshotted at reservation.