Depósitos USDC 2026: verificar cadenas y recompensas

El depósito de USDC se confirma mediante una transferencia del token oficial en la cadena acordada. La dirección de recepción y la cantidad deben coincidir. Compruebe también, por separado, que la transacción se haya ejecutado correctamente y que el bloque haya alcanzado la finalidad. Ni la recompensa indicada en el anuncio ni el hash bastan para dar por pagada la recompensa.

Vuelva a comprobar las direcciones y los ID de cadena en la documentación oficial de Circle, Ethereum y Base. (Valores comprobados: Ethereum Mainnet: ID de cadena 1, contrato USDC 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48. Base Mainnet: ID de cadena 8453 0x2105 , contrato USDC · Fuente: developers.circle.com · Comprobado el 2026-10-23)

Direcciones de los contratos USDC e ID de cada cadena

USDC usa direcciones de contrato distintas en Ethereum y Base. El ID de cadena es el número que distingue una red de otra. La dirección del contrato del token identifica el token en esa cadena. La dirección de recepción es la dirección de la billetera o cuenta que recibirá el pago.

La fecha de redacción y revisión de la documentación es el 23 de octubre de 2026. La siguiente tabla corresponde al USDC emitido por Circle en las redes principales. Una red principal es una red que usa activos con valor real.

La fuente de las direcciones de contrato es USDC contract addresses de Circle. El ID de cadena de Ethereum se especifica en EIP-155. El ID de cadena de Base puede consultarse en la documentación de eth_chainId de Base.

Aunque la dirección de recepción tenga la misma secuencia de caracteres, los registros son independientes si las cadenas son distintas. Un depósito en Ethereum no se suma automáticamente al saldo de Base. No contabilice como pago real el USDC de redes de prueba como Sepolia.

Orden para comprobar la dirección de recepción y la transacción

Fijar primero las condiciones de pago reduce el riesgo de confundir otra transacción con el pago. Este procedimiento consiste en leer registros públicos de transacciones. No hace falta conectar una billetera ni firmar para consultar el explorador.

1. Compruebe la red y el token en el acuerdo de pago. Distinga el importe en dólares del anuncio de la cantidad de USDC que se pagará realmente.
2. Copie la dirección de recepción de esa red desde la billetera que recibirá el pago. Si usa una plataforma de intercambio, tome como referencia la pantalla de depósitos de ese servicio. Compruebe también las redes que admite el servicio.
3. Busque la dirección del contrato de esa cadena en la tabla Mainnet de Circle. No se guíe solo por el nombre o el logotipo del token.
4. Busque el txHash en el explorador de esa cadena. El txHash es el identificador que permite localizar la transacción. Si no aparecen resultados, vuelva a contrastar la red y el hash.
5. Revise el estado y los registros de transferencias de tokens en los detalles de la transacción. Después, contraste el evento Transfer real en la pestaña Logs.

Un hash que no aparece en la consulta aún no demuestra un depósito. Sin embargo, que la consulta falle tampoco basta para concluir que la otra parte está cometiendo un fraude. Compruebe primero si se ha elegido una cadena incorrecta o si ha habido un error al copiar el hash.

Qué comprobar en el evento Transfer

La recepción se determina mediante el evento Transfer emitido por el contrato USDC. El campo To de la parte superior de la transacción puede corresponder al contrato al que se llamó. Compruebe la dirección que recibió los tokens en el campo to del evento.

El estándar ERC-20 define el evento de transferencia de la siguiente manera.

DEBE activarse cuando se transfieren tokens, incluidas las transferencias de valor cero.

Fuente: ERC-20: Token Standard, apartado Transfer

Esta regla también incluye las transferencias cuya cantidad es 0. Por tanto, la mera existencia de un evento no basta para reconocer un pago efectivo. Puede consultar el texto original en ERC-20: Token Standard.

En ocasiones, los tokens se envían desde un contrato que gestiona los pagos. Por eso, la dirección del remitente de la transacción no siempre coincide con la del empleador. Contraste también el número de trabajo y el detalle del pago. La dirección por sí sola no permite determinar la identidad del pagador real.

Cómo leer los logs sin procesar

En los logs sin procesar, las direcciones y las cantidades están codificadas. topics[0] es el hash de la firma del evento. La dirección de origen de una transferencia USDC Transfer estándar está en topics[1]. La dirección de recepción está en topics[2].

• Dirección: interprete los últimos 20 bytes del topic correspondiente como una dirección.
• Cantidad: interprete data como un entero sin signo.
• Decimales: convierta la cantidad usando el valor de decimals() del contrato oficial.
• Evento de autorización: Approval es un registro de autorización de uso.

El USDC de Ethereum y Base indicado aquí usa 6 decimales. Divida la cantidad sin procesar entre 1,000,000 para leerla en unidades de USDC. No aplique los decimales de ETH sin cambiarlos. Puede consultar la estructura de la pantalla de logs en Event Logs de Etherscan.

Diferencia entre ejecución correcta y finalidad

Success significa que la transacción se ejecutó correctamente. No significa que el bloque haya quedado confirmado de forma definitiva. La finalidad es el estado en el que un bloque queda confirmado según las reglas de consenso. En este artículo, un depósito confirmado definitivamente es un registro cuya finalidad también se ha comprobado.

Las transferencias internas de Base y los retiros a Ethereum siguen procedimientos distintos. No aplique directamente el periodo de espera de los retiros a los depósitos internos de Base. Base distingue entre la inclusión en un bloque y la finalidad del lote en L1. La fuente es Transaction Finality de Base.

Cuando el explorador no muestra claramente la finalidad

Si no hay un indicador de finalidad, puede dejar la verificación pendiente. Los desarrolladores pueden volver a comprobarla mediante un RPC fiable de esa cadena. RPC es una interfaz para solicitar datos a un nodo de la cadena de bloques.

1. Compruebe con eth_chainId a qué cadena se ha conectado.
2. Lea el recibo con eth_getTransactionReceipt. Revise status, los logs, el número de bloque y el hash del bloque.
3. Consulte el mismo número de bloque con eth_getBlockByNumber. Contraste si el hash devuelto coincide con el blockHash del recibo.
4. Pase finalized y false a eth_getBlockByNumber. Compruebe que la altura del bloque devuelto sea igual o superior a la del bloque de la transacción. Para las transacciones de Base, compare tomando como referencia el bloque finalized del RPC de Base.

Si el recibo es null, esa respuesta no permite confirmar la inclusión. Tampoco use una respuesta que no admita consultas finalized para dar la comprobación por válida. No interprete latest ni un simple número de confirmaciones como si fueran finalized. Los métodos se explican en Ethereum JSON-RPC y en la documentación de consulta de bloques de Base.

Ejemplo de cálculo: depósito simulado de 100 USDC

El siguiente es un ejemplo simulado de verificación, no un caso de pago real. Se supone que la condición de pago es de 100 USDC en Base. Las direcciones y los números de log son valores creados para la explicación. No use las direcciones del ejemplo como direcciones reales de recepción.

En estas condiciones, la cantidad recibida es de 100 USDC. Se supone que también se ha comprobado la coincidencia del hash del bloque de H. Sigue siendo necesaria una prueba independiente que vincule el depósito con el pago del trabajo por parte de un pagador externo.

Si la dirección de recepción es otra, no se reconoce como un depósito propio. Si el anuncio solo indicaba 100 dólares, también debe comprobarse por separado la cantidad que se pagará. Recibir 100 USDC no equivale a recibir 100 dólares en efectivo.

Comparación de las pruebas de depósito según el estado de la recompensa

Registre por separado el estado de la recompensa y el del depósito en la billetera. Una recompensa es una compensación asociada a un trabajo definido. La siguiente clasificación sirve para gestionar las pruebas de pago. No sustituye la determinación de un derecho de cobro legal ni de ingresos a efectos fiscales.

La custodia consiste en mantener los fondos separados hasta que se cumplan ciertas condiciones. Que los fondos estén en custodia no significa que se hayan pagado a su billetera. La aprobación de una plataforma y Approval de ERC-20 también son conceptos distintos.

Vincule también los depósitos definitivos con un número de trabajo o una factura. El registro de la transacción por sí solo no permite conocer el motivo del pago. Contraste además la fecha de pago para no confundirlo con otros depósitos de la misma cantidad.

Errores habituales al contabilizar depósitos como pagos de trabajos nuevos

No sume todo el USDC que entra en la billetera como si fueran pagos de trabajos nuevos. La recepción y su finalidad económica son datos distintos. La siguiente lista sirve como criterio para organizar el registro operativo de depósitos.

• Reembolsos: vincule los importes devueltos de gastos anteriores con el gasto original.
• Transferencias propias: distinga los movimientos entre billeteras que usted controla.
• Movimientos mediante puentes: separe los movimientos de sus activos entre cadenas de los nuevos pagos de clientes.
• Tokens de spam: compruebe la dirección del contrato oficial en lugar de guiarse por el nombre USDC.
• Tokens de representación mediante puentes: si el contrato es distinto, regístrelos como activos separados del USDC emitido por Circle.
• Eventos de cantidad 0: aunque haya un Transfer, no los sume como pagos efectivos.
• Consultas duplicadas: no sume el mismo evento una vez desde el explorador y otra desde la API.
• Pruebas reutilizadas: no vuelva a asignar un depósito ya vinculado a otro trabajo.
• Circulación de fondos propios: compruebe conjuntamente la salida y el reingreso de la misma transacción.
• Devoluciones posteriores: si devolvió un pago recibido, vincúlelo con el registro de recepción original.

Datos que registrar para evitar duplicados

Los eventos pueden distinguirse mediante chainId + txHash + logIndex. Una misma transacción puede contener varios eventos de transferencia. Por eso, agrupar todos los eventos en uno solo basándose únicamente en el txHash puede causar omisiones.

Si se produce una reorganización de bloques antes de la finalidad, vuelva a verificar los registros. Los logs eliminados deben excluirse del cómputo provisional anterior. Gestione por separado la suma de los pagos de trabajos y el saldo de la billetera. El saldo también refleja los fondos que ya se tenían y los retiros posteriores.

Lista de verificación de 5 minutos

Esta tabla resume los puntos que pueden comprobarse en unos 5 minutos. No garantiza el tiempo necesario para alcanzar la finalidad de la cadena de bloques. Deje pendientes los puntos que no pueda comprobar.

Puede que en la primera comprobación falten pruebas del pago. En ese caso, solicite el nombre de la cadena o el txHash que falte. Si los tokens se enviaron a otra dirección, comunique de forma concreta los datos que no coinciden.

Preguntas frecuentes

¿Basta con recibir el txHash para que el depósito esté completado?

El hash por sí solo no permite confirmar que el depósito esté completado. Incluso una transacción ejecutada correctamente puede tener otra dirección de recepción. Compruebe el contrato, la dirección de recepción, la cantidad y la finalidad.

¿Qué hago si aparece Success, pero no veo el saldo en la billetera?

Primero contraste la dirección de recepción del evento y el contrato oficial. Si coinciden, compruebe la red seleccionada y la visualización del token. También debe comprobarse por separado si el servicio receptor ha reflejado el depósito internamente.

¿Puedo buscar un depósito de Base en Ethereum?

Consulte las transacciones de Base en un explorador de Base. Aunque se use la misma dirección, los registros de cada cadena son independientes. No concluya que falta un depósito en Base basándose solo en los resultados de búsqueda de Ethereum.

Si aparece 0 ETH en la parte superior de la transacción, ¿significa que no hubo depósito?

La indicación de 0 ETH no demuestra que no se haya transferido USDC. La cantidad de ETH de la transacción y la cantidad de tokens ERC-20 son datos distintos. Compruebe la cantidad de USDC del evento Transfer.

¿Un depósito externo confirmado definitivamente es un ingreso nuevo?

Un depósito externo por sí solo no permite determinar que haya un nuevo ingreso por un trabajo. Puede ser un reembolso o una transferencia con otro motivo. Vincule el depósito con su motivo mediante la factura y el detalle del pago.

¿Puedo calcular los impuestos a partir del resultado de la comprobación del depósito?

Este procedimiento sirve para comprobar las pruebas de recepción en la cadena. No determina la situación tributaria de una persona. Para consultar la orientación fiscal de Corea, véase el Resumen del impuesto sobre la renta global del Servicio Nacional de Impuestos.