Представьте себе ситуацию. У вас есть USDC на Polymarket, а вам нужны XMR для спокойного приватного хранения. Вы идёте на rabbit.io, создаёте заявку на обмен USDC в сети Polygon на XMR, получаете адрес, на который нужно отправить USDC, отправляете токены, а обмена не происходит.
Кошелёк, который вы используете на Polymarket, подписал транзакцию. Polygonscan показывает зелёную галочку, нужный адрес, правильную сумму. А обменник не видит зачисления.
На первый взгляд, это странно. Блокчейн же общий для всех! Если эксплорер показывает поступление, почему обменник не может просто нажать кнопку и зачислить токены? Но с этим вы можете столкнуться в любом обменнике и на любой бирже. Потому что обменники и биржи не смотрят в обозреватель блоков глазами, а используют автоматическую систему учёта депозитов. И эта система должна понимать не только то, что где-то в блокчейне появилось движение, но и то, что это движение является настоящим, финальным, поддерживаемым и безопасным депозитом.
Именно здесь возникает проблема, о которой я хочу сегодня поговорить.
В EVM-сетях есть два типа адресов.

Оба типа адресов могут получать, хранить и отправлять монеты и токены, и для обычного пользователя оба адреса выглядят почти одинаково: как длинная строка, начинающаяся с 0x. Но для системы, учитывающей содержание транзакций, есть разница.
Покажу это на примере Ethereum.
Если вы отправили ETH из обычного кошелька, это простой перевод: адрес А отправил адресy B. Такая операция легко находится в основной вкладке Transactions.

Но если ETH пришёл из смарт-контракта, это может быть Internal transaction. Баланс адреса действительно увеличился, но сам перевод произошёл в рамках логики выполнения контракта, в строгом соответствии со всеми его условиями (вплоть до возможности вернуть средства обратно без согласия владельца, если такое условие прописано в контракте).

Было бы неправильно зачислять автоматически средства, отправленные в рамках таких транзакций. Вряд ли кто-нибудь будет спорить с тем, что сначала нужно внимательно изучить все условия контракта, в рамках которого они поступили.
Да, здесь очень важно отметить, что любой токен ERC-20 - USDT, USDC, WBTC, LINK и так далее - перемещается с адреса на адрес только на условиях выпустившего его смарт-контракта. Когда вы отправляете USDC, вы вызываете контракт этого токена, который меняет свою внутреннюю таблицу балансов и записывает в блокчейн событие Transfer.
Для токенов это нормальная механика, и все биржи и обменники автоматически принимают такие переводы. В чём же принципиальная разница между таким внутриконтрактным переводом, который легко принимается, и другим, который не может быть автоматически обработан?
Искать эту разницу нужно в том, кто указан отправителем в token transfer event. Если USDC списаны с вашего обычного EOA-адреса и отправлены на адрес обменника или биржи, всё пройдёт без сбоев. Проблемы могут возникнуть тогда, когда токены списаны с адреса моста, вольта, роутера, умного кошелька, мультисига или контракта торговой площадки.
Почему я пишу, что проблемы могут возникнуть? Дело в том, что правила обработки депозитов из смарт-контрактов отличаются у разных сервисов. Coinbase, например, пишет, что поддерживает депозиты ETH и ERC-20 через смарт-контракты, но не поддерживает аналогичные депозиты SOL и SPL (токенов в сети Solana). Bybit в FAQ указывает, что депозиты через смарт-контракты не поддерживаются ни для каких монет, кроме ETH. Crypto.com предупреждает о том, что большинство депозитов нативных токенов EVM-сетей из смарт-контрактов, кроме ETH, не зачисляются автоматически.
То есть индустрия до сих пор не имеет единого правила: какие контрактные переводы считать обычными депозитами, какие обрабатывать вручную, а какие не принимать вообще.
Всё усугубляется ещё и тем, пользователь может даже не знать о том, что токены отправляются не с адреса EOA.
Если я не заключал ни с кем никаких контрактов, то какое отношение смарт-контракты могут иметь к мои транзакциям? К сожалению, смарт-контракт действительно может появиться в цепочке без вашего прямого участия. Вот три распространённых сценария, в которых смарт-контракт возникает неожиданно для пользователя.
Первый сценарий - вывод средств с рынка прогнозов, агрегатора DEX, лендингового протокола или другого dApp. Все они держат активы не на вашем обычном адресе, а в контракте, даже если в web3-кошельке вы этого не видите и думаете, что активы всегда оставались у вас. Если быть точным, они были у вас на балансе, но не были под вашим полным контролем. Распоряжение этими токенами было возможно только на условиях смарт-контракта.
И вот вы нажимаете кнопку вывода, приложение отправляет средства на нужный адрес, но отправителем в блокчейне оказывается не ваш EOA, а контракт платформы.
Другой сценарий - мост. Он часто задействуется при выводе с бирж и платёжных сервисов, имеющих собственные внутренние блокчейны (Hyperliquid, dYdX, Paradex, Payy network и др.). В базе данных такого блокчейна токены были на вашем адресе, и вы думаете, что отправляете их с него, а не с адреса смарт-контракта. Но когда вы выводите их в другой блокчейн (Arbitrum, Polygon, Ethereum и т.п.), получателю приходят токены вовсе не с вашего адреса! Ведь на вашем адресе в сети назначения этих токенов не было, они были на адресе моста, на другой стороне которого для вас были выпущены токены во внутреннем блокчейне биржи или платёжного сервиса.
Всё это не значит, что каждый такой перевод обязательно потеряется. Но это значит, что для автоматической системы принимающей биржи или обменника он не будет выглядеть как простой перевод.
Третий сценарий - кошельки с абстракцией аккаунта. Они полезны: в них можно делать массовые выплаты, платить за газ стейблкоинами, поручать оплату газа другой стороне, настраивать условия восстановления доступа к кошельку при потере ключа и использовать другие удобные функции. Но такое удобство достигается за счёт того, что ваш кошелёк становится смарт-контрактом. Обратите внимание, что разработчики одного из самых популярных кошельков такого типа - OKX Wallet - специально указывают, что такие кошельки являются смарт-контрактами и не могут быть импортированы в другое приложение через сид-фразу или приватный ключ.
Для пользователя это выглядит как его личный кошелёк. А принимающий сервис видит в качестве отправителя смарт-контракт.
Самая простая причина - техническая. Автоматический сканер пополнений может не отслеживать нестандартные события в блокчейне.
Эту техническую причину было бы легко устранить. Но она возникла не по ошибке. За ней скрываются вопросы безопасности.
Нельзя доверять каждому событию Transfer просто потому, что оно красиво выглядит в эксплорере. В истории крипты уже были атаки фальшивыми депозитами, когда злоумышленник создаёт видимость депозита, а получатель ошибочно считает его настоящим.
Исследование DEPOSafe шесть лет назад нашло более 7 000 контрактов, потенциально уязвимых к таким атакам. Эти контракты никуда не делись. Они по-прежнему развёрнуты в сети Ethereum. И наверняка за прошедшие шесть лет к ним добавились новые, в том числе в других сетях.
Суть таких атак в доверии к неправильному сигналу. Получатель видит событие, выглядящее как поступление токенов, и думает, что средства теперь у него. Но затем контрактной логикой средства возвращаются, сгорают или пересылаются кому-то ещё: например, следующей жертве.
Поэтому осторожность бирж и обменников - это не бюрократия и не просто следствие нежелания вникать в неудобные транзакции. Смарт-контракты сложные, и не каждый легко отличит надёжное поступление от атаки фальшивым депозитом.
По интерфейсу приложения, из которого осуществляется отправка, иногда вообще невозможно понять, с адреса какого типа будут отправлены средства. Оценить это можно уже после отправки, по тому что произошло в эксплорере.
Если вы отправляете нативный актив вроде ETH, AVAX, BNB или HYPE, посмотрите, где отображается поступление. Если в графе Transactions - всё отлично. А если движение находится во вкладке Internal Transactions или Internal Transfers, это уже контрактный сценарий.

Если вы отправляете токен ERC-20, откройте Token Transfers и посмотрите на поле From. Зайдите на адрес, который там указан. В Etherscan и похожих эксплорерах у смарт-контрактов обычно есть вкладка Contract, verified code, contract name или label. Также адрес может быть подписан как Contract, Bridge, Router, Proxy, Safe, Vault, EntryPoint, Settlement и т.п.

Но это всё можно увидеть только когда транзакция уже есть. Поэтому прежде чем отправить из новой платформы значимую для вас сумму, совершите маленький тестовый перевод самому себе и проверьте, не пришёл ли он с адреса смарт-контракта. Если нет, то, скорее всего, и все последующие переводы с этой платформы пройдёт как обычные транзакции или трансферы токенов.
Есть случаи, когда отправку из смарт-контаркта можно распознать заранее. Самый очевидный - это если кошелёк позволяет производить оплату газа стейблкоинами. Без смарт-контракта такое не провернуть.
И ещё один простой признак: если вы вывели средства из приложения через мост, в сети назначения отправителем однозначно будет смарт-контракт.
Первый вариант - перевод будет обработан автоматически. Вообще-то, система смарт-контрактов была задумана так, чтобы наличие контракта не становилось помехой зачислению. Многие надёжные смарт-контаркты внесены в белые списки и на биржах, и в обменниках, и автоматические сканнеры поступлений корректно обрабатывают такие переводы.
Второй вариант - поступление не будет обработано автоматически, но его можно будет найти вручную. Однако в этом случае зачисление может быть не таким быстрым как хотелось бы, поскольку для безопасного зачисления потребуется тщательная проверка смарт-контракта и внутренней структуры транзакции. На форуме Bitcointalk не так давно один пользователь рассказал, что биржа HTX для ручного зачисления 15759 USDT, отправленных с платформы Polymarket, назначила срок 40 рабочих дней.
Третий вариант - в результате исследования транзакции получатель примет решение, что риски слишком высоки, и не согласится зачислять токены. В этом случае он может отправить их вам обратно.
Наконец, возможен и четвёртый вариант, когда средства доставлены получателю, но смарт-контракт не даёт ему возможности ими воспользоваться или распорядиться. В таком случае даже возврат осуществить не удастся. И не потому, что получатель - мошенник, а потому, что так устроен смарт-контракт, который использовал отправитель.
Именно поэтому перед первой отправкой на биржу или в обменник есть смысл разобраться, кто будет фактическим отправителем на блокчейне. Если сомневаетесь в том, что транзакция будет обычным переводом с вашего адреса - найдите в истории свою предыдущую исходящую транзакцию и проверьте в обозревателе блоков, что она не отправлена из смарт-контракта. Если предыдущих транзакций нет, то можно перевести сначала тестовую сумму, чтобы убедиться, что всё пройдёт гладко.
На сайте rabbit.io, даже если вы ошибётесь и случайно отправите нам криптоактивы из смарт-контракта, - не сомневайтесь, что мы сделаем всё от нас зависящее, чтобы в кратчайшие сроки обработать этот перевод, а в самом худшем случае - вернуть вам отправленные средства обратно.