Security
Understand the authorization boundary and protect keys, recipients, and irreversible allocations.
Slices' v1 integration separates permission to record rewards from authority to sign transfers. Your server authorizes the allocation; your operator approves each draft campaign and sends each transfer from their own wallet; Slices records, prepares and verifies the resulting workflow.
These docs describe the security requirements of that integration. They are not a claim of an independent audit, insurance coverage, regulatory approval, or a published certification.
Keep reward authorization on your server#
A client-side click must not authorize a payment. Your backend authenticates the user, verifies the business activity, determines eligibility, chooses the wallet and amount, and then calls Slices with a scoped server key.
If your frontend requests a reward, it should reference an activity your server can independently authorize. Never trust a browser-supplied recipient, amount, or verified flag as the final decision.
Protect API keys#
Store keys in your secret manager or protected backend environment. Use minimum campaign and operation access, separate environments, and a reviewed rotation process. Revoke suspected exposed keys immediately.
The SDK requires HTTPS outside loopback development and must not follow redirects that could expose credentials. Do not send a Slices key to a third-party endpoint or a user-supplied URL.
Preserve project isolation#
Every resource and operation is authorized within its project and environment. Browser-selected organization IDs, guessed reward IDs, or an old idempotency key do not create access rights.
Dashboard authentication, local project membership, and operator authority are separate checks. A partner API key does not provide console operator privileges.
Prevent duplicate or excessive issuance#
Use durable event identities, explicit idempotency keys, atomic capacity checks, and immutable accepted allocations. Do not regenerate keys on timeouts or discard deduplication history after cancellation.
Campaign caps control authorized obligations; they do not mean Slices holds a cash deposit. A stolen valid key can still misuse the access and remaining capacity granted to it, so caps are not a substitute for protecting credentials.
Signing stays in the operator's wallet#
Slices holds no signing key and never sends a token on anyone's behalf. The operator signs one approval over each draft campaign's exact allocation, and their wallet then authorizes each transfer separately: exactly the transfer(recipient, amount) Slices prepared and preflighted, with the same recipient, amount, token, nonce, and gas, from the same wallet. There are no token allowances to grant and no contract to fund.
A prepared transfer is not safe merely because it came from an API. The operator's wallet shows the call before signing; verify the network, token, recipient, and amount there. “No Slices signer” does not mean there are no wallet, token-contract, or chain risks.
Treat approval as the commitment boundary#
Once the operator has approved a draft campaign, its rewards cannot be cancelled through the API, and a sent transfer cannot be recalled. Do not close and recreate a draft just because a transfer failed or an operator is uncertain about its outcome: the same reward is retried, and Slices verifies which transaction paid it.
Cancellation is available only before approval. The Slices API provides no clawback or refund operation.
Minimize sensitive data#
Use opaque event references, not emails, card data, names, or transaction descriptions containing personal information. Do not attach arbitrary metadata; the request schema deliberately excludes it.
A draft campaign's allocation discloses wallet addresses and quantities. Treat internal reports as sensitive even when the resulting transfers use a public chain. Request and job logs must exclude secrets.
Evidence and incident handling#
A delivered status requires the verified transfer receipt. Neither an operator button, nor a wallet's success message, nor a current wallet balance substitutes for that evidence.
When evidence is stale, conflicting, or invalidated, preserve history and show the state as it is. Stop new issuance or sending where appropriate, revoke compromised credentials, and reconcile known transactions before taking further economic action.
Use the security contact or support procedure supplied during onboarding. Include identifiers and sanitized facts; never send keys or seed phrases.
Related: Authentication, Idempotency, and Going live.