- 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
1. Classify the asset and control model.
2. Load only the relevant public references from `references/tokenization-map.md`.
3. Recommend the right SDP template or custom configuration.
4. 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
5. 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.
GitHubで見る