Campaigns

Read the approved configuration that governs every reward instruction.

A campaign is the control boundary for a reward program. It fixes the network, token, token decimals, authorized issuance capacity, and maximum grant size.

A campaign produces many draft campaigns over time, each of up to 100 recipients on the campaign's asset, which your operator approves and sends from their own wallet. The two uses of “campaign” are not interchangeable: the campaign is the program, and a draft campaign is one approved set of transfers.

Read the configuration#

const campaign = await slices.campaigns.get("cmp_pilot001");

console.log({
  asset: campaign.asset,
  status: campaign.status,
  issuanceMode: campaign.issuanceMode,
  available: campaign.budget.availableBaseUnits,
  maximumGrant: campaign.maximumGrantBaseUnits,
});

The HTTP equivalent is GET /v1/campaigns/{campaignId}. Use GET /v1/campaigns to list the campaigns accessible to the current key.

Creation and configuration#

Campaigns are created and configured in the dashboard, where each one carries its event-type rules (see Campaign object). This version has no public POST /v1/campaigns endpoint or campaign-update endpoint.

Agree the token profile, issuance cap, maximum grant amount, recipient policy, the operator's wallet, and production mode before sending rewards. Do not create a guessed campaign ID and expect the API to provision it.

The request to issue a reward cannot change the campaign's asset, network, or spending limits. Reward qualification and calculation stay in your application.

Capacity is not custody#

budget.availableBaseUnits is the remaining authorized issuance capacity. It is not an available-to-withdraw balance and does not establish that Slices holds the reward inventory.

Acceptance moves quantity from available capacity to queued obligations. The operator's approval moves it to approved obligations. A verified transfer receipt moves it to delivered quantity. Delivery does not replenish the issuance cap.

See Funding and budgets for the accounting model.

Status and issuance mode#

status is active or paused. A pause prevents new rewards from being accepted, but it does not cancel existing grants or stop read-only reconciliation.

issuanceMode is disabled, canary, or live. It records whether the campaign is enabled for the approved release stage. An active campaign in disabled mode is not ready for issuance.

Check both fields for display and diagnostics. The backend remains authoritative: a configuration can change between a read and a subsequent issuance request.

Pausing and resuming#

An authorized owner can pause new issuance from the dashboard. Resuming is operator-gated. A pause does not withdraw an approval, recall a sent transfer, or stop the operator sending the transfers of an already approved draft campaign.

Approval and sending have their own operational holds. Coordinate those with the operator during an incident rather than assuming the campaign pause alone stops every external action.

Limits and changes#

A grant must fit both the maximum grant amount and remaining campaign capacity. These checks are atomic; two callers cannot both consume the same remaining capacity.

Ordinary v1 dashboard operations do not edit the issuance cap. Any additional authorization requires the reviewed operator workflow and an audit reference. Topping up the operator's wallet does not increase the cap.

Reference: Get a campaign, List campaigns, and Campaign object.