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.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 reduzlamports_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: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.
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:
- 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.
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:
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çã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 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.raydium-sdk-V2-demo/src/rent:
reclaimRent.ts agrupa em 20 contas por transação e assina todos os lotes em uma única 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 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
WithdrawExcessLamportsdo programa de token (discriminante 38), assinando como esse PDA. - Um vault de 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é-sincronização. 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 limpeza. - Uma conta de estado de propriedade do programa —
AmmInfo,PoolState,AmmConfig,ObservationState, umPlatformConfig, 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 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 revogaMintTokens 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.
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.

