Mint account
Stores supply, decimals, mint authority, and optional freeze authority for the token.
Account model
Four roles define a basic SPL mint.
Token account
Stores a balance for one mint and one account authority.
Owner wallet
Controls the destination account or is used to derive an associated token account.
Mint authority
Authorizes new units through a key, multisignature, program, or governance path.
Destination resolution
Derive, validate, and record the receiving account.
The API can create an associated token account idempotently when it is missing, then include minting in the same atomic transaction when constraints permit.
- Verify the cluster and mint account.
- Use the configured Token Program consistently.
- Validate a supplied token account's mint and owner.
- Record who paid for account creation and fees.
- Return owner and destination account separately.
{
"asset_id": "community-credit-v1",
"network": "solana-devnet",
"standard": "spl",
"recipient_owner": "7QhV...xP9",
"destination_mode": "associated_token_account",
"create_destination_if_missing": true,
"amount": "500",
"amount_unit": "display"
}Reference SPL mint request. Replace example values and apply your own authentication, authorization, and signing policy.
Program choice
Token extensions are asset-definition decisions.
Extensions can affect account state, transfer behavior, fees, confidentiality, metadata, and support procedures. Many must be planned when the mint is initialized.
Original Token Program
Mature core token capabilities for minting, transfers, delegates, authorities, freeze, thaw, burn, and account management.
Token Extensions Program
Core behavior plus optional features. Register enabled extensions and validate every account and instruction against that configuration.
Metadata path
Record whether metadata uses a separate program, a metadata pointer and extension, or another reviewed publication design.
Retry and commitment
Blockhash-aware execution needs durable state.
Before submission
- Create the idempotent operation
- Resolve destination and program
- Convert exact base units
- Capture recent blockhash context
- Constrain every signer and account
After submission
- Store the transaction signature
- Poll using the documented commitment
- Track expiry and provider ambiguity
- Verify token balance and mint supply evidence
- Publish a later finalization event if used
Response evidence
Return the fields a developer can verify.
Include cluster, mint, Token Program, owner, destination token account, raw amount, transaction signature, slot, commitment, and whether the associated account was created.
FAQ
SPL minting questions.
What address identifies an SPL token?
The mint account address identifies the token on a particular Solana cluster and Token Program. Symbols and display names are not unique identifiers.
Does minting send tokens directly to a wallet address?
The mint instruction credits a token account. An API may derive and create the recipient wallet’s associated token account, but it should return both the owner address and the actual destination token account.
What is the difference between the Token Program and Token-2022?
Both implement core token behavior, while Token-2022 adds optional extensions. The selected program and enabled extensions affect account validation, sizing, instructions, and product behavior.
How should an expired blockhash be retried?
First reconcile the known transaction signature. Re-signing with a new blockhash creates a different transaction and should occur only within the original idempotent operation after evidence shows the prior transaction did not land.
Build from explicit contracts
Use the reference architecture as a starting point.
Define assets, authorities, idempotency, confirmation, and reconciliation before connecting a production signer.