Reward states

Read a reward's status from acceptance, through your operator's approval, to the verified transfer.

A reward has one status. It says how far the reward has travelled from your backend's instruction to a verified token transfer out of your operator's wallet, and it is the only field to branch on. recipient.verificationStatus, statusReason and deliveryEvidence explain a status; they never replace it.

Status#

accepted → queued → approved → sent → delivered
   │          │         │        └──→ failed ──(the operator retries)──→ approved
   └──────────┴──→ cancelled ←── approved or failed, when the draft campaign closes with this transfer unsent

This is the normal progression, not a guarantee that a poll will observe every intermediate state. A reward can go from queued to sent between two reads.

Accepted, then queued#

Acceptance stores the instruction and reserves capacity against the campaign's issuance cap. It does not put the grant in front of your operator yet. A grant becomes queued when Slices adds it to the campaign's open draft campaign, which needs two things:

• A verified recipient. The recipient proves control of the wallet and their location once, through the verification page Slices provides and links from the reward (recipient.verificationUrl); see Recipients. A grant to an unverified wallet stays accepted with recipient.verificationStatus: unverified, and never blocks a draft campaign from being approved.
• Room in the draft. A draft campaign holds up to 100 recipients on one asset, one transfer per wallet. A second grant to a wallet that is already in the open draft waits for the next one.

Once the operator approves a draft, it is closed to new grants and the next accepted grant opens the next draft. See Approval and sending.

Approved: the commitment boundary#

Your operator reviews the draft campaign in the dashboard, with every recipient, exact amount and the Slices fee in front of them, and signs one approval over that exact allocation with their wallet. From that moment the reward cannot be cancelled through the API; POST /v1/rewards/{rewardId}/cancel returns 409 INVALID_STATE.

Approval is not a transfer. Slices holds no signing key. Each transfer is prepared server-side (policy, recipient verification, wallet lock and an RPC preflight of the exact transfer(recipient, amount) call) and then sent by the operator's own wallet, one request at a time. The Slices fee transfer confirms before the first recipient transfer.

Sent, then delivered#

sent means the operator's wallet was asked to send this transfer. Slices records the transaction hash the wallet returns and a per-minute job verifies the receipt: the sender, the recipient, the token, the exact amount, the transfer log and the required confirmations. Canonical inclusion is rechecked for 24 hours after that. A wallet request whose outcome the browser could not report is also sent; the job resolves it from the chain.

delivered is one verified transfer per reward. deliveryEvidence carries its transaction hash, block, confirmations, finality and log index. See Reward object.

Failed#

failed means the last attempt did not deliver: the wallet declined the request, or the transaction reverted onchain. Slices never retries by itself. The operator can prepare another attempt from the dashboard, a reverted one only after the chain has finalized past it, which returns the reward to approved. The reserved capacity stays with the reward. statusReason says which it was.

Cancelled#

cancelled is terminal and restores the reserved capacity once. It has two sources: your backend cancelled the reward while it was accepted or queued, or the operator closed the draft campaign while this transfer had not been sent. A cancelled reward keeps its identity and history; it is not deleted.

Capacity, not funding#

A campaign issuance cap is not a balance in the operator's wallet. The cap is the authorization limit Slices enforces when it accepts grants; the tokens themselves sit in the operator's wallet until that wallet sends each transfer. The dashboard's quote checks the wallet's balance and gas before approval, and campaign.budget reports the cap's accounts. See Funding and budgets.

What "delivered" establishes#

A delivered reward had its exact amount transferred to the recipient's wallet in one transaction from the operator's wallet, and that receipt was verified against the instruction. deliveredAmountBaseUnits is either "0" or the reward's full amountBaseUnits; there is no partial delivery.

"Delivered" is not a current wallet-balance assertion. A recipient can subsequently transfer tokens elsewhere.

What not to do#

Do not mark a reward delivered when the issue request succeeds, the user sees a notification, the operator approves the draft, or an unrelated transfer succeeds. Do not create a new reward because delivery is delayed or because an attempt failed: the operator's retry keeps the same reward.

Related: Track rewards, Reward object, and Troubleshooting.