> ## 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.

# Modelo de contas

> A arquitetura centrada em contas da Solana — contas armazenam estado, programas são código sem estado que operem em contas. Aluguel, propriedade, contas de programa versus contas de dados, e o que tudo isso significa ao ler o estado dos pools da Raydium.

<Info>
  **Esta página foi traduzida automaticamente por IA. A versão em inglês é a fonte oficial.**

  [Ver versão em inglês →](/solana-fundamentals/account-model)
</Info>

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

| Conta                      | Tamanho   | Aluguel     |
| -------------------------- | --------- | ----------- |
| 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 |
| ATA                        | 165 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`](/pt/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`](/pt/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:

```ts theme={null}
const pool = await raydium.cpmm.getPoolInfoFromRpc({ poolId });
console.log(pool.poolInfo);
```

Via RPC bruto + layout:

```ts theme={null}
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.

```ts theme={null}
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

* [`solana-fundamentals/programs-and-anchor`](/pt/solana-fundamentals/programs-and-anchor) — como programas processam contas.
* [`solana-fundamentals/pdas-and-cpis`](/pt/solana-fundamentals/pdas-and-cpis) — derivação de PDA e CPI.
* [`solana-fundamentals/transactions-and-fees`](/pt/solana-fundamentals/transactions-and-fees) — como contas são referenciadas em transações.
* [`sdk-api/anchor-idl`](/pt/sdk-api/anchor-idl) — layouts de conta para os programas da Raydium.

Fontes:

* [Documentação de Contas da Solana](https://docs.solana.com/developing/programming-model/accounts).
* [Programa SPL Token](https://spl.solana.com/token) — onde contas de token vivem.