Одинаковый адрес не означает одинаковый механизм приёма
ОперацияЧто вызываетсяМожет ли получатель отклонитьЧто считать результатом
Native ETH call без calldatareceive, либо payable fallback при его отсутствииДа, исполнение может revertУспешный receipt и изменение native balance
Обычный ERC-20 transferМетод token contract; callback получателю не обязателенПолучатель обычно не участвуетTransfer log и balanceOf(contract)
ERC-1363 transferAndCallToken transfer, затем onTransferReceivedДа, неверный receiver response должен revertУспешная callback-aware операция
Метод deposit приложенияКонкретная функция и её проверкиПо правилам контрактаЗапись внутреннего accounting, а не только token balance
Одинаковый адрес не означает одинаковый механизм приёма
Операция
Native ETH call без calldata
Что вызывается
receive, либо payable fallback при его отсутствии
Может ли получатель отклонить
Да, исполнение может revert
Что считать результатом
Успешный receipt и изменение native balance
Операция
Обычный ERC-20 transfer
Что вызывается
Метод token contract; callback получателю не обязателен
Может ли получатель отклонить
Получатель обычно не участвует
Что считать результатом
Transfer log и balanceOf(contract)
Операция
ERC-1363 transferAndCall
Что вызывается
Token transfer, затем onTransferReceived
Может ли получатель отклонить
Да, неверный receiver response должен revert
Что считать результатом
Успешная callback-aware операция
Операция
Метод deposit приложения
Что вызывается
Конкретная функция и её проверки
Может ли получатель отклонить
По правилам контракта
Что считать результатом
Запись внутреннего accounting, а не только token balance

Сначала докажите, какие токены и какой контракт получили баланс

  1. 1
    Закрепите сеть

    Сохраните chain ID, transaction hash и block hash. Одинаковая строка адреса в другой EVM-сети относится к другому состоянию.

  2. 2
    Проверьте token contract

    Сопоставьте полный адрес токена, а не ticker, название или изображение в кошельке.

  3. 3
    Откройте receipt

    Убедитесь, что status успешный, найдите Transfer именно ожидаемого token contract и прочитайте from, to и raw value.

  4. 4
    Сверьте balance delta

    Проверьте balanceOf получившего контракта на блоках до и после; применяйте decimals только для отображения.

  5. 5
    Отделите депозит

    Ищите event или state, которые документирует целевой deposit method. Один Transfer к адресу не доказывает внутренний credit.

Если перевод подтверждён, средства не обязательно исчезли: они учтены token contract на балансе адреса-получателя. Для отображения суммы применяйте decimals именно этого токена. Но способность увидеть balance не равна способности сформировать исходящий transfer. Для этого bytecode должен содержать достижимую логику, которая вызовет token contract от имени получателя.

ERC-20 не сообщает контракту о поступлении

В обычном ERC-20 transfer пользователь вызывает token contract. Тот меняет свою таблицу balances и выпускает Transfer event; стандарт не требует исполнить код по адресу to. Поэтому смарт-контракт-получатель может не вести депозитный учёт и даже не иметь функции вывода. ERC-1363 решает другую задачу отдельными transferAndCall и onTransferReceived, но наличие обычного ERC-20 интерфейса не означает поддержку этого расширения.

Recovery существует только как исполнимая ветка контракта

Decision tool: где искать реальный путь возврата
НаблюдениеЧто проверитьРеалистичный исход
Есть документированный rescue/sweep methodКто может вызвать, какие tokens/to разрешены, не paused ли функцияУполномоченная сторона может выполнить вызов по правилам кода
Контракт — upgradeable proxyТекущий implementation, admin/governance, upgrade constraints и публичный процессИзменение возможно только через действующий governance path; не обещано
Это exchange/deposit contractОфициальная поддержка, deposit method, memo/account mapping и policyВозможен ручной credit или отказ по правилам сервиса
Bytecode immutable, выхода для токена нетИсходники, verified bytecode и reachable call graphБаланс может остаться недоступным бессрочно
Адрес только похож на контрактeth_getCode на нужном блоке и EIP-7702/creation contextСначала исправить классификацию получателя
Decision tool: где искать реальный путь возврата
Наблюдение
Есть документированный rescue/sweep method
Что проверить
Кто может вызвать, какие tokens/to разрешены, не paused ли функция
Реалистичный исход
Уполномоченная сторона может выполнить вызов по правилам кода
Наблюдение
Контракт — upgradeable proxy
Что проверить
Текущий implementation, admin/governance, upgrade constraints и публичный процесс
Реалистичный исход
Изменение возможно только через действующий governance path; не обещано
Наблюдение
Это exchange/deposit contract
Что проверить
Официальная поддержка, deposit method, memo/account mapping и policy
Реалистичный исход
Возможен ручной credit или отказ по правилам сервиса
Наблюдение
Bytecode immutable, выхода для токена нет
Что проверить
Исходники, verified bytecode и reachable call graph
Реалистичный исход
Баланс может остаться недоступным бессрочно
Наблюдение
Адрес только похож на контракт
Что проверить
eth_getCode на нужном блоке и EIP-7702/creation context
Реалистичный исход
Сначала исправить классификацию получателя

Как обратиться к оператору без передачи секретов

  1. 1
    Соберите короткое доказательство

    Chain, transaction hash, token contract, recipient contract, raw amount и block time достаточно для первичного разбора.

  2. 2
    Найдите владельца процесса

    Используйте официальный домен проекта или support-канал, связанный с verified repository; личные сообщения посредников не подтверждают полномочия.

  3. 3
    Спросите о конкретной функции

    Запросите название recovery method, caller role, ожидаемый event и сроки. Формулировка «мы попробуем» не является гарантией.

  4. 4
    Проверьте предложенный вызов

    До подписи декодируйте target, function, token, amount и recipient. Rescue не требует seed или private key пользователя.

  5. 5
    Сверьте итог

    После исполнения проверьте новый receipt и balances отправителя/получателя; статус тикета сам по себе не является on-chain результатом.

Когда нужно остановить попытки

  • token contract, сеть или recipient address не подтверждены полностью;
  • предлагаемая функция отсутствует в verified bytecode или недостижима для заявленного caller;
  • неизвестно, кто контролирует admin, multisig или governance;
  • для возврата просят seed, private key, удалённый доступ или unlimited approval;
  • оператор обещает гарантированный возврат без transaction plan и проверяемого события.

Если recovery path отсутствует, технически честный результат — зафиксировать transfer и недоступность вывода, а не продолжать рискованные подписи. Если путь есть, завершение доказывает только новая успешная on-chain операция к правильному адресу. Отдельно отзовите ненужные allowances, если в ходе ошибочного сценария вы выдавали разрешение стороннему spender: само зачисление на контракт allowance не создаёт.

Источники

Мы используем прямые ссылки и фиксируем дату проверки. Полный текст чужих материалов не перепечатывается.

  1. ERC-20: Token Standard Ethereum Improvement Proposals · Проверено 21 августа 2026 г. в 22:03 GMT+5
  2. ERC-1363: Payable Token Ethereum Improvement Proposals · Проверено 21 августа 2026 г. в 22:03 GMT+5
  3. Solidity — Receive Ether and fallback functions Solidity Project · Проверено 21 августа 2026 г. в 22:03 GMT+5
  4. EIP-7702: Set Code for EOAs Ethereum Improvement Proposals · Проверено 21 августа 2026 г. в 22:03 GMT+5
Материал носит информационный характер и не является индивидуальной рекомендацией. Криптоактивы связаны с риском волатильности, технических сбоев, хищения и полной потери средств.