Integration guides Vault rewards

Vault rewards

Submit calculated vault allocations without building a native vault integration into Slices.

Use the partner payout API when your application already calculates who earned a vault reward. Your backend measures the position or activity, applies the reward rules, and sends final token allocations to Slices.

This is not a token-holding campaign model. Slices does not measure vault balances or run a yield strategy in this release.

Define the measurement policy#

Decide whether the reward is based on a deposit, a holding period, time-weighted balances, or another clearly defined rule. Your calculation must account for the receipt token, asset/share conversion where relevant, the measurement interval, recipient mapping, and your exclusion policy.

Store the calculation inputs and version in your own system. The Slices event is an audit reference, not a full position record.

Finalize one allocation per recipient and period#

Produce an exact amount for each eligible wallet. Persist the result before publication so recalculating a period cannot silently change amounts during an API retry.

const reward = await slices.rewards.issue({
  campaignId: approvedCampaignId,
  recipient: { walletAddress: positionOwnerWallet },
  amountBaseUnits: calculatedPeriodAllocation,
  event: {
    id: periodRecipientAllocationId,
    type: "vault.period_reward",
  },
  idempotencyKey: `vault:${periodRecipientAllocationId}`,
});

periodRecipientAllocationId should identify one intended allocation, for example through your immutable calculation-run and recipient records. Make it stable and bounded rather than concatenating unlimited raw identifiers.

Sending many allocations#

The API accepts one reward per request. There is no public bulk-issuance endpoint. Send your finalized allocations through a bounded worker pool, retain a result per instruction, and respect the project rate limit.

A calculation run is not atomically accepted as a whole. Some grants may succeed while others are rejected for capacity, recipient policy, or malformed input. Preserve successes, correct or investigate the remaining instructions, and do not restart the entire run with fresh keys.

Slices queues accepted grants into draft campaigns of up to 100 recipients, which your operator approves and sends from their wallet; a run of 350 allocations is four approvals. Your calculation period and a draft campaign do not have to be the same object.

Corrections and late data#

Do not revise an accepted amount in place. Before the operator's approval, an eligible grant can be cancelled. A corrected allocation needs a deliberately authorized new event identity and a record of the relationship in your system.

After approval, coordinate a review rather than assuming a late accounting adjustment can retract the existing allocation. The reward API has no negative grants or automatic netting endpoint.

No asset management is implied#

The integration does not deposit into a vault, harvest yield, redeem shares, reinvest, or buy reward inventory. Your users keep using the existing vault and wallet experience. Slices is the controlled distribution and reporting layer for the allocations you supply.