Recipients
Use an authorized existing wallet as the reward destination.
The initial recipient model is one existing EVM wallet address. Your application establishes who is entitled to the reward and which wallet is authorized to receive it.
This is a synthetic example, not a production destination.
Address validation#
Slices requires a 0x-prefixed, 40-hex-character address. The zero address is rejected. Incorrect mixed-case checksums are rejected; valid all-lowercase or all-uppercase hex addresses are normalized before storage.
Structural validation does not prove wallet control, recipient identity, token eligibility, or the recipient's location; verification does, below. Apply your authentication, account-to-wallet binding, and eligibility checks before calling the API.
The campaign determines the network#
A recipient address is interpreted on the campaign's configured chain. The request cannot select another network. Confirm that the recipient can access the approved wallet on that chain.
A wallet address is not an instruction to bridge tokens. Matching address text on two EVM networks does not cause a reward on one network to appear on the other.
Existing embedded and smart-contract wallets#
An existing wallet from your own wallet provider can be used when it passes the campaign's recipient policy and can receive a plain ERC-20 transfer. This version does not create that wallet or require your customer to open a separate Slices account.
For smart-contract wallets or specialized custody arrangements, confirm during onboarding that the wallet accepts an ERC-20 transfer and that its owner can sign the verification message. Passing the address-format check is not a compatibility certification.
Recipient verification#
Whether a recipient must verify the wallet is the campaign's verification setting. With off, the v1 default, your backend's attestation is the eligibility record: the reward queues at once and its recipient.verificationStatus is not_required. With required, a grant is queued for approval only once its recipient has verified the wallet: they sign a message with it, and their location is observed by the trusted edge, on the verification page Slices provides for the campaign. Until then the reward stays accepted with recipient.verificationStatus: unverified, and it never blocks a draft campaign from being approved. A verification can be expired before approval and must then be renewed; a location outside the campaign's policy is blocked.
The reward carries the link: recipient.verificationUrl is the verification page for that wallet and campaign, issued when the reward is accepted and reissued when a verification expires, null once the recipient is verified. Show it to the authenticated user who owns the wallet, from the moment the reward is recorded; it holds an unguessable token and must not be published or logged. There is no separate operation to create one. Verification is per wallet and campaign, not per reward: a verified wallet's later grants queue at once.
Recipient controls#
An approved campaign can enforce recipient restrictions, particularly during a canary. A disallowed destination produces RECIPIENT_NOT_ALLOWED. Do not interpret acceptance as an independent legal eligibility determination: the partner still owns the agreed recipient and asset checks.
Avoid placing identity information in event IDs. Slices needs a stable business reference and wallet, not an email address or a copy of the user's purchase details.
Changing a destination#
There is no update-recipient endpoint. An accepted instruction keeps its original destination. Before the operator's approval, an authorized caller can cancel an incorrect grant. A replacement requires a deliberate new reward instruction and event identity; it is not an automatic retry.
After approval, stop and investigate with the operator. Do not submit the same reward to another wallet while assuming the original transfer will not be sent.
Email recipients#
Email input and Slices-managed Privy provisioning are outside this version. Supplying recipient.email or a user ID instead of walletAddress fails the request schema. An application that already uses Privy can resolve its own existing wallet before calling Slices.
Related: Grant a reward, Assets, and Security.