Por que "aprovação de token" é a pior ideia em DeFi. ERC-20 acertou no token e errou na parte difícil. Ele padronizou saldos e transferências, mas nunca ofereceu uma maneira limpa para um contrato usar seus tokens. Uma transferência simples para um contrato nem mesmo o avisa de que algo chegou. Então, eles adicionaram um conserto temporário: approve + transferFrom. Observe o que esse conserto força sobre você. Para permitir que um contrato gaste seus tokens, você precisa: - aprová-lo uma única vez para uma quantia enorme ou infinita, e agora ele pode acessar sua carteira sempre que quiser, para sempre, até que você se lembre de revogar. Você está confiando em um contrato que provavelmente nunca leu. - OU aprovar a quantia exata imediatamente antes de cada ação, o que significa uma segunda transação e uma segunda taxa de gás em cada operação. Confie em um estranho ou pague um imposto em cada movimento. Essas são as duas opções, e o padrão não oferece nada melhor. Então, todos escolhem a porta um e clicam em "infinito", e a cadeia enche-se de carteiras apontando armas carregadas para si mesmas. Não é teórico. O bot MEV jaredfromsubway acabou de perder milhões dessa forma. Nada foi hackeado. Ele concedeu aprovações perseguindo negócios falsos, e alguém usou transferFrom para retirar os fundos. A pior parte: um design melhor existia o tempo todo. Transfer-and-call (ERC-223, ERC-1363) move a quantia exata e notifica o receptor em uma única transação. Nenhuma aprovação permanente, nenhuma transação extra, nenhum estranho segurando uma chave para sua conta. Ele perdeu para a vantagem inicial do ERC-20, e agora as aprovações infinitas são estruturais em todo o DeFi. Permit, Permit2, abstração de conta — cada "correção" é um remendo em um primitivo que nunca deveria ter sido lançado. Não obtivemos a opção segura. Obtivemos a conveniente, e temos pago por isso desde então.