Respuesta rápida: Un diseño propuesto de cuentas patrocinadas en XRP Ledger podría permitir que la cuenta de un usuario final mantenga cero XRP mientras un patrocinador distinto asume la reserva de la cuenta y, según la configuración, las tarifas de transacción. La obligación de reserva no desaparece: se traslada al patrocinador. Según la verificación de fuentes del 9 de noviembre de 2026, la especificación concreta SponsoredAccountCreate seguía siendo una propuesta abierta, por lo que no conviene suponer que todas las carteras o servicios de Mainnet admitan este flujo.
¿Por qué una cuenta de XRP Ledger necesita normalmente XRP?
XRP Ledger utiliza reservas para limitar la cantidad de datos que las cuentas y sus objetos añaden al registro compartido. Según los parámetros de reserva de Mainnet publicados por XRPL, la reserva base es de 1 XRP por cuenta y la reserva de propietario suele ser de 0,2 XRP por objeto del registro, con las excepciones documentadas. Normalmente una cuenta debe financiarse antes de existir en el registro, y los XRP reservados no pueden gastarse como un saldo libre.
Esas cifras son parámetros de red, no una tesis de inversión. Los validadores pueden modificar los ajustes de reserva mediante el proceso de votación de tarifas de la red. Cualquier artículo que cite una reserva fija debería fechar la cifra y enlazar a la página actual de XRPL.
¿Qué es una cuenta patrocinada?
Una cuenta patrocinada separa el control de la cuenta de la responsabilidad sobre su reserva y sus tarifas. XLS-68, Sponsored Fees and Reserves describe un patrocinador que paga ciertos costos en nombre de un patrocinado. El patrocinado conserva el control de sus claves y de su cuenta. El patrocinador mantiene XRP para cubrir el requisito de reserva soportado, en lugar de transferir un importe equivalente al saldo disponible del patrocinado.
Esto puede ayudar a una aplicación a incorporar usuarios que solo desean recibir una stablecoin o realizar un pago. No convierte XRP en una red sin tarifas ni elimina el costo económico de almacenar cuentas y trust lines. Alguien sigue aportando la reserva.
El diseño también necesita reglas para finalizar el patrocinio. La divulgación de vulnerabilidad de XRPL de septiembre de 2026 describió un fallo en Devnet en el que un patrocinador podía dejar de respaldar un objeto antes de que el propietario pudiera financiar su reserva. La corrección exige que la reserva siga cubierta por el patrocinado, otro patrocinador, o que el objeto sea eliminado. Dicha divulgación indicó que ningún fondo de Mainnet estuvo en riesgo porque la enmienda aún no se había activado en el momento de la publicación.
¿Qué añade SponsoredAccountCreate?
Propone una forma directa de crear una cuenta con saldo cero de XRP mientras otra cuenta patrocina su reserva. Un pull request de estándares del 16 de octubre de 2026 describe una nueva transacción SponsoredAccountCreate. En la propuesta, los XRP que respaldan la reserva de la cuenta permanecen con el patrocinador en lugar de tocar la nueva cuenta durante su creación.
La propuesta es distinta del marco más amplio de patrocinio XLS-68. Un pull request de estándares es evidencia de un diseño en discusión, no prueba de activación en Mainnet ni de compatibilidad con todas las carteras. Los editores deberían volver a consultar la página de estado de enmiendas de XRPL y la propuesta antes de publicar, porque el estado de la red puede cambiar.
¿Una cartera con cero XRP reduce la demanda de XRP?
La propuesta por sí sola no establece esa conclusión. Puede reducir la cantidad de XRP que un usuario final individual necesita adquirir antes de usar una aplicación. Sin embargo, el patrocinador seguiría reteniendo XRP para reservas y posiblemente pagando tarifas. El efecto sobre la demanda agregada de XRP depende de cuántas cuentas sean patrocinadas, de cómo evolucionen las reglas de reserva, de si esas cuentas habrían existido de otro modo y de cómo gestionen sus saldos los patrocinadores. Esas variables no pueden inferirse del texto de la propuesta ni de un titular.
El beneficio más claro para el usuario es operativo: un proveedor de cartera podría gestionar la reserva en segundo plano mientras el usuario conserva el control de sus claves. Una aplicación de pagos o de stablecoins aún tendría que explicar quién patrocina la cuenta, qué ocurre si el servicio deja de operar y qué operaciones exigen que el usuario financie sus propios XRP.
¿Qué deben comprobar los usuarios antes de confiar en una cartera patrocinada?
Revisa la implementación y los términos del servicio, no la etiqueta «cero XRP». Confirma que la enmienda correspondiente esté activa en la red que usas, que la cartera la haya implementado, que el patrocinador esté identificado y que las reglas de salida sean claras. Si el patrocinador deja de pagar, la cuenta o sus objetos podrían requerir otro patrocinador o XRP suficientes por parte del usuario antes de que ciertas acciones puedan continuar. El comportamiento exacto depende de las reglas finalmente activadas y de la implementación de la cartera.
¿Son lo mismo las tarifas de transacción y las reservas de cuenta?
No. Las tarifas pagan operaciones individuales; las reservas respaldan el espacio que una cuenta y sus objetos ocupan en el registro. Un pago único tiene una tarifa de transacción. Una cuenta tiene una reserva base, y ciertas entradas adicionales, como las trust lines, pueden generar requisitos de reserva de propietario. Un servicio podría patrocinar tarifas, reservas o ambas según las reglas permitidas. Un titular que dice «sin gas» o «cero XRP» no indica qué costos paga cada parte.
Considera un usuario que desea mantener una stablecoin dolarizada emitida en XRP Ledger. Es posible que necesite una cuenta y una trust line. Incluso si una aplicación paga la tarifa de transacción para crear la trust line, las obligaciones de reserva de la cuenta y del objeto siguen debiendo cubrirse. El marco de patrocinio aborda esas obligaciones por separado. Esto importa a los operadores de aplicaciones porque el costo de incorporar muchas cuentas no es solo la suma de tarifas de pago únicas. El operador podría tener que mantener un saldo de XRP mientras patrocine las cuentas u objetos.
La página de reservas de XRPL documenta los ajustes actuales de reserva base y de propietario. También explica que esos valores pueden cambiar. Un producto puede simplificar el saldo visible del cliente conservando una obligación real de reserva en segundo plano.
¿Qué pasa si un patrocinador quiere dejar de pagar?
La reserva debe seguir respaldada durante el traspaso. Esta es la cuestión central de seguridad detrás del patrocinio. Si un patrocinador pudiera reclamar al instante los XRP reservados mientras el patrocinado aún poseyera una cuenta o una trust line, el registro podría acumular entradas sin respaldo. La divulgación de vulnerabilidad de XRPL describe un fallo detectado durante pruebas en Devnet que expuso exactamente esa preocupación para los objetos patrocinados. La remediación reportada exige que el patrocinado cubra la reserva, que un nuevo patrocinador la asuma, o que la cuenta u objeto sean eliminados antes de que el primer patrocinador recupere su respaldo.
Esa regla cambia la economía para los proveedores de servicios. Patrocinar una gran base de usuarios puede inmovilizar XRP durante un período incierto. Por ello, un proveedor debería planificar el cierre de cuentas, la transferencia del patrocinio y los usuarios que no tienen XRP cuando el proveedor desee retirarse. Para los usuarios, la información clave es si su capacidad de seguir usando una cartera depende de que un proveedor concreto continúe pagando. La respuesta dependerá de la especificación finalmente activada y de los términos de servicio del proveedor.
¿Por qué una especificación abierta es distinta de una función usable en una cartera?
Una propuesta de estándares es un paso dentro de un camino más largo. La propuesta debe revisarse, implementarse en el software de nodo, aprobarse mediante el proceso de enmiendas de la red donde corresponda y ser adoptada por proveedores de carteras o aplicaciones. Incluso después de que una regla de red esté activa, una cartera existente podría no exponer un flujo de cuentas patrocinadas. El pull request de SponsoredAccountCreate seguía abierto cuando se consultó el 9 de noviembre de 2026. La página known-amendments ofrece un lugar para revisar la enmienda Sponsor más amplia, pero su estado debe leerse en el momento de la publicación y no copiarse de un artículo anterior.
Los lectores también deberían evitar confundir una cuenta de exchange con una cuenta on-chain de XRP Ledger. Un exchange centralizado puede permitir a un cliente ver un saldo de XRP dentro de su propio registro interno mientras el exchange gestiona direcciones y reservas on-chain. La función propuesta de cuentas patrocinadas concierne a las cuentas y transacciones de XRPL, no es una promesa de que todas las cuentas de exchange cambien sus requisitos de depósito.
¿Qué contaría como evidencia de adopción real?
Busca una implementación identificada y uso observable. La evidencia útil incluiría una enmienda de red activada, documentación de cartera en producción, términos de patrocinio publicados y datos de transacciones o cuentas que muestren el flujo en uso. Un anuncio de asociación o una propuesta de código pueden indicar intención, pero no cuantifican cuántos usuarios han sido incorporados ni cuánto XRP está inmovilizado en reservas. Esto es especialmente importante cuando alguien convierte una propuesta técnica en una predicción del precio del token. El mecanismo de ingeniería puede explicarse ahora; el resultado económico requiere evidencia posterior.
Preguntas frecuentes
¿Se elimina la reserva de cuenta de XRP?
No. El concepto de cuenta patrocinada desplaza quién es responsable de la reserva. No elimina la necesidad de la red de respaldar el almacenamiento del registro.
¿Una cartera con cero XRP permite enviar transacciones gratis?
Solo si un servicio patrocina las tarifas correspondientes según su implementación. Un saldo visible cero no es una promesa de transacciones gratuitas ilimitadas.
¿SponsoredAccountCreate está activo en Mainnet?
La especificación citada era una propuesta abierta en la consulta del 9 de noviembre de 2026. Verifica el estado actual de la enmienda y de las carteras antes de afirmar que un flujo de trabajo concreto está disponible.
