Un intercambio puede finalizar mientras el permiso que lo respalda permanece activo. Las aprobaciones de tokens permiten que una dirección específica gaste tokens de tu billetera, dentro de la autoridad que otorgues. Cerrar la aplicación no necesariamente elimina dicha autoridad.

Esta guía se centra en los tokens ERC-20 de Ethereum y otras redes EVM. Otros estándares de tokens y cadenas de bloques utilizan sistemas de permisos diferentes. La tarea práctica consiste en comprender quién es el gastador, el importe y el alcance antes de aprobar, y luego eliminar los permisos que ya no necesites.

Una asignación es un límite de gasto asociado a un gastador

En el flujo habitual de ERC-20, approve establece una asignación, allowance informa del importe restante y transferFrom permite que el gastador autorizado mueva tokens conforme a las reglas del contrato del token. La transacción de aprobación generalmente establece el permiso; la acción posterior de la aplicación lo utiliza.

Identifica cuatro cosas: la red, el contrato del token, la dirección del propietario y la dirección del gastador. El nombre de un sitio web no es el permiso en sí. El gastador puede ser un contrato de aplicación u otra dirección, y su código determina cómo puede utilizarse dicha autoridad.

Considera una billetera hipotética que contiene 200 tokens. Apruebas a un gastador por 100 tokens. El saldo permanece en 200 hasta que los tokens se mueven realmente. Si el gastador transfiere posteriormente 40 tokens conforme a una asignación finita estándar, tu saldo pasa a ser de 160 y la asignación restante pasa a ser de 60. Son números distintos.

El gastador puede utilizar el permiso restante sin otra solicitud de aprobación, sujeto a las reglas aplicables del contrato. Una nueva aprobación normalmente reemplaza la asignación existente por el importe que especifiques; no suma automáticamente dicho importe al límite anterior.

Las aprobaciones ilimitadas pueden alcanzar depósitos futuros

Una aplicación puede solicitar una asignación muy elevada para que no necesites una nueva aprobación para cada transacción. Esto puede reducir los pasos repetidos y los costes de aprobación, pero deja un importe mayor expuesto a la autoridad del gastador.

Algunas implementaciones comunes tratan la asignación máxima de enteros como ilimitada y no la reducen cuando se gastan tokens. No supongas que cada uso consume gradualmente un permiso ilimitado.

Una asignación también puede permanecer cuando el saldo de tus tokens llega a cero. Si posteriormente recibes más tokens del mismo tipo en esa dirección y en la misma red, el permiso existente puede volver a ser útil. Una vista de billetera vacía no demuestra que sus permisos anteriores hayan desaparecido.

Elegir un límite menor reduce el importe disponible mediante ese permiso. No demuestra que la aplicación sea confiable ni que la transacción propuesta sea sensata.

Revoca el permiso que realmente otorgaste

Revisa las asignaciones cuando dejes de usar una aplicación, no puedas identificar a un gastador, descubras un límite innecesariamente elevado o tengas conocimiento de un incidente de seguridad relevante. El objetivo es eliminar una vía innecesaria para gastar.

1. Comprueba la cuenta y la red. Un permiso en una cadena es independiente de un permiso en otra.
2. Identifica el token y el gastador. Utiliza una pantalla de permisos de una billetera confiable o el explorador de bloques adecuado. Una etiqueta conocida por sí sola no verifica una dirección.
3. Lee el cambio propuesto. Para una asignación ERC-20 estándar, la revocación normalmente envía una transacción en la cadena que establece en cero la asignación de ese gastador. Confirma el token, el gastador y el nuevo importe.
4. Verifica la confirmación. La revocación en la cadena cuesta gas de red, incluso si un servicio lo patrocina. Comprueba que la transacción se haya realizado correctamente y que la asignación correspondiente refleje ahora el cambio previsto.

Una revocación pendiente aún no ha cambiado el estado de la cadena. Un gastador puede actuar antes de que se confirme. Una revocación completada limita el uso futuro de esa asignación; no recupera los tokens que ya se hayan transferido.

Desconectar un sitio web cambia la conexión de la billetera con ese sitio. Las aprobaciones existentes en la cadena requieren un cambio independiente. Si se han filtrado claves privadas o frases de recuperación, los permisos son solo una parte del incidente: la revocación no elimina la capacidad de otra persona para firmar con esas claves.

Si utilizas una billetera personal junto con KTX, mantén los permisos de la billetera separados de la seguridad de la cuenta de la plataforma. La guía de KTX sobre billeteras con custodia y sin custodia explica quién controla la autorización y la recuperación de las transacciones. Consulta la guía de KTX para realizar copias de seguridad de la frase semilla para proteger el material de recuperación y nunca proporciones frases de recuperación a un sitio web que ofrezca revocar permisos.

Los permisos firmados requieren una segunda comprobación

Una billetera puede solicitar una firma en lugar de una transacción de aprobación inmediata. Una firma aún puede crear una autoridad significativa. ERC-2612 permite, por ejemplo, que otra parte envíe tu autorización firmada para establecer una asignación.

La fecha límite del permiso limita cuándo puede enviarse esa firma. No otorga automáticamente una fecha de vencimiento a la asignación ERC-20 ordinaria resultante. Establecer una asignación en cero tampoco invalida necesariamente una firma de permiso anterior y sin usar; sus reglas de nonce y validez requieren una atención independiente.

Permit2 introduce otra capa: la aprobación del token al contrato de Permit2, seguida de permisos para aplicaciones específicas. Sus permisos basados en asignaciones y sus transferencias mediante firmas de un solo uso tienen reglas diferentes para los importes, el vencimiento y los nonces.

Revisa cada capa aplicable y las autorizaciones firmadas pendientes. Un comprobador que lea las asignaciones actuales en la cadena puede no mostrar todas las firmas que se hayan firmado pero aún no se hayan enviado. Una pantalla de asignaciones tranquilizadora no puede dar cuenta de un permiso que todavía no puede ver.

Preguntas frecuentes

¿Necesito una aprobación ERC-20 para enviar ETH nativo?

Una transferencia normal de ETH nativo no utiliza una asignación ERC-20. Wrapped ETH es un token y puede utilizar ese mecanismo. Los permisos a nivel de cuenta son un asunto independiente.

¿Una aprobación ilimitada cubre todos los activos de mi billetera?

Una aprobación ERC-20 convencional se refiere a un token y un gastador específicos. No cubre automáticamente todos los tokens o NFT. Sin embargo, una sola solicitud de firma puede contener varios permisos, así que revisa su alcance completo.

¿Por qué una billetera podría pedirme que establezca una asignación en cero antes de cambiarla?

Algunas implementaciones de tokens lo requieren, y reemplazar una asignación distinta de cero puede crear riesgos relacionados con el orden de las transacciones. Sigue el flujo de trabajo compatible; un restablecimiento no puede deshacer un gasto que ya se haya producido.

¿Una billetera de hardware impedirá una aprobación perjudicial?

Ayuda a proteger las claves de firma. Aun así, puedes autorizar un permiso peligroso con esas claves. Revisa los detalles de la transacción y el gastador en lugar de confiar únicamente en el dispositivo.

¿Las aprobaciones de NFT funcionan como las asignaciones de tokens?

ERC-721 admite la aprobación de un NFT individual y la aprobación de un operador para todo ese contrato de NFT. Estas son diferentes de una asignación de cantidad de ERC-20. Comprueba el estándar y el alcance antes de revocar.

Este artículo proporciona información general, no asesoramiento personalizado sobre seguridad o inversiones. Las implementaciones de tokens y las interfaces de las billeteras varían. Nunca reveles claves privadas ni frases de recuperación.