Going live
Activate a funded integration only after configuration, evidence, and canary checks pass.
A deployment and a live reward program are different release decisions. The application can be deployed with issuance disabled while configuration and external behavior are verified.
Confirm the integration agreement#
Document the partner's qualification logic, destination authorization, exact allocation calculation, eligibility requirements, correction policy, and who the operator is: which wallet sends, who holds it, and how often they approve draft campaigns.
Confirm what recipients are told at acceptance, verification, approval, sending, and confirmed delivery. Do not advertise instant delivery, automatic purchases, or guaranteed fully secured acceptance under this initial model.
Supply the approved configuration#
Before live issuance, record the actual HTTPS API origin, reviewed SDK build, production project/key, campaign ID, chain ID, token contract, decimals, approved capacity, maximum grant, and recipient policy.
Provide the operator's sending wallet separately, and keep its key with the operator. Never supply the application or a coding agent with a production private key merely to complete deployment.
No production asset, approval, or API hostname should be inferred from the examples in these docs.
Verify the send profile#
The operator's evidence must establish the correct chain and deployed token contract, the token's transfer behavior, the net amounts and the Slices fee, the sending wallet and its balance, the recipient verification path, the finality and confirmation requirements, and the receipt verification.
Do not equate a wallet's success message or a balance change with a verified receipt into the recipient's wallet.
An unresolved capability is a release blocker, not permission to replace it with a fixture, a different asset, or a looser settlement definition without approval.
Verify application safety#
Confirm successful API/SDK integration, project isolation, key rotation, budget concurrency, duplicate-event protection, cancellation/approval races, background-job recovery, RPC-outage handling, and evidence corrections.
Check that the dashboard uses real authenticated data, that production cannot silently activate fixture authentication or fixture chain responses, and that migrations and backup restoration have a controlled process.
Production readiness includes a usable incident procedure and a tested way to stop new issuance and sending without losing records.
Run the authorized canary#
Move from disabled to canary only after the relevant checks pass. Use a very small approved cap and named eligible recipients. Canary mode can move real value.
Issue through the ordinary partner API, let the recipient verify, approve the draft campaign in the dashboard, send from the operator's wallet, and verify the receipt in the API and the dashboard. Preserve the artifacts and evidence used for the decision.
Do not skip the final delivery check because the transfer is slow. Do not run a second payment to make an unresolved first payment appear successful.
Approve live mode#
Move to live only after the canary's exact net amounts and evidence pass review and a human authorizes activation. Start with bounded volume and observe the approval cadence, the oldest queued grants, and the freshness of receipt verification.
The three checkpoints are implemented, operator-verified, and live-approved. They are not interchangeable.
Respond to an incident#
Pause new issuance and coordinate holds on approval and sending with the operator. Preserve approved drafts, known transaction hashes, and wallet nonces. Keep safe evidence reads running so uncertainty can be resolved.
Restoring an older database does not reverse a sent transfer. Reconcile restored records against immutable grant identities, draft campaigns, and chain facts before enabling workers.
Related: Testing your integration, Dashboard, and Security.