Principales conclusiones
- Los desarrolladores de XRPL proponen cuatro soluciones para cerrar brechas en la autorización de tokens
- Nuevas normas apuntan a tenencias no autorizadas en pagos y operaciones
- Los cambios permanecen sin aprobar, sin explotación externa conocida
Los desarrolladores de XRP Ledger están trabajando en cuatro correcciones relacionadas con la seguridad diseñadas para evitar que Activos digitales restringidos lleguen a cuentas sin autorización, abordando posibles debilidades en la infraestructura cada vez más utilizada para la tokenización institucional.
Los cambios se agrupan bajo una enmienda propuesta llamada fixCleanup3_5_0, con la propuesta de código de GitHub actualizada el 27 de octubre. Las correcciones fortalecerían los permisos controlados por el emisor de tokens en pagos, creadores de mercados automatizados y otras transacciones.
Desarrolladores de XRP Ledger apuntan a cuatro debilidades de autorización
La propuesta se centra en los tokens que requieren autorización explícita del emisor antes de que una cuenta pueda poseerlos.
Estas restricciones son particularmente relevantes para stablecoins reguladas y valores tokenizados, donde los emisores pueden necesitar verificar la identidad de los inversores o hacer cumplir los requisitos de elegibilidad.
Bajo la arquitectura existente, la aprobación se registra mediante una línea de confianza que conecta una cuenta con el emisor del token. Los desarrolladores identificaron varias circunstancias en las que las transacciones podrían omitir las verificaciones de autorización previstas.
Un problema involucra los tokens de liquidez de creadores de mercado automatizados, que representan reclamos sobre activos depositados en piscinas de negociación. La corrección propuesta requeriría que los receptores tengan autorización para ambos activos subyacentes antes de adquirir un token de piscina.
Otro aborda una exención que afecta las líneas de confianza con saldos existentes. Anteriormente, ciertas verificaciones se aplicaban solo cuando una línea de confianza tenía cero tokens, lo que potencialmente permitía que un saldo no autorizado aumentara a través de transacciones posteriores.
El paquete más amplio también busca evitar que los saldos de tokens no autorizados se utilicen en transferencias distintas a la redención al emisor e introducir controles de consistencia adicionales.
Estos cambios siguen trabajos anteriores sobre permissioned liquidity pools, donde los desarrolladores exploraron restringir la participación a contrapartes institucionales verificadas.
Por qué las correcciones son importantes para la tokenización institucional
Los cambios propuestos llegan mientras las instituciones financieras tradicionales amplían su uso del XRP Ledger para Activos digitales.
BNY recientemente amplió sus capacidades de custodia de XRP y RLUSD, mientras que Ripple ha buscado relaciones que involucran liquidación con stablecoin, valores tokenizados y financiamiento institucional.
Para instituciones reguladas, la capacidad de controlar qué cuentas pueden recibir o mantener legalmente activos específicos es esencial.
Un emisor que distribuye acciones de fondos tokenizadas, por ejemplo, puede necesitar asegurar que esos tokens permanezcan con inversores elegibles. Si una transacción en el mercado secundario o un mecanismo de pool de liquidez elude las verificaciones de autorización, los controles de cumplimiento del sistema se vuelven menos confiables.
Las soluciones propuestas fortalecerían esas protecciones sin modificar el modelo de propiedad nativa de XRP ni requerir que los titulares ordinarios de XRP obtengan permiso del emisor.
El trabajo también sigue un lanzamiento de seguridad de XRPL anterior, que introdujo protecciones separadas para la funcionalidad de transacciones por lote de la red.
¿Cuándo podría activarse la actualización de seguridad del libro mayor XRP?
Los cuatro cambios no se han integrado en el software principal del XRP Ledger ni se han activado en el mainnet.
Una vez completadas la implementación y la revisión, la enmienda aún necesitaría el apoyo de más del 80% de los validadores confiables durante dos semanas consecutivas antes de la activación.
El proceso es independiente de la ventana de actualización anterior 4 de noviembre, que se refiere a fixCleanup3_4_0 en lugar de fixCleanup3_5_0 recién propuesto.