Los desarrolladores que trabajan en la XRP Ledger están probando una forma de crear cuentas de cadena de bloques con cero XRP, lo que posiblemente permitirá que las aplicaciones de pago y el software automatizado operen sin necesidad de depositar primero la criptomoneda en cada monedero.
Una propuesta de código presentada el 15 de octubre introduce una transacción llamada SponsoredAccountCreate, que permitiría a una cuenta existente crear otra cuenta y cubrir su requisito de reserva.
XRP Ledger actualmente requiere una reserva mínima de 1 XRP por cada cuenta. Ese dinero permanece bloqueado mientras la cuenta esté activa, impidiendo que la red se sature con monederos vacíos.
Una empresa que crea 100,000 cuentas separadas necesitaría reservar 100,000 XRP solo para cumplir con esos requisitos de reserva.
Bajo el sistema propuesto, una cuenta patrocinadora cubriría la reserva, permitiendo que el nuevo monedero mantenga un saldo XRP de cero. La obligación total de reserva de la red permanecería, con el patrocinador asumiendo el costo en lugar del cliente.
Los patrocinadores también podrían cubrir las tarifas de transacción mediante un mecanismo de patrocinio más amplio, permitiendo que las aplicaciones paguen esos cargos en nombre de sus usuarios.
Ripple recientemente se asoció con Privy, propiedad de Stripe para incorporar monederos integrados en aplicaciones del XRP Ledger. La integración está diseñada para respaldar pagos con XRP y la stablecoin RLUSD de Ripple, incluyendo pagos automatizados realizados por agentes de IA.
Esos monederos actualmente requieren financiación con XRP antes de poder activarse, incluso cuando solo están destinados a mantener stablecoins.
La transacción de creación de cuenta propuesta se basa en el estándar más amplio de Tarifas y Reservas Patrocinadas, que permite que otra cuenta pague los costos de la red sin tomar el control de las claves privadas del usuario. El nuevo código crearía una cuenta directamente sin enviarle ninguna XRP.
La pull request permanece abierta, con dos hallazgos de revisión automática de código sin resolver. También depende de cambios en el patrocinio que aún no se han activado en el mainnet.
Esos cambios aún necesitan la aprobación del validador. La enmienda de patrocinio tenía 11 de los 35 votos que necesita de los validadores confiables de la red al 19 de octubre, según XRPL Dashboard, muy por debajo de los 29 requeridos.