TRC-20 Aprobación de token: qué es y cuándo la necesita — TRON Wiki

TRC-20 Aprobación de token: qué es y cuándo la necesita

8 min de lectura · ⌘K buscar

TRC-20 approve permite que un contrato inteligente extraiga tokens de su billetera sin que usted firme cada transferencia, lo cual es esencial para los intercambios y préstamos DEX, pero también el mecanismo principal detrás de las estafas de phishing de aprobación.

Cómo funciona la aprobación {#cómo-funciona}

TRC-20 hereda el patrón de aprobación ERC-20:

  1. Llamas a approve(spender, amount) en el contrato del token (por ejemplo, USDT).
  2. El token registra asignación[su dirección][gastador] = monto.
  3. El contrato del gastador llama transferFrom(you, destination, amount).
  4. La asignación disminuye a menos que usted apruebe type(uint256).max (ilimitado).

Ejemplo: intercambiar USDT por SunSwap requiere aprobar el contrato del enrutador para extraer USDT de su billetera para la transacción de intercambio.

Contrato oficial USDT:

Código
TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t

Aprobación versus transferencia {#aprobación-vs-transferencia}

Acción¿Quién inicia? Caso de uso
transferEnviar a un amigo, pagar al comerciante
approve + transferFromContratoDEX, préstamos, estrategias automatizadas

Los envíos P2P normales USDT nunca necesitan aprobación. Si un sitio aleatorio le pide que apruebe USDT para "recibir" fondos, es una estafa.

Aprobar no es una transferencia
La aprobación no envía tokens de inmediato: otorga derechos de gasto futuros. Los contratos maliciosos se agotan más tarde a través de transferFrom.

Cuando necesitas aprobación

Escenarios legítimos:

  • Intercambios DEX: aprobar el enrutador y luego intercambiar
  • Préstamos: aprobar el fondo común para depositar la garantía
  • Provisión de liquidez — aprobar contrato de par
  • Algunos puentes: aprobar el contrato del puente (verificar la interfaz de usuario oficial)

Cada aprobación cuesta energía/TRX como cualquier llamada de contrato. Consulte TRC-20 tarifas de transferencia.

Riesgos de aprobación ilimitados

Las billeteras y dApps a menudo tienen el valor predeterminado ilimitado (MaxUint256) porque:

  • Los usuarios evitan repetidos txs de aprobación (ahorra tarifas)
  • La experiencia de usuario es más fluida para los traders frecuentes

Riesgos:

RiesgoConsecuencia
Explotación del enrutadorEl atacante drena todos los aprobados USDT
Aplicación de phishingSitio falso obtiene derechos de extracción ilimitados
Actualización de proyecto comprometidoEl contrato de proxy cambia el comportamiento
Trate lo ilimitado como el acceso completo a la billetera
Para USDT no comercias activamente, no utilizas cantidades exactas ni revocas después de su uso.

Prácticas de aprobación segura

  1. Verificar URL: marcar las dApps oficiales como favoritas; ignorar los mensajes directos.
  2. Verifique la dirección del gastador en TronScan antes de confirmar.
  3. Prefiera cantidades exactas para interacciones únicas.
  4. Revocar después del usorevocar la aprobación TRC-20.
  5. Carteras separadas: billetera activa para DeFi, billetera fría para ahorros.
  6. Verificar el contrato USDTguía oficial USDT.

Aprobaciones de lectura en TronScan

  1. Abra la dirección de su billetera en TronScan.
  2. Navegue hasta la sección Aprobaciones o asignación de tokens (la interfaz de usuario varía según la versión).
  3. Ver contratos de gasto y asignación restante.
  4. Revocar entradas sospechosas mediante la herramienta de revocación o billetera TronScan.

Patrones de estafa comunes

PatrónRealidad
"Reclamar lanzamiento aéreo: aprobar primero"Roba fichas reales
Falso USDT con botón de aprobaciónToken sin valor, objetivo de aprobación real
Sitios de suplantaciónSpender es contrato de atacante
Soporte solicita aprobación txNunca legítimo

Los lanzamientos aéreos falsos USDT a menudo van acompañados de mensajes de aprobación: verifique el contrato antes de cualquier interacción.

Detalles técnicos para desarrolladores

Código
function approve(address spender, uint256 amount) external returns (bool);
function allowance(address owner, address spender) external view returns (uint256);
function transferFrom(address from, address to, uint256 amount) external returns (bool);

Mejores prácticas:

  • Utilice los patrones increaseAllowance / decreaseAllowance cuando estén disponibles
  • Evite forzar una aprobación ilimitada en la interfaz de usuario
  • Contrato de gasto de documentos para usuarios.

Contexto de creación del token: crear token TRC-20.

Explicación de los montos de las asignaciones

Tipo de aprobaciónValor en cadenaLo mejor para
Importe exactoTamaño de intercambio de coincidenciasComercio DEX por única vez
Ligeramente más altoIntercambio + buffer de deslizamientoComercio único con movimiento de precios
Ilimitado (MaxUint256)Efectivamente infinitoBots comerciales frecuentes (arriesgados)

Las billeteras se muestran ilimitadas como un número muy grande. La pestaña de asignación TronScan muestra el límite de gasto restante; se actualiza después de cada transferFrom.

Multifirma y aprobaciones

Las cuentas corporativas TRON que utilizan permisos multifirma aún firman approve con claves de propietario. La política del Tesoro debería exigir:

  • Lista blanca de contratos gastadores.
  • Aprobaciones de monto exacto por defecto.
  • Revocación obligatoria tras revisión trimestral.

Cronograma del incidente {#cronograma del incidente}

Si sospecha de una aprobación maliciosa:

MinutoAcción
0Revocar la asignación el TronScan
1Transfiera el USDT restante a una billetera nueva
5Dirección del gastador del documento; advertir al equipo
24hSupervise TronScan para detectar intentos de transferFrom

La velocidad importa: los robots obtienen aprobaciones ilimitadas dentro de los bloques.

Educación para usuarios no técnicos {#educación}

Los equipos deben capacitar al personal para que Aprobar no sea Enviar:

Etiqueta de interfaz de usuarioModelo mental de usuario
Enviar / TransferirEl dinero dejó la billetera ahora
Aprobar / PermitirPermiso futuro concedido

La referencia de capacitación en seguridad en una sola diapositiva guía de revocación reduce los incidentes repetidos.

Proxys de actualización de contrato

Algunos tokens TRC-20 utilizan patrones de proxy actualizables: las aprobaciones de los gastadores pueden persistir durante los intercambios de implementación. Prefiere revocar después de las migraciones del protocolo "v2", incluso cuando la interfaz de usuario afirma ser compatible.

Preguntas frecuentes

¿Qué hace aprobar en TRC-20?

Permite que un contrato inteligente gaste sus tokens hasta un límite de asignación. El contrato puede llamarse transferFrom sin su firma cada vez hasta que sea revocado o agotado.

¿Debería aprobar el USDT ilimitado?

Sólo para contratos en los que confíes plenamente. Las aprobaciones ilimitadas son convenientes pero peligrosas si el contrato es pirateado o malicioso.

Lista de verificación para solucionar problemas

Si algo sale mal en TRON, trátelo como un problema de depuración estructurado: confirme el txid exacto en la cadena, verifique la dirección del contrato de destino y solo entonces decida si la falla es recuperable. En TRON, muchos problemas "misteriosos" son simplemente uno de: red incorrecta (mainnet vs testnet), contrato de token incorrecto (falso USDT/tokens con nombres similares), recursos insuficientes (OUT_OF_ENERGY/ancho de banda) o retraso en la interfaz de usuario/indexador entre la billetera y el explorador.

Comience con estas comprobaciones en cadena:- Copie siempre el txid/hash completo de su billetera o explorador.

  • Confirme el estado del resultado del tx en TronScan (SUCCESS, REVERT, OUT_OF_ENERGY o aún pendiente).
  • Compruebe si la dirección del destinatario/contrato coincide con la que desea enviar.
  • Si se trata de una llamada de contrato, confirme que el selector de función y los parámetros coincidan con el estándar de token que cree que está utilizando (TRC-20 vs TRC-10 vs BEP-20 en BSC).

Luego aplique la ruta de corrección para su categoría:

  • Confirmar el estado y los parámetros de la transacción.
  • Verificar direcciones (contrato de token, destinatario, enrutador/gastador).
  • Agregar o delegar recursos (Energía/Ancho de banda) cuando el fallo esté basado en recursos.

Errores comunes

Estos patrones causan la mayoría de los errores a nivel de usuario:

  • Usar direcciones de mainnet en testnet (o al revés).
  • Copiar un símbolo de token en lugar de la dirección real del contrato TRC-20.
  • Firmar la dirección de aprobación/gastador incorrecta porque el enlace de la interfaz de usuario es malicioso o está desactualizado.
  • Reintentar sin cambiar la entrada fallida (por ejemplo, REVERT sigue revirtiéndose hasta que corrija el parámetro).

Si no está seguro, no “simplemente envíe de nuevo”. Realice un cambio controlado, verifique en TronScan y luego continúe.

Preguntas frecuentes

¿Cómo sé si una transacción está realmente confirmada?

Utilice TronScan y verifique el estado del resultado del tx. Las etiquetas "pendientes" de la billetera pueden retrasarse; El estado de la cadena es la fuente de la verdad. Copie txid y verifique SUCCESS/REVERT/OUT_OF_ENERGY, no solo el texto de la interfaz de usuario.

¿Por qué la interfaz de usuario difiere de TronScan?

Algunas billeteras y dApps utilizan diferentes indexadores o capas de caché. Es normal que haya un breve retraso entre la transmisión y la indexación; compare txid y espere a que la cadena se estabilice antes de concluir que hay una falla.

¿Qué debo hacer después de un REVERT?

Detenga y decodifique la llamada fallida. La mayoría de los REVERT se deben a parámetros no válidos, dirección de contrato incorrecta, aprobaciones faltantes o una falta de coincidencia entre el estándar del token y el método. Solucione la causa y luego vuelva a firmar.

¿Es seguro firmar una aprobación ilimitada?

Las aprobaciones ilimitadas son seguras solo para direcciones de gastadores confiables que usted haya verificado (fuente verificada, enrutador correcto y contrato de token esperado). Para las pruebas, prefiera aprobaciones limitadas y revoque una vez que haya terminado.

¿Qué recursos requiere TRON para las llamadas de contrato?

La ejecución de contratos inteligentes consume principalmente energía, mientras que los bytes de transacciones consumen ancho de banda. Si recibe OUT_OF_ENERGY, agregue/congela/delegue energía. Si se agota el ancho de banda, concéntrese en mantener suficiente líquido TRX para bytes y asignación de recursos.

¿Cómo puedo reducir los tickets de soporte?

Muestre a los usuarios un mensaje claro de "qué sucedió" basado en el estado de la cadena y vincule directamente a la guía relevante (pendiente, fallida, sin energía o verificación). Guarda txid para que puedas conciliar rápidamente.