Campaigns and sending Funding and budgets

Funding and budgets

Tell an issuance cap, the operator's wallet balance, and a sent transfer apart.

An issuance cap, a wallet balance, and a sent transfer are different things. Slices tracks them separately so that accepting a reward never implies that tokens have moved, or even that they are on hand.

The issuance cap#

The approved campaign cap limits how many net token units your integration may promise through Slices. New grants consume that capacity when accepted.

text

authorized capacity
  = available capacity
  + queued obligations
  + approved obligations
  + delivered quantity

The corresponding API fields live in campaign.budget:

Field	Meaning
`authorizedBaseUnits`	Total approved net issuance authorization.
`availableBaseUnits`	Capacity that can still be used for new grants.
`queuedBaseUnits`	Accepted and queued allocations the operator has not yet approved.
`approvedBaseUnits`	Approved allocations without a verified delivery: approved, sent, or failed and awaiting a retry.
`deliveredBaseUnits`	Allocations whose transfer receipt has been verified.

All quantities use the same campaign asset and integer-string representation.

A simple example#

Assume a campaign authorizes 100 tokens and a customer issues a 10-token grant.

Step	Available	Queued	Approved	Delivered
Before issuance	100	0	0	0
Grant accepted	90	10	0	0
Draft campaign approved	90	0	10	0
Transfer receipt verified	90	0	0	10

The example uses whole token units for readability. API values remain base-unit strings. Delivery does not restore the original 100-token capacity. Cancelling the grant before approval would restore the 10 tokens of capacity instead. A failed transfer keeps its 10 tokens in the approved account until the operator's retry delivers or the draft campaign is closed with the transfer unsent.

Who supplies the tokens?#

Your operator does, from their own wallet. There is no Slices treasury, escrow, or signing key. The dashboard's quote for a draft campaign checks that wallet's token balance and gas before the operator approves, and Slices prepares each transfer against the same wallet; a transfer the wallet cannot cover is not sent.

A campaign issuance cap is not a balance in the operator's wallet. The cap is the authorization limit Slices enforces at acceptance; the wallet balance is what the transfers actually draw on. Keep both in view: an accepted grant with an under-funded operator wallet stays queued or approved until the wallet can send it.

Net amounts and the Slices fee#

amountBaseUnits is always the recipient's exact net entitlement. The Slices fee is quoted separately for each draft campaign, in the same asset, and the operator's wallet pays it as its own transfer before the first recipient transfer. Insufficient balance for the fee must not shrink recipient allocations; the quote shows the net total, the fee, and the gross requirement apart.

Fee rules, and what happens to a fee when a draft campaign closes with transfers unsent, follow the approved campaign profile: a fee refund is a separately verified transfer, never automatic. These docs do not hardcode a universal fee or refund formula.

Approving a draft campaign#

Review every recipient and exact amount, the asset and network, the recipient count, the net total, the fee, and the wallet check. Sign the approval only through the operator's own wallet; the signature covers the exact allocation and nothing else is inferred from it. Each transfer then needs that wallet again, one at a time. See Approval and sending.

Delays and incidents#

Keep queued obligations visible while a draft campaign waits for approval, and approved obligations visible while transfers are sent. Stop new issuance when the operator's wallet no longer supports the program. Do not create a replacement reward because a transfer failed or its outcome is uncertain: the operator's retry keeps the same reward, and Slices verifies which transaction actually paid it.

Related: Approval and sending, Cancel a reward, and Dashboard.