DOCSEARCHbyAlgolia
Submit Docs

Anchor Framework

repository·master·Indexed 26 days ago

https://github.com/otter-sec/anchor

A framework for Solana program development featuring a Rust eDSL, IDL specification, TypeScript client generation, and a CLI for workspace management. It includes the Anchor Version Manager (AVM) for managing Anchor, Solana CLI, and platform-tools versions, as well as integration with Crucible for coverage-guided program fuzzing via `anchor fuzz`.

Tokens
116.6K
Snippets
331
Records
628
Agent score
85%

What's inside Anchor

  2. Understand Token 2022 Extensions

    master

    The Token Extensions Program (Token 2022) allows adding optional features to token mints and accounts via extensions.

    Key Implementation Rules:

    • Initialization: Most extensions add state that must be initialized during the initial creation of the mint or token account.
    • Exceptions: The following extensions can be added to an account after it has been initialized:
      • cpi-guard
      • memo-transfer
      • token-group
      • token-member
      • token-metadata
    • Incompatibility: Some extensions cannot be used together. For example, NonTransferable is incompatible with TransferFeeConfig due to conflicting behaviors.
    • Data Storage: Extension-specific state is stored in the tlv_data field, which follows the base account data. To access this data, you must deserialize the tlv_data according to the specific ExtensionTypes enabled for that account.

  3. Choose the correct Account wrapper

    master

    Anchor provides several account wrappers that determine ownership checks, data layout, borrow behavior, and exit behavior. Choose based on your data requirements:

    TypeUse for
    Account<T>Program-owned fixed-size data. Zero-copy, Pod-backed.
    BorshAccount<T>Variable-length data with Vec, String, or payload enums.
    Slab<H, Item>Header plus dynamic Pod item tail (e.g., ledgers, order books).
    Option<A>Optional account slot (uses program ID as absent sentinel).
    Nested<T>Inline composition of another #[derive(Accounts)] struct.
    Box<A>Heap-boxed wrapper for large account structs.
    SignerAn account that must have signed the transaction.
    Program<T: Id>A CPI target or well-known executable program.
    SystemAccountSystem-owned account with no typed payload.
    UncheckedAccountEscape hatch with no validation.
    Sysvar<T>Account-form sysvar access.

  4. Understand the Anchor v2 Design and Account Model

    master

    Anchor v2 is a pinocchio-based, #![no_std] runtime. It is designed to be zero-copy by default for fixed-size accounts and is organized around traits to allow for extensibility of account wrappers, constraints, CPI helpers, and IDL metadata.

    Account Types

    • Account<T>: Use this for Pod-backed account state. It is zero-copy by default.
    • BorshAccount<T>: Use this when an account requires variable-length fields, such as Vec or String.

    CPI and Safety

    Cross-program calls (CPI) use borrow-tracked CpiHandle<'a> values, ensuring that typed account access and CPI share the same safety model.

  5. Understand Token Extensions (Token 2022)

    master

    Token Extensions (part of the Token 2022 program) allow you to add optional functionality to token mints and token accounts.

    Key Implementation Rules

    • Initialization: Most extensions must be enabled during the initial creation of the mint or token account. They cannot be added to an existing account.
    • Exceptions: The following extensions can be added after the account has been initialized:
      • cpi-guard
      • memo-transfer
      • token-group
      • token-member
      • token-metadata
    • Incompatibility: Some extensions are mutually exclusive. For example, you cannot combine the NonTransferable extension with the TransferFeeConfig extension.
    • Data Storage: Extension-specific state is stored in the tlv_data field, which follows the base account data. This data must be deserialized according to the specific enabled ExtensionTypes.

  8. Understand Anchor Discriminators

    master

    Anchor uses unique 8-byte discriminators to identify specific instructions and account types within a program. These discriminators are automatically handled by the Anchor client, so direct interaction is typically unnecessary. As of Anchor v0.30, these discriminators are included in the IDL file.

    Discriminators are generated by taking the first 8 bytes of the Sha256 hash of a specific prefix combined with the name of the instruction or account.

  9. Understand SPL token account models in Anchor

    master

    When working with the legacy SPL Token Program in Anchor, the SPL surface uses specific account wrappers and constraints to mirror Anchor's account model:

    • Account<Mint>: Used to zero-copy SPL mint data.
    • Account<TokenAccount>: Used to zero-copy SPL token account data.
    • mint::* and token::* constraints: These act as downstream AccountConstraint markers.
    • CPI helpers: Available via anchor_spl_v2::token::cpi.
    • CPI account structs: Constructed using cpi_handle() and cpi_handle_mut().

  10. Use anchor-spl-v2 for SPL Token and Token-2022 support

    master

    The anchor-spl-v2 crate provides tools for interacting with SPL token programs via Cross-Program Invocations (CPI). It includes zero-copy account types, namespaced constraints, CPI helpers, and support for the Token-2022 interface.

    Key features include:

    • Account Wrappers: Implement shared traits for easy handling.
    • Constraints: Downstream AccountConstraint markers for validation.
    • CPI Helpers: Use CpiHandle to execute token instructions through a cost-optimized CPI path.
    • Token-2022 Support: Use InterfaceAccount<T> to accept accounts owned by either the legacy Token Program or the new Token-2022 program.

  11. Understand Anchor Program Fundamentals

    master

    Anchor programs are built around several core concepts that manage how instructions are processed and how data is validated on Solana. To build a program, you must understand:

    • Program Structure: How handlers, discriminators, and generated modules are organized.
    • Accounts and Context: Using Context<T> to manage instruction data, typed bumps, and remaining accounts.
    • Account Validation: Using the #[derive(Accounts)] macro to perform validation passes and apply constraints.
    • PDAs (Program Derived Addresses): Using seeds and bumps to derive addresses and utilizing generated Resolved structs.
    • IDL (Interface Definition Language): The schema emitted by Anchor that describes accounts, types, instructions, constants, and events for client-side consumption.
    • CPI (Cross-Program Invocation): How one program calls another using CpiContext, CpiHandle, and generated CPI wrappers.

  12. SPL Token Basics Overview

    master

    This guide provides an overview of common instructions for interacting with SPL tokens (both the original Token Program and the Token 2022 Token Extension Program) within Anchor programs. The following operations are supported:

    • Create a mint account: Initializes a mint that defines a new token.
    • Create a token account: Initializes an account to hold a balance of a specific mint.
    • Mint tokens: Increases the supply of a mint and credits a token account.
    • Transfer tokens: Moves tokens between two token accounts of the same mint.