name	sdp-tokenization
description	Explain, plan, and prototype tokenization workflows on Solana Developer Platform using the supported public docs and API surface. Use when a consumer wants to issue a stablecoin, tokenized security, loyalty token, or other asset with SDP.

SDP Tokenization

Use this skill when someone wants to understand how to tokenize an asset with Solana Developer Platform, map a business requirement to the right token model, or turn that plan into an SDP integration sequence.

Scope

Stay on the supported public surface only:

public docs under apps/sdp-docs/content/docs/**
public API contract in apps/sdp-api/src/openapi/**

Do not rely on hidden or internal route families.

Default workflow

Classify the asset and control model.
Load only the relevant public references from references/tokenization-map.md.
Recommend the right SDP template or custom configuration.
Explain the implementation sequence in order:
- organization and wallet setup
- API key scope and permissions
- token creation
- deployment
- minting, transfers, and redemptions
- allowlist, freeze, pause, and authority operations if needed
Call out operational constraints and authority ownership explicitly.

Output shape

Default to these sections unless the user asks for something narrower:

Asset type and operating model
Recommended SDP template or token configuration
Required wallets, authorities, and permissions
Step-by-step implementation flow
Relevant docs and endpoints
Risks, compliance controls, and operational caveats

Decision rules

Recommend stablecoin for fiat-backed issuance with pause and delegated admin controls.
Recommend tokenized-security for regulated assets that usually need allowlists and stronger compliance controls.
Recommend arcade for closed-loop, loyalty, or gaming-style tokens.
Recommend custom only when templates do not fit the issuance model.
Prefer SDP-controlled custody wallets for mint, freeze, metadata, and other authorities by default.
Treat external or multisig authorities as an advanced path and state that clearly.

Operational guidance

A token must be created before it can be deployed, and deployed before it can be minted or transferred.
Amounts are usually submitted in smallest-unit token amounts, not UI-decimal strings.
Burn, freeze, and similar account-level operations often require a token account address rather than a wallet address.
If a token is paused, minting and transfer-related actions should be treated as unavailable until it is unpaused.
If a workflow needs SDP to sign directly, recommend execute flows first; use prepare flows only when the signer needs to be external to SDP.

When to open more references

Open references/tokenization-map.md first for the public playbook.
Open specific guides only for the steps actually relevant to the user.
Open apps/sdp-api/src/openapi/paths/issuance.ts and apps/sdp-api/src/openapi/paths/payments.ts when the user needs endpoint-level mapping from committed source.

Boundaries

Do not promise legal or regulatory sufficiency; describe product controls and note where legal review is still needed.
Do not invent unsupported issuance templates, custody modes, or hidden APIs.
Do not recommend internal-only routes even if they exist in the codebase.

SDP Tokenization

Scope

Stay on the supported public surface only:

public docs under apps/sdp-docs/content/docs/**

public API contract in apps/sdp-api/src/openapi/**

Do not rely on hidden or internal route families.

Default workflow

Classify the asset and control model.

Load only the relevant public references from references/tokenization-map.md.

Recommend the right SDP template or custom configuration.

Explain the implementation sequence in order:

organization and wallet setup
API key scope and permissions
token creation
deployment
minting, transfers, and redemptions
allowlist, freeze, pause, and authority operations if needed

Call out operational constraints and authority ownership explicitly.

Output shape

Default to these sections unless the user asks for something narrower:

Asset type and operating model

Recommended SDP template or token configuration

Required wallets, authorities, and permissions

Step-by-step implementation flow

Relevant docs and endpoints

Risks, compliance controls, and operational caveats

Decision rules

Recommend stablecoin for fiat-backed issuance with pause and delegated admin controls.

Recommend tokenized-security for regulated assets that usually need allowlists and stronger compliance controls.

Recommend arcade for closed-loop, loyalty, or gaming-style tokens.

Recommend custom only when templates do not fit the issuance model.

Prefer SDP-controlled custody wallets for mint, freeze, metadata, and other authorities by default.

Treat external or multisig authorities as an advanced path and state that clearly.

Operational guidance

A token must be created before it can be deployed, and deployed before it can be minted or transferred.

Amounts are usually submitted in smallest-unit token amounts, not UI-decimal strings.

Burn, freeze, and similar account-level operations often require a token account address rather than a wallet address.

If a token is paused, minting and transfer-related actions should be treated as unavailable until it is unpaused.

If a workflow needs SDP to sign directly, recommend execute flows first; use prepare flows only when the signer needs to be external to SDP.

When to open more references

Open references/tokenization-map.md first for the public playbook.

Open specific guides only for the steps actually relevant to the user.

Open apps/sdp-api/src/openapi/paths/issuance.ts and apps/sdp-api/src/openapi/paths/payments.ts when the user needs endpoint-level mapping from committed source.

Boundaries

Do not promise legal or regulatory sufficiency; describe product controls and note where legal review is still needed.

Do not invent unsupported issuance templates, custody modes, or hidden APIs.

Do not recommend internal-only routes even if they exist in the codebase.

sdp-tokenization