Events and qualification
Keep qualification in your application and send a stable audit reference.
An event tells Slices which business decision produced a reward. It does not ask Slices to verify that decision.
All rewards in this version have source: "partner_attested". Your authenticated backend is responsible for the event's qualification and exact reward calculation.
Choose a stable identity#
Use an opaque event ID from your application. Preserve its value and case across retries. Event IDs may be 1–128 characters; event types may be 1–64 letters, digits, underscores, periods, colons, or hyphens.
Within a project, the uniqueness boundary is:
One tuple creates at most one grant, even if a different idempotency key is supplied later. Cancellation does not remove that uniqueness constraint.
Do not change the type from purchase.settled to purchase.verified merely to bypass a duplicate. Treat type conventions as part of your stable integration contract.
One event, two beneficiaries#
A referral may legitimately reward both the referrer and the invited user. Represent the two allocations with explicit event identities:
Each instruction has its own recipient, exact amount, and idempotency key. Slices does not split one grant or infer that two different recipients should be paid for the same tuple.
Supported labels are not native integrations#
| Example label | What your backend must already have done |
|---|---|
referral.qualified | Established attribution, eligibility, and the reward amount. |
card_purchase.eligible | Applied your transaction and refund policy. |
swap.qualified | Identified the trader, verified eligibility, and calculated the allocation. |
vault.period_reward | Calculated the recipient's allocation for a defined position or period. |
These are examples, not a fixed event enum or automatic adapter selection. Slices does not contact a card processor, decode a swap, or measure vault balances based on the label.
What belongs in your records#
Keep the evidence supporting the business decision in your own system: transaction details, referral attribution, measurement period, calculation version, destination authorization, and any cancellation relationship.
The Slices request schema does not accept arbitrary metadata or attachments. Do not encode sensitive evidence into an event string to work around that boundary.
Refunds and corrections#
Define your reversal policy before launch. You can cancel only a reward your operator has not yet approved. A downstream refund or dispute does not recall a sent transfer.
If your use case requires waiting for a hold period or final eligibility decision, implement that waiting period before submitting the reward. There is no scheduled or conditional-grant field in v1.
Related: Idempotency, Referral rewards, and Card rewards.