Capabilities and limitations
What the v1 partner payout integration includes, and what stays outside it.
The v1 integration is designed around one clear boundary: your trusted backend tells Slices which existing wallet should receive an exact amount of the approved campaign token, and your operator's own wallet sends it.
Included#
| Capability | Boundary |
|---|---|
| Exact allocation issuance | One recipient and one positive base-unit token amount per request. |
| Campaign controls | Approved asset/network, issuance cap, per-grant limit, and recipient policy. |
| Durable grant records | Stable IDs, event deduplication, idempotent writes, and audit history. |
| Cancellation | Accepted and queued grants only, before the operator's approval. |
| Recipient verification | One wallet signature and location observation per wallet and campaign, on a page Slices provides and links from the reward. |
| Draft campaigns | Grants queue into a draft of up to 100 recipients on one asset that the operator reviews and approves with one signature. |
| Sending | One prepared, preflighted transfer per reward, sent by the operator's own wallet; the Slices fee transfer first. |
| Receipt verification | A per-minute job verifies every sent transfer against the chain and rechecks inclusion for 24 hours. |
| Reporting | Reward and campaign reads, a business dashboard, and transfer evidence. |
| TypeScript server SDK | Thin client for the six documented HTTP operations. |
The initial operating scope is one partner, one approved token, and one EVM chain. Project scoping and pagination do not imply an open multi-asset marketplace.
Not included#
| Capability | What to do in v1 |
|---|---|
| Native card, swap, referral, or vault verification | Qualify the activity in your own backend. |
| Reward policy engine or price conversion | Calculate and persist the exact token allocation before issuance. |
| Token procurement, minting, swaps, or bridging | The operator holds the reward tokens in their own wallet. |
| Email recipients or Slices-managed Privy wallets | Supply an authorized existing wallet address. |
| Browser-authorized reward issuance | Call Slices only from your trusted server. |
| Embedded recipient SDK or hosted recipient account | Recipients verify their wallet once on the page Slices provides; nothing else is asked of them. |
| Outgoing webhooks | Poll the documented read API. |
| Public campaign creation or asset catalog | Complete operator onboarding and read the configured campaign. |
| Bulk issuance | Submit individual instructions with bounded concurrency; Slices groups them into draft campaigns. |
| Server-side signing or automatic sending | Every approval and every transfer is signed by the operator's wallet. |
| Guaranteed instant or automatic receipt | Display the queued, approved and sent states; nothing moves until the operator sends. |
| Refunds, debits, clawbacks, or partial delivery | Use the cancellation window before approval and your own correction policy. |
| Gas sponsorship for recipients | The operator's wallet pays gas for each transfer; recipients pay nothing to receive one. |
What "approved" means#
Your operator reviewed the draft campaign and signed the exact allocation. It does not mean tokens moved: each transfer still needs the operator's wallet, the Slices fee transfer confirms first, and a transfer the preflight refuses is not sent.
A campaign issuance cap is not a balance in the operator's wallet. An accepted grant reserves authorization; the wallet balance is checked by the quote before each approval.
What "delivered" means#
Slices verified one transfer receipt for this reward: the operator's wallet sent the exact amount to the recipient's wallet on the campaign's network, with the required confirmations, and canonical inclusion held. There is no cumulative claim and no partial delivery; deliveredAmountBaseUnits is "0" or the full amount.
Insufficient or unverifiable evidence keeps the reward sent, visibly. This is a release requirement, not a reason to guess that delivery happened.
Expansion without changing the first contract#
Your application can add new qualified event sources while continuing to submit the same recipient, exact amount, and event reference. That is the first expansion path.
Native event verification, email resolution, automated sending, procurement, and outgoing webhooks would each require an additional documented capability. Do not build dependencies on them merely because the current API can accept an event label associated with that use case.
Related: Overview, API overview, and Going live.