Swap rewards

Issue rewards for trades your application has already attributed and qualified.

Use Slices after your trading application verifies a qualifying swap and calculates a reward. Slices does not index a DEX, inspect a router, identify the trader, or evaluate trading behavior in this version.

Establish the eligible trade#

Your backend determines the relevant chain, venue, transaction or action, trader identity, qualifying asset pair, finality policy, and program limits. It also decides which activity is excluded, such as self-generated or otherwise ineligible trading under your program rules.

A transaction hash supplied by a browser is not sufficient on its own to authorize a reward. Verify the activity and bind the authorized wallet in your own system first.

Choose one economic event identity#

A transaction can contain more than one action. Define the exact unit your program rewards and assign one stable internal event ID to it. That identity should survive indexing retries and repeated notifications.

If your internal ID derives from chain, transaction, and log or action identity, ensure the final string fits the event limit. Do not make the idempotency key longer than 128 characters; a stable digest or opaque database ID can keep it bounded.

Submit an allocation#

const reward = await slices.rewards.issue({
  campaignId: approvedCampaignId,
  recipient: { walletAddress: authorizedTraderWallet },
  amountBaseUnits: calculatedTradeReward,
  event: {
    id: qualifiedTradeRewardId,
    type: "swap.qualified",
  },
  idempotencyKey: `swap:${qualifiedTradeRewardId}`,
});

The reward is denominated in the approved campaign token. The request cannot choose the input or output token from the trade as a payout asset.

calculatedTradeReward must already be a positive integer base-unit string. This API does not convert trade volume, fees, or USD notional into a reward.

Finality and reversals#

Choose your activity-confirmation policy before issuance. If the source activity becomes invalid, only a reward the operator has not yet approved remains cancellable. A trading-chain reorganization does not automatically cancel a Slices reward or undo a claim on the reward chain.

Keep the evidence supporting qualification and any correction in your own records. Slices stores the opaque event reference, not an arbitrary transaction-evidence blob.

The reward network is fixed#

Your activity may originate elsewhere, but the operator's wallet sends only on the campaign's configured reward chain. Slices does not bridge balances, route between networks, or assume that a wallet can receive a transfer merely because the same address exists on another network.

Validate recipient access to the reward chain as part of onboarding.

What you can build next#

You can add more verified trading-event sources in your backend without changing the Slices issuance interface. Native verification by Slices would be a separate integration capability, not a new interpretation of event.type.

Related: Recipients, Events and qualification, and Idempotency.