Esta página foi traduzida automaticamente por IA. A versão em inglês é a fonte oficial.Ver versão em inglês →
Rent é 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.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 é: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 reduzlamports_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.
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 Foundation 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 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, o 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.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: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 isso é 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.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 rent é liberado apenas quando a conta é fechada — uma operação destrutiva com suas próprias pré-condições, não uma varredura de rent.
Contas SOL envolvidas 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 varredura de rent 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:
- Não leva 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.
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 upstream soletra o identificador WithdrawalExcessLamports, com o “al” extra, então procure por isso:
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 sysvar Rent.
Lotes: quantos cabem em uma transação
Cada instruçãoWithdrawExcessLamports 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 varredura 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 em lote. 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
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 lote de transações.raydium-sdk-V2-demo/src/rent:
reclaimRent.ts faz lotes de 20 contas por transação e assina todos os lotes em uma passagem:
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 rent também — vaults, mints de LP, e as contas de estado de propriedade do programa que foram todas financiadas à taxa antiga. Esse rent 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, e CLMM seguiu em 2026-09-30:
Endereços estão em
reference/program-addresses. AMM estável não tem equivalente.
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 varredura. Não há ação do lado do usuário, nenhum opt-in, e nenhum prazo.
As três formas de conta que cada programa trata
Todos os quatro 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 CPIs a
WithdrawExcessLamportsdo programa de token (discriminante 38), assinando como esse PDA. Em CLMM esse PDA é oPoolStateem si, então uma chamada cobre os vaults de um pool. - Um vault SOL envolvido —
WithdrawExcessLamportsrecusa contas nativas, então o programaSyncNativeprimeiro (que dobra o excesso doado noamountenvolvido), mede exatamente quanto o valor envolvido cresceu,UnwrapLamportspara esse delta, e então afirma que o saldo envolvido está de volta ao seu valor pré-sync. Se essa verificação falhar, toda a instrução reverte com umLamportsCalculateError. É por isso que um vault de pool do lado SOL mantém sua liquidez completa através de uma varredura. - Uma conta de estado de propriedade do programa —
AmmInfo,PoolState,AmmConfig,ObservationState, umPlatformConfig, umTickArrayStateCLMM, e assim por diante. Um programa pode debitar suas próprias contas diretamente, então move o saldo pararent.minimum_balance(data_len)sem nenhum CPI.
Esses caminhos dependem do programa de token implantado, não de uma versão de crate. Todos os quatro programas codificam manualmente as instruções de token — um único byte
38 para WithdrawExcessLamports, 45 mais um COption<u64> para UnwrapLamports — e as 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 varredura contra ele 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
Você ainda não pode reclamar o rent de uma posição CLMM no lugar você mesmo. Ele volta quando a posição é fechada, como a tabela acima diz. OCollectExcessLamports próprio de CLMM não verifica quem financiou uma conta, então pode tirar o excesso de um PersonalPositionState ou LimitOrderState. A conta fica no seu mínimo de rent, e esse mínimo é o que o close reembolsa. O mesmo para o mint base de LaunchLab: a instrução initialize revoga MintTokens na mesma chamada que cunha o suprimento, então nenhuma chave pode nunca assinar um WithdrawExcessLamports para esse mint e seu rent fica preso 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 varredura após a etapa 5 custa o mesmo em taxas que uma varredura 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.
Leitura adicional
SIMD-0437
A proposta em si — os cinco feature gates 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 contas Solana são financiadas, possuídas e fechadas — o contexto para tudo acima.

