Saltar para o conteúdo principal

Documentation Index

Fetch the complete documentation index at: https://docs.raydium.io/llms.txt

Use this file to discover all available pages before exploring further.

Esta página foi traduzida automaticamente por IA. A versão em inglês é a fonte oficial.Ver versão em inglês →
O modelo de contas da Solana é a coisa mais importante a entender antes de ler o código da Raydium. Diferentemente da Ethereum, onde o estado vive junto do código do contrato, os programas da Solana são completamente sem estado: todo estado vive em “contas” separadas nas quais os programas operam. Cada pool, posição e vault da Raydium é uma conta — compreender como essas contas funcionam faz o resto da documentação fazer sentido.

​
A divisão fundamental: programas versus contas

​
Programas

Um programa na Solana é código executável — um binário compilado carregado de um arquivo, implantado em uma Pubkey, e invocável via transações. Programas não possuem estado associado; contêm apenas lógica. Programas da Raydium:
  • CPMM: CPMMoo8L3F4NbTegBCKVNunggL7H1Zpdmwpwh8KMoZ0F
  • CLMM: CAMMCzo5YL8w4VFF8KVHrK22GGUsp5VTaW7grrKgrWqK
  • AMM v4: 675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8
Cada um é um binário fixo. O programa não “lembra” de nada entre invocações.

​
Contas

Uma conta é uma linha de dados on-chain. Cada conta possui:
  • pubkey — seu endereço.
  • owner — o programa que a possui (controla escritas).
  • data — os bytes brutos.
  • lamports — saldo em SOL (1 SOL = 1.000.000.000 lamports).
  • rent_epoch — campo legado de coleta de aluguel (ignorado desde que a isenção de aluguel se tornou obrigatória).
Quando você consulta um pool da Raydium, está lendo uma ou mais contas. Quando um swap é executado, o programa CPMM lê/escreve várias contas — o estado do pool, os vaults, o estado de observação e as contas de token do usuário.

​
Propriedade

Cada conta é de propriedade de exatamente um programa. Apenas o código desse programa pode modificar o campo data da conta. Um usuário pode modificar lamports (enviar/receber SOL) em uma conta que possa assinar, mas modificar data requer que o programa proprietário faça isso em seu nome. Exemplos:
  • Sua carteira de usuário: de propriedade do Program de Sistema. Lamports vivem aqui; você assina para transferir.
  • Sua conta de token USDC: de propriedade do Programa de Token SPL. A instrução transfer do programa de token atualiza o saldo.
  • Uma conta de estado de pool da Raydium: de propriedade do programa CPMM. Apenas as instruções CPMM podem modificar as reservas, taxas, etc.
  • O PersonalPositionState de um NFT de posição da Raydium: de propriedade do programa CLMM.
“De propriedade de” é rigoroso: se o programa A escrever em uma conta de propriedade do programa B, o tempo de execução da Solana rejeita a transação.

​
Aluguel e isenção de aluguel

Criar uma conta consome espaço de armazenamento. A Solana cobra aluguel por esse espaço, mas desde 2020 todas as novas contas devem ser isentas de aluguel — significando que possuem lamports suficientes para que o aluguel que deveriam ao longo de 2 anos seja pré-pago. Na prática:
  • Conta isenta de aluguel vive para sempre.
  • Fechar a conta retorna os lamports para quem a fecha.
Para uma conta de 165 bytes (por exemplo, conta de Token SPL), a isenção de aluguel é ~0,00204 SOL. Para um estado de pool CPMM da Raydium de 1.440 bytes, é ~0,011 SOL.

​
Custos de aluguel da Raydium

ContaTamanhoAluguel
CPMM PoolState~1.440 B~0,011 SOL
CLMM PoolState~1.500 B~0,012 SOL
CLMM TickArray~9.000 B~0,063 SOL
CLMM PersonalPositionState~280 B~0,003 SOL
ATA165 B~0,002 SOL
Vault (Conta de Token)165 B~0,002 SOL
A criação de pool requer aluguel para várias contas de uma vez — é por isso que a criação de pool CPMM custa ~0,15 SOL no total.

​
Contas de dados versus executáveis

Contas vêm em dois tipos:

​
Contas de dados

Armazenam estado (reservas do pool, saldos de token, posições de usuário). executable = false. Esta é a grande maioria.

​
Contas executáveis

Armazenam bytecode do programa. executable = true. Estes são programas (CPMM, CLMM, etc.). Programas não possuem dados além de seu bytecode.

​
Contas derivadas do programa (PDAs)

Uma PDA é uma conta de dados cujo endereço é derivado deterministicamente de um programa e algumas sementes — nenhuma chave privada existe para este endereço. Apenas o programa de derivação pode assinar em nome de uma PDA via invoke_signed. A Raydium usa PDAs extensivamente:
  • PDAs de estado de pool: derivados de [poolTypeDiscriminator, mintA, mintB, ammConfig].
  • PDAs de vault: derivados de [pool, mint].
  • PDA de estado de observação: derivado de [observationSeed, pool].
PDAs permitem que a Raydium crie contas em endereços previsíveis sem gerenciar chaves. Qualquer pessoa pode calcular o endereço PDA para um pool conhecido dadas as sementes. Veja solana-fundamentals/pdas-and-cpis.

​
Transações e referências de contas

Cada transação da Solana carrega uma lista explícita de contas que será lida/escrita. O tempo de execução impõe:
  • Contas listadas podem ser lidas ou escritas (de acordo com sua flag is_writable).
  • Contas não listadas não podem ser tocadas.
Para um swap da Raydium, a lista de contas da transação inclui: 
[readonly] programa CPMM
[writable] estado de pool
[readonly] configuração amm
[readonly] autoridade de pool (PDA)
[writable] vault de entrada
[writable] vault de saída
[writable] ATA de entrada do usuário
[writable] ATA de saída do usuário
[readonly] mint de entrada
[readonly] mint de saída
[readonly] programa de token de entrada
[readonly] programa de token de saída
[writable] estado de observação
[signer,writable] usuário
Esta enumeração explícita é por que as transações da Solana são rápidas e paralelizáveis — o tempo de execução pode determinar txs não conflitantes antecipadamente.

​
Tamanho de conta e layout de dados

Cada conta da Raydium possui um tamanho fixo ou limitado. O layout é definido em código (structs Rust com #[repr(C)]) e documentado em sdk-api/anchor-idl. Programas Anchor colocam um discriminador de 8 bytes no início de cada conta que criam, derivado de hash("account:<StructName>")[0..8]. Isto permite que clientes identifiquem o tipo de uma conta apenas lendo os primeiros 8 bytes — crucial para digitalizações getProgramAccounts que enumeram todas as contas de um tipo.

​
Lendo um estado de pool da Raydium

Via SDK: 
const pool = await raydium.cpmm.getPoolInfoFromRpc({ poolId });
console.log(pool.poolInfo);
Via RPC bruto + layout: 
const accountInfo = await connection.getAccountInfo(poolId);
const data = accountInfo.data;
// Pule os primeiros 8 bytes (discriminador), então analise de acordo com o layout da struct.
const poolState = CpmmPoolStateLayout.decode(data.slice(8));
O layout está em src/raydium/cpmm/layout.ts na fonte do SDK.

​
Exemplo prático: lendo uma conta de token

Vamos ler o saldo USDC de um usuário. 
import { Connection, PublicKey } from "@solana/web3.js";
import { getAssociatedTokenAddressSync, AccountLayout } from "@solana/spl-token";

const connection = new Connection("https://api.mainnet-beta.solana.com");
const user       = new PublicKey("YourUserWallet...");
const usdcMint   = new PublicKey("EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v");

// 1. Calcule o endereço ATA (derivação estilo PDA).
const ata = getAssociatedTokenAddressSync(usdcMint, user);

// 2. Leia a conta.
const accountInfo = await connection.getAccountInfo(ata);
if (!accountInfo) {
  console.log("ATA ainda não existe (usuário nunca teve USDC).");
  return;
}

// 3. Verifique se o proprietário é o programa SPL Token.
console.assert(accountInfo.owner.toBase58() === "TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA");

// 4. Decodifique os dados.
const parsed = AccountLayout.decode(accountInfo.data);
console.log("Saldo (menores unidades):", parsed.amount.toString());
console.log("Mint:",                     new PublicKey(parsed.mint).toBase58());
console.log("Proprietário:",             new PublicKey(parsed.owner).toBase58());
Este padrão — derive endereço, busque conta, verifique proprietário, decodifique — se aplica a cada leitura on-chain, incluindo pools da Raydium.

​
Por que isto importa para a Raydium

O modelo de contas molda o design da Raydium:
  • O estado do pool é uma única conta — tudo sobre um pool (mints, reservas, taxas, administrador) vive em uma conta de propriedade do programa de pool.
  • Tokens LP são contas de token SPL padrão — a Raydium delega a tokenização ao programa SPL Token.
  • Arrays de ticks são divididos em chunks — CLMM não pode ter um único array crescente de ticks porque contas têm tamanho alocado fixo; em vez disso, usa PDAs de TickArray divididas em chunks.
  • NFTs de posição são NFTs Metaplex — posições CLMM são NFTs padrão per Metaplex; o estado de posição é uma PDA separada.
Compreender isso permite responder corretamente perguntas como “onde X vive?”:
  • “Onde estão as reservas do pool?” → duas contas de vault (contas de token) de propriedade do programa SPL Token, com autoridade delegada a uma PDA do programa de pool.
  • “Onde estão os dados de ticks para CLMM?” → uma série de PDAs TickArray, cada uma cobrindo 60 ticks consecutivos.
  • “Onde está meu stake em farm?” → uma PDA UserLedger derivada de [user, farmId], de propriedade do programa de farm.

​
Referências

Fontes: