Las reservas patrocinadas de Stellar permiten que una cuenta asuma el requisito de reserva de una entrada que pertenece a otra. Según el diseño documentado en CAP-0033, el patrocinador puede aportar ese respaldo sin ceder al beneficiario el control de los fondos que lo sostienen. Sustituir a un patrocinador existente es un proceso distinto: se dirige a una entrada concreta del registro o a un firmante, y puede fallar si quien debe asumir la reserva no tiene capacidad suficiente.
Por eso, la expresión «cuenta patrocinada» no basta para entender el mecanismo. Hay que distinguir quién es titular de la entrada, quién asume su requisito de reserva y qué cuenta figura como origen de cada operación. Esas funciones pueden recaer en cuentas diferentes. Durante un relevo de patrocinador, además, cambian de una forma que resulta fácil malinterpretar si se supone que todas las operaciones actúan directamente sobre el titular de la entrada.
Esta guía analiza la especificación de reservas patrocinadas escrita por Jonathan Jove, creada el 18 de mayo de 2020 y actualizada el 13 de agosto de 2020. Su estado «Final» y sus etiquetas de versión del protocolo describen el documento; no acreditan el estado de activación actual, los parámetros de reserva vigentes ni el comportamiento de los monederos. Los ejemplos siguientes explican el diseño registrado, no transacciones observadas.
Respaldar una reserva no equivale a entregar fondos para gastar
La motivación de CAP-0033 parte de un emisor dispuesto a asumir la reserva de las líneas de confianza, o trustlines, de su activo. En los ejemplos de activos de la propuesta, una línea de confianza es una entrada asociada a una cuenta. El emisor quiere respaldarla sin poner los fondos de reserva a libre disposición de su titular. La ventaja central consiste en separar la responsabilidad por la reserva del control de esos fondos, no en prometer que cada beneficiario recibirá tokens nativos.
El autor explica por qué una simple transferencia de activos nativos produce una situación distinta. En el escenario histórico que plantea, un atacante crea una cuenta y una línea de confianza, espera la financiación del emisor, elimina la línea y fusiona la cuenta para extraer los fondos. Se trata del supuesto que motiva la propuesta, no de la descripción de un ataque concreto. El patrocinio busca proporcionar el respaldo exigido sin reproducir esa exposición propia de la financiación directa.
También hay que separar el respaldo de reservas del pago por ejecutar una transacción. CAP-0033 contrasta expresamente su mecanismo de reservas con el mecanismo de comisiones de CAP-0015. Nuestra guía sobre monederos smart contract explica el patrocinio del gas en Ethereum: cambiar quién paga no elimina el coste de ejecución. La comparación sirve para distinguir ese coste del respaldo de reservas, pero no establece las reglas de comisiones de Stellar. El patrocinio de reservas, por sí solo, tampoco implica que se financien automáticamente las comisiones de las transacciones.
Los contadores de la cuenta y el patrocinador de cada entrada
La especificación registra el patrocinio en varios lugares. La extensión de la cuenta incluye numSponsored, descrito como el número de reservas patrocinadas para esa cuenta, y numSponsoring, el número de reservas que esta patrocina. Los comentarios les atribuyen efectos opuestos: el primero reduce el requisito de reserva de la cuenta y el segundo lo aumenta. Son registros de responsabilidad por reservas, no dos saldos adicionales de tokens disponibles para gastar.
Por separado, una extensión de las entradas del registro contiene sponsoringID. Este descriptor de patrocinio de cada entrada identifica la cuenta que la patrocina; si está vacío, la entrada no tiene patrocinador. Responde así a una pregunta más específica que los contadores de la cuenta: no solo si una cuenta participa en patrocinios, sino quién respalda la entrada concreta que se está examinando.
La consecuencia para el análisis es importante: el saldo que muestra una interfaz no permite identificar, por sí solo, a todos los responsables de las reservas. Tampoco un contador agregado revela quién patrocina una línea de confianza determinada. Para averiguarlo hace falta consultar el registro de esa entrada. Así se evita atribuir un único patrocinador a toda la cuenta: como demuestra el ejemplo de la propuesta, distintas entradas de un mismo titular pueden tener patrocinadores diferentes.
Nuestra comparación entre UTXO y el modelo de cuentas explica cómo Bitcoin y Ethereum registran el valor y por qué el saldo mostrado por una interfaz no cuenta toda la historia del estado subyacente. Su utilidad aquí se limita a fomentar una lectura cuidadosa de los registros contables. Esa guía no describe Stellar, y no corresponde trasladar a este diseño las reglas de Ethereum sobre nonces, gas o autorización de cuentas.
Cerrar la relación temporal no elimina el patrocinio registrado
CAP-0033 introduce una relación temporal denominada patrocinio de reservas futuras. BeginSponsoringFutureReservesOp la inicia y tiene como origen a la cuenta patrocinadora. EndSponsoringFutureReservesOp la termina y tiene como origen a la cuenta patrocinada. La diferencia entre ambas cuentas de origen forma parte del mecanismo: no son denominaciones intercambiables.
El modelo de acuerdo de la especificación exige incluir ambas operaciones en una misma transacción y afirma que esto garantiza el acuerdo de las dos cuentas. Es una propiedad del diseño documentado, no una receta completa para construir las firmas. Hay que atender también al origen de la transacción, los orígenes de las operaciones y la autorización aplicable; esta guía no reconstruye un algoritmo completo de autorización.
El término «terminar» puede inducir a error. Lo que termina es la relación de reservas futuras utilizada en torno a las operaciones pertinentes. No significa «eliminar todos los patrocinios registrados anteriormente para esta cuenta». La propuesta introduce por separado RevokeSponsorshipOp para modificar el patrocinio de entradas y firmantes existentes. Sus ejemplos cierran la relación temporal y, aun así, mantienen patrocinadas las entradas recién creadas.
Conviene, por tanto, formular dos preguntas distintas. ¿Qué relación de reservas futuras está vigente mientras se crea una entrada o se cambia su patrocinio? ¿Qué patrocinador queda registrado para esa entrada después? Cerrar la primera relación es compatible con que la segunda respuesta siga identificando a un patrocinador. Confundir ambos planos dificulta entender tanto los relevos como la salida de un patrocinador.
Respaldar a un firmante no demuestra control sobre su clave
El patrocinio de firmantes tiene su propio registro. Según CAP-0033, signerSponsoringIDs mantiene una correspondencia uno a uno con los firmantes de la cuenta: el patrocinador de cada firmante se guarda en la posición correspondiente. Un valor vacío indica que ese firmante no tiene patrocinador. Es una información más precisa que afirmar, de forma general, que una misma parte respalda económicamente a todos los firmantes de una cuenta.
La parte inicial que se conserva íntegra de la semántica de modificación de firmantes también comprueba que exista la cuenta y que el firmante indicado figure en su lista. Si falta la cuenta o el firmante no está en ella, se obtiene REVOKE_SPONSORSHIP_DOES_NOT_EXIST. Estas comprobaciones identifican el objeto al que se dirige la operación. No permiten completar por inferencia las comparaciones posteriores dañadas ni afirmar que el texto disponible contiene todas las condiciones de autorización.
La distinción respecto al control se desprende de lo que describen esos registros: un responsable de la reserva asociada al firmante, no una prueba de que se haya transferido el secreto de firma. Por sí solo, un registro de patrocinio no demuestra que el patrocinador pueda firmar como ese firmante, recuperar sus credenciales o tomar el control de la cuenta. Del mismo modo, conocer el respaldo económico no sustituye el análisis de la política de autorización real de la cuenta.
La guía sobre frase semilla y clave privada explica la diferencia entre un secreto de firma y el material de recuperación que puede abarcar varias claves. Aporta contexto sobre las credenciales, una cuestión distinta del pago de reservas. No establece que todos los monederos de Stellar utilicen un mnemónico, un método de derivación o un procedimiento de recuperación concreto: esos detalles dependen del monedero y de la configuración de la cuenta.
Dos entradas del mismo titular pueden tener patrocinadores distintos
Tomemos el ejemplo de la propuesta en el que la cuenta A crea las líneas de confianza X e Y, con S1 como respaldo de X y S2 como respaldo de Y. Son etiquetas de funciones dentro de un ejemplo cualitativo, no cuentas reales. Antes de la creación, llamar a S1 y S2 futuros patrocinadores no acredita que el resultado se haya completado. Son las operaciones y los registros resultantes los que dan contenido a esas etiquetas.
Para X, S1 inicia el patrocinio de reservas futuras de A. Después, A ejecuta la operación que crea la línea de confianza X y termina la relación. Para Y, S2 abre otra relación con A, A crea Y y luego la cierra. El ejemplo de las dos líneas de confianza reúne ambas secuencias en una sola transacción, pero mantiene separados sus respectivos contextos de patrocinio.
Si el proceso concluye correctamente tal como se ilustra, A sigue siendo titular de ambas líneas. El respaldo de sus reservas, en cambio, es diferente: X registra a S1 e Y registra a S2. Aportar ese respaldo no convierte a ninguno de los patrocinadores en titular. Tampoco el cierre de las dos relaciones de reservas futuras borra el patrocinio de las entradas que el ejemplo pretendía crear.
La pregunta útil no es simplemente quién patrocina a A. Hay que identificar al titular y al patrocinador registrado de X, y repetir la consulta para Y. Las respuestas coinciden en el titular, pero no en el patrocinador. Si una operación posterior solo se dirige a X, no incluye automáticamente a Y por pertenecer ambas a A. En el ejemplo de relevo que sigue, el objetivo lo determina la clave de la entrada, no únicamente el identificador de la cuenta titular.
En el relevo interviene el patrocinador anterior, no solo el titular
Supongamos ahora que un nuevo patrocinador, S3, va a asumir el respaldo de X que hasta entonces corresponde a S1. S3 es una nueva etiqueta para el patrocinador sustituto del ejemplo de transferencia de CAP-0033; el cambio de nombre evita confundirlo con S2, que ya respalda Y. K identificará la entrada de X en el registro. Esta explicación combina los ejemplos del documento; no describe una transferencia ejecutada.
La secuencia introduce un cambio de participante que merece atención. S3 inicia el patrocinio de reservas futuras para S1, el patrocinador existente, y no para A, el titular. A continuación, S1 figura como origen de RevokeSponsorshipOp, dirigida a K. Finalmente, S1 termina la relación abierta para él. En este contexto de transferencia, la cuenta patrocinada es el patrocinador anterior, aunque A sigue siendo titular de la línea de confianza afectada.
El patrón de transferencia documentado utiliza esa configuración para sustituir el patrocinio de la entrada seleccionada. Por ello, «revocar» no significa siempre dejar una entrada sin patrocinador: en el contexto de sustitución ilustrado, la operación forma parte de un relevo. El documento también indica que RevokeSponsorshipOp requiere el umbral medio de autorización, sin que esa indicación equivalga a un número universal de firmas.
Si la transferencia del ejemplo tiene éxito, el patrocinador de X pasa de S1 a S3. A conserva la titularidad, e Y queda fuera de esta operación específica. Ese cambio de funciones no acredita una retirada de activos, una transferencia de cuenta ni un cambio del secreto de firma. Su consecuencia es más limitada: K pasa a tener otro responsable de su reserva, sujeto a las condiciones aplicables y al resultado efectivo de la transacción.
Los errores de la relación temporal y los fallos del cambio son distintos
CAP-0033 define categorías de fallo diferentes según la etapa. Al iniciar una relación de reservas futuras, los comentarios identifican el autopatrocinio, una cuenta que ya está patrocinada y una relación recursiva que involucra a una cuenta que, a su vez, está patrocinando a otra. Estas categorías ayudan a situar el problema en el establecimiento de la relación temporal. No deben interpretarse como un reglamento completo para todas las configuraciones permanentes de patrocinio de entradas.
El cierre tiene su propio fallo: END_SPONSORING_FUTURE_RESERVES_NOT_SPONSORED, cuya descripción indica que la cuenta debe estar patrocinada para poder terminar la relación. En el nivel de la transacción, txBAD_SPONSORSHIP se describe como «patrocinio no terminado». Son cuestiones diferentes de si una entrada existente tiene un patrocinador válido o de si el sustituto puede asumir su requisito de reserva.
Para modificar un patrocinio existente, las definiciones de resultados de la operación distinguen entre una entrada inexistente, una cuenta de origen que no es su patrocinadora y una capacidad de reserva insuficiente por parte del nuevo responsable. En particular, REVOKE_SPONSORSHIP_LOW_RESERVE significa que quien debe asumir la reserva no puede respaldar la entrada. La voluntad de hacerse cargo, por tanto, no demuestra que el relevo se haya completado.
Esas mismas definiciones señalan una restricción específica: el patrocinio de un saldo reclamable debe transferirse a otra cuenta, en lugar de eliminarse sin más. Esto no constituye una guía general sobre los reclamantes ni sobre las condiciones de reclamación. Lo que establece es que el tipo de entrada puede limitar los cambios de patrocinio disponibles; el ejemplo de las líneas de confianza no debe generalizarse indiscriminadamente.
En el relevo hipotético de X, la distinción práctica es la que separa un cambio solicitado de uno realizado con éxito. Una categoría de fallo no acredita que S3 se haya convertido en patrocinador de X. Para verificarlo harían falta el resultado real y el estado registrado. Estas definiciones, por sí solas, tampoco justifican afirmaciones adicionales sobre el cobro de comisiones, la reversión de cambios o todos los motivos por los que podría fallar una transacción en producción.
La salida de un patrocinador exige dos comprobaciones separadas
La fusión de cuentas muestra por qué conviene distinguir las relaciones temporales de las obligaciones que permanecen registradas. CAP-0033 establece que una fusión falla con ACCOUNT_MERGE_IS_SPONSOR si la cuenta está patrocinando reservas futuras de otra cuenta en ese momento. Añade una segunda comprobación, con el mismo resultado, cuando numSponsoring no es cero. La primera se refiere a la relación activa; la segunda, a la responsabilidad por reservas ya registrada.
Apliquemos ambas comprobaciones a S1 después de crear X. Terminar el contexto de creación resuelve la relación temporal, pero no demuestra que el contador de patrocinios haya quedado a cero: en el ejemplo, S1 sigue respaldando X. Interpretar «terminar» como una liberación completa haría pasar por alto la segunda restricción para fusionar la cuenta. La semántica de fusión de cuentas conserva expresamente esa distinción contable.
Una transferencia posterior de X a S3, si tiene éxito, cambia la obligación asociada a X, pero no demuestra que S1 carezca de otras obligaciones. Del mismo modo, un relevo dirigido a X no resuelve el respaldo que S2 aporta a Y. Determinar si una cuenta puede fusionarse requiere algo más que reconocer una transferencia exitosa; además, cumplir estas comprobaciones de patrocinio no acredita que se satisfagan todas las demás condiciones de fusión.
Qué permite concluir la advertencia sobre la reserva base
La sección de seguridad de la propuesta identifica una contrapartida cualitativa: según el autor, el patrocinio reducirá ligeramente la eficacia de los cambios en la reserva base, porque las entradas patrocinadas no pueden hacer que una cuenta quede por debajo del requisito de reserva. Es la preocupación expresada por el autor sobre la interacción del diseño con esos cambios. No es una estimación medida del impacto en la red ni una garantía frente a cualquier fallo relacionado con los saldos.
De esa frase no se desprende un importe de reserva actual ni un escenario numérico de estrés. Tampoco corresponde reconstruir una fórmula exacta de saldo mínimo a partir de las expresiones incompletas del texto disponible. La discusión del esquema de saldos reclamables contiene, además, una indicación en la que sponsoringID aparece sustituyéndose a sí mismo; ese pasaje no permite establecer con seguridad una migración de campos. Estas limitaciones no anulan la utilidad de las distinciones intactas entre funciones, registros y resultados, pero impiden tratar el documento histórico como respuesta a todas las preguntas de implementación.
Para una entrada real, las pruebas decisivas son concretas: identificar a su titular, consultar el patrocinador registrado, distinguir de ambos la cuenta de origen de la operación y comprobar el resultado de cualquier cambio solicitado. En el ejemplo de X, un relevo completado exige pruebas de que S3 sustituyó a S1 para esa entrada. No basta con que se haya cerrado una relación de reservas futuras o con que el monedero siga mostrando el mismo saldo.
