Skip to main content
Esta página foi traduzida automaticamente por IA. A versão em inglês é a fonte oficial.Ver versão em inglês →
Aluguel é um depósito reembolsável, não uma taxa. SIMD-0437 reduz o depósito que cada conta deve manter, em cinco etapas independentes. 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.
Leia Modelo de conta primeiro se você é novo em como as contas Solana são financiadas.

O que aluguel realmente é

Toda conta em Solana mantém um depósito de SOL dimensionado pelo espaço que ocupa. Não é gasto — é devolvido integralmente quando a conta é fechada. A fórmula é:
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 de token SPL 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 portais de recursos separados para que validadores possam absorver o efeito do crescimento de estado um passo de cada vez. A etapa 1 foi ativada na mainnet em 3 de setembro de 2026. A etapa 2 chegou à testnet no mesmo dia e é esperada na mainnet em meados de setembro de 2026; as etapas 3–5 estão reservadas para Agave 4.4, esperado por volta de novembro de 2026. Trate o cronograma como sujeito a mudanças — a Fundação disse que pausará o lançamento se o crescimento de estado se comportar mal — e leia o valor ao vivo do cluster em vez de codificá-lo.
SIMD-0437 depende de SIMD-0194, que depreca o limite de isenção de aluguel “para evitar matemática de ponto flutuante desnecessária ao definir os parâmetros de aluguel na ativação do recurso”. Na prática, o Rent sysvar 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.

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 está superfundida por:
Para uma conta de token SPL 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 está 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 programa só podem ser movidos por esse programa. Se você pode reclamar aluguel sem fechar a conta depende inteiramente de qual programa a possui.

SPL Token e Token-2022

Ambos expõem WithdrawExcessLamports. A conta permanece aberta, mantém seu saldo de tokens e simplesmente cai para o mínimo atual.

Tudo mais

Nenhuma instrução equivalente. O aluguel é liberado apenas quando a conta é fechada — uma operação destrutiva com suas próprias pré-condições, não uma limpeza de aluguel.
Concretamente, para os tipos de conta que usuários Raydium mantêm: 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. Ambos os programas expõem UnwrapLamports (discriminante 45) para esse caso — está em spl-token-interface junto com WithdrawExcessLamports, então o programa legado também tem, não apenas Token-2022 — e @solana/spl-token fornece createUnwrapLamportsInstruction para isso a partir de 0.4.15. Pule contas nativas em uma limpeza de aluguel simples e trate-as deliberadamente; o padrão para fazer isso com segurança é o que os próprios programas Raydium usam, abaixo.

A instrução WithdrawExcessLamports

Discriminante 38 nos enums de instrução de ambos os programas de token. De spl-token-interface:
Três propriedades a tornam segura para disparar em cada conta de uma carteira:
  • Não leva um valor. O programa computa source.lamports − rent.minimum_balance(source.data_len()) por si só, 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 — e note que o upstream escreve o identificador WithdrawalExcessLamports, com o “al” extra, então faça grep por isso:
Codifique-a diretamente. A carga útil é um único byte discriminante:
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:
getMinimumBalanceForRentExemption(0) é um canal lateral útil: retorna exatamente 128 × lamports_per_byte, então dividir por 128 diz qual etapa de lançamento o cluster está sem analisar o Rent sysvar.

Agrupamento: quantos 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 25 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 implementação própria 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 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 aluguel 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

Banner de versão. Esses demos visam @raydium-io/raydium-sdk-v2@0.2.64-alpha contra Solana mainnet-beta, verificado em 2026-09; o repositório raydium-sdk-V2-demo em si atualmente instala 0.2.62-alpha, e os dois são intercambiáveis aqui. WithdrawExcessLamports é codificado manualmente e é independente da versão do SDK — o SDK é usado apenas para construção e agrupamento de transações.
Dois scripts em raydium-sdk-V2-demo/src/rent:
reclaimRent.ts agrupa em 20 contas por transação e assina todos os lotes em uma única passagem:
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á.

O que os programas Raydium varrem do seu lado

Sua carteira não é o único lugar onde a redução libera lamports. Cada pool mantém aluguel também — vaults, mints de LP e as contas de estado de propriedade do programa que foram todas financiadas à taxa antiga. Esse aluguel pertence ao protocolo, não aos LPs: foi pago por quem criou a conta, não faz parte das reservas de nenhum pool, e nunca entrou na curva. Três programas ganharam uma instrução de admin em 2026-09-09 para devolvê-lo: Endereços estão em reference/program-addresses. CLMM e Stable AMM não fizeram parte desse lançamento. Nada aqui afeta um LP ou um trader. Essas instruções movem lamports e apenas lamports. Saldos de tokens, dados de conta, proprietários, status do pool, suprimento de LP, contadores de taxa e a curva são todos intocados, e nenhum deles pode fechar uma conta. A cotação de um pool para um swap é idêntica antes e depois de uma limpeza. Não há ação do lado do usuário, nenhuma opção de participação e nenhum prazo.

As três formas de conta que cada programa trata

Todos os três seguem o mesmo despacho, no proprietário da conta de origem:
  • Uma conta de token ou mint de propriedade de um PDA de autoridade do programa — o programa CPI o WithdrawExcessLamports do programa de token (discriminante 38), assinando como esse PDA.
  • Um vault de SOL envolvido — WithdrawExcessLamports recusa contas nativas, então o programa SyncNative primeiro (que dobra o excesso doado no amount envolvido), mede exatamente quanto o valor envolvido cresceu, UnwrapLamports para esse delta, e então afirma que o saldo envolvido está de volta ao seu valor pré-sincronização. Se essa verificação falhar, toda a instrução reverte com um LamportsCalculateError. É por isso que um vault de pool do lado SOL mantém sua liquidez completa através de uma limpeza.
  • Uma conta de estado de propriedade do programa — AmmInfo, PoolState, AmmConfig, ObservationState, um PlatformConfig, e assim por diante. Um programa pode debitar suas próprias contas diretamente, então move o saldo para rent.minimum_balance(data_len) sem nenhum CPI.
Contas de propriedade de qualquer outra coisa são puladas silenciosamente, então passar uma conta não relacionada é inofensivo em vez de fatal. A sequência de SOL envolvido vale a pena copiar se você mantém contas nativas próprias: é a única forma de tirar o excesso de uma conta wSOL sem mudar o que a conta relata como seu saldo de tokens.
Esses caminhos dependem do programa de token implantado, não de uma versão de crate. Todos os três programas codificam manualmente as instruções de token — um único byte 38 para WithdrawExcessLamports, 45 mais um COption<u64> para UnwrapLamports — e os enviam para qualquer programa de token que possua a conta de origem. Ambas as instruções existem nos programas SPL Token e Token-2022 atuais da mainnet. Um validador local ou harness de teste executando uma compilação SPL Token agrupada mais antiga não as implementa, e uma limpeza contra ela falha em um discriminador desconhecido em vez de em qualquer coisa no programa Raydium. Teste esses caminhos contra um programa de token clonado da mainnet.

O que ainda não pode ser reclamado no lugar

O aluguel de uma posição CLMM é inalterado por tudo isso — volta quando a posição é fechada, como a tabela acima diz. O mesmo para o mint base LaunchLab: a instrução de inicialização revoga MintTokens na mesma chamada que cunha o suprimento, então nenhuma chave pode nunca assinar um WithdrawExcessLamports para esse mint e seu aluguel é isolado por design.

Você deve reclamar agora ou esperar?

Ambos estão bem, 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 deixa 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

SIMD-0437

A proposta em si — os cinco portais de recursos e a lógica para escalonar a redução.

Reduced rent

Página de lançamento de Solana: etapa atual, cronograma e o que muda para novas contas.

Rent reduction: a data-backed analysis

A economia e o risco de crescimento de estado que o lançamento escalonado é projetado para gerenciar.

Account model

Como as contas Solana são financiadas, possuídas e fechadas — o contexto para tudo acima.