Menu
Documentation
Operations Dashboard

Dashboard

Read the same reward records as the API, approve draft campaigns, and send transfers from the operator's wallet.

The dashboard is the business and operations interface for the same reward records exposed by the API. It is where your operator approves draft campaigns and sends transfers from their own wallet. It is not a separate balance system or treasury, and it holds no signing key.

Overview#

Read the approved token and network alongside authorized capacity, available issuance capacity, queued obligations, approved obligations, and delivered quantity.

These values are token quantities. The dashboard does not invent a USD portfolio value or label authorized capacity as tokens held by Slices.

Watch the oldest queued reward, the open draft campaign, the latest successful receipt verification, and unresolved incidents. A healthy application server does not establish that the operator's wallet has sent anything.

Rewards#

Inspect the reward ID, event reference, wallet, exact amount, status, the recipient's verification status, and the draft campaign it was queued into. Open a reward to see its original instruction, its history, and its transfer evidence.

Where your role permits, cancel an eligible accepted or queued reward with a reason and explicit confirmation. The action is not available after approval. There is no force-mark-paid control or edit-in-place amount field.

Copy controls should preserve full addresses, quantities, and hashes even when a table abbreviates them for display.

Draft campaigns#

A draft campaign lists its recipients and exact amounts, the recipient count and net total, the Slices fee, and the quote: every recipient's verification, the operator's wallet balance and gas, and the policy version the approval will bind.

Operator actions are to review the draft, sign the approval with the operator's wallet, send each prepared transfer from that wallet, prepare another attempt after a failed transfer, and close the draft. Each send is one wallet request for exactly the transfer Slices prepared; the dashboard never composes a different transaction, and Slices never sends one.

"Approve" does not mean "sent": the operator's wallet still has to send each transfer. "Sent" does not mean "delivered": the receipt is verified by the job before the reward changes. Read the status after each step rather than assuming it.

Campaign#

Inspect the configured asset, cap, maximum grant amount, issuance mode, and active/paused status. An owner may pause new issuance; resumption and profile activation are operator-gated.

A campaign's rules are set here, one per event type: the reward for one event of that type and, optionally, a per-wallet cap for it. A rule lets your backend send the event without an amount; the amount it carries, when it does, is always used instead. Rules price rewards and bound them; they do not change the asset, the budget or the maximum grant, which stay the campaign's own fields. There is no open asset picker, automated procurement control, or ordinary cap-editing screen.

Developers#

Find the approved API origin and installation information. Create, inspect, and revoke scoped server keys where your role permits. The full secret is displayed once. Store it securely rather than pasting it into a browser example or a screenshot.

Public API keys do not authorize dashboard operator actions. Do not build customer integrations against the dashboard's internal routes.

Activity and issues#

Use the audit timeline and issue views to investigate failed transfers, transfers whose outcome the browser could not report, receipts the job could not verify yet, and expired recipient verifications.

A retry repeats preparation for the same reward under controlled state; it is not an unrestricted new token payment. Escalate unresolved evidence rather than forcing a successful status.

Roles#

RoleResponsibilities
Partner ownerRead project records, manage scoped keys, pause new issuance, and cancel eligible accepted or queued rewards.
Partner viewerRead authorized project data and available reports.
OperatorThe holder of the sending wallet: reviews and approves draft campaigns, sends each transfer, retries failed ones, closes drafts, and operates the campaign's controls and launch gates.

Only the operator's wallet can approve or send, and only for the transfers Slices prepared. Backend authorization applies to every action, regardless of which controls appear in a browser.

Reports and sensitive artifacts#

Treat downloaded reports as sensitive project data. A draft campaign's allocation discloses wallet addresses and amounts, and the resulting transfers are visible on a public chain. Avoid embedding personal event identifiers in reason labels.