Ferramentas de Devzero-copy-attribute
#[account(zero_copy)] (Anchor)
An Anchor attribute applied to account structs to enable zero-copy deserialization, where account data is accessed directly from the underlying byte buffer using repr(C) memory layout rather than Borsh deserialization. Zero-copy accounts use AccountLoader instead of Account and are accessed via load() or load_mut(). Best for large accounts where full deserialization would consume excessive compute units. Fields must be fixed-size types (no Vec, String, or Option).
Ferramentas de Devanchor-account-macro
#[account] Macro (Anchor)
The Anchor macro applied to structs to define on-chain account data layouts. `#[account]` auto-derives Borsh serialization, adds an 8-byte discriminator prefix (SHA-256 of 'account:<Name>'), and implements space calculation. Optional attributes: `#[account(zero_copy)]` for zero-copy deserialization of large accounts.
Ferramentas de Devanchor-derive-accounts
#[derive(Accounts)] (Anchor)
The Anchor macro that defines the accounts struct for an instruction. Each field specifies an account with validation constraints. Account types include: `Account<'info, T>` (deserialized), `Signer<'info>` (must sign), `Program<'info, T>` (program reference), `SystemAccount<'info>`, and `UncheckedAccount<'info>` (no validation, use carefully).
Segurançaaccess-control-bypass
Access Control Bypass
Category of vulnerabilities where program authorization checks are insufficient or missing, allowing unauthorized users to execute privileged operations. Includes missing signer checks, owner checks, PDA validation, and constraint violations. The most common class of critical Solana program vulnerabilities.
Ecossistema Solanaaccess-protocol
Access Protocol
A content monetization protocol on Solana where creators stake ACS tokens and subscribers lock tokens to access premium content, replacing traditional paywalls with a staking-based model. Subscribers maintain access as long as their tokens remain locked, earning staking yields while supporting creators. The protocol enables a non-extractive relationship between content producers and their audience.
AliasACS
Blockchain Geralaccount-abstraction
Account Abstraction
A design pattern that replaces the rigid externally-owned account (EOA) model with programmable smart contract wallets capable of custom authentication, gas sponsorship, and batched transactions. ERC-4337 implements this on Ethereum via UserOperations, bundlers, an EntryPoint contract, and paymasters. EIP-7702 (Pectra upgrade, May 2025) extends this by allowing EOAs to delegate to smart contract logic.
AliasAAAliasERC-4337AliasSmart Account
Modelo de Programaçãoaccount-data
Account Data
The byte array stored in an account that holds program-specific state. Data is typically serialized using Borsh and must be explicitly allocated at account creation. The maximum data size is 10MB. Programs are responsible for defining and managing their own data layout, including discriminators for type identification.
Ferramentas de Devaccount-deserializer
Account Deserializer
Tool or library that converts raw on-chain account bytes into structured data using program-specific schemas. Anchor provides automatic deserialization via its IDL. For non-Anchor programs, developers use Borsh, custom byte parsing, or tools like Codama-generated clients to interpret account data.
Infraestruturaaccount-filter
Account Filter (memcmp / dataSize)
Optional filter objects passed to getProgramAccounts that narrow results by comparing raw bytes in account data. A memcmp filter specifies a byte offset and an expected bytes value (base58 or base64 encoded), enabling field-level matching such as filtering all token accounts by a specific mint address; a dataSize filter restricts results to accounts whose data length equals an exact byte count. Combining both filters is the standard pattern for efficiently querying discriminated Anchor accounts or specific SPL token account sets.
Redeaccount-locking
Account Locking (Read/Write)
The mechanism by which Solana's scheduler reserves access to accounts for the duration of a transaction's execution, granting either shared read locks (multiple transactions can hold simultaneously) or exclusive write locks (only one transaction at a time). Before execution, the runtime inspects every transaction's declared account list and grants or denies locks accordingly, preventing data races without requiring a global mutex. Transactions that cannot acquire all required locks are queued or dropped, making correct account declaration in transaction instructions critical for both correctness and landing probability.
Fundamentos de Programaçãoaccount-model-vs-utxo
Account Model vs UTXO Model
Two models for tracking blockchain state. Account model (Solana, Ethereum): each account has a balance and state that is updated in place. UTXO model (Bitcoin, Cardano): transactions consume unspent transaction outputs and create new ones. Account models are more intuitive for smart contracts; UTXO models offer better privacy and parallelism for simple transfers.
AliasUTXO
Segurançaaccount-reloading
Account Reloading Attack
A vulnerability in Anchor programs where a program reads an account's data before making a CPI call, the CPI modifies that account's lamports or data, but the program continues using the stale pre-CPI snapshot instead of reloading the account from the runtime. In Anchor, after a CPI the account reference still holds the pre-call data unless account.reload() is explicitly called, meaning balance checks, state assertions, or further computation can operate on incorrect values. Attackers can exploit this to pass checks using an initial account state that the CPI subsequently invalidates.
Segurançarevival-attack
Account Revival Attack
An exploit that resurrects an account that a program has logically closed within the same transaction by sending lamports back to it before the transaction finalizes, causing its on-chain data — which was never securely wiped — to re-appear as a funded, seemingly valid account in future transactions. Because the Solana runtime keeps an account alive as long as it holds any lamports, transferring even 1 lamport back to a closed-but-not-wiped account prevents its deletion and allows an attacker to reuse its stale state. The defense is to explicitly overwrite account data with a closed discriminator and to use force-defund patterns so any lamports transferred in during the same transaction are immediately drained.
Modelo de Programaçãoaccount-info
AccountInfo
The runtime struct passed to programs for each account in an instruction: `AccountInfo { key, is_signer, is_writable, lamports, data, owner, executable, rent_epoch }`. In native programs, the entrypoint receives a slice of AccountInfos. Anchor abstracts this with typed account structs but AccountInfo is available via `to_account_info()`.
Modelo de Programaçãoaccount-loader
AccountLoader (Anchor)
An Anchor account type that provides zero-copy access to large account data without deserializing the entire account upfront. AccountLoader wraps the raw account data and provides load() and load_mut() methods to access the data as a typed reference. It is used with #[account(zero_copy)] structs and is preferred over Account<T> when accounts exceed ~1KB, as it significantly reduces compute unit consumption.
Protocolo Baseaccounts-db
AccountsDB
The persistent storage layer for all Solana accounts. AccountsDB stores account data in memory-mapped AppendVec files, indexed by pubkey and slot. It supports fast lookups, handles account deduplication across slots, and periodically cleans up dead accounts. AccountsDB is the largest consumer of validator disk space.
AliasAccountsDb
Infraestruturaaccount-subscribe
accountSubscribe
A WebSocket subscription method that pushes a notification to the client every time the data or lamport balance of a specified account changes, delivering the updated AccountInfo payload at the configured commitment level. It is commonly used by UIs to reactively update token balances, NFT ownership, or program state without polling, and each subscription is referenced by a numeric subscription ID returned upon successful registration.
DeFiaccredited-investor
Accredited Investor
SEC regulatory category: individuals with $1M+ net worth or $200K+ annual income permitted to participate in private securities offerings. Most tokenized security offerings on Solana restrict participation to accredited investors, requiring KYC and wallet whitelisting.
Modelo de Programaçãoaddress-lookup-table
Address Lookup Table (ALT)
An on-chain account that stores up to 256 pubkeys, enabling v0 transactions to reference accounts by 1-byte index instead of full 32-byte pubkeys. ALTs dramatically reduce transaction size when interacting with many accounts (e.g., DEX routing). ALTs must be created and populated in advance; entries become active after a slot delay.
AliasALTAliasLUT
Fundamentos de Programaçãoaes-gcm-siv
AES-GCM-SIV
Authenticated encryption scheme combining AES block cipher with Galois/Counter Mode and Synthetic Initialization Vector for nonce-misuse resistance. Used in Solana's Token-2022 confidential transfers to encrypt token amounts on-chain while preserving the ability to prove balance validity through zero-knowledge proofs.
AliasAES-GCM
Protocolo Baseagave
Agave
The Rust-based Solana validator client maintained by Anza (formerly Solana Labs). Agave is the original and most widely deployed validator implementation. It handles all aspects of validation: TPU, TVU, gossip, AccountsDB, and RPC. The name 'Agave' was adopted to distinguish it from the Firedancer client.
AliasAnza Agave
Protocolo Baseleader-schedule
Agenda de Líderes
A deterministic mapping of slots to validators for an entire epoch, computed from stake weights. Validators with more stake are assigned proportionally more leader slots. The schedule is derived using a seed from the previous epoch's randomness, so all validators independently compute the same schedule without coordination.
IA / MLagent-loop
Agent Loop
The core iterative execution cycle of an agentic AI system: Perceive, Reason, Act, Observe, Repeat. At each iteration, the agent assembles context, invokes an LLM to reason and select an action, executes via tools, observes the result, and feeds it back into the next iteration—continuing until the task is complete. The agent loop is the architectural pattern that distinguishes AI agents from simple chatbots.
AliasAgentic LoopAliasReAct Loop
IA / MLagent-ai
Agente de IA
An autonomous AI system that can plan, use tools, and take actions to accomplish goals. Agents use LLMs as the reasoning core and have access to tools (APIs, code execution, web browsing, database queries). In blockchain: agents can analyze smart contracts, execute transactions, monitor DeFi positions, and automate trading strategies. Frameworks: LangChain, CrewAI, Claude Agent SDK.
AliasAutonomous AgentAliasAgentic AI