¿Se puede seguir transfiriendo USDC después de que venza la atestación de CCTP?
Para las transferencias rápidas de CCTP V2 en las que los USDC ya se quemaron en la cadena de origen, pero aún no se han acuñado en la cadena de destino, la documentación de Circle contempla la posibilidad de solicitar una nueva atestación. Para localizar el problema, hay que verificar por separado el registro de la cadena de origen, la validez de la atestación y la ejecución en la cadena de destino; no basta con que la aplicación indique «correcto» o «tiempo agotado».
En esta revisión del 30 de octubre, solo consulté la guía técnica de Circle, la referencia de la API de nueva atestación y el código fuente del contrato EVM en la versión fijada a la que enlaza la documentación. La página web no indica una fecha de publicación clara, así que este artículo explica la documentación actual. No inicié ninguna transferencia, no solicité una nueva atestación ni confirmé la recuperación de fondos para ningún usuario.
Veamos un escenario hipotético: una transferencia rápida con destino a Arbitrum, cuyo registro de quema ya existe en la cadena de origen, pero en la que los USDC aún no han llegado a la cadena de destino. La investigación debe centrarse primero en ese mismo registro y conservar el hash de la transacción en la cadena de origen, el nonce del mensaje, el domain de destino y la dirección del destinatario. Si solo aparece un error en la interfaz, no se puede dar por confirmado que los tokens se hayan quemado. Tampoco se deben aplicar directamente los procedimientos de otros puentes o de versiones anteriores.
Supongamos que el problema se debe a que la atestación anterior ya venció. La guía técnica indica que se puede solicitar una nueva atestación y actualizar expirationBlock, siempre que la transacción de quema siga existiendo en la cadena de origen. El código fuente de TokenMessengerV2 enlazado en la documentación también valida que el bloque de vencimiento no sea cero; los mensajes vencidos deben volver a emitirse. Esto explica por qué no se puede seguir usando una atestación antigua, pero no significa que los USDC se devuelvan automáticamente. Para este ejemplo de Arbitrum, la guía indica que el vencimiento debe calcularse según el número de bloque de Ethereum L1; no se debe sustituir directamente por el número de bloque de L2 ni por la cuenta regresiva de la interfaz.
Supongamos ahora que la solicitud de nueva atestación devuelve un código 200. El proceso aún no ha terminado. La referencia de la API define esta respuesta como el inicio del proceso; después todavía hay que obtener la nueva atestación y verificar la ejecución en la cadena de destino y el registro de recepción real. Que se acepte una solicitud, que se emita una nueva atestación y que lleguen los USDC son tres pruebas distintas. Consultar el código fuente tampoco sustituye la verificación de la versión del contrato desplegada realmente en una cadena concreta.
Datos recopilados en esta revisión a las 18:16: USDCUSDT cotizaba aproximadamente a 1.00122, y el volumen negociado al contado de la hora completa entre las 17:00 y las 18:00 fue de unos 28,17 millones de USDT. Esto solo ofrece contexto sobre el mercado de los activos transferidos en los exchanges; no demuestra el uso de CCTP, la velocidad de procesamiento ni la recepción de fondos.
Mi conclusión es que el vencimiento de una atestación es un estado de procesamiento que requiere investigación; no se debe afirmar directamente que los fondos se hayan perdido para siempre. La transferencia también puede estar pendiente de la confirmación en la cadena de origen, del procesamiento de la atestación o de la ejecución en la cadena de destino; hay que verificar la causa concreta en cada transacción. Si más adelante cambian la red, los contratos o las reglas del servicio, habrá que volver a comprobar la versión correspondiente. Este artículo explica cómo evaluar el estado; no es una guía para recuperar fondos. $USDC
Para las transferencias rápidas de CCTP V2 en las que los USDC ya se quemaron en la cadena de origen, pero aún no se han acuñado en la cadena de destino, la documentación de Circle contempla la posibilidad de solicitar una nueva atestación. Para localizar el problema, hay que verificar por separado el registro de la cadena de origen, la validez de la atestación y la ejecución en la cadena de destino; no basta con que la aplicación indique «correcto» o «tiempo agotado».
En esta revisión del 30 de octubre, solo consulté la guía técnica de Circle, la referencia de la API de nueva atestación y el código fuente del contrato EVM en la versión fijada a la que enlaza la documentación. La página web no indica una fecha de publicación clara, así que este artículo explica la documentación actual. No inicié ninguna transferencia, no solicité una nueva atestación ni confirmé la recuperación de fondos para ningún usuario.
Veamos un escenario hipotético: una transferencia rápida con destino a Arbitrum, cuyo registro de quema ya existe en la cadena de origen, pero en la que los USDC aún no han llegado a la cadena de destino. La investigación debe centrarse primero en ese mismo registro y conservar el hash de la transacción en la cadena de origen, el nonce del mensaje, el domain de destino y la dirección del destinatario. Si solo aparece un error en la interfaz, no se puede dar por confirmado que los tokens se hayan quemado. Tampoco se deben aplicar directamente los procedimientos de otros puentes o de versiones anteriores.
Supongamos que el problema se debe a que la atestación anterior ya venció. La guía técnica indica que se puede solicitar una nueva atestación y actualizar expirationBlock, siempre que la transacción de quema siga existiendo en la cadena de origen. El código fuente de TokenMessengerV2 enlazado en la documentación también valida que el bloque de vencimiento no sea cero; los mensajes vencidos deben volver a emitirse. Esto explica por qué no se puede seguir usando una atestación antigua, pero no significa que los USDC se devuelvan automáticamente. Para este ejemplo de Arbitrum, la guía indica que el vencimiento debe calcularse según el número de bloque de Ethereum L1; no se debe sustituir directamente por el número de bloque de L2 ni por la cuenta regresiva de la interfaz.
Supongamos ahora que la solicitud de nueva atestación devuelve un código 200. El proceso aún no ha terminado. La referencia de la API define esta respuesta como el inicio del proceso; después todavía hay que obtener la nueva atestación y verificar la ejecución en la cadena de destino y el registro de recepción real. Que se acepte una solicitud, que se emita una nueva atestación y que lleguen los USDC son tres pruebas distintas. Consultar el código fuente tampoco sustituye la verificación de la versión del contrato desplegada realmente en una cadena concreta.
Datos recopilados en esta revisión a las 18:16: USDCUSDT cotizaba aproximadamente a 1.00122, y el volumen negociado al contado de la hora completa entre las 17:00 y las 18:00 fue de unos 28,17 millones de USDT. Esto solo ofrece contexto sobre el mercado de los activos transferidos en los exchanges; no demuestra el uso de CCTP, la velocidad de procesamiento ni la recepción de fondos.
Mi conclusión es que el vencimiento de una atestación es un estado de procesamiento que requiere investigación; no se debe afirmar directamente que los fondos se hayan perdido para siempre. La transferencia también puede estar pendiente de la confirmación en la cadena de origen, del procesamiento de la atestación o de la ejecución en la cadena de destino; hay que verificar la causa concreta en cada transacción. Si más adelante cambian la red, los contratos o las reglas del servicio, habrá que volver a comprobar la versión correspondiente. Este artículo explica cómo evaluar el estado; no es una guía para recuperar fondos. $USDC