Busca en todas las páginas de la documentación
Las listas de cuentas de CPI deben reflejar el orden esperado del llamado, las banderas de firmante y la capacidad de escritura. Tu programa es responsable de no elevar privilegios más allá de lo que la transacción externa pretendía.
let metas = vec![
AccountMeta::new(source, false),
AccountMeta::new(dest, false),
AccountMeta::new_readonly(authority, true),
];Cuándo usar esto:
// Validar que la fuente sea escribible solo si el llamador pretendía una mutación
if !source.is_writable { return Err(ProgramError::InvalidAccountData); }
let ix = spl_token::instruction::transfer(...)?;
invoke(&ix, &[source.clone(), dest.clone(), authority.clone(), token_program.clone()])?;Lo que esto demuestra:
Pasar writable + signer al llamado cuando la transacción externa no lo autorizó es un error crítico.
Sigue las definiciones de origen del llamado (spl-token, system).
// AccountMeta::new_readonly(key, is_signer)| Alternativa | Usar Cuando | No Usar Cuando |
|---|---|---|
| Constructores de instrucciones SPL | Metadatos correctos | Programas personalizados |
Módulo cpi de Anchor | Generado | Manual |
| Clientes Codama | Solo fuera de la cadena | En la cadena sigue siendo manual |
El programa llamado las revalida.
Firmantes de la transacción externa + solo invoke_signed.
El llamado genera un error.
Se resuelven antes de la ejecución.
Usar el patrón remaining accounts en Anchor.
Consideraciones de reentrada.
Generalmente cuenta de programa de solo lectura.
Si el llamado lo requiere.
Cuentas de firmante adicionales.
Muestran el ID del programa del llamado.
Bajo.
Pruebas negativas de LiteSVM.
Versiones de Stack: Esta página fue 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, y LiteSVM 0.6.x.
Revisado por Chris St. John·Última actualización: 19 jul 2026