ERC-2612 и юзабилити Ethereum dApp

Нам с коллегами нравится еще Phalcon, но Tenderly тоже используем)

Я думаю, что рассчитывать на то, что старые токены начнут поддерживать permit не стоит, потому что большинство токенов не используют шаблон upgradeable в своих контрактах, а деплоить новый токен (с permit функционалом) автоматически означает смену адреса и поднимает вопрос миграции пользователей на новый токен, да и с ликвидностью в сервисах (биржах, лендинг протоколах) надо что-то тоже делать. Подобный процесс будет очень затратным)

Исследование оставило противоречивые чувства. С одной стороны, существуют стандарты по улучшению юзабилити в Ethereum-сетях. С другой стороны, анализ показал, что из 30 рассмотренных токенов на популярных сетях, только на 8 можно выпускать доверенности на аппрув, из них для трех придется писать отдельные обработчики (два для version и один для нестандартного permit).

Это не совсем так. Например если смотреть смарт-контракты Polygon, многие токены (чтобы не быть голословным я проверил несколько - WETH, USDT, BNB, BUSD, но я думаю их больше) имеют функцию executeMetaTransaction, фактически она позволяет делать делать то же, что и permit, при этом позволяет вызывать через подпись любую функцию смарт-контракта. Эта функция тоже поддерживает EIP712.

Оптимизм не проверял, возможно там что-то подобное. На счет Ethereum - думаю это связано с тем, что рассматриваемые токены были туда задеплоены еще до появления стандарта ERC-2612.

Красным отмечен один токен (DAI на Mainnet), у которого есть функция permit, но не по ERC2612 (sic!). Она позволяет два варианта создании доверенности на аппрув: (1) на максимально возможную сумму или (2) вообще отозвать его. Почему так сделано – загадка. permit принимает параметр allowed: bool.

Думаю тут все просто. Они почему-то решили, что выдавать апрув на определенную сумму через подпись не нужно, а вот сделать переключатель (вкл/выкл апрув) вполне можно) Скорее всего тут нужно ковырять протокол MakerDAO.

А еще существую другие подходы, например ERC-1363: Payable Token, и чуть более простой ERC-677 (он по смыслу такой же как 1363, но чуть проще, используется в токене Link). Они идут как расширение ERC20 и добавляю колбэк-функции типа transferAndCall или approveAndCall. В некоторых протоколах это может сработать даже лучше permit.

А вообще за статью спасибо, тема важная, было интересно почитать)