Por qué la “aprobación de tokens” es la peor idea en DeFi. ERC-20 acertó con el token y se equivocó en la parte difícil. Estandarizó saldos y transferencias, pero nunca proporcionó una forma limpia para que un contrato utilice realmente tus tokens. Una transferencia simple a un contrato ni siquiera le informa que algo llegó. Así que añadieron un parche: approve + transferFrom. Mira lo que ese parche te obliga a hacer. Para permitir que un contrato gaste tus tokens, debes: - Aprobarlo una vez por una cantidad enorme o infinita, y ahora puede acceder a tu monedero cuando quiera, para siempre, hasta que recuerdes revocarlo. Estás confiando en un contrato que probablemente nunca leíste. - O aprobar la cantidad exacta justo antes de cada acción, lo que significa una segunda transacción y una segunda comisión de gas en cada operación. Confía en un extraño, o paga un impuesto por cada movimiento. Esas son las dos opciones, y el estándar no ofrece nada mejor. Así que todos eligen la puerta uno y hacen clic en “infinito”, y la cadena se llena de monederos apuntando armas cargadas hacia ellos mismos. No es teórico. El bot MEV jaredfromsubway acaba de perder millones de esta manera. Nada fue hackeado. Repartió aprobaciones persiguiendo operaciones falsas, y alguien usó transferFrom para retirar los fondos. Lo peor: ya existía un diseño mejor todo el tiempo. Transfer-and-call (ERC-223, ERC-1363) mueve la cantidad exacta y notifica al receptor en una sola transacción. Sin aprobación permanente, sin transacción adicional, sin extraño con una llave a tu cuenta. Perdió frente al primer impulso de ERC-20, y ahora las aprobaciones infinitas son estructurales en todo DeFi. Permit, Permit2, abstracción de cuenta, cada “solución” es un parche sobre un elemento primitivo que nunca debería haberse lanzado. No obtuvimos la opción segura. Obtenemos la conveniente, y hemos estado pagando por ella desde entonces.