EIP-2612 (Permit) — це стандарт Ethereum, що дозволяє користувачу авторизувати передачу токенів, підписуючи off-chain повідомлення, замість відправки on-chain approval-транзакції. Користь мала бути економією газу — без окремої approve-транзакції, permit-підпис подорожує з реальним трансфером. Ціна в тому, що signature-фішинг тепер домінує як провідний вектор криптовтрат у 2025-2026.
Що Permit-підпис реально робить
Користувач підписує EIP-712 typed повідомлення, що гласить: "Я авторизую адресу X витрачати до Y токена Z з моєї адреси, закінчується в момент T." Підпис — валідний доказ on-chain; будь-хто, що тримає підпис, може відправити її в контракт токена, і контракт розпізнає авторизацію без вимоги попередньої approve-транзакції.
З точки зору UX це елегантно: один підпис, без газу, без окремої транзакції. З точки зору атаки це катастрофічно: підпис виглядає як безглуздий криптографічний блок в UI гаманця, у користувача немає інтуїції, що її підписання еквівалентне передачі кастодіальних відносин для цього токена за цією адресою.
Еволюція Permit2
Uniswap запустив Permit2 наприкінці 2022 року як оновлену permit-систему. Permit2 вводить єдиний approval-контракт, який може використовувати будь-який застосунок, з більш гранулярним контролем (ліміти per-transaction, batch-операції, expiration nonces). Той самий вектор signature-based фішинг-атаки застосовується, з доданою складкою, що Permit2 підписи можуть бути валідні для багатьох токенів одночасно.
До середини 2024 року Permit2 став домінуючим approval-механізмом на Uniswap і багатьох інших Ethereum dApp. Chainalysis у піврічному звіті 2025 року приписав приблизно 60% approval-фішинг втрат підписам типу Permit2.
Шаблон атаки у 2026
Користувач приземляється на фейковий інтерфейс — іноді клонований DEX, іноді фішингова сторінка "claim airdrop", іноді скомпрометований легітимний dApp. Інтерфейс запитує з'єднання гаманця, потім запитує "підпис", а не транзакцію. Підпис в UI гаманця виглядає як хеш або рядок typed-data полів.
Якщо користувач підписує, зловмисник збирає підпис і чекає — часто дні — перш ніж відправити. Затримка навмисна: ламає ментальний зв'язок користувача між "я підписав щось дивне три дні тому" і "мій USDC щойно зник".
Що реально захищає
Три шари:
Перше, читайте кожен off-chain підпис. Display EIP-712 typed-data у Rabby Wallet, MetaMask (з оновлення травня 2024 року) і сучасній прошивці Ledger і Trezor показує структуровані поля Permit-підпису у людиночитаній формі. Якщо ви бачите "spender", встановлений на адресу, яку ви не впізнаєте, не підписуйте.
Друге, віддавайте перевагу DEX-агрегаторам, що не використовують signature-only approval-потоки. 1inch використовує стандартний on-chain approval (більше газу, більше тертя, але видно в історії транзакцій користувача). Деякі менші DEX мають схожі конфігурації.
Третє, регулярно відкликайте. Запускайте revoke.cash раз у квартал і відкликайте кожен Permit2 allowance, який ви не можете ідентифікувати. Це операційний еквівалент "аудиту ваших approval".
Застереження по апаратному гаманцю
Апаратні гаманці відображають EIP-712 підписи, але якість відображення варіюється. Ledger Nano S Plus показує структуровані дані на маленькому екрані; Trezor Safe 5 показує у великому тексті на кольоровому тачскрині. Який би пристрій ви не використовували, уповільніться для typed-data підписів — вікно атаки в секунду або дві між "це виглядає нормально, натисну підтвердити" і "насправді це був шкідливий approval".
Подальше читання: setApprovalForAll, Фішинг, revoke.cash.