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.
1---2name: sdp-tokenization3description: 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.4---56# SDP Tokenization78Use 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.910## Scope1112Stay on the supported public surface only:1314- public docs under `apps/sdp-docs/content/docs/**`15- public API contract in `apps/sdp-api/src/openapi/**`1617Do not rely on hidden or internal route families.1819## Default workflow20211. Classify the asset and control model.222. Load only the relevant public references from `references/tokenization-map.md`.233. Recommend the right SDP template or custom configuration.244. Explain the implementation sequence in order:25 - organization and wallet setup26 - API key scope and permissions27 - token creation28 - deployment29 - minting, transfers, and redemptions30 - allowlist, freeze, pause, and authority operations if needed315. Call out operational constraints and authority ownership explicitly.3233## Output shape3435Default to these sections unless the user asks for something narrower:3637- Asset type and operating model38- Recommended SDP template or token configuration39- Required wallets, authorities, and permissions40- Step-by-step implementation flow41- Relevant docs and endpoints42- Risks, compliance controls, and operational caveats4344## Decision rules4546- Recommend `stablecoin` for fiat-backed issuance with pause and delegated admin controls.47- Recommend `tokenized-security` for regulated assets that usually need allowlists and stronger compliance controls.48- Recommend `arcade` for closed-loop, loyalty, or gaming-style tokens.49- Recommend `custom` only when templates do not fit the issuance model.50- Prefer SDP-controlled custody wallets for mint, freeze, metadata, and other authorities by default.51- Treat external or multisig authorities as an advanced path and state that clearly.5253## Operational guidance5455- A token must be created before it can be deployed, and deployed before it can be minted or transferred.56- Amounts are usually submitted in smallest-unit token amounts, not UI-decimal strings.57- Burn, freeze, and similar account-level operations often require a token account address rather than a wallet address.58- If a token is paused, minting and transfer-related actions should be treated as unavailable until it is unpaused.59- 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.6061## When to open more references6263- Open `references/tokenization-map.md` first for the public playbook.64- Open specific guides only for the steps actually relevant to the user.65- 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.6667## Boundaries6869- Do not promise legal or regulatory sufficiency; describe product controls and note where legal review is still needed.70- Do not invent unsupported issuance templates, custody modes, or hidden APIs.71- Do not recommend internal-only routes even if they exist in the codebase.