Guia do Solana Anchor Framework

O Solana Anchor Framework ajuda desenvolvedores a construir programas com validação estruturada de contas, definições de instruções, interfaces geradas e verificações de segurança reutilizáveis.

Nota de versão: As versões do Anchor, Rust, Solana CLI e cliente JavaScript mudam independentemente. Verifique a compatibilidade atual na documentação oficial do Anchor antes de instalar ou implantar.

Este artigo é apenas para fins educacionais e não constitui aconselhamento financeiro ou de investimento. Investimentos em criptomoedas carregam riscos significativos. Sempre conduza sua própria pesquisa antes de tomar decisões de investimento.

📌 NOTA: Este guia usa Anchor v0.29.x e Solana CLI v1.18.x+, atuais em 2024. O Anchor Framework evolui rapidamente. Execute anchor --version para verificar sua versão instalada antes de seguir estas instruções.

Sumário

1. O que é o Solana Anchor Framework?
2. Modelo de Conta da Solana
3. Componentes Principais do Solana Anchor Framework
4. Pré-requisitos
5. Como Instalar o Anchor Framework
6. Construindo e Implantando Seu Primeiro Programa Anchor
7. Testando Programas Anchor
8. Anchor vs. Alternativas
9. Segurança do Anchor Framework
10. Solução de Problemas Comuns do Anchor
11. O Anchor Framework e o Ecossistema de Desenvolvedores da Solana
12. Perguntas Frequentes sobre o Solana Anchor Framework
13. Conclusão: O Anchor Framework é Certo para Seu Projeto Solana?

O que é o Solana Anchor Framework?

O Solana Anchor Framework é um framework de desenvolvimento de código aberto que elimina a complexidade de boilerplate e validação de contas ao escrever programas Solana (o equivalente on-chain de smart contracts) em Rust puro.

Solana é uma blockchain Camada 1 de alta performance que processa aproximadamente 65.000 transações por segundo em condições ideais (a partir de 2024), com finalidade em menos de um segundo e taxas geralmente abaixo de US$ 0,001. Solana atinge essa vazão em parte através de um mecanismo de consenso único chamado Proof of History (PoH), que cria um relógio criptográfico que ordena transações sem o overhead de comunicação dos protocolos de consenso tradicionais.

Construir na Solana sem um framework significa escrever código Rust verboso e de baixo nível para cada programa. Desenvolvedores devem validar manualmente a propriedade da conta, serializar dados, gerenciar erros e controlar relacionamentos de contas para cada transação individual. Para engenheiros vindos de backends Web2 ou desenvolvimento Ethereum, essa curva de aprendizado é tão íngreme que impede a maioria dos projetos antes mesmo de começarem.

Anchor muda isso. Pense no Anchor como o Ruby on Rails do desenvolvimento Solana: um framework opinativo que cuida da infraestrutura para que você possa focar na lógica do seu programa em vez da infraestrutura por baixo dele. O Anchor foi criado por Armani Ferrante e é mantido pela Coral XYZ. Você pode encontrar o código fonte e releases no repositório GitHub do Anchor (coral-xyz/anchor).). A versão estável atual é a v0.29.x.

Anchor permite que desenvolvedores construam aplicações descentralizadas (dApps). Uma dApp é uma aplicação cuja lógica de back-end roda em uma blockchain através de programas Solana, em vez de um servidor centralizado. O programa é o back-end da dApp; o cliente TypeScript que o Anchor gera é como seu front-end o chama. Categorias de dApps construídas com Anchor incluem protocolos de Finanças Descentralizadas (DeFi), plataformas de Token Não Fungível (NFT), organizações autônomas descentralizadas (DAOs) e jogos Web3.

Ao final deste guia, você entenderá a arquitetura principal do Anchor, terá um ambiente de desenvolvimento funcional, terá implantado um programa na devnet da Solana (uma rede de testes com SOL gratuito e sem valor) e terá contexto suficiente para avaliar se o Anchor se encaixa no seu projeto. Para uma análise direta de como o Anchor se compara às ferramentas Ethereum e ao desenvolvimento Rust nativo, veja como o Anchor se compara ao Hardhat do Ethereum e ao desenvolvimento Rust nativo.

O que você aprenderá:

• O que é Solana e por que sua arquitetura torna o Anchor necessário
• O que o IDL, macros e PDAs fazem, e como os programas se chamam
• Como instalar o ambiente completo de desenvolvimento Anchor
• Como escrever e implantar seu primeiro programa Anchor
• Vulnerabilidades de segurança a serem evitadas antes de enviar para a mainnet
• Como solucionar os erros mais comuns do Anchor

Modelo de Conta da Solana: A Base que Você Precisa Entender Primeiro

O modelo de conta da Solana é a base arquitetônica que torna o Anchor necessário. É genuinamente diferente de qualquer coisa que você encontra no desenvolvimento Ethereum ou Web2. Antes que as abstrações do Anchor façam sentido, você precisa entender o problema que elas resolvem.

O que é Solana

Solana é uma rede blockchain Camada 1 projetada para alta vazão e baixos custos de transação. Ao contrário do Ethereum, que processa cerca de 15 a 30 transações por segundo na mainnet, Solana processa aproximadamente 65.000 transações por segundo em condições ideais (a partir de 2024). As taxas de transação geralmente ficam abaixo de US$ 0,001. Essa combinação de velocidade e custo torna a Solana adequada para aplicações que exigem muitas transações pequenas e frequentes: sistemas de trading (DeFi), plataformas de minting (NFT) e jogos on-chain.

SOL é o token nativo da Solana. Ele paga pelas taxas de transação e pelo aluguel que as contas on-chain devem manter para permanecerem ativas na rede. Cada programa que você implanta e cada conta que seu programa cria requerem SOL para existir on-chain. Na devnet (a rede de testes gratuita da Solana), você recebe airdrops de SOL sem custo.

As vantagens de velocidade existem por causa de decisões arquitetônicas que tornam o desenvolvimento Solana mais difícil do que o desenvolvimento Ethereum no nível bruto. O Anchor aborda exatamente essas partes difíceis.

Como Solana Armazena Programas e Dados

Na Solana, "contas" não são contas de usuário ou de carteira no sentido comum. Contas são unidades de armazenamento na blockchain: contêineres distintos que podem conter dados, um saldo de SOL ou código de programa executável.

A distinção arquitetônica principal: na Solana, programas (código executável) e dados (estado) vivem em contas separadas. Programas são stateless. Uma conta de programa contém apenas o bytecode compilado. Os dados vivem em contas de dados separadas das quais os programas leem e para as quais escrevem.

No Ethereum, um smart contract é como um apartamento autônomo: o código e os móveis vivem no mesmo espaço. Na Solana, um programa é mais como uma empresa com departamentos separados: a lógica executável vive em uma conta, e os dados que ela lê e escreve vivem em outras contas inteiramente.

Cada conta Solana tem três propriedades: um proprietário (um programa que a controla), um endereço de chave pública (seu identificador na blockchain) e um saldo em lamports (a menor unidade do SOL, onde 1 SOL equivale a 1 bilhão de lamports). Contas de dados também armazenam dados de programa serializados.

A consequência prática: ao invocar um programa Solana, você deve passar explicitamente todas as contas que o programa lerá ou escreverá. Você deve provar a propriedade. Você deve declarar quais contas são mutáveis. Você deve verificar quais contas são signatárias. Em Rust puro, esse gerenciamento de contas requer centenas de linhas de código de validação por programa.

Esse gerenciamento explícito de contas é precisamente o problema que o sistema de restrições do Anchor foi projetado para resolver.

Componentes Principais do Framework Anchor do Solana: IDL, Macros, PDAs e CPI

O Anchor fornece quatro mecanismos interconectados que, juntos, eliminam a maior parte da complexidade no desenvolvimento bruto do Solana. Entender cada um em sequência é o pré-requisito para escrever seu primeiro programa.

A IDL (Interface Definition Language): Contrato de Comunicação do Anchor

O Anchor gera automaticamente um arquivo JSON chamado Interface Definition Language (IDL) sempre que você executa anchor build. Pense nisso como uma especificação OpenAPI para seu programa na blockchain: uma descrição legível por máquina de cada instrução que seu programa aceita, cada conta que essas instruções exigem e cada tipo de dado envolvido.

A IDL é para o Anchor o que uma ABI (Application Binary Interface) é para um contrato Solidity no Ethereum. Se você já desenvolveu no Ethereum, já sabe como as ABIs permitem que o código front-end chame funções de contrato com segurança de tipo. A IDL do Anchor faz o mesmo para programas Solana e é gerada automaticamente a partir do seu código Rust. Você nunca a escreve manualmente.

O arquivo IDL fica em target/idl/seu_nome_de_programa.json após anchor build. Ao lado dele, o Anchor gera target/types/seu_nome_de_programa.ts, um arquivo de tipo TypeScript que seu front-end ou scripts de teste importam para obter acesso totalmente tipado às instruções do seu programa.

Uma IDL abreviada se parece com isto:

{
  "version": "0.1.0",
  "name": "balance_tracker",
  "instructions": [
    {
      "name": "initialize",
      "accounts": [
        { "name": "balanceAccount", "isMut": true, "isSigner": false },
        { "name": "user",           "isMut": true, "isSigner": true  },
        { "name": "systemProgram",  "isMut": false, "isSigner": false }
      ],
      "args": []
    },
    {
      "name": "deposit",
      "accounts": [
        { "name": "balanceAccount", "isMut": true, "isSigner": false },
        { "name": "user",           "isMut": false, "isSigner": true }
      ],
      "args": [{ "name": "amount", "type": "u64" }]
    }
  ]
}

O cliente TypeScript lê essa IDL e fornece chamadas de método totalmente tipadas (program.methods.initialize() e program.methods.deposit(amount)) sem nenhuma escrita manual de interface. Suas habilidades em TypeScript são diretamente aplicáveis aqui.

Macros do Anchor: Como o Anchor Elimina Código Repetitivo

O Anchor fornece um conjunto de macros Rust, que são geradores de código que escrevem lógica de validação repetitiva para você. Uma macro em Rust é uma anotação que se expande em código em tempo de compilação. As macros do Anchor geram o código de validação de conta, serialização e tratamento de erros que você escreveria manualmente.

Três macros formam o núcleo de todo programa Anchor:

#[program] marca o módulo que contém suas funções de tratamento de instrução. O Anchor trata cada função pública neste módulo como uma instrução chamável.

#[derive(Accounts)] gera código de validação de conta a partir de uma definição de struct Rust. Você declara quais contas uma instrução precisa, e o Anchor gera o código para verificar propriedade e mutabilidade, além do tipo de cada conta, automaticamente.

#[account] marca um struct como um tipo de dado de conta gerenciado pelo Anchor e adiciona o discriminador de 8 bytes que permite ao Anchor distinguir seu tipo de conta de outros.

Veja como essas macros aparecem no contexto:

#[derive(Accounts)]
pub struct Initialize<'info> {
    #[account(
        init,           // Anchor cria esta conta (valida que ela não existe)
        payer = user,   // A conta 'user' financia o depósito de isenção de aluguel
        space = 8 + 8   // Discriminador de 8 bytes + 8 bytes para o campo u64 total
    )]
    pub balance_account: Account<'info, BalanceAccount>,

    #[account(mut)]          // Declara que o saldo em lamports desta conta mudará
    pub user: Signer<'info>, // Tipo Signer: Anchor verifica se esta conta assinou a tx

    pub system_program: Program<'info, System>,
}

Cada atributo dentro de #[account(...)] é uma restrição do Anchor. Restrições são regras de validação que executam automaticamente antes que a lógica da sua instrução seja executada. Elas são a principal razão pela qual os programas Anchor exigem muito menos código de validação manual do que os programas Rust puros.

As restrições mais comuns são:

#[derive(Accounts)]
pub struct ExampleAccounts<'info> {
    #[account(init, payer = user, space = 8 + 8)]
    // init: cria a conta; reverte se ela já existir
    pub new_account: Account<'info, MyData>,

    #[account(mut)]
    // mut: declara que os dados ou o saldo em lamports desta conta mudarão
    pub existing_account: Account<'info, MyData>,

    #[account(seeds = [b"vault", user.key().as_ref()], bump)]
    // seeds + bump: deriva um endereço PDA e verifica o bump canônico
    pub pda_account: Account<'info, VaultData>,

    #[account(constraint = user_account.authority == user.key())]
    // constraint: avalia uma expressão booleana; falha se for falsa
    pub user_account: Account<'info, UserData>,

    pub user: Signer<'info>,
    // Signer: verifica se a conta assinou a transação
}

Sem restrições, você escreveria cada uma dessas verificações manualmente no corpo da sua instrução. Com restrições, o Anchor as impõe antes que a lógica da sua instrução seja executada. Isso é tanto um ganho de produtividade quanto um recurso de segurança, pois é mais difícil esquecer as restrições do que verificações manuais enterradas no código da instrução.

Endereços Derivados de Programa (PDAs): Armazenamento Determinístico na Blockchain

Um Endereço Derivado de Programa (PDA) é um dos conceitos mais complicados no desenvolvimento Solana. Planeje ler esta seção duas vezes. PDAs desbloqueiam um dos padrões mais poderosos do Solana, e o Anchor os torna muito mais gerenciáveis do que o Rust puro.

Um PDA é um endereço de conta derivado deterministicamente de um conjunto de seeds e um ID de programa. Ao contrário de um endereço de carteira normal, um PDA não tem chave privada correspondente. Nenhum usuário individual pode assinar por um PDA. Apenas o programa proprietário pode autorizar transações envolvendo-o.

Pense em um PDA como um cofre que apenas o banco (o programa) pode abrir. Nenhum cliente tem a chave; o banco controla o acesso programaticamente. Isso torna os PDAs ideais para cofres controlados por programa, contas de custódia e armazenamento específico do usuário onde o programa, e não o usuário, deve ter autoridade.

Em Rust puro, derivar um PDA requer chamar Pubkey::find_program_address(&seeds, &program_id) e verificar manualmente o resultado. O Anchor lida com isso com a restrição seeds:

pub system_program: Program<'info, System>,

}

O constraint `seeds` diz ao Anchor como derivar o endereço PDA. O campo `bump` armazena a seed canônica de bump, um pequeno inteiro que garante que o endereço derivado saia da curva elíptica e não tenha chave privada. No Anchor v0.29.x, o bump canônico é derivado e verificado automaticamente.

PDAs são determinísticos: dados os mesmos seeds e ID do programa, eles sempre produzem o mesmo endereço. Essa propriedade permite que os clientes computem o endereço PDA fora da blockchain para buscar dados, enquanto o programa controla o acesso de escrita.

### Invocação Cross-Program (CPI): Como Programas se Comunicam

Invocação Cross-Program (CPI) é o mecanismo do Solana para um programa chamar as instruções de outro. É o equivalente na blockchain de chamar uma função de biblioteca compartilhada. CPI permite a composabilidade: seu protocolo DeFi pode chamar o programa SPL Token para transferir tokens, seu contrato de governança pode chamar um programa de Staking, e assim por diante.

O Solana Program Library (SPL) é o equivalente do Solana a uma biblioteca padrão para programas on-chain. SPL Token é para o Solana o que ERC-20 é para o Ethereum, mas implementado como um programa on-chain compartilhado em vez de um modelo de contrato que cada projeto implanta independentemente. Quando seu programa Anchor precisa cunhar ou transferir tokens, ele chama o SPL Token via CPI.

Anchor simplifica chamadas CPI com o crate `anchor-spl` e `CpiContext`:

use anchor_spl::token::{self, Transfer, Token};

pub fn withdraw(ctx: Context<Withdraw>, amount: u64) -> Result<()> {
    let cpi_accounts = Transfer {
        from: ctx.accounts.vault_token_account.to_account_info(), // Source token account
        to: ctx.accounts.user_token_account.to_account_info(),   // Destination token account
        authority: ctx.accounts.vault.to_account_info(),         // PDA signs for the vault
    };
    let cpi_ctx = CpiContext::new(ctx.accounts.token_program.to_account_info(), cpi_accounts);
    token::transfer(cpi_ctx, amount)?;  // Calls SPL Token's transfer instruction
    Ok(())
}

Sem o Anchor, montar informações de conta, construir a instrução e chamar invoke_signed requer aproximadamente 30 linhas. Os helpers de CPI do Anchor reduzem isso a uma chamada de função tipada e legível.

Você colocará esses conceitos em prática em o tutorial passo a passo do programa.

Pré-requisitos: O que Você Precisa Antes de Instalar o Anchor Framework

Quatro ferramentas são necessárias antes que você possa construir com o Anchor Framework no Solana.

Ferramentas Obrigatórias:

1. Rust e Cargo (via rustup), versão 1.70.0 ou posterior recomendada
2. Solana CLI (v1.18.x ou posterior), a ferramenta oficial de linha de comando para interagir com a rede Solana; gerencia carteiras, solicitações de Airdrop e configuração de cluster
3. Node.js (v18 ou posterior) mais Yarn ou npm, necessário para o cliente TypeScript e testes do Anchor
4. Anchor Version Manager (avm), que instala e gerencia versões do Anchor CLI; sempre instale o Anchor via avm em vez de diretamente via Cargo

Sobre Rust: Programas Anchor são escritos em Rust. Rust é obrigatório. Não há como fugir disso. Dito isso, os macros do Anchor abstraem os padrões mais dolorosos do Rust: validação de contas e serialização, além de propagação de erros. Você não precisa de profundo domínio de Rust para construir seu primeiro programa.

O que você precisa para começar: structs, funções, posse básica e limites de traits em um nível superficial. O que você pode adiar para depois: lifetimes, Rust assíncrono e os pontos mais finos do borrow checker. Suas habilidades em TypeScript ou JavaScript se aplicam diretamente ao código do lado do cliente do Anchor. Testes, interações de front-end e chamadas de cliente geradas por IDL usam TypeScript. Você não precisa ser um especialista em Rust para construir com Anchor, da mesma forma que não precisa ser um especialista em Ruby para construir com Ruby on Rails. Mas você encontrará Rust, e familiaridade básica ajuda.

Se a abstração do Anchor sobre padrões Rust lhe interessa, a seção de componentes principais explica em detalhes o que o Anchor abstrai do Rust.

Sobre Solana CLI vs. Anchor CLI: Estas são duas ferramentas separadas com responsabilidades diferentes. A CLI solana lida com a interação da rede: verificando Saldos, solicitando Airdrops e alternando entre devnet e Mainnet. A CLI anchor lida com o ciclo de vida do seu programa: inicializando projetos, construindo programas, executando testes e implantando. Ambas são necessárias.

Como Instalar o Anchor Framework: Configuração Passo a Passo

📌 NOTA: Todos os comandos abaixo são validados para Anchor v0.29.x e Solana CLI v1.18.x a partir de 2024. Execute anchor --version após a instalação para confirmar sua versão. Se estiver lendo isso após a publicação, verifique a versão atual no repositório GitHub do Anchor (coral-xyz/anchor).

Passo 1: Instalar Rust via rustup

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
# Siga as instruções na tela e selecione a instalação padrão
source "$HOME/.cargo/env"
rustc --version
# Deve imprimir: rustc 1.70.0 ou posterior

Passo 2: Instalar o Solana CLI

sh -c "$(curl -sSfL https://release.solana.com/stable/install)"
# Siga as instruções de PATH da saída do instalador
solana --version
# Deve imprimir: solana-cli 1.18.x ou posterior

Quando você implanta um programa Anchor no Solana, ele é armazenado on-chain e executado pelos nós validadores da rede sempre que uma transação o invoca. O Solana CLI é como você interage com esses validadores a partir do seu terminal.

Passo 3: Configurar Solana CLI para devnet e criar uma carteira

solana config set --url devnet
solana-keygen new
# Cria um keypair local (sua carteira de desenvolvimento)
# Salve o caminho da saída. Anchor usa este keypair para assinar implantações

💡 DICA: Salve o caminho do seu arquivo keypair. Anchor lê este keypair da sua configuração Anchor.toml para assinar transações de implantação na devnet.

Passo 4: Solicitar um Airdrop de SOL na devnet

solana airdrop 2
solana balance
# Confirme que o Saldo mostra 2 SOL

Passo 5: Instalar avm (Anchor Version Manager) e Anchor

cargo install --git https://github.com/coral-xyz/avm avm --locked --force
avm install latest
avm use latest
anchor --version
# Deve imprimir: anchor-cli 0.29.x

📌 NOTA: Sempre instale o Anchor através do avm em vez de diretamente via cargo install anchor-cli. O avm permite que você alterne entre versões do Anchor sem reinstalar. Isso importa quando os projetos são fixados em uma versão específica ou quando você está atualizando um projeto existente.

Passo 6: Inicializar seu primeiro projeto

anchor init my-first-program
cd my-first-program

Sua estrutura de projeto após anchor init:

my-first-program/
├── Anchor.toml
├── programs/
│   └── my-first-program/
│       └── src/
│           └── lib.rs
├── tests/
│   └── my-first-program.ts
└── app/

💡 DICA: O comando anchor init cria um programa de exemplo funcional em lib.rs. Execute anchor test imediatamente para confirmar se seu ambiente está funcionando antes de escrever qualquer código seu.

Construindo e Implantando seu Primeiro Programa Anchor: Um Guia Completo

Esta seção leva você de um projeto vazio a um programa implantado na devnet do Solana. O exemplo é um rastreador de Saldo: um programa que inicializa um Saldo armazenado em zero e, em seguida, aceita instruções de Depósito para incrementá-lo. Isso demonstra o ciclo de vida completo da conta e é funcionalmente idêntico a um programa contador, mas usa nomes de variáveis originais.

Escrevendo o Programa Rastreador de Saldo

Seu arquivo programs/my-first-program/src/lib.rs já contém um esqueleto do anchor init. Substitua seu conteúdo pelo seguinte:

// Anchor v0.29.x Balance Tracker Program
use anchor_lang::prelude::*;

declare_id!("Fg6PaFpoGXkYsidMpWTK6W2BeZ7FEfcYkgHH5WfZCnQ");

#[program]
pub mod balance_tracker {
    use super::*;

    pub fn initialize(ctx: Context<Initialize>) -> Result<()> {
        ctx.accounts.balance_account.total = 0;  // Saldo inicial é zero
        Ok(())
    }

    pub fn deposit(ctx: Context<Deposit>, amount: u64) -> Result<()> {
        ctx.accounts.balance_account.total += amount;  // Incrementa o saldo armazenado
        Ok(())
    }
}

#[derive(Accounts)]
pub struct Initialize<'info> {
    #[account(
        init,
        payer = user,
        space = 8 + 8   // Discriminador Anchor de 8 bytes + 8 bytes para u64
    )]
    pub balance_account: Account<'info, BalanceAccount>,

    #[account(mut)]
    pub user: Signer<'info>,

    pub system_program: Program<'info, System>,
}

#[derive(Accounts)]
pub struct Deposit<'info> {
    #[account(mut)]
    pub balance_account: Account<'info, BalanceAccount>,
    pub user: Signer<'info>,
}

#[account]
pub struct BalanceAccount {
    pub total: u64,
}

Três padrões neste código são importantes antes de prosseguir. Primeiro, #[derive(Accounts)] gera toda a lógica de validação de contas. O Anchor lê a sua definição de struct e escreve as verificações de propriedade, verificações de mutabilidade e verificação de signatário. Você declara a intenção; o Anchor a aplica. Segundo, space = 8 + 8 aloca exatamente os bytes necessários para a conta: 8 bytes para o discriminador do Anchor (uma tag única que identifica o tipo de conta e previne ataques de confusão de conta) mais 8 bytes para o u64 total. Terceiro, Signer<'info> é o tipo integrado do Anchor que verifica se a conta assinou a transação. Sem ele, qualquer conta poderia chamar sua instrução de depósito.

Testando seu Programa com Mocha e TypeScript

Mocha é um executor de testes JavaScript; Chai fornece sintaxe de asserção. Ambos vêm pré-instalados quando você executa anchor init. Abra tests/my-first-program.ts e substitua seu conteúdo:

import * as anchor from "@coral-xyz/anchor";
import { Program } from "@coral-xyz/anchor";
import { MyFirstProgram } from "../target/types/my_first_program";
import { assert } from "chai";

describe("balance-tracker", () => {
  const provider = anchor.AnchorProvider.env();
  anchor.setProvider(provider);

  const program = anchor.workspace.MyFirstProgram as Program<MyFirstProgram>;
  const balanceAccount = anchor.web3.Keypair.generate();

  it("Inicializa uma conta de saldo com total = 0", async () => {
    await program.methods
      .initialize()
      .accounts({
        balanceAccount: balanceAccount.publicKey,
        user: provider.wallet.publicKey,
        systemProgram: anchor.web3.SystemProgram.programId,
      })
      .signers([balanceAccount])
      .rpc();

    const account = await program.account.balanceAccount.fetch(
      balanceAccount.publicKey
    );
    assert.equal(account.total.toNumber(), 0, "Saldo inicial deve ser 0");
  });

  it("Deposita 500 e atualiza o saldo armazenado", async () => {
    await program.methods
      .deposit(new anchor.BN(500))
      .accounts({
        balanceAccount: balanceAccount.publicKey,
        user: provider.wallet.publicKey,
      })
      .rpc();

    const account = await program.account.balanceAccount.fetch(
      balanceAccount.publicKey
    );
    assert.equal(account.total.toNumber(), 500, "Saldo deve ser 500 após o depósito");
  });
});

O pacote npm @coral-xyz/anchor é a biblioteca cliente TypeScript do Anchor. O tipo Program<MyFirstProgram> foi gerado automaticamente a partir do IDL quando anchor build foi executado. Este é o valor prático do IDL em ação: seu código TypeScript obtém segurança de tipo total sobre a interface do seu programa Rust, sem nenhuma escrita manual de interface.

Este programa também é o backend de um dApp. O cliente TypeScript mostrado acima é como um aplicativo frontend chamaria ele. Adicione uma interface React ou Next.js sobre essas chamadas de método e você terá um aplicativo descentralizado completo rodando no Solana.

Compilar e Implantar na Devnet

Execute esses três comandos em sequência a partir da raiz do seu projeto:

anchor build
# Saídas: target/deploy/my_first_program.so, target/idl/my_first_program.json, target/types/my_first_program.ts

anchor test
# Inicia o validador local, implanta, executa testes Mocha, desliga

anchor deploy --provider.cluster devnet
# A saída inclui o seu ID do Programa: ABC123...xyz789

💡 DICA: Copie seu ID de Programa da saída de implantação. Atualize o valor declare_id!("...") em lib.rs com ele e, em seguida, execute anchor build novamente para incorporar o endereço correto no seu programa compilado. Atualize também a seção [programs.devnet] no Anchor.toml.

📌 NOTA: Você está implantando na devnet, a rede de teste do Solana. Isso não custa SOL real. Seu airdrop da devnet da seção de configuração cobre a taxa de implantação.

Você agora escreveu e testou um programa Solana, depois o implantou usando o Anchor Framework. O programa vive na devnet no seu ID de Programa e executa sempre que uma transação o invoca.

Testando Programas Anchor: O Fluxo anchor test

anchor test é um único comando que inicia um validador Solana local, implanta seu programa nele, executa sua suíte de testes Mocha completa e desliga o validador quando termina. Você não precisa gerenciar o validador manualmente.

O fluxo de teste em sequência:

1. anchor test lê seu Anchor.toml para configuração
2. Ele inicia um processo de validador local em segundo plano
3. Ele compila e implanta seu programa nesse validador
4. Ele executa todos os arquivos de teste TypeScript no seu diretório tests/ usando Mocha
5. Ele imprime resultados de aprovação/falha e desliga o validador

Estrutura do arquivo de teste: Cada arquivo de teste importa de @coral-xyz/anchor, configura um provedor (que se conecta ao validador local) e referencia seu programa através do objeto workspace gerado pelo IDL. Os blocos describe e it são sintaxe padrão do Mocha.

Buscando dados da conta: Após chamar uma instrução, busque a conta na blockchain para afirmar seu estado:

const account = await program.account.balanceAccount.fetch(
  balanceAccount.publicKey
);
assert.equal(account.total.toNumber(), 0);

Testando casos de erro: Teste que entradas inválidas falham corretamente. Um programa bem testado inclui testes negativos:

it("Rejeita depósito de uma conta não assinada", async () => {
  const badActor = anchor.web3.Keypair.generate();
  try {
    await program.methods
      .deposit(new anchor.BN(100))
      .accounts({
        balanceAccount: balanceAccount.publicKey,
        user: badActor.publicKey,
      })
      .rpc();
    assert.fail("A transação deveria ter sido rejeitada");
  } catch (err) {
    assert.ok(err, "Anchor rejeitou a transação não assinada");
  }
});

Localnet vs. devnet: Use anchor test (localnet) para todo o desenvolvimento ativo. A Localnet é instantânea e gratuita, e é reiniciada entre as execuções. Implante na devnet apenas quando quiser compartilhar um URL persistente ou testar contra condições reais da rede.

Mocha é o executor de testes (a estrutura de blocos describe e it). Chai fornece sintaxe de asserção (assert.equal, assert.ok, expect). Ambos são pré-configurados em cada projeto anchor init e não requerem instalação separada.

Anchor vs. Alternativas: Escolhendo seu Caminho de Desenvolvimento Solana

Existem três caminhos de desenvolvimento para construir no Solana: o Anchor Framework, Rust nativo sem framework e Seahorse. O próprio Solana é um entre vários blockchains que valem a pena avaliar para o seu projeto. As tabelas abaixo apresentam as principais diferenças sem viés.

Tabela 1: Abordagens de Desenvolvimento Solana

Tabela 2: Ferramentas Solana vs. Ethereum

Quando escolher o Anchor em vez do Rust nativo: Para muitos casos de uso de desenvolvimento de aplicações na Solana, incluindo protocolos DeFi, plataformas NFT, sistemas de token-gating, DAOs e jogos on-chain, o Anchor é um ponto de partida comum. A redução de boilerplate é substancial: um programa que requer 300 linhas em Rust puro pode levar 80 linhas com Anchor. O desenvolvimento em Rust nativo faz sentido quando um programa requer controle preciso sobre o consumo de unidades de computação, quando as abstrações do Anchor conflitam com uma arquitetura incomum ou quando uma equipe tem profundo conhecimento em Rust e precisa de flexibilidade máxima.

O Framework Seahorse: O Seahorse permite que desenvolvedores escrevam programas Solana em Python, que o Seahorse então compila para Rust compatível com Anchor nos bastidores. Isso reduz a barreira da linguagem para desenvolvedores Python que desejam experimentar com a Solana sem aprender Rust. A contrapartida é a maturidade: o Seahorse é um projeto comunitário com uma base de usuários muito menor do que o Anchor e não é recomendado para aplicações em produção em 2024. Para prototipagem, é uma opção razoável; para produção, o Anchor continua sendo o padrão de fato.

Ethereum vs. Solana: O Ethereum oferece o maior ecossistema de desenvolvedores de Smart Contracts, o histórico de auditoria de segurança mais profundo e o suporte de ferramentas mais amplo. A Solana oferece uma taxa de transferência substancialmente maior e taxas mais baixas, tornando-a mais adequada para aplicações onde a frequência e o custo das transações são as restrições primárias. Essas plataformas atendem a diferentes perfis de aplicação. Desenvolvedores que criam infraestrutura de negociação de alta frequência ou jogos de microtransações podem favorecer a Solana; desenvolvedores que criam sistemas de governança ou padrões de token que precisam de compatibilidade máxima com o ecossistema podem favorecer o Ethereum. Para a maioria das aplicações Solana em produção, o Anchor é um ponto de partida comum, confirmado por grandes protocolos, incluindo Raydium, Marinade Finance e Metaplex, que escolheram o Anchor como sua base.

Segurança do Framework Anchor: Cinco Vulnerabilidades que Todo Desenvolvedor Solana Deve Conhecer

⚠️ AVISO: Vulnerabilidades de segurança em programas Solana podem resultar em perda permanente e irreversível de fundos dos usuários. Antes de implantar qualquer programa na Mainnet, execute-o em uma ferramenta de análise estática como a Soteria e considere uma auditoria de segurança profissional. O ecossistema Solana sofreu explorações significativas exatamente pelas vulnerabilidades descritas abaixo. A revisão de segurança não é opcional para programas em produção. Para uma leitura mais aprofundada, consulte a documentação oficial do Anchor.

O sistema de restrições do Anchor, os atributos #[account(...)] em suas structs de conta, é sua primeira linha de defesa de segurança. Ele impõe automaticamente verificações de propriedade, permissões de mutabilidade e verificação de tipo que, de outra forma, você escreveria manualmente em Rust puro. Mas as restrições só protegem o que você declara. As vulnerabilidades abaixo surgem do que os desenvolvedores esquecem de declarar.

Falta de Verificação do Signatário (Signer Check)

Qualquer conta pode invocar sua instrução se o chamador não for obrigado a assinar a transação. Isso permite que qualquer carteira chame instruções que deveriam ser restritas.

// VULNERÁVEL: AccountInfo não verifica se o chamador assinou a transação
#[derive(Accounts)]
pub struct Deposit<'info> {
    #[account(mut)]
    pub balance_account: Account<'info, BalanceAccount>,
    pub user: AccountInfo<'info>,  // Nenhuma verificação de assinatura
}

// SEGURO: Signer<'info> falha a transação se a conta não assinou
#[derive(Accounts)]
pub struct Deposit<'info> {
    #[account(mut)]
    pub balance_account: Account<'info, BalanceAccount>,
    pub user: Signer<'info>,  // A transação é revertida se o usuário não assinou
}

Use Signer<'info> para qualquer conta que deva autorizar uma instrução.

Falta de Verificação de Propriedade (Substituição de Conta)

Um invasor pode substituir uma conta maliciosamente criada que tenha o mesmo layout de dados que a conta esperada, mas que pertença a um programa diferente.

// VULNERÁVEL: AccountInfo não verifica o proprietário do programa da conta
pub balance_account: AccountInfo<'info>,  // Aceita qualquer conta

// SEGURO: Account<'info, T> verifica se a conta pertence ao seu programa
pub balance_account: Account<'info, BalanceAccount>,  // Verificação de propriedade é automática

Sempre use o wrapper tipado Account<'info, T> do Anchor em vez do AccountInfo<'info> puro para contas que contenham dados controlados pelo programa.

Ataque de Reinicialização

Se uma instrução initialize puder ser executada mais de uma vez na mesma conta, um invasor pode resetar um estado que deveria ser permanente.

// VULNERÁVEL: init_if_needed aceita silenciosamente contas já inicializadas
#[account(init_if_needed, payer = user, space = 8 + 8)]
pub balance_account: Account<'info, BalanceAccount>,

// SEGURO: init reverte se a conta já existir
#[account(init, payer = user, space = 8 + 8)]
pub balance_account: Account<'info, BalanceAccount>,

Use init (não init_if_needed) para contas que só devem ser criadas uma vez. Se init_if_needed for genuinamente necessário, adicione uma flag de inicialização explícita e verifique-a na lógica da sua instrução.

Overflow e Underflow de Inteiros

A aritmética do Rust entra em pânico em caso de overflow em builds de debug, mas faz o wrap silenciosamente em builds de release, o que pode corromper Saldos financeiros sem gerar um erro.

// VULNERÁVEL: aritmética direta faz wrap silencioso no modo release
pub fn deposit(ctx: Context<Deposit>, amount: u64) -> Result<()> {
    ctx.accounts.balance_account.total += amount;
    Ok(())
}

// SEGURO: checked_add retorna um Err em vez de fazer wrap no overflow
pub fn deposit(ctx: Context<Deposit>, amount: u64) -> Result<()> {
    ctx.accounts.balance_account.total = ctx.accounts.balance_account.total
        .checked_add(amount)
        .ok_or(error!(ErrorCode::Overflow))?;
    Ok(())
}

Use checked_add, checked_sub e checked_mul para toda aritmética em valores financeiros. Defina um enum ErrorCode personalizado com uma variante Overflow para mensagens de erro claras.

Usar uma semente de bump não canônica pode produzir um endereço PDA válido, mas inesperado, permitindo ataques de falsificação de endereço (address spoofing).

// VULNERÁVEL: o bump manual não é garantido como canônico
#[account(seeds = [b"vault", user.key().as_ref()], bump = ctx.accounts.vault.bump)]
pub vault: Account<'info, Vault>,

// SEGURO: omita o valor explícito do bump. O Anchor v0.29.x deriva e verifica
// o bump canônico automaticamente
#[account(
    seeds = [b"vault", user.key().as_ref()],
    bump,
)]
pub vault: Account<'info, Vault>,

No Anchor v0.29.x, omita o valor explícito do bump e deixe o Anchor derivar o bump canônico. Se você armazenar o bump nos dados da conta, preencha-o durante init usando ctx.bumps.vault.

Para mensagens de erro que você encontrar ao implementar esses padrões de segurança, consulte a seção de solução de problemas.

Solução de Problemas de Erros Comuns do Anchor

Os erros abaixo representam os problemas mais comuns que os desenvolvedores encontram ao construir com o Anchor Framework. Cada entrada inclui a mensagem de erro exata, a causa e a correção.

📌 OBSERVAÇÃO: Incompatibilidades de versão causam a maioria das falhas em anchor build. Verifique esta tabela primeiro antes de investigar outras causas.

Erro 1: AccountNotInitialized

AnchorError causado pela conta: balance_account.
Código de Erro: AccountNotInitialized.
Número do Erro: 3012.

Causa: Seu programa tentou ler uma conta de dados que ainda não existe on-chain. A instrução initialize não foi chamada.

Correção: Chame sua instrução initialize antes de qualquer instrução que leia da conta. Em testes, garanta que o bloco it de inicialização seja executado antes do bloco de teste de depósito.

Erro 2: Discrepância de Tipo no anchor build

error[E0308]: tipos incompatíveis
esperado struct `anchor_lang::prelude::AccountInfo`
encontrado struct `anchor_lang::accounts::signer::Signer`

Causa: Seu código usa a sintaxe de restrição de conta do Anchor v0.26.x ou anterior, que mudou na v0.29.x.

Correção: Verifique a documentação oficial do Anchor) para a sintaxe de restrição da v0.29.x. Execute avm use 0.29.0 para confirmar que sua versão da CLI corresponde à sua dependência Cargo.toml.

Erro 3: Incompatibilidade de Versão do Anchor/Solana CLI

Error: Resposta do RPC com erro -32002: Falha na simulação da transação

Causa: Sua versão do Anchor CLI e sua versão do Solana CLI são incompatíveis.

Correção:

avm use 0.29.0
solana --version     # Confirme que a CLI Solana é v1.18.x ou posterior

Erro 4: Discrepância de declare_id! Após Redeploy

Error: Discrepância de ID do Programa

Causa: Você redeployou para um novo endereço, mas declare_id!() em lib.rs ainda contém o ID do programa antigo.

Correção:

anchor keys sync
anchor build

Erro 5: Fundos Insuficientes no Devnet

Error: Falha na simulação da transação: fundos insuficientes

Causa: Sua carteira devnet não tem SOL suficiente para pagar a taxa de implantação ou transação.

Correção:

solana airdrop 2
solana balance

Erro 6: Binário do Programa Excede Limite de Tamanho

Error: dados da conta muito pequenos para a instrução

Causa: Seu binário de programa compilado excede o limite de tamanho de programa da Solana para programas atualizáveis.

Correção: Adicione otimizações de release ao seu Cargo.toml:

[profile.release]
opt-level = "z"
lto = true

Remova dependências não utilizadas e flags de funcionalidade do seu Cargo.toml e Anchor.toml.

Se você estiver enfrentando erros de versão, retorne ao guia de instalação e verifique se suas versões de ferramenta correspondem à tabela de compatibilidade acima.

O Anchor Framework e o Ecossistema de Desenvolvedores da Solana

O Anchor Framework impulsiona a maioria dos programas de produção implantados na mainnet da Solana, incluindo protocolos em Finanças Descentralizadas (DeFi), infraestrutura de NFT e governança on-chain.

Protocolos de produção construídos com Anchor:

• Raydium: Market Maker automatizado (AMM) e protocolo de liquidez
• Marinade Finance: Protocolo de staking líquido para SOL
• Metaplex: Padrão de NFT, metadados de token e suíte de ferramentas
• Drift Protocol: Exchange descentralizada de futuros
• Kamino Finance: Protocolo de liquidez e empréstimos
• Jito: Staking ciente de MEV e infraestrutura de validadores

Protocolos de DeFi representam a categoria dominante de programas implantados pelo Anchor. Exchanges descentralizadas, plataformas de empréstimos e agregadores de rendimento dependem da taxa de transferência da Solana (aproximadamente 65.000 transações por segundo em condições ideais, a partir de 2024) e das baixas taxas (geralmente abaixo de US$ 0,001 por transação) para suas operações principais. O crescimento de instrumentos financeiros on-chain e a tokenização de ativos do mundo real na Solana refletem essa maturidade de infraestrutura.

De acordo com o Electric Capital Developer Report (disponível em electriccapital.com para dados atuais), a base de desenvolvedores ativos da Solana cresceu ano após ano em 2023 e no início de 2024. O aumento da adoção por desenvolvedores geralmente contribui para a saúde do ecossistema blockchain, embora isso não deva ser interpretado como conselho de investimento.

SOL serve como a moeda de taxa da rede Solana. Cada transação que invoca um programa on-chain custa uma pequena quantia de SOL (negociável em grandes exchanges de criptomoedas, incluindo Coinbase e Binance). Para dados de mercado atuais do SOL, veja preço atual e dados de mercado do SOL na CoinGecko.)

Mais desenvolvedores trabalhando com Anchor significa mais programas implantados, o que significa maior uso da rede Solana. Essa conexão é uma observação sobre a dinâmica do ecossistema, não um sinal de investimento.

Perguntas Frequentes Sobre o Anchor Framework da Solana

Em que linguagem de programação a Solana é escrita?

Os programas da Solana são escritos em Rust. O runtime também suporta C e C++, mas Rust é o padrão para desenvolvimento de produção. Para código do lado do cliente, incluindo testes, interações de front-end e scripts que chamam seus programas, TypeScript e JavaScript são usados através do pacote npm @coral-xyz/anchor. O Anchor Framework cobre ambas as camadas: Rust para lógica de programa e TypeScript para tudo que interage com ele.

Rust é necessário para usar o Anchor Framework?

Sim. Programas Anchor são escritos em Rust, e não há como contornar isso. Dito isso, as macros do Anchor abstraem as partes mais intensivas em Rust do desenvolvimento da Solana: validação de conta e propagação de erros. Um desenvolvedor com familiaridade básica em Rust (structs, funções, traits, propriedade básica) pode construir e implantar um programa Anchor funcional. Profundo conhecimento em Rust sobre lifetimes, padrões async e genéricos avançados não é necessário para começar. Suas habilidades em TypeScript ou JavaScript se aplicam diretamente ao lado do cliente de todo projeto Anchor.

O que é um Endereço Derivado de Programa (PDA) em termos simples?

Um Endereço Derivado de Programa (PDA) é um endereço de conta que um programa controla, em vez de um usuário com uma chave privada. Como PDAs não têm chave privada, apenas o programa proprietário pode autorizar transações envolvendo-os. Dada as mesmas seeds e ID do programa, um PDA sempre se resolve para o mesmo endereço, o que permite que os clientes encontrem contas controladas por programas sem armazenar seus endereços separadamente. O Anchor gerencia a derivação de PDA automaticamente através da restrição seeds em suas structs de conta. PDAs são comumente usados para cofres controlados por programas, contas de custódia e armazenamento de dados por usuário.

É possível criar NFTs com o Anchor Framework?

Sim. A maioria da infraestrutura de NFT da Solana é construída sobre o Anchor. O padrão Metaplex, que define metadados de token, estrutura de coleção e royalties para NFTs da Solana, é ele próprio um programa baseado em Anchor. Qualquer plataforma de NFT na Solana interage com os programas da Metaplex via Invocação Cross-Program (CPI) usando o crate anchor-spl, que fornece wrappers type-safe para instruções do SPL Token.

O Anchor Framework é ativamente mantido?

Sim. O Anchor é mantido pela Coral XYZ e é o padrão de facto para o desenvolvimento de programas na Solana a partir de 2024. A versão estável atual é a v0.29.x. O repositório do Anchor no GitHub (coral-xyz/anchor) recebe lançamentos regulares que acompanham as atualizações de tempo de execução da Solana. Grandes protocolos de produção, incluindo Raydium, Marinade Finance e Metaplex, continuam a construir no Anchor, confirmando sua prontidão para produção.

Como o Anchor se compara ao Hardhat da Ethereum?

Anchor e Hardhat desempenham papéis análogos em suas respectivas blockchains: ambos fornecem scaffolding de projeto, um ambiente de teste e ferramentas de implantação. As diferenças começam com a arquitetura subjacente. O Hardhat visa o modelo de contrato com estado da Ethereum, onde um Smart Contract detém tanto sua lógica quanto seu estado. O Anchor visa o modelo de programa sem estado da Solana, onde programas e dados residem em contas separadas. As linguagens também diferem: projetos Hardhat usam Solidity para contratos e JavaScript ou TypeScript para testes; projetos Anchor usam Rust para programas e TypeScript para testes. Os custos de transação também diferem substancialmente: as transações na Solana normalmente custam menos de $0,001, enquanto as taxas de gás da Ethereum variam e podem chegar a $1 a $50 ou mais por transação. Para uma comparação completa lado a lado, consulte as tabelas de comparação Anchor vs. Alternativas.

Quanto tempo leva para aprender o framework Anchor?

Um desenvolvedor com experiência em TypeScript ou JavaScript e sem conhecimento prévio de Rust pode, normalmente, construir e implantar um programa Anchor básico na devnet dentro de um a dois dias usando um guia estruturado. Mudar de um programa básico para um protocolo DeFi de produção leva de semanas a meses, dependendo da complexidade do programa e da profundidade em Rust. A curva de aprendizado do Rust é a variável principal. Desenvolvedores que investem tempo nos fundamentos do Rust junto com o Anchor veem um progresso mais rápido em programas não triviais.

A Solana Program Library (SPL) é uma coleção de programas pré-implantados e auditados na Solana para operações comuns. O programa SPL Token é o equivalente da Solana ao padrão ERC-20, implementado como um programa compartilhado On-Chain em vez de um modelo de contrato que cada projeto implanta de forma independente. O Anchor se integra à SPL através da crate anchor-spl, que fornece wrappers com tipos seguros para instruções do SPL Token, incluindo transfer, mint_to e burn. A SPL também é a base para metadados de tokens NFT através do programa Metaplex.

O que é Proof of History (PoH) na Solana?

Proof of History (PoH) é um mecanismo criptográfico de cronometragem que a Solana usa para ordenar transações antes que elas cheguem aos validadores para consenso. Em vez de exigir que os validadores se comuniquem para concordar com a ordem das transações, o PoH incorpora uma sequência de carimbo de data/hora verificável diretamente na Blockchain. Isso reduz a sobrecarga de coordenação dos protocolos de consenso tradicionais e é uma das razões pelas quais a Solana atinge aproximadamente 65.000 transações por segundo sob condições ideais em 2024.

A Solana é boa para o desenvolvimento de Smart Contracts?

A Solana é bem adequada para aplicações onde o rendimento e o custo das transações são as principais restrições: protocolos DeFi de alta frequência, marketplaces de NFT com muitas transações pequenas e jogos On-Chain. Seu modelo de conta exige mais aprendizado inicial do que a Ethereum, mas o framework Anchor reduz significativamente esse atrito. Se a Solana é a escolha certa depende do perfil da sua aplicação. A Ethereum oferece um ecossistema maior e um histórico de auditoria de segurança mais estabelecido, enquanto a Solana oferece taxas mais baixas e maior rendimento para casos de uso que se beneficiam de ambos.

Conclusão: O framework Anchor é adequado para o seu projeto Solana?

Para muitos fluxos de trabalho de desenvolvimento de aplicações na Solana, o framework Anchor é um ponto de partida comum, enquanto o Rust nativo permanece relevante quando um controle de nível inferior é necessário.

O Anchor reduz substancialmente o boilerplate do desenvolvimento em Rust puro. Programas que exigiriam centenas de linhas em código nativo da Solana ocupam uma fração disso com o sistema de macros do Anchor. Ele impõe a segurança da conta por meio de seu sistema de restrições, detectando erros de propriedade e autorização no momento da compilação ou execução, em vez de na produção. E ele gera um cliente TypeScript automaticamente a partir da IDL, oferecendo aos desenvolvedores JavaScript uma interface tipada e familiar para seus programas sem a necessidade de escrever Rust no lado do cliente.

O desenvolvimento em Rust nativo vale a pena ser considerado apenas quando seu programa exige controle preciso sobre o consumo de unidades de computação ou quando as abstrações do Anchor entram genuinamente em conflito com uma arquitetura incomum. Para a grande maioria dos programas, incluindo protocolos DeFi, plataformas NFT, DAOs e sistemas de token-gating, o Anchor é por onde você deve começar.

Próximos passos:

1. Implante o programa rastreador de Saldo deste guia na devnet usando anchor deploy --provider.cluster devnet
2. Explore a documentação oficial do Anchor em anchor-lang.com para a referência completa da API e recursos avançados
3. Navegue no repositório de exemplos do Anchor no GitHub para programas com padrões de produção
4. Junte-se ao Discord do Anchor ou ao Solana Stack Exchange para suporte da comunidade quando encontrar problemas

O programa que você implantou neste guia é real: ele vive na devnet da Solana, aceita transações e armazena o estado On-Chain. Essa é a base sobre a qual toda aplicação Solana de produção é construída.

Guias Técnicos Relacionados da Solana

• Endereços de contrato Solana e IDs de Programa
• Padrões de Token da Solana
• Tokens SPL da Solana

Desenvolvedores que acompanham o SOL junto com as ferramentas do ecossistema podem consultar a página de preço do SOL como uma referência de mercado separada; ela não valida a segurança do programa ou a prontidão para implantação.