Permisos de tokens: conectar, aprobar, firmar y revocar

Cuatro solicitudes que conviene separar

Una aplicación descentralizada puede pedir conectar una billetera, firmar un mensaje, aprobar un token o ejecutar otra transacción. Esas palabras describen acciones distintas. La conexión habitualmente comparte la cuenta pública elegida y permite solicitar acciones posteriores. Una aprobación puede habilitar a un gastador a mover un token concreto según las reglas del contrato. Una firma también puede otorgar autoridad relevante dependiendo del mensaje y del protocolo.

Leé cada solicitud como una decisión nueva. No deduzcas que una portada confiable vuelve apropiado todo pedido posterior. Una transacción sin movimiento inmediato de activos también puede cambiar permisos. Antes de aceptar, explicá en lenguaje cotidiano qué se autoriza, en qué red, para qué cuenta y con qué contraparte. Si no podés explicarlo, no necesitás firmar para averiguar qué va a suceder después.

Evidencia: Token approvals · Disconnect vs revoke

MetaMask describe su billetera y conceptos generales de aprobación de tokens; otros proveedores e implementaciones pueden diferir.

Token, gastador e importe forman el permiso

En el modelo habitual de allowance para tokens fungibles, el titular autoriza a un gastador a utilizar una cantidad de un token específico. El gastador es una dirección, muchas veces de un contrato. La allowance es independiente de la lista de conexiones de la billetera. Registrá contrato del token, red, gastador e importe, en vez de anotar solamente la marca de la aplicación. Una aprobación ilimitada puede exponer más saldo que el necesario para una operación.

Aprobar normalmente no transfiere la propiedad por sí solo. Crea una autoridad que el gastador puede utilizar según las reglas del token y de la aplicación. Depositar en una farm o protocolo de préstamos puede requerir una aprobación y después otra interacción. Revocar el permiso restante no retira automáticamente una posición ya depositada en el protocolo. Identificá la operación concreta en lugar de tratar cada botón de aprobar como un acceso inocuo.

Evidencia: ERC-20 specification · BEP20 token-contract interface specification

Se usa sólo para la interfaz de contratos BEP20 y los métodos/eventos nombrados en la especificación. No demuestra que un contrato desplegado concreto cumpla el estándar, sea auténtico, seguro, emitido por una entidad determinada, respaldado por reservas o equivalente a un activo en otra red. El archivo contiene una referencia histórica a Beacon Chain que no se toma como guía de migración actual.

Que no cobre gas no significa que no tenga consecuencias

Algunos permisos usan mensajes firmados. ERC-2612 es un estándar concreto para tokens: un mensaje permit válido puede establecer la allowance de un titular para un gastador cuando el contrato acepta una llamada permit posterior. La firma por sí sola no escribe la allowance onchain, pero puede presentarse antes del vencimiento; según el estándar, podría enviarla una persona distinta del titular. Por eso, “no pide gas ahora” no significa “no otorga autoridad”. Esta explicación corresponde a implementaciones ERC-2612, no a toda firma EIP-712 ni a todas las variantes permit.

En una solicitud ERC-2612, compará el contrato del token/verificador y el contexto de red que muestra el dominio de firma; después leé owner, spender, value, nonce y deadline. El dominio normalmente vincula el mensaje con un contrato y contexto de cadena concretos; las billeteras pueden mostrar esos campos de manera distinta o incompleta. Interpretá el importe como el valor de allowance del estándar, no como una transferencia. Si no podés explicar contrato, red, gastador, importe, nonce o vencimiento, no firmes sólo para inspeccionar.

Un resumen legible de la billetera puede ayudar, pero no reemplaza comprobar qué autoriza el mensaje exacto. No pegues una firma, frase, clave privada ni código de autenticación en un sitio o conversación de soporte. Para mensajes que no sean ERC-2612, identificá la especificación y los campos aplicables; no supongas las mismas consecuencias ni método de cancelación.

Evidencia: Signed approvals

Resolvé una solicitud permit ERC-2612 ficticia

Campos hipotéticos, no una solicitud real de billetera: chain ID 56; contrato verificador del token [CONTRATO_ABC]; titular [CUENTA_A]; gastador [GASTADOR_X]; value 60 ABC; nonce 8; deadline [VENCIMIENTO_FICTICIO]. Las etiquetas entre corchetes son ficticias, no direcciones ni una firma utilizable. La allowance actual del titular para X es 20 ABC y el saldo es 250 ABC.

Leé value como la nueva allowance especificada por este permit ERC-2612, no como una transferencia de 60 ABC. Si el mensaje es válido para ese dominio, nonce y vencimiento, y el token acepta después una llamada permit, la allowance de A → X pasa a 60 ABC. Antes de que se presente esa llamada, la allowance onchain sigue en 20 ABC. Según el estándar, una tercera persona podría presentar un permit válido; quien llama paga la comisión de transacción. El titular no necesariamente envió una transacción onchain para crear la firma.

En este ejemplo hipotético, el saldo sigue en 250 ABC porque permit modifica la allowance, no el saldo del token. La allowance del gastador Y es un registro distinto. Una comprobación terminada compararía red/token/titular/gastador exactos, revisaría el recibo exitoso de la llamada permit si se envió y volvería a leer allowance A → X; mostrar o compartir una firma no prueba que cambió el estado onchain. Para este ejercicio no se creó, envió ni probó ninguna firma.

Evidencia: Signed approvals · ERC-20 specification

Revisá antes de autorizar un swap o una farm

Comenzá por la dirección oficial y la información de contratos documentada por el proyecto. Un símbolo coincidente o un resultado de búsqueda no alcanzan. Determiná si tu acción prevista necesita realmente un permiso de gasto. Compará el gastador solicitado con el contrato esperado para esa acción. Los proxies y routers pueden agregar complejidad; una etiqueta de código verificado no demuestra por sí sola que comportamiento, administración o actualizaciones sean seguros.

Evaluá si el importe solicitado guarda proporción con la operación. Una allowance menor puede limitar la exposición de ese permiso, pero no elimina contratos maliciosos, firmas dañinas, claves comprometidas o riesgos de activos ya depositados. El rendimiento anunciado por una farm no garantiza compensar esos riesgos. Evitá firmar bajo urgencia. Leé cómo se retira y cómo se administran permisos antes de comprometer fondos, en lugar de hacerlo después de un problema.

Evidencia: Token approvals · ERC-20 specification

MetaMask describe su billetera y conceptos generales de aprobación de tokens; otros proveedores e implementaciones pueden diferir.

Qué significa revocar en el modelo de allowance

En el modelo convencional de allowance ERC-20, el permiso corresponde a un titular, contrato de token y gastador. Revocar describe un cambio de estado onchain separado para ese permiso concreto; establecer la allowance en cero significa que ese gastador no tiene importe restante en ese registro. No equivale a desconectar una app ni transfiere tokens por sí solo.

El cambio de estado puede requerir una comisión de red; el método o la interfaz del producto dependen del token y de la documentación actual de la billetera o protocolo. Otros sistemas de autorización, incluidos los permits firmados, pueden tener reglas diferentes. Esta guía es conceptual y no indica cómo crear, enviar, cancelar ni confirmar una revocación.

Cambiar una allowance no dice nada sobre otro gastador, otra red, activos ya depositados en un protocolo o una autoridad de firma separada. No recupera activos ni repara claves expuestas. El valor cero de un registro es un hecho acotado, no una conclusión de que la cuenta o aplicación sea segura.

Evidencia: Disconnect vs revoke · ERC-20 specification · Signed approvals

Interpretá un cambio hipotético de allowance

Ejemplo ficticio en BSC, chain ID 56: titular [CUENTA_A], token [CONTRATO_ABC], gastador [GASTADOR_X], allowance de 100 ABC y saldo de 250 ABC. En este registro hipotético, la allowance de X luego figura en 0 ABC. Las etiquetas entre corchetes son ficticias, no direcciones reales ni datos observados de la red.

El valor 0 significa solamente que el importe restante del registro exacto titular-token-gastador es cero en el estado hipotético indicado. No significa que se hayan movido 100 ABC ni 250 ABC. En el ejemplo, el saldo del token sigue en 250 ABC; no se representa ninguna transferencia.

Si Y tiene una allowance separada de 200 ABC, ese otro registro sigue en 200 ABC. El ejemplo no dice nada sobre otra red, una posición depositada, una autorización firmada aún no presentada o claves expuestas. Ilustra solamente el significado y alcance de un valor; no se examinó una billetera ni estado real de la red.

Evidencia: ERC-20 specification · BEP20 token-contract interface specification · Disconnect vs revoke · Signed approvals

Se usa sólo para la interfaz de contratos BEP20 y los métodos/eventos nombrados en la especificación. No demuestra que un contrato desplegado concreto cumpla el estándar, sea auténtico, seguro, emitido por una entidad determinada, respaldado por reservas o equivalente a un activo en otra red. El archivo contiene una referencia histórica a Beacon Chain que no se toma como guía de migración actual.

Desconectar cierra una sesión, no toda autoridad

Desconectar una aplicación desde la billetera controla su conexión con la interfaz. No borra por sí solo las aprobaciones de tokens registradas onchain. Revocar una allowance cambia ese permiso; no demuestra que toda la cuenta esté segura. Si alguien tiene la clave privada, puede autorizar nuevas transacciones al margen de la lista de conexiones. Amenazas distintas necesitan respuestas diferentes y una evaluación concreta de qué autoridad quedó expuesta.

Usá un registro del incidente: sitio visitado, cuenta pública, red, solicitud sospechosa, token y gastador, hashes y acciones ya realizadas. No incluyas secretos. Si la billetera o el navegador muestran una advertencia de peligro, detenete e investigá por canales oficiales. No desactives la protección porque una página diga ser educativa o no muestre botones de billetera. Un rediseño no certifica que se haya resuelto la clasificación del dominio.

Evidencia: Disconnect vs revoke · Wallet recovery models