Approval and sending
Understand the path from an accepted grant to a verified transfer out of your operator's wallet.
Slices sends nothing by itself. Issuing a reward records an instruction; your operator approves each draft campaign in the dashboard and their own wallet sends each transfer. Slices prepares and verifies every step in between.
1. Queue into a draft campaign#
An accepted grant whose recipient has verified their wallet joins the campaign's open draft campaign. A draft holds up to 100 recipients on one asset, one transfer per wallet; a grant to a wallet already in the open draft waits for the next one, and so does a grant to an unverified wallet. Each grant belongs to at most one draft campaign.
Once the operator approves a draft it is closed to new grants, and the next accepted grant opens the next draft. A campaign produces many draft campaigns over time; the two uses of "campaign" are not interchangeable.
2. Review and approve#
The operator opens the draft in the dashboard and sees every recipient and exact amount, the recipient count and net total, the Slices fee, and the quote's check of their wallet's balance and gas. Every recipient must still be verified and unexpired; the quote says which are not.
The operator signs one approval over that exact allocation with their wallet. The signed text names the draft campaign, the asset and network, the allocation digest, the recipient count and total, the fee and the policy version, and states that each token transfer still requires the wallet's authorization. Slices verifies the signature against the operator's wallet address before recording the approval. Cancellation through the API ends here; an approved reward returns 409 INVALID_STATE to POST /v1/rewards/{rewardId}/cancel.
3. Prepare and send#
Slices prepares one transfer at a time from the approved draft: it re-checks the execution policy, the operator's session and wallet, the recipient's verification, and the campaign's approval, takes a lock on the operator's wallet so that only one request is outstanding, and simulates the exact transfer(recipient, amount) call over RPC. A transfer whose preflight fails is not sent; the reason is recorded and the operator can prepare it again.
The operator's wallet then sends exactly that call: the same recipient, amount, token, nonce, and gas the preflight established, from the same wallet. The Slices fee transfer confirms before the first recipient transfer. Slices records the transaction hash the wallet returns and the reward becomes sent.
There is no server-side signing, no relayer, and no batching of transfers into one transaction. One reward is one transfer.
4. Verify the receipt#
A job runs every minute and checks each sent transfer against the chain: the sender, the recipient, the token, the exact amount, the Transfer log, and the required confirmations. When they match, the reward becomes delivered and deliveryEvidence carries the transaction hash, block, confirmations, finality, and log index. Canonical inclusion is rechecked for 24 hours after that.
A wallet request whose outcome the browser could not report is verified the same way; the job resolves it from the chain, including a replacement transaction that consumed the nonce without paying the recipient. delivered is never inferred from a wallet's success message or a balance change.
5. Failures and retries#
A declined wallet request or a reverted transaction makes the reward failed, with statusReason saying which. Nothing was delivered and the reserved capacity stays with the reward. Slices never retries by itself: the operator prepares another attempt from the dashboard, after the chain has finalized past a reverted transaction, which returns the reward to approved and then through sent again. The same reward, never a second one.
An unresolved outcome never authorizes a second payment. Investigate with the reward ID and the transaction hashes in its evidence.
Closing a draft campaign#
The operator can close a draft campaign with transfers unsent. Those rewards become cancelled and their capacity is restored once; delivered transfers are untouched. A fee already paid for the closed draft is refunded, where the profile allows it, by a separately verified transfer, never automatically.
Automation and gas#
The operator's wallet pays gas for the fee transfer and each recipient transfer on the campaign's network. Recipients pay nothing to receive a transfer and take no action beyond verifying their wallet once. No gas-sponsorship promise applies to anything the recipient does afterwards.
Related: Reward states, Funding and budgets, and Troubleshooting.