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

# Rent e rent reclamável

> Solana está reduzindo o mínimo isento de rent em 90% em cinco etapas sob SIMD-0437. Contas financiadas antes de cada etapa agora mantêm mais do que precisam — qual é esse excesso, quais programas o devolvem e como encontrá-lo e reclamá-lo.

<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/rent-and-reclaimable-rent)
</Info>

<Info>
  Rent é um depósito reembolsável, não uma taxa. SIMD-0437 reduz o depósito que cada conta deve manter, em cinco etapas independentemente controladas. Contas criadas antes de uma etapa mantêm o saldo com o qual foram financiadas, então cada etapa as deixa superfundidas. Os programas SPL Token e Token-2022 podem devolver essa diferença através de `WithdrawExcessLamports` sem fechar a conta ou tocar no saldo de tokens. Nada expira — o excesso fica em suas próprias contas até você escolher movê-lo.
</Info>

Leia [Modelo de conta](/pt/solana-fundamentals/account-model) primeiro se você é novo em como as contas Solana são financiadas.

## O que rent realmente é

Toda conta em Solana mantém um depósito de SOL dimensionado pelo espaço que ocupa. Ele não é gasto — é devolvido integralmente quando a conta é fechada. A fórmula é:

```
minimum_balance(data_len) = (ACCOUNT_STORAGE_OVERHEAD + data_len) × lamports_per_byte
```

`ACCOUNT_STORAGE_OVERHEAD` é um fixo de 128 bytes que toda conta paga independentemente de sua carga útil. `lamports_per_byte` é a constante em toda a rede que SIMD-0437 altera.

Uma conta SPL token padrão de 165 bytes sempre custou `(128 + 165) × 6,960 = 2,039,280` lamports — o \~0.00203928 SOL que você vê deduzido sempre que uma carteira abre uma conta de token associada.

## O que SIMD-0437 muda

SIMD-0437 reduz `lamports_per_byte` de 6,960 para 696 — uma redução de 90% — implementada através de cinco feature gates separados para que validadores possam absorver o efeito do crescimento de estado um passo de cada vez.

| Etapa        | `lamports_per_byte` | Redução do original | Rent para uma conta de token de 165 bytes |
| ------------ | ------------------- | ------------------- | ----------------------------------------- |
| — (original) | 6,960               | —                   | 2,039,280 lamports                        |
| 1            | 6,333               | 9%                  | 1,855,569 lamports                        |
| 2            | 5,080               | 27%                 | 1,488,440 lamports                        |
| 3            | 2,575               | 63%                 | 754,475 lamports                          |
| 4            | 1,322               | 81%                 | 387,346 lamports                          |
| 5            | 696                 | 90%                 | 203,928 lamports                          |

A etapa 1 foi ativada na mainnet em 3 de setembro de 2026. As etapas restantes chegam conforme seus feature gates são habilitados; trate o cronograma como sujeito a mudanças e leia o valor ao vivo do cluster em vez de codificá-lo.

<Note>
  SIMD-0437 depende de SIMD-0194, que depreca o limiar de isenção de rent "para evitar matemática de ponto flutuante desnecessária ao definir os parâmetros de rent na ativação do feature". Na prática, a sysvar `Rent` agora carrega `lamports_per_byte_year = 6,333` com `exemption_threshold = 1.0`, em vez da antiga divisão `3,480 × 2` que produzia 6,960. Não multiplique esses dois campos você mesmo — chame `getMinimumBalanceForRentExemption` e deixe o cluster responder.
</Note>

## Por que contas existentes mantêm muito

Reduzir a constante muda o que uma conta *precisa*. Não muda o que uma conta *tem*. Uma conta financiada a 6,960 lamports por byte mantém esse saldo após a etapa 1 ser ativada, então ela é superfundida por:

```
excess = (128 + data_len) × (old_rate − new_rate)
```

Para uma conta SPL token de 165 bytes após a etapa 1, isso é `293 × (6,960 − 6,333) = 183,711` lamports, ou \~0.000184 SOL por conta. Uma conta Token-2022 com extensões é maior, então mantém proporcionalmente mais — uma conta de 182 bytes é superfundida por `310 × 627 = 194,370` lamports.

Individualmente é insignificante. Uma carteira que interagiu com algumas centenas de tokens ao longo dos anos está mantendo um múltiplo significativo disso, e pela etapa 5 cada conta de 165 bytes tem 1,835,352 lamports (\~0.00184 SOL) acima de seu mínimo.

## Quais contas podem devolver

Lamports em excesso em uma conta de propriedade de um programa só podem ser movidos por esse programa. Se você pode reclamar rent sem fechar a conta depende inteiramente de qual programa a possui.

<CardGroup cols={2}>
  <Card title="SPL Token e Token-2022" icon="circle-check">
    Ambos expõem `WithdrawExcessLamports`. A conta permanece aberta, mantém seu saldo de tokens e simplesmente cai para o mínimo atual.
  </Card>

  <Card title="Tudo mais" icon="circle-xmark">
    Nenhuma instrução equivalente. O rent é liberado apenas quando a conta é fechada — uma operação destrutiva com suas próprias pré-condições, não uma limpeza de rent.
  </Card>
</CardGroup>

Concretamente, para os tipos de conta que usuários Raydium mantêm:

| Conta                                 | Proprietário                                  | Pode devolver excesso no lugar?                                  |
| ------------------------------------- | --------------------------------------------- | ---------------------------------------------------------------- |
| Conta de token SPL                    | `TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA` | Sim — `WithdrawExcessLamports`                                   |
| Conta de token Token-2022             | `TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb` | Sim — `WithdrawExcessLamports`                                   |
| Conta de token SOL envolvido (nativo) | qualquer programa de token                    | Não — veja abaixo                                                |
| Posição CLMM                          | Raydium CLMM                                  | Não — rent retorna quando a posição é fechada                    |
| OpenBook v1 open orders               | OpenBook v1                                   | Não — apenas `CloseOpenOrders`                                   |
| OpenBook v2 open orders               | OpenBook v2                                   | Não — apenas `close_open_orders_account`                         |
| Conta de stake                        | Programa de Stake                             | Não — SIMD-0490 fixa `rent_exempt_reserve` em 2,282,880 lamports |

Contas de SOL envolvido são a única exceção do programa de token: seu saldo de lamports *é* seu saldo de tokens, então ambos os programas as rejeitam com `TokenError::NativeNotSupported`. Token-2022 adicionou `UnwrapLamports` (discriminant 45) para esse caso; `@solana/spl-token` fornece `createUnwrapLamportsInstruction` para isso a partir de 0.4.15. Pule contas nativas em uma limpeza de rent e trate-as deliberadamente.

## A instrução `WithdrawExcessLamports`

Discriminant **38** nos enums de instrução de ambos os programas de token. De `spl-token-interface`:

```rust theme={null}
/// This instruction is to be used to rescue SOL sent to any TokenProgram
/// owned account by sending them to any other account, leaving behind only
/// lamports for rent exemption.
///
/// 0. `[writable]` Source Account owned by the token program
/// 1. `[writable]` Destination account
/// 2. `[signer]` Authority
/// 3. `..3+M` `[signer]` M signer accounts
WithdrawExcessLamports,
```

Três propriedades a tornam segura para disparar em toda conta em uma carteira:

* **Não recebe um valor.** O programa computa `source.lamports − rent.minimum_balance(source.data_len())` por si mesmo, então nunca pode levar uma conta abaixo do mínimo atual, e permanece correto conforme as etapas posteriores são ativadas.
* **Não fecha nada.** A conta mantém seus dados, seu proprietário e seu saldo de tokens.
* **É idempotente.** Executá-la contra uma conta já no mínimo move zero lamports e tem sucesso.

Uma conta de token congelada ainda é elegível: congelamento restringe movimento de tokens, não lamports.

### Construindo a instrução

`@solana/spl-token` não exporta um construtor para ela. A partir de `0.4.15` a entrada do enum ainda está comentada:

```ts theme={null}
// packages/spl-token/src/instructions/types.ts
export enum TokenInstruction {
    // ...
    TransferHookExtension = 36,
    // ConfidentialTransferFeeExtension = 37,
    // WithdrawalExcessLamports = 38,   // ← not exposed
    MetadataPointerExtension = 39,
    // ...
}
```

Codifique-a diretamente. A carga útil é um único byte de discriminant:

```ts theme={null}
import { PublicKey, TransactionInstruction } from "@solana/web3.js";

export function createWithdrawExcessLamportsInstruction(params: {
  source: PublicKey;        // the token account holding excess lamports
  destination: PublicKey;   // where the excess goes — usually the wallet itself
  authority: PublicKey;     // owner of `source`, or the multisig account
  multiSigners?: PublicKey[];
  programId: PublicKey;     // TOKEN_PROGRAM_ID or TOKEN_2022_PROGRAM_ID
}): TransactionInstruction {
  const { source, destination, authority, multiSigners = [], programId } = params;
  return new TransactionInstruction({
    programId,
    keys: [
      { pubkey: source, isSigner: false, isWritable: true },
      { pubkey: destination, isSigner: false, isWritable: true },
      { pubkey: authority, isSigner: !multiSigners.length, isWritable: false },
      ...multiSigners.map((pubkey) => ({ pubkey, isSigner: true, isWritable: false })),
    ],
    data: Buffer.from([38]),
  });
}
```

Passe o `programId` de cada conta. Instruções SPL Token e Token-2022 podem compartilhar uma transação, mas cada uma deve ser endereçada ao programa que possui sua conta de origem.

Medido na mainnet, a instrução custa 270 unidades de computação no programa SPL Token e 1,414 no Token-2022 — negligenciável de qualquer forma. A restrição real é o tamanho da transação, não a computação.

## Encontrando contas reclamáveis

Não derive o excesso de uma taxa codificada. Pergunte ao cluster o que cada conta precisa agora, para que o mesmo código continue funcionando através de todas as cinco etapas:

```ts theme={null}
const [tokenResp, token2022Resp] = await Promise.all([
  connection.getTokenAccountsByOwner(owner, { programId: TOKEN_PROGRAM_ID }),
  connection.getTokenAccountsByOwner(owner, { programId: TOKEN_2022_PROGRAM_ID }),
]);
const raw = [...tokenResp.value, ...token2022Resp.value];

// one lookup per distinct account size — a wallet normally has two or three
const spaces = Array.from(new Set(raw.map(({ account }) => account.data.length)));
const minimums = new Map(
  await Promise.all(
    spaces.map(async (space) => [space, await connection.getMinimumBalanceForRentExemption(space)] as const),
  ),
);

const reclaimable = raw.filter(({ account }) => {
  // wrapped SOL carries its token balance as lamports — both programs refuse it.
  // The `is_native` COption tag sits at offset 109 in the token account layout,
  // which Token-2022 preserves before its extension data.
  if (account.data.readUInt32LE(109) === 1) return false;
  return account.lamports > minimums.get(account.data.length)!;
});
```

`getMinimumBalanceForRentExemption(0)` é um canal lateral útil: retorna exatamente `128 × lamports_per_byte`, então dividir por 128 diz qual etapa de implementação o cluster está sem analisar a sysvar `Rent`.

## Agrupamento: quantas cabem em uma transação

Cada instrução `WithdrawExcessLamports` contribui com uma chave de conta gravável única — 32 bytes na mensagem compilada — mais cerca de 7 bytes de codificação de instrução. Destino, autoridade e pagador de taxa são todos a mesma carteira, então custam uma chave entre eles.

Contra o limite de transação de 1,232 bytes, aproximadamente 26 instruções cabem uma vez que instruções de orçamento de computação e o blockhash são contados. **Vinte por transação** é o número de trabalho seguro, e é o que a própria implementação Raydium usa. Uma carteira com 116 contas reclamáveis varre em seis transações, a uma taxa base de 5,000 lamports cada.

Note a economia: a taxa é cobrada por transação, não por conta. Reclamar menos contas não custa menos, é por isso que uma limpeza parcial raramente vale as viagens extras.

## Reclamando através de Raydium

A página [raydium.io/reclaim-rent](https://raydium.io/reclaim-rent) escaneia as contas SPL Token e Token-2022 da carteira conectada, mostra o total dividido por programa e varre tudo em transações agrupadas. O scan é somente leitura — nenhuma assinatura até você pressionar **Reclaim all rent**.

A página deliberadamente cobre apenas contas de token. Tipos de conta que podem liberar rent apenas fechando são excluídos em vez de listados como indisponíveis, porque fechar uma conta é uma ação diferente e destrutiva.

## Reclamando do demo do SDK

<Info>
  **Banner de versão.** Demos visam `@raydium-io/raydium-sdk-v2@0.2.42-alpha` contra Solana mainnet-beta, verificado 2026-09. `WithdrawExcessLamports` é codificado manualmente e é independente da versão do SDK; o SDK é usado apenas para construção e agrupamento de transações.
</Info>

Dois scripts em [`raydium-sdk-V2-demo/src/rent`](https://github.com/raydium-io/raydium-sdk-V2-demo/tree/master/src/rent):

```bash theme={null}
# read-only: what can this wallet reclaim, and what would it be worth after all five steps
yarn dev src/rent/checkReclaimableRent.ts
yarn dev src/rent/checkReclaimableRent.ts <any wallet address>

# build, simulate (DRY_RUN = true by default), then send the batched sweep
yarn dev src/rent/reclaimRent.ts
```

`reclaimRent.ts` agrupa em 20 contas por transação e assina todos os lotes em uma passagem:

```ts theme={null}
const batches = chunk(report.accounts, ACCOUNTS_PER_TX);

const builtTxs = await Promise.all(
  batches.map(async (batch) => {
    const builder = new TxBuilder({
      connection,
      feePayer: owner.publicKey,
      cluster: raydium.cluster,
      owner: raydium.owner,
    });
    builder.addInstruction({
      instructions: batch.map((account) =>
        createWithdrawExcessLamportsInstruction({
          source: account.pubkey,
          destination: owner.publicKey,
          authority: owner.publicKey,
          programId: account.programId,
        }),
      ),
    });
    return builder.versionBuild({ txVersion });
  }),
);

// versionMultiBuild puts the calling builder's transaction first and appends
// extraPreBuildData after it, so batch 1 drives and batches 2..n follow in order
const [firstTx, ...restTxs] = builtTxs;
const { execute } = await firstTx.builder.versionMultiBuild({ txVersion, extraPreBuildData: restTxs });
const { txIds } = await execute({ sequentially: true });
```

Simule antes de enviar. `simulateTransaction` com `accounts.addresses` retorna saldos de lamports pós-execução, que é a forma mais barata de confirmar que a aritmética corresponde ao que o cluster realmente fará.

## Você deve reclamar agora ou esperar?

Ambos são bons, e a diferença é pequena de qualquer forma:

* **O excesso não vai a lugar nenhum.** Fica em suas próprias contas. Nada expira, nada é varrido, nenhum prazo se aplica.
* **Esperar compõe.** Cada etapa libera mais das mesmas contas, e uma limpeza após a etapa 5 custa o mesmo em taxas que uma limpeza hoje.
* **Reclamar agora não perde etapas posteriores.** Uma conta que você varre hoje está simplesmente no mínimo atual; a próxima etapa a torna superfundida novamente e você pode varrê-la novamente.

O único custo real de reclamar cedo é a taxa base, e o único custo real de esperar é que os lamports permaneçam imóveis um pouco mais.

## Leitura adicional

<CardGroup cols={2}>
  <Card title="SIMD-0437" icon="file-code" href="https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0437-incremental-rent-reduction.md">
    A proposta em si — os cinco feature gates e a justificativa para escalonar a redução.
  </Card>

  <Card title="Rent reduzido" icon="book" href="https://solana.com/upgrades/reduced-rent">
    Página de implementação de Solana: etapa atual, cronograma e o que muda para novas contas.
  </Card>

  <Card title="Redução de rent: uma análise baseada em dados" icon="chart-line" href="https://solana.com/news/rent-reduction-deep-dive">
    A economia e o risco de crescimento de estado que a implementação escalonada é projetada para gerenciar.
  </Card>

  <Card title="Modelo de conta" icon="database" href="/pt/solana-fundamentals/account-model">
    Como contas Solana são financiadas, possuídas e fechadas — o contexto para tudo acima.
  </Card>
</CardGroup>
