Principais conclusões
- Desenvolvedores do XRPL propõem quatro correções para lacunas na autorização de tokens
- Novas regras visam detenções não autorizadas em pagamentos e negociações
- As alterações permanecem não aprovadas, sem exploração externa conhecida
Desenvolvedores do XRP Ledger estão trabalhando em quatro correções relacionadas à segurança projetadas para impedir que ativos digitais restritos alcancem contas sem autorização, abordando possíveis fraquezas na infraestrutura cada vez mais utilizada para tokenização institucional.
As alterações estão agrupadas sob uma proposta de emenda chamada fixCleanup3_5_0, com a proposta de código do GitHub atualizada em 27 de outubro. As correções fortaleceriam as permissões de tokens controladas pelo emissor em pagamentos, market makers automatizados e outras transações.
Desenvolvedores do XRP Ledger visam quatro fraquezas de autorização
A proposta concentra-se em tokens que exigem autorização explícita do emissor antes que uma conta possa detê-los.
Essas restrições são particularmente relevantes para stablecoins regulamentadas e títulos tokenizados, onde os emissores podem precisar verificar a identidade dos investidores ou aplicar requisitos de elegibilidade.
Na arquitetura existente, a aprovação é registrada por meio de uma linha de confiança que conecta uma conta ao emissor do token. Desenvolvedores identificaram várias situações nas quais transações poderiam contornar as verificações de autorização pretendidas.
Um problema envolve tokens de liquidez de criadores automatizados, que representam reivindicações sobre ativos depositados em pools de negociação. A correção proposta exigiria que os destinatários tenham autorização para ambos os ativos subjacentes antes de adquirir um token de pool.
Outro endereço trata de uma isenção que afeta linhas de confiança com saldos existentes. Anteriormente, certas verificações se aplicavam apenas quando uma linha de confiança tinha zero tokens, potencialmente permitindo que um saldo não autorizado aumentasse por meio de transações subsequentes.
O pacote mais amplo também busca impedir que saldos de tokens não autorizados sejam utilizados em transferências distintas da resgate junto ao emissor e introduzir verificações adicionais de consistência.
Essas alterações seguem trabalhos anteriores sobre permissioned liquidity pools, onde os desenvolvedores exploraram a restrição da participação a contrapartes institucionais verificadas.
Por que as correções importam para a tokenização institucional
As propostas de alterações chegam à medida que instituições financeiras tradicionais ampliam seu uso do XRP Ledger para ativos digitais.
BNY expandiu recentemente suas capacidades de custódia de XRP e RLUSD, enquanto a Ripple buscou parcerias envolvendo liquidação em stablecoin, títulos tokenizados e financiamento institucional.
Para instituições regulamentadas, a capacidade de controlar quais contas podem legalmente receber ou detentar ativos específicos é essencial.
Um emissor que distribui ações de fundo tokenizadas, por exemplo, pode precisar garantir que esses tokens permaneçam com investidores elegíveis. Se uma transação no mercado secundário ou um mecanismo de pool de liquidez contornar verificações de autorização, os controles de conformidade do sistema tornam-se menos confiáveis.
As correções propostas fortaleceriam essas proteções sem alterar o modelo de propriedade nativa do XRP nem exigir que detentores comuns de XRP obtenham permissão do emissor.
O trabalho também segue uma versão de segurança anterior do XRPL, que introduziu proteções separadas para a funcionalidade de transações em lote da rede.
Quando poderia ser ativada a atualização de segurança do XRP Ledger?
As quatro alterações não foram integradas ao software principal do XRP Ledger nem ativadas no mainnet.
Após a implementação e a revisão serem concluídas, a emenda ainda precisaria do apoio de mais de 80% dos validadores confiáveis por duas semanas consecutivas antes da ativação.
O processo é separado da janela de atualização anterior November 4 upgrade window, que se refere ao fixCleanup3_4_0 e não ao recém-proposto fixCleanup3_5_0.