Launch a loyalty / closed-loop token

Sui CLT with allowlist-gated transfers + pause. Holders move points only between addresses you've pre-approved.

Loyalty points and in-app credits work best when they stay in the ecosystem you control. This preset deploys a Sui Closed-Loop Token where the deployer maintains an allowlist of approved recipient addresses (merchants, partners, operator wallets). Tokens minted to users can only flow into that allowlist — there's no escape path through arbitrary wallets, no swap into a generic Coin, no DEX listing by default. Pause is bundled as the emergency stop.

What's included

• Immutable Metadata: Token metadata (name, symbol, icon) cannot be changed after creation
• Closed-Loop Policy (CLT): Rule-gated transfers. Holders receive a policy-gated token instead of a standard coin; the deployer picks which actions (transfer, spend, to-coin, from-coin) are allowed and whether they're open to anyone or gated by an admin-managed allowlist. Use for loyalty points, in-game currency, or closed-ecosystem credits.
• Pausable: Owner can pause all token transfers

Why this stack

Sui's `sui::token` Closed-Loop Token is the only mainstream Move primitive that gates transfers at the type-system level — holders receive `Token<T>` (no `store` ability, no `public_transfer`) and every transfer produces an ActionRequest that must be approved against the deployed TokenPolicy. The allowlist Rule is a `VecSet<address>` config that the deployer manages via two admin functions (add_to_allowlist, remove_from_allowlist) gated by the TokenPolicyCap. Pause covers the case where the closed loop itself needs an emergency halt.

Can I make holders' tokens permanently soulbound instead?

Yes — drop closed-loop-policy from the bundle and enable non-transferable. That registers an empty TokenPolicy: every transfer ActionRequest aborts at confirm_request. The non-transferable + Identity-SBT preset on Sui covers that case.

How do I add addresses to the allowlist after deploy?

The deployed Move module exposes `add_to_allowlist(policy, cap, addr, ctx)` and `remove_from_allowlist`. Call them from the manage page or any wallet that holds the TokenPolicyCap — the same wallet that deployed the token by default.

What happens to tokens sent to non-allowlisted addresses?

The `token::transfer` call returns an ActionRequest; `verify_allowlist_transfer` asserts the recipient is on the list, otherwise the transaction aborts. Tokens never leave the sender's address — there's no failed-and-stranded balance to clean up.