O XRP Ledger 3.2.0 está prestes a ser lançado, e o software principal rippled foi renomeado para xrpld

As Operações da XRP Ledger anunciaram no dia 4 de junho, na X, que a versão 3.2.0 do XRP Ledger está prestes a ser implantada na rede principal; o software do servidor central passará de «rippled» para «xrpld». Todos os fornecedores de infraestruturas, validadores e operadores de nós devem concluir as atualizações do sistema antes de efetuarem a migração para a nova rede principal XRPL; a equipa de desenvolvimento confirmou que estão a ser elaborados guias técnicos de migração detalhados.

Detalhes da renomeação 3.2.0 e requisitos de atualização obrigatória

A CLI (interface de linha de comandos) foi atualizada para refletir o novo nome do software, exibindo «versão xrpld 3.2.0» durante a verificação da versão. As Operações da XRP Ledger, no comunicado, indicaram: «Esta transição exigirá que os operadores de infraestruturas façam algumas atualizações.» A equipa de desenvolvimento confirmou que está a preparar um manual técnico operacional detalhado para orientar os participantes no processo de migração, assegurando a continuidade da consensualização e da participação na rede durante a atualização.

dUNL validador Vet deu as boas-vindas a este anúncio publicamente e afirmou: «O sentimento do mercado é temporário, mas as melhorias do protocolo central são permanentes.» O ex-CTO da Ripple, David Schwartz, respondeu a questões-chave em relação à atualização de 3.1.3, que acabou por ser aprovada com 100% de consenso.

Integração RLUSD Wormhole NTT: cadeias confirmadas e números de circulação

De acordo com o comunicado oficial da Ripple e da Wormhole a 4 de junho de 2026, o RLUSD já pode ser transferido nativamente entre ecossistemas de cadeias suportadas através da framework NTT da Wormhole. A Ripple confirmou como ecossistemas-alvo suportados a Optimism, Base, Ink, Unichain e a sidechain EVM da XRPL; o RLUSD já tinha sido emitido nativamente na XRP Ledger e na Ethereum. A framework NTT da Wormhole suporta limites de taxa, controlo de acesso e estatísticas de quantidade em circulação, permitindo que as entidades emissoras mantenham o controlo e as funcionalidades nativas do token durante transferências cross-chain.

A Wanchain já integrou o RLUSD na sua arquitetura de ponte, suportando a transferência entre XRPL, Ethereum, Cardano e Wanchain.

Perguntas frequentes

Que impacto operacional tem a renomeação de «rippled» para «xrpld» nos operadores de nós existentes?

De acordo com a explicação oficial das Operações da XRP Ledger, todos os fornecedores de infraestruturas, validadores e operadores de nós devem concluir as atualizações do sistema antes de migrarem para a nova rede principal XRPL; a CLI já foi atualizada antecipadamente para refletir o novo nome. A equipa de desenvolvimento confirmou que está a preparar guias de migração detalhados, mas até à data do comunicado, o manual técnico operacional específico ainda não foi publicado formalmente.

Quais são as diferenças confirmadas de funcionalidades entre o XRP Ledger 3.2.0 e o 3.1.3?

O texto de origem confirma que o 3.1.3 (lançado a 27 de maio de 2026) introduziu várias correções para componentes de NFT, sistema de custódia, domínios de permissões e protocolos de empréstimo, e melhorou a fiabilidade de longo prazo da rede através de alterações ao fixCleanup3_1_3. A principal alteração confirmada no 3.2.0 é a renomeação do software central (rippled→xrpld) e a modernização mais abrangente da arquitetura subjacente do protocolo; a lista completa de novas funcionalidades ainda não foi divulgada até à data do comunicado.

Em que difere a integração do RLUSD via Wormhole NTT face às anteriores soluções cross-chain?

A framework NTT da Wormhole (transferência nativa de tokens) permite que o RLUSD, durante transferências cross-chain, mantenha as funcionalidades nativas do token (incluindo metadados, propriedade, possibilidade de atualização e funcionalidades personalizadas). Ao mesmo tempo, a entidade emissora mantém o controlo sobre o token e a solução suporta limites de taxa e controlo de acesso. Isto difere de arquiteturas tradicionais de ponte, que normalmente envolvem mecanismos de «bloquear e cunhar» de ativos, podendo acarretar riscos contratuais na ponte.