Depósitos USDC 2026: verificar cadenas y recompensas
Los depósitos de USDC se verifican con registros de transferencias que coincidan en la cadena, el contrato oficial, la dirección de destino y la cantidad. Tras comprobar que la transacción se completó correctamente y es definitiva, distingue los depósitos de las promesas de pago de recompensas, los reembolsos y las transferencias a ti mismo.
Comprueba la cadena acordada para recibir el pago y la dirección del contrato oficial de USDC.
Confirma la dirección de destino en la cadena seleccionada desde tu cartera o servicio receptor.
Contrasta el éxito de la transacción con el evento Transfer en el explorador de esa cadena.
Comprueba que el bloque que incluye la transacción sea definitivo.
Vincula el depósito con el pago del trabajo y clasifica por separado los reembolsos, las transferencias a ti mismo y los registros duplicados.
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.
Red | ID de cadena, decimal | ID de cadena, hexadecimal | Dirección del contrato oficial de USDC | Explorador
Ethereum Mainnet | 1 | 0x1 | 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48 | Etherscan
Base Mainnet | 8453 | 0x2105 | 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913 | BaseScan
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.
· 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.
· 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.
· 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.
· 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.
· 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.
Elemento que comprobar | Dónde leerlo | Criterio de validación
Resultado de la ejecución de la transacción | Status o status del recibo | Success o 0x1
Contrato emisor del log | address del log | Coincide con el contrato oficial de USDC de esa cadena
Tipo de evento | Nombre y firma del evento | Transfer(address,address,uint256)
Dirección de origen de los tokens | from del evento | Origen que pueda vincularse con la documentación del pago
Dirección de recepción de los tokens | to del evento | Coincide con la dirección de recepción completa comprobada previamente
Cantidad real | value del evento | La cantidad, tras aplicar los decimales, coincide con las condiciones de pago
Bloque de inclusión | blockNumber, blockHash | El hash coincide con el del bloque de la misma altura en la cadena actual
Finalidad | Estado de confirmación definitiva de ese bloque | Se comprueba por separado con el procedimiento de finalidad que figura a continuación
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.
Red | Estado que puede observarse primero | Criterio de confirmación definitiva
Ethereum | La transacción se incluye en un bloque y se ejecuta correctamente | El bloque de la transacción está dentro del rango finalized
Base | Confirmación previa o inclusión en un bloque L2 | Ese bloque L2 alcanza la finalidad del lote en L1
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.
· Compruebe con eth_chainId a qué cadena se ha conectado.
· Lea el recibo con eth_getTransactionReceipt. Revise status, los logs, el número de bloque y el hash del bloque.
· Consulte el mismo número de bloque con eth_getBlockByNumber. Contraste si el hash devuelto coincide con el blockHash del recibo.
· 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.
Elemento | Valor del ejemplo simulado
Cadena | Base Mainnet, ID de cadena 8453
Contrato emisor del log | 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913
Dirección de origen de los tokens | 0x2222222222222222222222222222222222222222
Dirección de recepción acordada | 0x1111111111111111111111111111111111111111
Dirección de recepción de Transfer | 0x1111111111111111111111111111111111111111
Cantidad sin procesar | 100,000,000 unidades mínimas
Decimales | 6 decimales
Cantidad convertida | 100,000,000 ÷ 1,000,000 = 100 USDC
Estado de la transacción | status = 0x1
Identificador de la transacción | H, símbolo que sustituye a un txHash real
Posición del log | logIndex = 7, valor simulado
Finalidad | Se supone que el bloque de la transacción está dentro del rango finalized
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.
Información comprobada | Qué demuestra | Estado de gestión del depósito
100 dólares en el anuncio | Condiciones de la recompensa indicadas en el anuncio | Revisión de la promesa de pago
Oferta de trabajo o mensaje de selección | Existencia de una oferta de trabajo o de una selección | Fase de contratación
Trabajo terminado y revisión aprobada | Estado del trabajo en la plataforma | Pago pendiente de comprobación por separado
Depósito en custodia | Movimiento de fondos a una dirección de custodia independiente | Antes de la recepción propia
ERC-20 Approval | Permiso para que la parte designada use los tokens | No demuestra una transferencia de tokens
Hay txHash, pero la transferencia se hizo a otra dirección | Transferencia a esa dirección | No es un depósito propio
Transferencia correcta a la dirección propia, sin comprobar la finalidad | Transferencia ejecutada | A la espera de finalidad
Depósito externo en la dirección propia confirmado definitivamente | Recepción en la cadena | Comprobación del vínculo con el pago del trabajo
Coincidencia entre el depósito definitivo y el detalle del pago del trabajo | Prueba de recepción vinculada a ese trabajo | Recepción del pago confirmada
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.
Dato que guardar | Objetivo del registro
ID de cadena, dirección del contrato del token | Identificar la red y el activo
txHash, logIndex | Distinguir los eventos de transferencia
blockNumber, blockHash | Volver a verificar el bloque de inclusión
Dirección de origen, dirección de recepción | Comprobar la dirección del movimiento de fondos
Cantidad sin procesar, decimals, cantidad de USDC | Reproducir la conversión de unidades
Hora del bloque, hora de comprobación, zona horaria | Distinguir el momento de la transferencia del de la verificación
Estado de finalidad | Distinguir los registros pendientes de los definitivos
Número de trabajo, factura, detalle del pago | Vincular el depósito con su motivo
Clasificación de reembolsos, transferencias propias y duplicados | Evitar sobreestimar los pagos de trabajos nuevos
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.
Orden | Pregunta de comprobación | Resultado que registrar
1 | ¿Conoce la cadena y la cantidad de las condiciones de pago? | Red y cantidad de USDC acordadas
2 | ¿El servicio receptor admite esa cadena? | Dirección de recepción y compatibilidad
3 | ¿El contrato del log coincide con la dirección de Circle? | Coincidencia con el contrato oficial
4 | ¿La transacción se ejecutó correctamente y los tokens se enviaron a mi dirección? | Estado y dirección de recepción de Transfer
5 | ¿Ha convertido correctamente la cantidad sin procesar? | Cantidad real de USDC
6 | ¿Ha comprobado el bloque de inclusión y la finalidad? | Hash del bloque y estado de confirmación definitiva
7 | ¿Puede vincularse con un pago externo de ese trabajo? | Número de trabajo y documentación del pago
8 | ¿Ha separado los reembolsos, las transferencias propias y los duplicados? | Resultado de la clasificación e identificador del evento
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.
Injoys
