CPIs de Token SPL
anchor-spl expõe funções CPI tipadas para o SPL Token: transfer, mint_to, burn, approve, e mais. Elas encapsulam metadados de conta e dados de instrução para o programa de token.
Receita
use anchor_spl::token::{self, MintTo, Transfer};
token::mint_to(cpi_ctx, amount)?;
token::transfer(cpi_ctx, amount)?;
token::burn(cpi_ctx, amount)?;Quando usar isso: Seu programa move tokens SPL sem reimplementar layouts de instrução de token.
Exemplo de Trabalho
#[derive(Accounts)]
pub struct Deposit<'info> {
#[account(mut)]
pub user: Signer<'info>,
#[account(mut)]
pub user_ata: Account<'info, TokenAccount>,
#[account(mut)]
pub vault_ata: Account<'info, TokenAccount>,
pub token_program: Program<'info, Token>,
}
pub fn deposit(ctx: Context<Deposit>, amount: u64) -> Result<()> {
token::transfer(
CpiContext::new(
ctx.accounts.token_program.to_account_info(),
Transfer {
from: ctx.accounts.user_ata.to_account_info(),
to: ctx.accounts.vault_ata.to_account_info(),
authority: ctx.accounts.user.to_account_info(),
},
),
amount,
)?;
Ok(())
}O que isso demonstra:
- MintTo requer um signatário da autoridade de cunhagem ou PDA.
- Transfer precisa de ATAs de origem e destino mutáveis.
- Burn reduz o suprimento da conta de queima.
- Token-2022 usa o módulo
token_interface.
Mergulho Profundo
Interface de Token (2022)
use anchor_spl::token_interface::{self, Mint, TokenAccount, TokenInterface};
pub token_program: Interface<'info, TokenInterface>,Use ao suportar os programas clássicos Token e Token-2022.
Armadilhas
- Autoridade não signatária para transferência de usuário - CPI falha. Correção: Use
Signerouwith_signerpara PDA. - Discrepância de cunhagem/decimais - Valor com magnitude errada. Correção: Valide a cunhagem em ambos os ATAs.
- Esqueceu
mutnos ATAs - O programa de token rejeita. Correção: Marque as contas de token comomut. - Usando o programa Token para cunhagem Token-2022 - Discrepância de proprietário. Correção: Mude para tipos
Interface. - Aprovação sem revogação - Risco de permissão pendente. Correção: Revogue ou use o padrão
exact-delegate.
Alternativas
| Alternativa | Use Quando | Não Use Quando |
|---|---|---|
| CPI de instrução de token bruta | Layouts personalizados | Fluxos SPL padrão |
| Transferências de token apenas do lado do cliente | Usuário assina instruções de token | Custódia do programa |
FAQs
Formato de erro do Anchor 0.32.1?
Códigos personalizados no IDL mais strings #[msg].
emit! vs emit_cpi!?
emit_cpi! custa mais CU, mas melhora a confiabilidade da captura.
Devo usar msg! na mainnet?
Evite, exceto atrás de flags de recurso.
Como os clientes obtêm códigos de erro?
Do IDL via Anchor ou geração de código Codama.
Eventos aparecem no IDL?
Sim, os tipos #[event] são listados.
Restrições podem retornar erros personalizados?
Sim, com @ MyError::Variant.
O que usa CU no logging?
Cada linha de log e string formatada.
Como testar erros?
anchor test esperando códigos de erro.
Logs são dados de consenso?
Sim, mas não um contrato de API; use eventos.
Próxima leitura?
Veja Relacionados para CPI SPL.
Relacionados
- Noções Básicas de CPI no Anchor - CpiContext
- Restrições de Token e Token Associado - validação
- Noções Básicas de SPL Token - modelo de token
Versões da Stack: Esta página foi escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, anchor-lang 0.32.1, Rust 1.91.1, @solana/kit 7.0.0, Surfpool 0.12.0, e LiteSVM 0.6.x.