В кошельке был разрешён лимит 100 единиц токена, а пользователь решил оставить только 50. После изменения он видит новое число и ожидает, что суммарно больше 50 списать уже нельзя. Но allowance описывает оставшееся разрешение в текущем состоянии. Оно не является общим пределом всех переводов, выполненных до и после изменения.
Что меняется при approve
Стандарт ERC-20 описывает approve как установку нового значения разрешения для spender. Повторный вызов заменяет текущее allowance. Это не прибавление к старому значению и не возврат ранее переведённых токенов. Владелец, контракт токена и получатель разрешения определяют конкретную связь, которую нужно проверять.
- Баланс
- Сколько токенов находится у владельца в рассматриваемом состоянии.
- Allowance
- Сколько ещё разрешено списать определённому spender.
- Уже выполненное списание
- Отдельный результат прошлого действия. Новый лимит сам по себе его не отменяет.
Перевод владельцем через transfer и использование разрешения через transferFrom — разные операции. Поэтому сначала выясните, что именно просит подтвердить интерфейс: перевод, разрешение конкретному контракту или другое действие. Наличие слова «обмен» не объясняет смысл запрашиваемой операции.
Учебный пример с двумя очередями
Пусть исходный конечный лимит равен 100 минимальным единицам. Владелец заранее выбрал два изменения: сначала 0, затем 50. Вторая сторона делает две попытки списания: сначала 100, затем 50. Внутренний порядок каждой очереди сохраняется, но между очередями возможны разные чередования.
Обозначим изменения владельца U1 и U2, попытки списания S1 и S2. В модели approve всегда заменяет лимит успешно. Списание проходит только при достаточном allowance и уменьшает его; при недостаточном разрешении попытка отмечается неуспешной и лимит не меняется. Баланс считается достаточным и отдельно не моделируется.
| Порядок | Успешно списано, единиц | Лимит в конце | Что произошло |
|---|---|---|---|
| U1 U2 S1 S2 | 50 | 0 | 100 не проходит, затем проходят 50 |
| U1 S1 U2 S2 | 50 | 0 | Первая попытка встречает нулевой лимит |
| U1 S1 S2 U2 | 0 | 50 | Обе попытки происходят до нового разрешения |
| S1 U1 U2 S2 | 150 | 0 | 100 списаны до обнуления, ещё 50 после нового разрешения |
| S1 U1 S2 U2 | 100 | 50 | Вторая попытка встречает нулевой лимит |
| S1 S2 U1 U2 | 100 | 50 | После первых 100 разрешение исчерпано |
Почему обнуление не возвращает прежние средства
В ERC-20 есть рекомендация для интерфейсов сначала установить ноль перед изменением значения. Это не означает, что уже выполненный до обнуления перевод исчезнет. В четвёртой строке таблицы первые 100 списаны раньше U1. Последующее U2 создаёт заранее выбранное новое разрешение 50, поэтому итог успешных списаний в этой модели равен 150.
Проблема порядка операций при изменении allowance рассмотрена и в исследовании Resolving the Multiple Withdrawal Attack on ERC20 Tokens. Однако таблица — собственный ограниченный пример, а не воспроизведение реальной сети или доказательство поведения любого токена.
Что именно перебирает инструмент
Вводятся исходный лимит, до трёх новых значений владельца и до четырёх попыток списания. Все суммы — целые минимальные единицы одного токена, без перевода в пользовательские десятичные количества. Например, 100 здесь не обязательно означает 100 целых монет. Параметр decimals инструмент не узнаёт.
Он сохраняет порядок внутри каждой очереди и перебирает только их чередования. Для двух и двух действий получаются шесть вариантов, для трёх и четырёх — тридцать пять. Суммы считаются точно целыми числами. Минимум и максимум относятся только к перечисленным вариантам и принятым правилам, а не к возможным потерям реального кошелька.
Какие детали реального контракта остаются за рамками
- Особое поведение максимального разрешения и нестандартных токенов.
- Недостаточный баланс, комиссии, паузы, ограничения получателей и ошибки approve.
- Подписи permit, временные разрешения, пакетные или атомарные операции.
- Мемпул, комиссии за газ, приоритет транзакций, отмены и реорганизации.
Инструмент не читает блокчейн и не проверяет разрешения адреса. Для разбора собственного случая нужны сеть, точный контракт токена, spender и фактически подтверждённые операции. Не вводите сюда приватные ключи, seed-фразу или подписи: полей для них нет и для объяснения они не нужны.
На странице KOT.CASH «Как это работает» описан процесс с отправкой на депозитный адрес. Это не повод считать любое стороннее окно approve частью заявки. Сверьте действие с текущими инструкциями своего ордера; при непонятном запросе уточните его назначение до подтверждения. Этот материал объясняет смысл лимита, а не предлагает выдавать новое разрешение.
Сравнить порядки изменения разрешения
Целые минимальные единицы 0–10^30. Один токен, владелец и spender. Внутренний порядок очередей сохраняется. Approve всегда успешен и заменяет лимит, успешное списание уменьшает его. Баланс считается достаточным. Нет unlimited, permit, газа, сетевого прогноза, подключения кошелька и реальных операций. Расчёт выполняется на вашем устройстве, введённые данные никуда не отправляются.