Un saldo reclamable de Stellar, tal como lo describe CAP-0023, separa tres hechos que quien utiliza un monedero podría confundir: crear una entrada en el registro, cumplir las condiciones para reclamarla y recibir efectivamente su activo. Demostrar el primero no demuestra los otros dos. Incluso una cuenta que reúne los requisitos para reclamar puede encontrarse con una comprobación de recepción que impida completar la operación.
Esta guía explica el documento CAP-0023 revisado; no verifica su despliegue actual. Su preámbulo identifica a Jonathan Jove como autor, marca la propuesta como Final y recoge el 4 de junio de 2019 como fecha de creación, el 5 de febrero de 2020 como fecha de actualización y la versión 14 del protocolo. Son datos del documento, no una fecha de activación ni una prueba de su implementación presente. El texto también remite a una actualización posterior de XDR que queda fuera de las fuentes examinadas aquí.
Qué demuestra realmente el registro de un pago
La idea central del resumen de pagos de CAP-0023 es que las operaciones propuestas separan el envío de un pago de su recepción. El objetivo es permitir que una cuenta inicie un pago aunque el destino todavía no esté preparado para recibir el activo. Esa separación resulta útil, pero obliga a precisar qué pruebas acreditan que el proceso ha concluido.
Un registro de creación permite comprobar si la operación estableció una entrada reclamable conforme a las reglas descritas. El registro de un reclamante identifica una cuenta que podría reclamar esa entrada. Una reclamación completada con éxito acredita la transición posterior que abona el activo especificado y consume la entrada. Llamar «pago recibido» a cualquiera de estos tres hechos borraría precisamente la distinción que introduce la propuesta.
Al investigar un pago que no aparece, la primera pregunta debe ser más concreta: ¿de cuál de esos hechos hay pruebas? La intención de pago que declara un remitente no equivale a un registro de la entrada. Y ese registro no equivale a un abono en la cuenta receptora. Se trata de un marco de diagnóstico, no del diagnóstico de una cuenta real: para esta guía no se aportaron transacciones ni historiales de cuentas.
Identificar la entrada y distinguir las funciones de cada cuenta
CAP-0023 describe cada ClaimableBalanceEntry como una entidad independiente dentro del registro. Una ficha útil para una investigación de solo lectura debe comenzar por su balanceID, el activo especificado, el importe y los reclamantes. Conviene copiar el identificador del registro pertinente, en lugar de intentar reconstruirlo a partir de un extracto incompleto del esquema técnico.
A continuación hay que distinguir tres funciones. La cuenta de origen de la operación de creación se utiliza para las comprobaciones de financiación y los demás requisitos de esa operación. La cuenta de origen de la transacción se guarda en createdBy: el documento aclara expresamente que se trata del origen de la transacción, no de la operación. Por su parte, la cuenta de origen de la posterior operación de reclamación es la que se compara con el destino de un reclamante y, si la operación tiene éxito, recibe el activo. Agrupar estas funciones en un campo ambiguo llamado «creador» dificulta el análisis.
La guía sobre UTXO y modelo de cuentas explica cómo la representación del valor en una cadena se distingue del saldo que muestra un monedero. Esa distinción general ayuda a entender por qué una entrada y un total mostrado responden a preguntas diferentes; no convierte un saldo reclamable de Stellar en un UTXO de Bitcoin ni incorpora las reglas de cuentas de Ethereum. Aquí importa un hecho más limitado: CAP-0023 describe un objeto separado cuya existencia no acredita por sí misma un abono al destinatario previsto.
Distinguir las cuentas es especialmente importante al determinar adónde se devuelve la reserva. Un informe que solo identifique quién financió la operación de creación puede omitir la cuenta de origen de la transacción guardada en createdBy. Según las reglas revisadas, esa cuenta tiene una función específica en la posterior devolución de la reserva, aunque otra cuenta haya actuado como origen de la operación de creación.
Financiar la creación no equivale a estar preparado para recibir
Las reglas de creación de CAP-0023 distinguen los requisitos de reserva en el activo nativo de la financiación del activo especificado. Entre los fallos enumerados figuran una reserva insuficiente, problemas con la línea de confianza y la autorización, y fondos insuficientes. Por tanto, poder aportar el importe del activo no demuestra que también se cumpla el requisito independiente de reserva.
Una línea de confianza, o trustline, es la relación específica entre una cuenta y un activo a la que remiten las comprobaciones de tenencia y autorización del documento. En la explicación de la creación, la cuenta de origen de la operación debe disponer de una línea de confianza para el activo y esta debe tener AUTHORIZED_FLAG. La misma sección comprueba por separado que haya fondos disponibles del activo. Son tres preguntas distintas: si existe la relación exigida, si está autorizada y si hay valor disponible suficiente.
El documento presenta una limitación importante. La explicación de la creación no establece una excepción para el activo nativo en sus comprobaciones de líneas de confianza. En cambio, la explicación posterior de la reclamación limita expresamente esas comprobaciones y las de autorización a los activos no nativos. Esta guía conserva esa asimetría, sin corregirla de forma implícita ni presentar el texto como un algoritmo completo de creación para el activo nativo. Para conocer los valores actuales de reserva y las reglas de implementaciones posteriores hacen falta otras fuentes.
La creación también contempla errores de formato en los datos de entrada. Los ejemplos enumerados incluyen un activo no válido, un importe menor o igual que cero, una lista vacía de reclamantes, destinos de reclamantes duplicados y determinados defectos en los predicados. Estos fallos de validación no son lo mismo que la falta de fondos. Además, aunque el documento enumera pasos de débito y posibles fallos, su orden no demuestra que los débitos anteriores se mantengan de manera independiente si falla un paso posterior. El comportamiento general de reversión de transacciones queda fuera de la documentación revisada.
El derecho a reclamar corresponde a una cuenta
La justificación del diseño de los reclamantes describe una lista finita e inmutable de cuentas que podrían reclamar una entrada. Ese carácter potencial es importante: figurar en la lista satisface una parte de la comprobación, pero no concede un derecho incondicional a recibir el activo en cualquier momento o en cualquier destino.
El diseño vincula deliberadamente la reclamación a una cuenta, en lugar de permitir que una clave incluida en la lista redirija libremente el activo a otra cuenta. CAP-0023 explica que permitir reclamaciones hacia cuentas arbitrarias debilitaría las restricciones de autorización de activos. Su justificación también reconoce un riesgo condicionado: que las condiciones puedan satisfacerse no garantiza que la entrada siga siendo reclamable en la práctica y, por tanto, podría quedar bloqueada.
La guía sobre frase semilla y clave privada distingue la capacidad de autorizar operaciones del alcance de una copia de recuperación. Esa diferencia general resulta útil aquí: restaurar una copia de seguridad puede devolver la capacidad de autorizar acciones, pero no modifica los destinos de los reclamantes de esta propuesta ni elimina las comprobaciones de autorización del activo. El enlace aporta contexto sobre credenciales y recuperación; no es un procedimiento de recuperación de cuentas de Stellar.
En una investigación de solo lectura, hay que registrar la cuenta de origen de la operación de reclamación propuesta y compararla con el destino del reclamante incluido en la lista. La afirmación «el usuario controla una clave» no sustituye esa comparación entre cuentas. Los registros públicos pueden examinarse sin revelar claves privadas ni frases de recuperación, y este marco no requiere firmar una demostración ni compartir secretos.
Los predicados establecen condiciones, no prueban un pago
Un predicado es una condición asociada a la posibilidad de que un reclamante reclame la entrada. El esquema revisado enumera las categorías incondicional, AND, OR, NOT, anterior a un tiempo absoluto y anterior a un tiempo relativo. Conceptualmente, permiten expresar un permiso incondicional, combinar condiciones, negarlas y establecer restricciones temporales. Que un predicado se cumpla responde a una pregunta sobre el permiso para reclamar; no demuestra que una operación de reclamación haya tenido éxito.
La regla de conversión del tiempo relativo de CAP-0023 vincula las condiciones temporales relativas a datos del registro. Durante la creación, el valor relativo se suma a closeTime en LedgerHeader y se convierte en un predicado de tiempo absoluto. Si esa suma supera INT64_MAX, el documento indica que se utilice INT64_MAX.
La consecuencia para el diagnóstico es clara: una condición relativa no inicia una cuenta atrás cuando alguien abre el monedero o descubre el pago. Su referencia documentada es la hora de cierre del registro utilizada durante la creación. Para investigarla hacen falta la condición almacenada correspondiente y el contexto del registro, no una estimación basada en cuándo se vio por primera vez una notificación.
La extracción técnica suministrada contiene comparaciones XDR incompletas. Por ello, esta guía no reconstruye operadores ausentes ni afirma qué ocurre cuando el tiempo coincide exactamente con el límite. Tampoco inventa una marca temporal para ilustrarlo. Si una decisión depende de ese punto exacto, debe quedar pendiente hasta disponer de documentación íntegra, pertinente y de la versión correspondiente. Afirmar una precisión que las pruebas no respaldan restaría fiabilidad al diagnóstico.
Las comprobaciones previas a la devolución de la reserva
Las reglas de la operación de reclamación comprueban primero si existe una entrada que coincida con balanceID. Si no existe, el resultado enumerado es CLAIM_CLAIMABLE_BALANCE_DOES_NOT_EXIST. La comprobación siguiente compara la cuenta de origen de la operación con un destino de reclamante y exige que se cumpla el predicado de ese reclamante. Si falla, el resultado es CLAIM_CLAIMABLE_BALANCE_CANNOT_CLAIM.
Solo después de esas comprobaciones, la secuencia documentada aborda el destino de la reserva. Primero considera createdBy. Si esa cuenta existe y tiene capacidad disponible suficiente en el activo nativo para recibir la reserva, la ruta descrita le abona ese valor. Si la cuenta no existe o carece de esa capacidad, la secuencia comprueba la cuenta de origen de la operación de reclamación como destinataria alternativa de la reserva nativa.
Esta alternativa puede fallar con CLAIM_CLAIMABLE_BALANCE_LINE_FULL si la cuenta de origen de la reclamación no dispone de capacidad suficiente en el activo nativo. Se trata de un fallo de capacidad para recibir la reserva, no necesariamente de un problema en la línea de confianza del activo especificado. Más adelante, la secuencia utiliza el mismo código cuando falta capacidad para recibir el activo reclamado. Por tanto, el código aislado no permite identificar en qué comprobación se produjo el fallo.
La cuenta guardada en createdBy importa, por tanto, aunque no sea el reclamante que recibe el activo. A la inversa, recibir una reserva por la ruta descrita no equivale a recuperar el activo reclamable: son valores separados, con reglas de destino distintas. Tampoco debe interpretarse la secuencia como prueba de que un abono intermedio de reserva permanece tras un fallo posterior. El cuerpo del documento revisado no establece ese comportamiento general de ejecución.
Una matriz cualitativa de control y estado
Consideremos un supuesto conceptual, no un pago real. Se da por hecho que se creó correctamente una entrada de un activo no nativo, que remitente y destinatario son cuentas distintas y que la entrada sigue existiendo en todas las observaciones anteriores a la reclamación. Para simplificar, el remitente es tanto el origen de la operación de creación como el de la transacción. Ambas cuentas figuran expresamente como reclamantes: el destinatario tiene un predicado anterior a un tiempo y el remitente tiene su negación. No se presupone ninguna regla sobre el instante exacto del límite temporal.
| Estado observado | Qué demuestra | Qué sigue sin demostrarse |
|---|---|---|
| Se cumple el predicado del destinatario, pero falta la línea de confianza exigida. | El destinatario supera la comprobación de cuenta y predicado asumida en el ejemplo. | Una reclamación completada y la recepción del activo: la comprobación de recepción todavía impide el éxito. |
| Más adelante se cumple el predicado del remitente y la entrada sigue existiendo. | El remitente, incluido expresamente en la lista, puede intentar reclamar. | Que supere las comprobaciones de destino de la reserva y los requisitos de recepción aplicables. |
La cuenta de createdBy no está disponible o carece de capacidad para recibir la reserva nativa. |
La alternativa documentada comprueba la cuenta de origen de la reclamación. | Que esta disponga de capacidad nativa suficiente; aún puede producirse LINE_FULL. |
| Una reclamación tiene éxito. | La cuenta de origen de la reclamación recibe el activo y la entrada se elimina. | Cualquier pago separado de esa entrada o cualquier abono en una cuenta no relacionada. |
Desplaza la tabla horizontalmente para ver todas las columnas.
El punto analítico es que el permiso puede cambiar sin que quede acreditada la recepción. El destinatario puede cumplir su condición y, aun así, carecer de la línea de confianza necesaria. El remitente puede cumplir posteriormente su propia condición y seguir sin superar una comprobación de recepción. Ninguna de esas observaciones equivale a una transferencia automática.
En este ejemplo, la posibilidad de que el remitente reclame nace de su inclusión expresa como reclamante y del cumplimiento de su predicado. No deriva de haber financiado la creación ni de figurar en createdBy. Sin ese derecho incluido en la lista, no habría base para inferir la misma posibilidad de recuperación. La tabla ayuda a razonar; no es una instrucción para construir, firmar o transmitir una operación de este tipo.
Recibir el activo, devolver la reserva y consumir la entrada
Después de determinar el destino de la reserva, CAP-0023 aplica expresamente las comprobaciones de línea de confianza y autorización de recepción cuando el activo especificado no es nativo. La ausencia de línea de confianza produce CLAIM_CLAIMABLE_BALANCE_NO_TRUST; una línea sin la marca de autorización exigida produce CLAIM_CLAIMABLE_BALANCE_NOT_AUTHORIZED. Aquí las excepciones para el activo nativo sí son explícitas, a diferencia de la redacción sobre la creación examinada antes.
La comprobación siguiente pregunta si la cuenta de origen de la reclamación tiene capacidad disponible suficiente para el importe del activo. Si no la tiene, el resultado es CLAIM_CLAIMABLE_BALANCE_LINE_FULL. Esta comprobación corresponde al activo reclamado y es distinta de la alternativa para recibir la reserva nativa. Un informe útil identifica qué valor y qué cuenta receptora se están examinando, en lugar de interpretar cualquier resultado LINE_FULL como «la línea de confianza del activo está llena».
La secuencia de una reclamación completada con éxito abona después el importe del activo especificado a la cuenta de origen de la reclamación, elimina la entrada e informa del éxito. En el supuesto anterior, consumir la entrada impide que el otro reclamante obtenga posteriormente un importe reclamable duplicado de esa misma entrada. Cumplir las condiciones no la consume; la consume la reclamación exitosa descrita en el documento.
La guía sobre USDC y USDC.e: identificación del activo y requisitos del receptor ofrece un paralelismo limitado: identificar el activo no demuestra que el destinatario pueda aceptarlo. Del mismo modo, conocer el activo que nombra una entrada reclamable no acredita que su destino pueda recibirlo y utilizarlo. La comparación no convierte CAP-0023 en una guía de puentes ni de rutas entre cadenas: sus condiciones pertinentes son las comprobaciones de cuenta, predicado, reserva y activo descritas en el documento.
El mecanismo revisado tampoco describe un reembolso automático al vencer un plazo. Un cambio en un predicado temporal puede permitir reclamar a una cuenta incluida en la lista, pero el documento establece que la entrada solo puede eliminarse mediante la operación de reclamación. Devolver la reserva nativa a createdBy tampoco equivale a devolver automáticamente el activo reclamable. Para concluir que el remitente lo recuperó hacen falta pruebas de su derecho a reclamar y de una reclamación exitosa.
Cerrar la investigación con un registro de alcance preciso
Una ficha completa de solo lectura debe identificar la entrada y el activo especificado, distinguir el origen de la operación de creación del origen de la transacción almacenado en createdBy y señalar la cuenta propuesta como origen de la reclamación. Después debe separar la coincidencia con un reclamante, la evaluación del predicado, el destino de la reserva, la autorización de la línea de confianza para activos no nativos y la capacidad para recibir el activo. En cada campo hay que distinguir las pruebas públicas observadas de las suposiciones y las preguntas pendientes.
Si una comprobación devuelve DOES_NOT_EXIST, debe anotarse únicamente lo que ese resultado demuestra: no se encontró una entrada coincidente conforme a la regla descrita. Por sí solo no prueba que hubiera una creación anterior, no identifica a un reclamante que haya tenido éxito ni acredita un reembolso. Para reconstruir el historial hacen falta registros adicionales de creación o reclamación. Del mismo modo, el memo de una transacción no debe sustituir la identidad de la entrada: CAP-0023 trata expresamente el memo como una propiedad de la transacción, no de una operación ni de una entrada del registro.
El resultado útil es una pregunta pendiente y concreta, por ejemplo, si una cuenta de origen identificada superó la comprobación de recepción en un intento documentado. Mientras un registro de reclamación exitosa no acredite la recepción, «entrada creada», «reclamante que cumple las condiciones» y «activo recibido» deben seguir siendo tres conclusiones separadas.
