Las Restricciones #[account]
Los atributos de campo en los miembros de la struct de cuentas componen las reglas de validación. Anchor las evalúa en un orden definido antes de que se ejecute tu manejador de instrucciones.
//
Busca en todas las páginas de la documentación
Los atributos de campo en los miembros de la struct de cuentas componen las reglas de validación. Anchor las evalúa en un orden definido antes de que se ejecute tu manejador de instrucciones.
#[account(
mut,
has_one = authority,
constraint = vault.amount > 0 @ MyError::InvalidAmount,
)]
pub vault: Account<'info, Vault>,Las expresiones de restricción solo pueden hacer referencia a campos de cuenta hermanos y argumentos de instrucción declarados con #[instruction(...)]. Un amount simple aquí no compilaría; si realmente es un argumento de instrucción, añade #[instruction(amount: u64)] a la struct.
Cuándo usar esto: Expresas propiedad, relaciones o invariantes personalizados de forma declarativa.
#[derive(Accounts)]
#[instruction(new_fee_bps: u16)]
pub struct SetFee<'info> {
#[account(
mut,
seeds = [b"config"],
bump = config.bump,
has_one = admin,
constraint = new_fee_bps <= 10_000 @ ConfigError::FeeTooHigh,
)]
pub config: Account<'info, Config>,
pub admin: Signer<'info>,
}Lo que esto demuestra:
#[instruction(...)] trae los argumentos del manejador al ámbito de la restricción; debe listarlos en orden, comenzando por el primero.mut marca las cuentas escribibles.has_one comprueba la igualdad de la pubkey con el campo anidado.constraint ejecuta expresiones booleanas arbitrarias.@ se mapea a una variante de enum de error personalizada.| Atributo | Propósito |
|---|---|
mut | La cuenta es escribible |
signer | Debe ser firmante (en tipos que no son Signer) |
has_one = field | El campo de la cuenta coincide con la clave de otra cuenta |
address = expr | Coincidencia exacta de pubkey |
owner = prog | Comprobación del programa propietario |
constraint = expr | Invariante personalizado |
Combina atributos; todos deben pasar.
@ MyError::Variant para mayor claridad.pubkey! por feature flags del clúster.mut en las cuentas que persistes.| Alternativa | Úsala Cuando | No la Uses Cuando |
|---|---|---|
| require! en el manejador | Lógica dinámica entre cuentas | Comprobaciones de relaciones estáticas |
| Tokens de restricción personalizados (0.32) | Patrones reutilizables | Reglas simples de un solo uso |
| Comprobaciones nativas manuales | No usas Anchor | Usas Anchor por seguridad |
0.32.1 para anchor-lang, Anchor CLI y ejemplos en esta sección.
Sí. Solana CLI 3.0.10 maneja keypairs, airdrops e inspección de solana program.
target/idl/<program>.json en tu espacio de trabajo.
Sí, pero cada campo no verificado necesita restricciones explícitas o comprobaciones en el manejador.
Usa anchor test con Surfpool 0.12.0 o LiteSVM 0.6.x en CI.
Discriminador de cuenta de Anchor; no lo elimines al dimensionar space.
Sí, o publica el IDL en la cadena para que los clientes tengan una fuente canónica.
Ejecuta con logs; Anchor imprime el nombre de la restricción y el índice de la cuenta.
Sí. Esta pila se dirige a validadores Agave con Solana CLI 3.0.10.
Consulta los artículos hermanos en Relacionados para temas más profundos sobre restricciones de cuentas.
Versiones de la pila: 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: 16 jul 2026