Что такое DEX в криптовалюте: кошелёк, swap, liquidity pool и smart contract

Что такое DEX в криптовалюте? В практическом смысле это способ обменять on-chain активы через кошелёк и смарт-контракты без предварительного перевода монет на внутренний баланс централизованной биржи. Пользователь открывает интерфейс, подключает адрес, выбирает сеть и токены, получает quote, при необходимости выдаёт разрешение на расходование ERC-20 токена, подписывает swap и затем проверяет фактический результат в блокчейне. На каждом шаге меняется не только экран, но и юридически и технически значимое действие: connection, signature, approval и transaction — разные операции.

Эта статья построена как карта одного полного DEX-сеанса — от подготовки рабочего кошелька до проверки TXID и отзыва лишних разрешений. Она не повторяет отдельный материал про устройство DEX-рынка, семейства AMM и сравнение DEX с CEX. Также здесь намеренно не превращается в самостоятельную тему математика slippage и комиссий: для неё в плане есть отдельная статья. Задача этого материала — чтобы пользователь понимал, что именно происходит после каждого клика и в какой момент можно безопасно остановиться.

Главная ошибка новичка — воспринимать DEX как обычный сайт обмена валюты. На самом деле интерфейс лишь готовит данные, а активы живут в выбранной сети, кошелёк контролирует ключи, токен существует по конкретному адресу контракта, router или другой исполнитель формирует вызов, а финальный результат определяется состоянием блокчейна. Поэтому правильный вопрос не «какую кнопку нажать», а «какое состояние я сейчас меняю и каким контрактам даю право это сделать».

Что такое DEX в криптовалюте: путь от кошелька к смарт-контракту

Увеличить

DEX не создаёт вам биржевой счёт

На классической централизованной площадке пользователь обычно сначала отправляет актив оператору, после чего видит запись о балансе внутри системы. В типичном self-custody DEX-сценарии отдельного депозитного счёта протокола нет: токен остаётся на адресе пользователя до момента исполнения on-chain операции. Это меняет модель контроля. Площадка не обязана хранить приватный ключ, но пользователь сам отвечает за сеть, адрес токена, подпись, allowances и безопасность устройства.

Поэтому фраза «средства на DEX» часто технически неточна. До swap актив находится в вашем кошельке; во время исполнения контракт получает ровно те права и входные данные, которые предусмотрены вызовом; после подтверждения блокчейн фиксирует новое состояние. Если интерфейс исчезнет, подтверждённая транзакция не исчезнет вместе с сайтом. И наоборот, красивая зелёная анимация на сайте не может заменить проверку состояния сети.

Кошелёк — не место хранения токенов, а средство управления адресом

Криптокошелёк удобнее понимать как программу, которая помогает управлять ключами, адресами, сетями и подписями. Балансы токенов и состояние смарт-контрактов находятся в блокчейне, а не «в приложении». Из-за этого один и тот же адрес может отображаться в нескольких совместимых кошельках, если пользователь контролирует соответствующий ключ. Для DEX это важно: интерфейс получает публичный адрес и предлагает действия, но право подтвердить их остаётся у владельца ключа.

Перед работой с DeFi полезно отдельно изучить, как безопасно подключать кошелёк к DeFi-приложению. Само соединение ещё не равно переводу средств, но оно создаёт рабочую сессию, после которой сайт может запрашивать подписи и транзакции. Поэтому «Connect» не нужно бояться как автоматического списания, но и считать его началом безусловного доверия нельзя.

Интерфейс DEX и протокол — не одно и то же

Пользователь видит веб-страницу или приложение, но за ней могут находиться отдельные smart contracts, router, pools, quoting services и дополнительные компоненты. Один интерфейс способен маршрутизировать сделку через несколько источников ликвидности; другой может быть только оболочкой над существующим протоколом. Следовательно, проверка бренда сайта не отвечает на вопрос, какой именно contract address окажется получателем вызова.

Практический вывод простой: официальный домен нужно проверять до connection, а адреса и смысл транзакции — перед подписью. Для фишинговых копий особенно полезен отдельный алгоритм проверки настоящего сайта DEX. Даже если котировки выглядят правдоподобно, вредный интерфейс способен подготовить совсем другой calldata или попросить опасное разрешение.

Smart contract исполняет правило, а не «обещание сайта»

Когда кошелёк отправляет транзакцию на адрес контракта, сеть исполняет код этого контракта с указанными параметрами. Контракт не читает намерение пользователя в человеческом смысле: он получает данные вызова и действует по заложенной логике. Поэтому swap — это не абстрактная команда «обменяй мне токен», а конкретный вызов одной или нескольких функций, которые переводят активы и проверяют ограничения результата.

Если хочется глубже понять этот слой, полезен отдельный разбор что такое smart contract. Для DEX достаточно запомнить: пользователь доверяет не только интерфейсу, но и исполняемому коду, а подпись означает авторизацию конкретного действия. Ошибка в адресе контракта или вредный spender важнее логотипа и текста кнопки.

Liquidity pool — один из возможных контрагентских механизмов

В AMM-сценарии обмен идёт против ликвидности, размещённой в smart contract pool. Пользователь не ждёт конкретного продавца на другой стороне: контракт рассчитывает результат по состоянию пула и правилам протокола. Для практического workflow важно не выводить из этого ложный вывод, что «DEX всегда означает один пул». Router может выбрать несколько pools, а другие DEX-модели вообще используют order book, RFQ или intent-based исполнение.

Подробная экономика pool вынесена в материал что такое пул ликвидности. Здесь достаточно проверять три вещи: существует ли ликвидность именно по нужной паре и сети, достаточна ли она для вашего размера и соответствует ли route той задаче, которую вы собираетесь подписать.

Quote — это расчёт до транзакции, а не финальный on-chain результат

До подписи интерфейс обычно рассчитывает ожидаемый output по текущему состоянию рынка. Этот quote помогает понять порядок цифр, route и ограничения, но между расчётом и включением транзакции в блок состояние может измениться. Поэтому quote нужно читать как моментальный расчёт условий, а не как обещание получить ровно показанное число.

На этом этапе полезно смотреть minimum output и предупреждения интерфейса. Глубокая математика price impact и slippage относится к отдельным темам, однако операционно важно понимать различие: цена может ухудшиться из-за размера вашей сделки или потому, что рынок изменился до исполнения. Для первой категории есть отдельная статья про price impact.

Подпись и транзакция — тоже не одно и то же

Кошелёк может попросить либо подписать on-chain transaction, которая будет отправлена в сеть и потребует fee, либо подписать сообщение, которое само по себе не меняет состояние блокчейна. Но off-chain signature может авторизовать permit, order или intent, который позднее использует другой участник. Поэтому отсутствие gas не является доказательством безвредности.

Правильная привычка — определять тип действия до подтверждения: connection, message signature, token approval или state-changing transaction. Если смысл окна непонятен, полезно сначала свериться с материалом как понять, что подписывает криптокошелёк, а не подтверждать «потому что иначе сайт не пускает дальше».

Что подготовить перед первым DEX-swap: сеть, кошелёк, gas и токены

Сначала определите одну конкретную on-chain задачу

Новичок часто начинает с бренда DEX, хотя безопаснее начать со сценария: «обменять 300 USDC в сети Base на ETH и оставить результат на рабочем адресе». Такая формулировка сразу задаёт сеть, input, output, размер и место назначения. После этого проще понять, нужен ли bridge, какой native token требуется для комиссии и какие token contracts должны участвовать.

Если задача сформулирована как «хочу купить токен X где-нибудь на DEX», пользователь уже склонен подстраиваться под любой найденный интерфейс. Точная задача делает обратное: интерфейс должен соответствовать заранее проверенным условиям, а не условия меняться ради интерфейса.

Рабочий адрес должен иметь ограниченный blast radius

DeFi-операции создают больше подписей и контактов со smart contracts, чем холодное хранение. Поэтому полезно заранее отделить адрес для активной работы от резерва. Это не устраняет риск смарт-контракта, но ограничивает сумму, которую потенциально затронет ошибочный allowance или вредная подпись. Количественный лимит рабочего кошелька лучше абстрактного обещания «буду внимательнее».

Для первой операции размер рабочего баланса должен быть связан не с доступным капиталом, а с целью теста. Если нужно проверить маршрут на 100 USDC, нет причины держать на адресе весь долгосрочный портфель. После подтверждения процесса лимит можно пересмотреть, но только отдельно от решения о конкретном swap.

Сеть должна совпадать на всех уровнях

Совпадающий символ токена может встречаться в нескольких блокчейнах. Например, USDT на Ethereum, Tron, Solana или другой сети — это разные on-chain объекты и разные адресные пространства. DEX работает внутри конкретной поддерживаемой сети или через дополнительный cross-chain механизм. Если кошелёк переключён на Base, а пользователь ищет ERC-20 контракт из Ethereum mainnet, интерфейс может не видеть баланс или показать другой токен. Перед подключением зафиксируйте сеть, адрес контракта входного и выходного актива и нативную монету для комиссии.

Gas нельзя потратить полностью в swap

Типичная ошибка — обменять весь баланс нативной монеты или оставить на адресе только токены. На Ethereum-подобной сети gas оплачивается нативным активом; на Solana нужен SOL, в BNB Smart Chain — BNB. Approval может быть отдельной on-chain транзакцией и тоже потребовать комиссию. Поэтому расчёт максимальной суммы для swap должен оставлять резерв на approval, сам обмен и последующие действия. Если вы планируете сразу перевести полученный актив дальше, нужен запас и на этот перевод.

Контракт важнее тикера и логотипа

Название токена не уникально. Любой разработчик может создать актив с символом USDT, ETH, PEPE или любым похожим названием, если сеть это позволяет. Проверка должна начинаться с адреса контракта из официального источника проекта или другого надёжного первичного источника, а затем сверяться с тем, что показывает DEX. Не добавляйте токен только потому, что логотип совпадает и цена выглядит правдоподобно. Для новых и малоликвидных активов имеет смысл пройти полный алгоритм из статьи как проверить токен перед покупкой.

Официальный интерфейс нужно открывать не через рекламную копию

Фишинговый DEX может полностью копировать дизайн известного протокола и даже показывать реальные котировки, пока не наступит момент подписи. Самый надёжный путь — заранее сохранить официальный домен из первичного источника, использовать закладку и сверять домен перед чувствительной операцией. Рекламный результат в поиске, сообщение в Telegram и ссылка от «поддержки» не должны быть источником адреса интерфейса. Отдельная проверка домена и подписи разобрана в материале как проверить настоящий сайт DEX.

Chain ID и название сети лучше проверять как отдельные поля

Одинаковые адреса формата 0x могут существовать в нескольких EVM-сетях, а интерфейс кошелька способен быстро переключаться между ними. Это создаёт неприятную иллюзию: пользователь видит знакомый адрес и думает, что находится в правильной сети. Перед операцией полезно отдельно сверять network name, chain ID в кошельке и контракт токена именно этой сети. Совпадение адреса аккаунта не означает совпадение активов.

Если DEX предлагает автоматическое network switch, сначала прочитайте, на какую сеть он переключает кошелёк. Не подтверждайте добавление неизвестной RPC-конфигурации только потому, что сайт просит. Для популярных сетей разумнее использовать заранее проверенные настройки кошелька.

Токен с правильным символом может иметь неправильный contract address

Практически любой пользовательский интерфейс может отобразить символ и изображение токена. Эти метаданные удобны, но не являются уникальным идентификатором. Для неизвестного актива адрес контракта важнее названия. Перед DEX-покупкой особенно важно проверить не только входной токен, но и выходной: именно поддельный target token часто используется в схемах с похожими тикерами.

Развёрнутый pre-buy workflow уже собран в статье как проверить токен перед покупкой. Для текущей задачи минимум состоит из сети, contract address, способности токена нормально переводиться и продаваться, а также разумной ликвидности.

Перед первой подписью нужен запас времени, а не только gas

DEX не подходит для обучения в момент, когда цена резко движется и пользователь боится «опоздать». Спешка заставляет пропускать contract verification, повышать slippage, игнорировать wallet warnings и соглашаться на непонятные permits. Поэтому первый тест лучше делать в спокойной ситуации и небольшой суммой. Цель первого прохода — разобраться в состоянии системы, а не поймать оптимальную цену.

Если интерфейс меняет quote во время проверки, это нормально: рынок живой. Ненормально — менять собственные правила только потому, что quote стал хуже. У пользователя должен быть заранее задан предел, после которого сделка откладывается.

Как DEX превращает quote в on-chain swap: router, pool и вызов контракта

Выбор токенов запускает поиск исполнимого маршрута

После выбора input и output интерфейс или routing-сервис ищет способ получить целевой актив из доступной ликвидности. Прямой путь может использовать один pool, а более сложный — промежуточные токены или несколько источников. Пользователь видит итоговый quote, но для безопасности полезно хотя бы приблизительно понимать маршрут: какие активы и протоколы участвуют и не появляется ли неожиданная зависимость от bridge или малоизвестного контракта.

Чем сложнее route, тем важнее отличать удобство агрегатора от фактического исполнения. Агрегатор может лишь рассчитать и передать вызовы внешним протоколам. Это не обязательно плохо, но число зависимостей увеличивается, и «известный интерфейс» не превращает каждый внешний pool в одинаково безопасный.

Router не обязан владеть вашим токеном до сделки

Типичная схема ERC-20 swap устроена так, что пользователь выдаёт определённому spender право использовать input token, после чего router вызывает нужные контракты и направляет output на указанный адрес. Важный нюанс: право списания возникает из allowance или permit, а не из того, что токен заранее переведён на «счёт DEX». Поэтому spender address — одно из ключевых полей перед approval.

Это также объясняет, почему approval может успешно пройти, а swap — нет. Первая операция только меняет allowance; вторая использует это разрешение и пытается выполнить обмен. В истории блокчейна они являются разными событиями.

Minimum output превращает ожидание в ограничение исполнения

Пользователь обычно видит expected output и минимально допустимый output. Второе значение важнее с точки зрения контроля: если условия ухудшились сильнее разрешённого, транзакция должна откатиться вместо получения слишком плохого результата. Это не делает сделку бесплатной — вычисления уже могли потребовать network fee — но ограничивает экономический результат токенов.

Глубокий расчёт tolerance относится к следующей статье про swap. Здесь нужен только принцип: minimum output не должно быть случайным числом. Оно связано с тем, какое ухудшение пользователь готов принять между quote и исполнением.

Calldata описывает конкретное действие

On-chain transaction содержит адрес получателя-контракта и input data, кодирующие вызываемую функцию и параметры. Большинство кошельков не показывает calldata в удобном виде, поэтому интерфейс и simulation становятся переводчиками между низкоуровневым вызовом и человеческим описанием. Но именно calldata, а не текст кнопки, определяет то, что будет исполнено сетью.

Для обычного пользователя не требуется вручную декодировать каждый байт. Нужно проверять более высокий набор признаков: официальный интерфейс, ожидаемый contract/spender, сеть, токены, amount, permissions и wallet preview. Если любой слой неожиданен, транзакцию лучше не подписывать.

Пул хранит резервы, но output создаёт не «курс на сайте»

В AMM-маршруте фактический обмен меняет состояния smart contracts. Количество output зависит от резервов, fee logic и маршрута в момент исполнения. Поэтому число в интерфейсе — вычисление на основе текущего состояния, а не самостоятельный источник цены. Для небольших сделок в глубоком пуле различие может быть минимальным; для тонкой ликвидности сам размер операции заметно влияет на результат.

Эта часть механики подробно раскрывается в материале о liquidity pool. Для P0 №2 важнее уметь распознать, что swap проходит через реальную on-chain ликвидность, а не только видеть знакомую цену токена.

Native token и wrapped token могут участвовать по-разному

Нативный актив сети, например ETH, технически отличается от ERC-20 токена. Многие DEX-маршруты используют wrapped representation вроде WETH внутри контрактов, хотя интерфейс может скрывать wrap/unwrap как часть одного удобного действия. Это нормальная техническая деталь, если она соответствует официальной архитектуре и видна в simulation или событиях.

Проблема возникает, когда пользователь воспринимает любой wrapped asset как эквивалент оригинала независимо от сети и issuer. Если route неожиданно ведёт через стороннюю wrapped-версию, нужно остановиться и понять, откуда она берётся и сможет ли полученный актив свободно использоваться дальше.

Swap может быть atomic, но пользовательский маршрут — нет

В пределах одной транзакции несколько контрактных вызовов могут выполняться атомарно: либо весь набор действий завершается, либо состояние откатывается. Это снижает риск «первая внутренняя нога прошла, вторая нет» внутри правильно собранного вызова. Но весь пользовательский процесс может включать отдельный approval до swap, последующий bridge или перевод после него — эти операции уже не образуют одну атомарную транзакцию.

Поэтому безопасный workflow рассматривает каждую подпись отдельно. Успешный approval не гарантирует успешный swap, а успешный swap не гарантирует успешный cross-chain transfer.

Не путайте swap и bridge

Если output находится в той же сети, обычный DEX swap меняет актив внутри одного blockchain state. Если пользователь хочет получить токен в другой сети, появляется cross-chain слой: bridge, messaging protocol, lock/mint, burn/release или другой механизм. Это другой набор рисков и другое время финализации.

Общий выбор маршрута между convert, spot, DEX, bridge и P2P разобран в сравнении способов обмена криптовалюты. Для первого DEX-сеанса проще специально выбрать сценарий без bridge, чтобы не смешивать два независимых механизма.

Approval, Permit, Permit2 и подписи: какие права получает DEX

Увеличить

ERC-20 allowance — отдельное состояние токена

Стандарт ERC-20 предусматривает approve и allowance: владелец токена разрешает конкретному spender использовать до заданной суммы. Это состояние хранится on-chain и может пережить браузерную сессию, закрытие сайта и disconnect кошелька. Поэтому approval нужно воспринимать как самостоятельное право, а не как временную галочку интерфейса.

Для практической проверки полезно отдельно записывать token contract, spender address и allowance amount. Если spender неизвестен или сумма намного больше операции, сначала выясните причину. Базовое объяснение механики собрано в статье что такое approval в криптокошельке.

EIP-2612 permit переносит выдачу allowance в подписанное сообщение

Permit-подход позволяет авторизовать изменение allowance с помощью подписи, которую затем можно передать в контрактную транзакцию. Это улучшает UX и иногда сокращает число шагов, но меняет форму риска: пользователь может не увидеть отдельного on-chain approval, хотя подпись всё равно создаёт значимое право. В структуре permit обычно важны owner, spender, value, nonce и deadline.

Из-за этого правило «если нет gas, значит ничего важного не происходит» неверно. Off-chain signature может быть одноразовой авторизацией, ордером, permit или частью intent-схемы. Перед подписью нужно читать structured data и срок действия.

Permit2 — инфраструктурный слой, а не универсальное разрешение всему интернету

Permit2 используется некоторыми приложениями как единый механизм разрешений, который упрощает взаимодействие с токенами и позволяет задавать дополнительные параметры подписи. Но наличие известного Permit2-контракта в окне кошелька не означает, что любой подписываемый запрос безопасен: критичны token, spender, amount и expiration конкретного сообщения.

Отдельный разбор OneMagic что такое Permit2 полезен именно потому, что пользователь должен различать инфраструктурный контракт и приложение, которое получает полномочия через него.

Почему approval появляется до swap

ERC-20 токен нельзя списать из кошелька произвольно. Пользователь сначала разрешает определённому smart contract тратить токен в пределах заданного allowance. Поэтому первая работа с новым токеном часто включает отдельный approval, а уже потом swap. Это нормальный механизм, но именно здесь возникает один из главных рисков DeFi: если разрешение выдано вредному spender-адресу на большую сумму, этот контракт может получить техническую возможность перемещать разрешённые токены без новой подписи пользователя в рамках правил allowance.

Unlimited approval удобен, но расширяет ущерб при компрометации

Некоторые интерфейсы предлагают разрешить сумму намного больше текущей операции, чтобы последующие swaps не требовали нового approval. Пользователь экономит gas и клики, но оставляет долгоживущее право. Для известного протокола и рабочего кошелька это может быть осознанным компромиссом; для экспериментального DEX или редкого токена — часто неоправданным. Перед подтверждением смотрите spender и amount; одного названия приложения в кошельке недостаточно.

Подпись сообщения не всегда безобидна

Отсутствие gas не означает отсутствие риска. Современные схемы разрешений могут использовать off-chain подписи, которые затем исполняются контрактом. Permit2 и другие permit-механизмы уменьшают число on-chain approvals и улучшают UX, но пользователь всё равно должен понимать, кому, на какой токен, сумму и срок выдаётся право. Если кошелёк показывает непонятный structured message вместо обычного send, это повод прочитать детали, а не считать подпись безопасной только потому, что она бесплатна.

Disconnect и revoke решают разные задачи

Отключение сайта от кошелька обычно прекращает интерфейсную сессию и доступ к публичному адресу. Оно не обязано отменять уже записанный on-chain allowance. Revoke — отдельное действие, которое изменяет разрешение в блокчейне. После работы с малоизвестным приложением или после подозрительной подписи имеет смысл проверить активные approvals. Пошаговый разбор находится в статье как отозвать разрешения токенов, а смысл разных типов подписей — в материале как понять, что подписывает криптокошелёк.

Одноразовый approval и unlimited approval решают разные UX-задачи

Ограниченный allowance уменьшает максимально доступную spender сумму, но может потребовать нового approval для следующей сделки. Unlimited approval сокращает будущие транзакции и network costs, но расширяет потенциальный ущерб, если spender или связанный контракт окажется скомпрометирован. Универсально правильного значения нет; оно зависит от частоты использования, размера рабочего баланса и доверия к протоколу.

Для экспериментального токена и одноразового swap консервативный лимит обычно проще объяснить. Для часто используемого проверенного протокола пользователь может принять другой компромисс, но решение должно быть сознательным, а не результатом кнопки «Max» по умолчанию.

Revoke меняет on-chain право, disconnect — нет

После завершения операции браузер может показать кнопку Disconnect, но она относится к сессии приложения. Allowance остаётся в token contract, пока не будет изменён или пока permit не истечёт по своим условиям. Поэтому после тестовой работы с малоизвестным dApp правильная проверка — посмотреть активные разрешения и при необходимости выполнить revoke.

Пошаговый материал как отозвать разрешения токенов помогает не путать две разные процедуры. Сам revoke тоже является on-chain транзакцией и может требовать network fee.

Spender должен объясняться архитектурой маршрута

Иногда spender не совпадает с названием интерфейса, потому что протокол использует router или специализированный executor. Это допустимо только тогда, когда адрес можно подтвердить официальной документацией и он соответствует ожидаемому маршруту. Если интерфейс показывает один бренд, а wallet просит unlimited approval неизвестному контракту без объяснения, это достаточная причина остановиться.

Практическая безопасность строится не на запоминании всех адресов, а на проверяемой связи: официальный домен → документация/верификация → contract address → функция и лимит. Отсутствие этой цепочки делает подпись непрозрачной.

Как выполнить первый DEX-swap: пошаговый workflow без лишних подписей

До открытия интерфейса создайте pre-trade карточку

Для первого swap достаточно пяти полей: сеть, input token, output token, максимальная сумма и причина операции. Дополнительно запишите предел total loss относительно ожидаемого результата. Карточка нужна не для бюрократии, а чтобы интерфейс не заставлял вас принимать новые решения на ходу. Если неожиданно появляется bridge, другой token contract или неподходящая сеть, вы сразу видите отклонение от плана.

Такой подход особенно полезен при покупке нового токена: сначала проверка объекта, затем исполнение. Никогда наоборот. Вертикальная свеча или сообщение «осталось две минуты» не меняют безопасный порядок.

Первый проход лучше выполнять маленькой суммой и с обязательным sell-test

Небольшой buy проверяет только половину сценария. Для неизвестного токена важно убедиться, что он продаётся обратно и что contract logic не блокирует transfer или sell. Минимальный тест не доказывает, что крупная сделка исполнится так же хорошо, но способен выявить базовые проблемы до масштабирования.

Если маленький sell требует неожиданно высокой tolerance, выдаёт нестандартные предупреждения или не проходит при нормальных условиях, увеличивать сумму не следует. Сначала нужно понять причину.

Шаг 1. Зафиксируйте цель и лимит потерь

До открытия DEX запишите, что именно меняете: сеть, входной актив, сумму и желаемый выход. Для крупной сделки полезно заранее определить предел совокупного отклонения от внешнего ориентира. Это защищает от психологической ловушки: пользователь уже потратил время на подключение кошелька и начинает соглашаться на плохую котировку только чтобы «закончить процесс». Если quote не укладывается в ваш лимит, правильным результатом проверки может быть отказ от сделки.

Шаг 2. Откройте сохранённый официальный домен и подключите отдельный рабочий адрес

Для экспериментов с DeFi разумно не подключать кошелёк, на котором хранится весь долгосрочный капитал. Отдельный рабочий адрес ограничивает последствия ошибки разрешения и делает историю действий понятнее. Подключение само по себе обычно не перемещает средства, но после него сайт получает адрес и может предлагать подписи. Проверяйте сеть сразу после connection: многие ошибки начинаются с того, что интерфейс автоматически переключён не туда, где пользователь считает свой баланс.

Шаг 3. Выберите токены по контрактам и проверьте ликвидность

Для популярных активов интерфейс может иметь curated list, однако незнакомый токен лучше добавлять по подтверждённому адресу. Затем оцените пул: TVL/глубину, доступный route, price impact, реальный объём торгов и способность продать токен обратно. Один высокий TVL не исключает вредную логику токена, а красивый график не подтверждает ликвидность именно для вашей суммы. Для малоликвидного актива сначала моделируется маленький sell, и обязательно sell.

Шаг 4. Прочитайте quote как договор условий

Перед подписью должны быть понятны input, expected output, minimum output, fee, network cost, price impact и route. Если интерфейс показывает предупреждение о высоком impact, необычном токене или нестандартном route, не закрывайте его автоматически. Пользователь должен уметь своими словами объяснить, почему результат приемлем. Если единственное объяснение — «Telegram сказал срочно купить», сделку лучше остановить.

Шаг 5. Approval — затем swap — затем проверка TXID

После approval дождитесь его подтверждения, если он on-chain, и убедитесь, что кошелёк не предлагает неизвестные дополнительные действия. Затем подпишите swap и сохраните transaction hash. Не судите об успехе по анимации сайта: источник истины — блокчейн и состояние кошелька. Если баланс нового токена не отображается, проверьте события транзакции и правильный контракт. Материал как проверить транзакцию по TXID полезен именно после того, как операция уже отправлена.

Шаг 6. После теста решите, оставлять ли approval

Если это разовая работа с незнакомым приложением, после завершения можно проверить и уменьшить разрешения. Если протокол используется регулярно, каждый revoke/re-approve создаёт новые network costs, поэтому решение зависит от суммы риска и доверия к контракту. Главное — не забывать, что закрытая вкладка не является security-action. Разрешение существует в блокчейне до изменения или истечения, если схема предусматривает срок.

Не подтверждайте цепочку окон быстрее, чем успеваете назвать каждое действие

Некоторые интерфейсы последовательно показывают connect, approval, signature и swap. Пользователь быстро привыкает нажимать Confirm несколько раз подряд. Это опасная автоматизация поведения. Перед каждым окном полезно вслух или мысленно назвать действие: «подключаю адрес», «выдаю allowance 300 USDC», «подписываю permit до такого-то срока», «отправляю swap на такой-то contract».

Если действие нельзя объяснить короткой фразой, оно ещё не проверено. Скорость интерфейса не должна задавать скорость решения.

После broadcast перестаньте нажимать новые кнопки и дождитесь статуса

Когда swap уже отправлен, повторная отправка похожей транзакции может создать второй ордер, конфликт nonce или дополнительный расход. Сначала получите transaction hash и проверьте, pending ли операция, включена ли она в блок и не reverted ли. Только после диагностики решайте, требуется ли replacement, новая попытка или вообще ничего делать не нужно.

Проверка TXID позволяет отделить проблему блокчейна от проблемы отображения интерфейса. Если сеть уже зафиксировала success, повторять swap только потому, что сайт не обновился, опасно.

Жизненный цикл DEX-транзакции: pending, success, revert и диагностика ошибок

Broadcast создаёт TXID, но ещё не делает swap завершённым

После отправки подписанная транзакция распространяется по сети и получает transaction hash. Затем она ожидает включения в блок. На этом этапе интерфейс может показывать pending, а баланс ещё не измениться. Сам факт существования TXID доказывает, что транзакция была сформирована и передана, но не гарантирует успешного исполнения.

Практический источник истины — block explorer и состояние сети. Для чтения статуса полезен материал как проверить транзакцию по TXID.

Nonce задаёт порядок транзакций одного аккаунта

В EVM-сетях nonce последовательно нумерует транзакции аккаунта. Если предыдущая операция застряла, следующая может ожидать её. Это объясняет ситуации, когда новый swap имеет нормальную fee-настройку, но не подтверждается: очередь аккаунта заблокирована более ранней транзакцией. Проблему нельзя лечить случайной отправкой ещё пяти swaps.

Перед replacement или cancel нужно понимать, какую транзакцию и какой nonce вы заменяете. Иначе пользователь создаёт ещё более сложную очередь и теряет контроль над тем, какое действие исполнится первым.

Revert означает, что состояние откатилось, но вычисления уже были выполнены

Если условия контракта не выполнены — например minimum output уже недостижим — транзакция может revert. Токены обычно не должны остаться в промежуточном состоянии внутри атомарного swap, но network fee за использованные вычисления не возвращается полностью. Поэтому «failed» не равно «ничего не произошло»: экономически пользователь мог потерять gas.

Это одна из причин не повышать tolerance механически после каждой ошибки. Сначала нужно определить слой сбоя: liquidity, token behavior, allowance, gas, route или состояние сети.

Недостаточно нативной монеты

Интерфейс может позволить выбрать сумму, превышающую реально доступный после gas баланс. Особенно это заметно при обмене нативного ETH на токен: если поставить «max», кошелёк должен зарезервировать часть ETH на комиссию. У токенов ERC-20 проблема выглядит иначе — USDT есть, но ETH равен нулю, поэтому approval или swap не отправляется. Решение — пополнить нативный gas-токен, а не увеличивать slippage.

Slippage слишком низкий для текущего движения цены

Если котировка успела измениться сильнее заданного допуска, контракт может отменить сделку. Пользователь теряет network cost за failed transaction, но не получает токены по неприемлемой цене. Повышать slippage имеет смысл только после понимания причины движения. Если рынок волатилен, умеренное изменение допуска может помочь. Если токен берёт огромный sell tax или пул почти пуст, высокий slippage лишь разрешит плохое исполнение.

Токен имеет нестандартную механику

Fee-on-transfer, rebasing, reflection и другие нестандартные токены могут конфликтовать с конкретным router. Некоторые интерфейсы прямо предупреждают, что определённые типы не поддерживаются. Кроме технического fail, это сигнал пересмотреть сам актив: нестандартная механика может менять фактический получаемый объём и усложнять продажу. Не надо бесконечно увеличивать slippage, пока транзакция «когда-нибудь не пройдёт». Сначала разберите контракт и документацию.

У токена есть honeypot или ограничение продажи

Самая опасная версия проблемы — купить можно, продать нельзя или можно только с огромной комиссией. Такой токен может быть специально создан как ловушка. Если маленький sell-маршрут не строится, контракт содержит необычные ограничения или ликвидность контролируется одним адресом, попытка «подобрать настройки» опасна. Факт успешной покупки не доказывает возможность выхода. Перед покупкой незнакомого актива sellability должна проверяться заранее.

Deadline или route устарел

Quote имеет срок жизни. При медленном подтверждении сети или длительной паузе между просмотром и подписью маршрут может стать неактуальным. Интерфейс либо перестроит его, либо транзакция revert. В такой ситуации лучше обновить quote и заново проверить условия. Увеличение deadline повышает шанс технического исполнения, но одновременно разрешает более долгое окно движения рынка; это компромисс, а не универсальное лечение.

Approval success и swap success проверяются отдельно

Если пользователь видит успешную transaction в истории, но не получил target token, первым делом нужно определить тип вызова. Успешный approval только установил allowance и не обязан менять баланс. В таком случае повторный approval не нужен; нужно вернуться к интерфейсу, сформировать swap и отдельно подтвердить его.

Это особенно важный навык для новичка: имя сайта в истории кошелька не сообщает, что именно произошло. Смотрите function, events и balance changes.

Токен может быть получен, но не отображаться в интерфейсе кошелька

Wallet UI ведёт собственный список известных активов и может скрыть редкий токен. Если TXID успешен и block explorer показывает balance или Transfer event на ваш адрес, проблема может быть только в отображении. Тогда нужно добавить правильный token contract, а не повторять покупку.

Обратная ситуация тоже возможна: сайт рисует «success», но в блокчейне операция failed. Поэтому проверка должна идти от on-chain фактов к интерфейсу, а не наоборот.

Слишком широкое увеличение slippage может превратить техническую проблему в экономический ущерб

Если swap не проходит, некоторые пользователи сразу увеличивают tolerance до очень большого значения. Это может помочь только в ограниченном наборе причин, но одновременно расширяет допустимый диапазон плохого исполнения и делает сделку привлекательнее для adversarial execution. Нестандартный token fee, малая ликвидность или honeypot не становятся безопасными от высокого slippage.

Глубокий разбор этой метрики будет в следующем P0, а здесь действует операционное правило: сначала диагностировать причину, затем менять параметр. Для терминологии можно использовать отдельный материал о slippage.

Безопасность DEX-сеанса: рабочий кошелёк, simulation и действия после подозрительной подписи

Безопасность начинается до открытия dApp

Если browser profile заражён расширением, seed хранится в облачном документе или пользователь привык подтверждать blind signing, никакой рейтинг DEX не компенсирует слабую базу. Рабочий DeFi-процесс должен начинаться с защищённого устройства, актуального кошелька, отдельного адреса и запрета на передачу seed/private key любому сайту или «поддержке».

Базовая гигиена собрана в материале как защитить криптокошелёк. Для DEX к ней добавляются contract permissions и проверка каждой подписи.

Cold storage и active DeFi wallet решают противоположные задачи

Кошелёк для долгосрочного хранения должен минимизировать количество подписей и контактов с dApps. Рабочий DeFi-адрес, наоборот, регулярно взаимодействует с контрактами. Смешивание этих ролей означает, что одна фишинговая подпись потенциально касается всего капитала. Поэтому крупные держатели часто разделяют резервный адрес и активный адрес с ограниченной суммой. Это не требует сложной инфраструктуры: даже два логически разделённых аккаунта уже создают дополнительный барьер.

Лимит рабочего баланса — простой количественный контроль риска

Определите максимальную сумму, потеря которой не разрушит долгосрочный портфель, и не превышайте её на экспериментальном адресе. Например, если для недели swaps нужно 2 000 USDC, нет практической причины держать там 50 000 USDC и все долгосрочные ETH. После завершения цикла прибыль или остаток можно переводить на резервный адрес. Это добавляет network costs, поэтому частота вывода выбирается экономически, но сама идея делает риск измеримым.

Аппаратная подпись помогает только если человек читает, что подписывает

Hardware wallet защищает приватный ключ от извлечения обычным веб-сайтом, но не способен остановить владельца, который сам подтверждает вредную транзакцию. Если экран устройства показывает неизвестный contract call, blind signing или непонятный spender, физическая кнопка не превращает действие в безопасное. Аппаратный кошелёк снижает риск кражи ключа, но социальная инженерия и malicious approval остаются актуальными.

Адресная книга и whitelist уменьшают ошибки после swap

После DEX пользователь часто отправляет полученный актив на другой кошелёк или биржу. В этот момент появляется address poisoning и обычная ошибка копирования. Сохранённые адреса, проверка первых и последних символов, тестовый transfer и подтверждение сети предотвращают потерю уже после успешного swap. Безопасность маршрута заканчивается не на зелёной галочке DEX, а после того, как актив оказался в плановом месте хранения.

Компрометацию сайта и компрометацию seed нужно лечить по-разному

Если вы просто открыли фишинговый сайт, но ничего не подписали, достаточно закрыть его и проверить устройство. Если подписали вредный allowance — нужен revoke и контроль токенов. Если раскрыли seed/private key — адрес считается полностью скомпрометированным и средства переводятся на новый seed. Правильная классификация инцидента предотвращает две крайности: игнорирование реальной угрозы и бессмысленное создание нового кошелька после безобидного connect.

Wallet simulation нужно читать как независимую проверку намерения

Если кошелёк умеет прогнозировать изменения balance, это дополнительный канал проверки. Например, ожидаемый swap должен показывать уменьшение input token и получение output token, а не передачу всего баланса третьему адресу. Несоответствие между DEX quote и wallet simulation важнее текста на странице: подпись нужно остановить.

Но simulation не является аудитом контракта и не гарантирует будущее поведение токена. Это снимок конкретного вызова при конкретном состоянии.

Интерфейс DEX и окно кошелька показывают разные части операции

Страница DEX обычно удобнее объясняет ожидаемый курс, route, fee, minimum output и price impact. Кошелёк, напротив, ближе к фактическому действию: он показывает сеть, адрес контракта, ожидаемые изменения баланса, permission или предупреждение симуляции — если конкретный кошелёк поддерживает такие функции. Пользователь должен сопоставить оба слоя. Если DEX обещает swap A→B, а wallet preview показывает approval неизвестному spender или transfer другого токена, подпись нужно остановить и выяснить расхождение.

Simulation — сильный сигнал, но не гарантия безопасности

Современные кошельки могут симулировать транзакцию и показывать предполагаемое изменение активов. Это помогает заметить очевидную кражу или неожиданное списание до broadcast. Но симуляция оценивает конкретное состояние и конкретную транзакцию; она не доказывает, что контракт не обновится позже, токен не изменит правила или market conditions останутся прежними. Поэтому зелёный preview не заменяет проверку домена, контрактов и экономических параметров. Он является последним контрольным слоем, а не единственным механизмом доверия.

Предупреждение кошелька нельзя лечить механическим отключением защиты

Если wallet показывает подозрительный spender, unlimited approval, simulation failure или неизвестное действие, плохая реакция — искать кнопку «всё равно продолжить», пока транзакция не отправится. Сначала определите, какое право или call требуется протоколу и совпадает ли оно с официальной документацией. Для permissionless токена failure может быть сигналом о sell restriction или нестандартной логике. Для фишингового сайта — попыткой получить доступ к активам. Отключение предупреждений убирает информацию, но не устраняет причину риска.

Подписание сообщения тоже требует смысловой проверки

Не каждая wallet signature отправляет on-chain транзакцию и gas. Подпись может использоваться для входа, permit, intent или авторизации исполнения. Именно поэтому фраза «это же бесплатная подпись» опасна: отсутствие gas не означает отсутствие последствий. Перед подтверждением смотрите домен, адрес/верификацию приложения, текст или структурированные поля сообщения, срок действия и объём разрешения. Если смысл невозможно объяснить одной фразой — например «разрешаю этому spender потратить до 500 USDC до такой-то даты» — подпись разумнее отложить.

Проверка smart contract полезна и после подтверждения домена

Официальный сайт снижает риск фишинговой копии, но не отвечает на все вопросы о коде и полномочиях. Для неизвестного токена или малоизвестного протокола полезно проверить верификацию контракта, proxy/upgradability, owner/admin roles и очевидные ограничения transfer. Не каждый пользователь должен читать Solidity, но базовые признаки помогают заметить несоответствие.

Практический чек-лист доступен в статье как проверить smart contract токена.

Инцидент нужно классифицировать по уровню доступа

Открытый фишинговый сайт, подключённый адрес, подписанный approval и раскрытая seed-фраза — четыре разных уровня проблемы. Если ничего не подписано, on-chain право обычно не создано. Если выдан allowance, нужен revoke. Если подписана вредная state-changing transaction, нужно анализировать её результат. Если раскрыт private key или seed, сам адрес больше нельзя считать надёжным.

Правильная классификация экономит время: не нужно создавать новый seed после каждого connect, но нельзя ограничиваться disconnect после компрометации ключа.

Не продолжайте цепочку «для отмены подпишите ещё раз»

Мошеннический интерфейс часто использует психологическое давление: первая подпись якобы «не прошла», затем предлагается «cancel», «verify» или «synchronize». Каждая следующая подпись может расширять ущерб. Если смысл действия неясен, остановитесь, отключите сайт и проверьте on-chain approvals с чистого интерфейса. Не вводите seed ни в один сервис «отмены».

Если выдан approval, уменьшите или отзовите его

При подозрительном spender-адресе on-chain revoke имеет приоритет над косметическим disconnect. Сначала определите сеть и токен, затем allowance. Учитывайте, что revoke тоже требует gas. Если злоумышленник уже пытается списать токены, время имеет значение, однако суета не должна приводить к подписанию новых неизвестных транзакций. Для крупного баланса может быть рациональнее переместить безопасные активы на новый адрес, если приватный ключ не скомпрометирован.

Если раскрыт seed или приватный ключ, revoke недостаточен

Seed даёт контроль над приватными ключами. Злоумышленник может подписывать новые транзакции сам, поэтому отмена одного approval не решает проблему. На чистом устройстве создаётся новый кошелёк с новой seed-фразой и переводятся оставшиеся активы; старый адрес больше не считается безопасным для хранения. Нельзя «сменить seed» у уже скомпрометированного адреса через настройки приложения.

После инцидента сохраните on-chain след

Скопируйте TXID подозрительной операции, адрес spender/контракта, токен, время, домен сайта и скрин окна подписи, если он остался. Это помогает понять механизм ущерба и не повторить ошибку. Если средства уже ушли, такие данные пригодятся при обращении к бирже, эмитенту управляемого стейблкоина или правоохранительным органам. Удаление истории браузера до фиксации деталей ухудшает собственную диагностику.

После неизвестной подписи сначала сохраните доказательства, потом очищайте интерфейс

Паническая реакция часто начинается с удаления расширения и истории браузера. Это может уничтожить домен, screenshot, transaction hash и structured message, которые помогают понять, что именно было подписано. Сначала зафиксируйте данные, затем принимайте меры по revoke или миграции средств.

Если неизвестная транзакция уже отправлена, используйте отдельный алгоритм что делать после неизвестной подписи или транзакции.

После DEX-swap: TXID, фактический результат, журнал и дальнейший маршрут

Проверяйте не только status, но и фактические balance changes

Успешный status означает, что транзакция не reverted, но пользователю всё равно нужно проверить, сколько input token ушло, сколько output получено, какая network fee списана и не было ли дополнительных transfer events. Для сложного маршрута это важнее простой строки «success». Финальный экономический результат может отличаться от первоначального quote.

Сохраните TXID сразу после операции. Он связывает пользовательский журнал с объективным on-chain событием и позволяет восстановить детали даже если интерфейс DEX изменится.

Результат нужно сверять с исходной задачей, а не с эмоцией после сделки

Если план был «обменять 300 USDC на ETH в Base и оставить результат на рабочем адресе», итоговая проверка должна ответить именно на это: правильная ли сеть, правильный ли token, ожидаемый ли диапазон output, достаточен ли остаток gas и не появились ли лишние approvals. Рост цены через десять минут не говорит ничего о качестве исполнения.

Такой post-trade review превращает разовую операцию в воспроизводимый процесс и помогает заметить систематические ошибки раньше, чем они масштабируются.

Сохраняйте TXID вместе с назначением операции

Через несколько месяцев один адрес может содержать сотни contract calls. TXID доказывает техническое событие, но не объясняет, зачем оно было сделано. Полезно хранить короткую запись: «обмен 1 000 USDC на ETH для долгосрочного портфеля», «тест sell токена X», «revoke после работы с dApp». Это помогает финансовому учёту и расследованию ошибок, не раскрывая seed или приватные данные.

Approval не является покупкой токена, а failed swap — не нулевая операция

В истории кошелька approval может выглядеть как самостоятельная транзакция с gas, хотя актив не менялся. Failed swap тоже может списать gas. Если бухгалтерский или личный журнал учитывает только успешные transfers токенов, он будет недооценивать расходы. Отдельно фиксируйте network fees, потому что серия отменённых attempts иногда заметно меняет фактическую стоимость торговой стратегии.

Налоговый смысл swap зависит от юрисдикции

On-chain обмен одного криптоактива на другой технически не использует фиат, но это не означает, что он автоматически нейтрален для налогового учёта. Правила отличаются по стране и могут меняться. Поэтому храните дату, входной и выходной актив, количество, стоимость на момент операции и комиссии, а налоговую квалификацию проверяйте по актуальным нормам своей юрисдикции. DEX не выдаёт универсальную справку, которая заменяет этот учёт.

Собственный журнал помогает оценивать качество маршрутов

Если записывать expected output, фактический output, gas и total loss relative to reference, через десять сделок видно, где вы систематически переплачиваете. Возможно, один агрегатор лучше для крупных swaps, а прямой пул — для маленьких. Возможно, Ethereum mainnet экономически не подходит вашим суммам, а L2 даёт лучше результат. Это уже не субъективное впечатление, а данные собственной истории операций.

После swap не спешите переводить актив в другую сеть

Пользователь часто объединяет покупку и cross-chain transfer в один эмоциональный процесс: «купил — теперь срочно отправлю туда». Это создаёт второй независимый набор рисков сразу после первого. Лучше сначала убедиться, что swap полностью завершён, output token корректно отображается и contract address подтверждён, а уже затем выбирать bridge или биржевой withdrawal route.

Если действительно нужен перенос сети, используйте отдельную инструкцию как переводить актив между сетями без путаницы bridge и swap.

Историю approvals стоит включать в журнал вместе со swaps

Журнал только успешных обменов не показывает, какие долгоживущие права остаются на адресе. Для активного DeFi-кошелька полезно периодически фиксировать новые spenders и причины, по которым allowance оставлен. Это делает ежемесячный permission review быстрой проверкой, а не расследованием сотен неизвестных контрактов.

Если протокол больше не используется, revoke можно рассматривать как закрытие операционного хвоста сделки. Но оно тоже требует network fee, поэтому частота review должна быть разумной.

Фактическая стоимость операции включает failed attempts

Если до успешного swap было два failed calls и отдельный approval, экономическая себестоимость выше, чем fee последней транзакции. Пользовательский журнал должен учитывать network costs всех попыток, иначе сравнение маршрутов будет систематически искажено. Особенно это важно на дорогих сетях и при маленьких суммах.

В следующей статье блока будет детально разобрана экономика swap — fee, slippage и фактический output. Здесь достаточно сохранить данные, из которых такой расчёт можно восстановить.

Практические сценарии: как понять, что DEX-workflow выбран правильно

Сценарий 1. Популярный токен в той же сети

У пользователя уже есть USDC и gas на проверенном рабочем адресе, а нужный output token имеет подтверждённый contract и глубокую ликвидность. Это лучший учебный сценарий: нет bridge, неизвестных токенов и необходимости разбираться с несколькими сетями одновременно. Основная задача — правильно пройти connection, approval/permit, swap, TXID и post-trade review.

Если первый DEX-тест выбирается специально для обучения, простота маршрута — преимущество. Сложность можно добавлять после того, как базовый lifecycle понятен.

Сценарий 2. Новый токен с красивым графиком и тонкой ликвидностью

Здесь проблема уже не только в DEX-workflow. Нужно подтвердить contract, transfer/sell behavior, holder concentration, liquidity и отсутствие очевидных ловушек. Маленький buy без sell-test недостаточен. Даже идеально выполненная транзакция может закончиться владением активом, который невозможно продать нормальным способом.

Поэтому безопасность DEX не заменяет проверку токена. Если объект сделки неизвестен, этап due diligence должен быть завершён до подключения кошелька к торговому интерфейсу.

Сценарий 3. Swap требует bridge

Если input token находится в Ethereum, а output нужен в другой сети, пользователь может увидеть интерфейс, обещающий «один клик». За этим удобством могут скрываться swap, bridge, relayer и второй swap. Такой маршрут нельзя оценивать как обычную одну DEX-транзакцию. Сначала выясните, какие промежуточные активы и протоколы участвуют и где возникает финальность.

Для первого опыта лучше разделить действия и проверить каждый этап отдельно. Atomic UX не всегда означает атомарность всего cross-chain процесса.

Сценарий 4. Интерфейс просит unlimited approval перед маленькой сделкой

Сам по себе unlimited approval не доказывает мошенничество: это распространённый UX-компромисс. Но для разового теста на небольшую сумму пользователь вправе выбрать ограниченное разрешение, если кошелёк и протокол это поддерживают. Если интерфейс не объясняет spender и не позволяет понять, зачем нужен большой allowance, операция не должна продолжаться автоматически.

Критерий здесь не «все unlimited approvals плохие», а соответствие полномочий цели и размеру рабочего баланса.

Сценарий 5. Swap failed, сайт предлагает увеличить slippage до 50%

Такой совет сам по себе не объясняет причину. Для нормального ликвидного актива столь экстремальное значение может означать token fee, очень тонкую ликвидность, нестандартную логику или вредный актив. Прежде чем менять tolerance, проверьте allowance, network, gas, pool, token contract и способность продать актив.

Высокий slippage — это не «ремонт» транзакции, а разрешение на более широкий диапазон исполнения. Он не должен использоваться как универсальная кнопка устранения ошибок.

Сценарий 6. В кошельке появилась бесплатная подпись вместо on-chain транзакции

Отсутствие network fee может означать login message, Permit, Permit2 или intent. Проверьте structured fields, domain, spender, token, amount и deadline. Если вы ожидаете обычный swap, а подпись выглядит как передача широких прав неизвестному адресу, остановитесь. Нельзя считать message signature автоматически безопаснее transaction.

Смысл подписи важнее наличия gas. Это один из базовых принципов современной DeFi-гигиены.

Сценарий 7. TXID success, но токена не видно

Не повторяйте покупку. Сначала откройте explorer, проверьте Transfer events и balance target token на своём адресе. Если актив получен, добавьте его в wallet по правильному contract address или проверьте скрытые токены. Если TXID оказался только approval, завершите отдельный swap после новой проверки quote.

Такой порядок предотвращает двойные покупки и помогает понимать различие между состоянием блокчейна и пользовательским интерфейсом.

Сценарий 8. Нужно решить, оставлять ли allowance после сделки

Если это был разовый эксперимент с небольшим dApp, revoke сокращает долгоживущий permission risk. Если протокол используется ежедневно, постоянные revoke/re-approve увеличивают network costs. Решение должно учитывать размер остатка на рабочем адресе, доверие к контракту и частоту использования. Главное — allowance не должен оставаться просто потому, что пользователь забыл о нём.

Хорошая операционная привычка — review permissions по расписанию и после каждого необычного инцидента.

Сначала ответьте на вопрос, зачем вам DEX. Если нужен on-chain токен, обмен без кастодиального депозита или доступ к конкретной ликвидности, инструмент может быть оправдан. Если задача — просто купить первую криптовалюту за банковские деньги, DEX часто добавляет лишний уровень сложности. Выбор должен следовать из пользовательской задачи, а не из идеологии «децентрализация всегда лучше».

Дальше зафиксируйте сеть и точные контракты. Откройте официальный интерфейс, подключите рабочий кошелёк, оставьте gas, проверьте ликвидность и возможность обратной продажи. Прочитайте quote: ожидаемый и минимальный output, fees, price impact, route. Отдельно изучите approval/permit. Для неизвестного токена — маленький buy и маленький sell. Для крупной суммы — сравнение нескольких маршрутов и расчёт итоговой цены.

После сделки сохраните TXID и фактические числа. Если что-то не совпало, диагностируйте слой проблемы: сеть, token contract, allowance, route, liquidity, slippage, gas или интерфейс. Не повышайте slippage и не подписывайте новые действия наугад. Если выдали подозрительный approval — revoke; если раскрыли seed — новый кошелёк. Эта последовательность делает DEX предсказуемым рабочим инструментом вместо набора кнопок, каждая из которых может означать другое действие.

Как провести контрольный review перед увеличением суммы

Успешный тест на маленькой сумме — это только проверка базовой работоспособности маршрута. Перед масштабированием нужно сравнить план и фактический результат: совпали ли token contracts, кто был spender, какой allowance остался, сколько network fee ушло на approval и swap, какой output реально получен, потребовались ли повторные попытки и не возникло ли предупреждений, которые пользователь просто проигнорировал. Если хотя бы один этап остаётся непонятным, увеличение суммы превращает неизвестность в более крупный риск.

Следующий вопрос — что изменится при большем размере. Даже если технология работает одинаково, экономические условия могут стать другими: price impact растёт относительно доступной ликвидности, router способен выбрать другой путь, а maximum loss при ошибочной permission становится больше. Поэтому масштабирование нельзя трактовать как «тот же тест, только в десять раз больше». Оно требует нового quote и повторной проверки всех лимитов непосредственно перед подписью.

Отдельно оцените операционный остаток на адресе. Если после swap на рабочем кошельке остаются токены, которые не нужны для следующих действий, их наличие увеличивает потенциальный ущерб от старого allowance или будущей вредной подписи. Смысл рабочего кошелька именно в ограничении blast radius: держать там столько, сколько требуется для ближайшего DeFi-цикла, а не постепенно превращать экспериментальный адрес в основное хранилище.

Наконец, зафиксируйте критерий отказа от повторной сделки. Например: неизвестный новый spender, отсутствие понятного wallet preview, необычный token warning, необходимость резко расширить tolerance, неподтверждённый contract address или неожиданный cross-chain route. Такой stop-list важнее субъективного ощущения «первый раз всё прошло нормально». Хороший DEX-workflow не только объясняет, как выполнить swap, но и заранее определяет условия, при которых пользователь ничего не подписывает.

Итог. DEX становится понятным, когда пользователь перестаёт воспринимать его как одну кнопку Swap и видит последовательность независимых состояний: сеть и token contracts → wallet connection → quote → allowance или permit → transaction signature → blockchain execution → TXID → post-trade verification → permission review. Именно эта последовательность отвечает на запрос «что такое DEX в криптовалюте» практичнее, чем список брендов. Она позволяет использовать любой совместимый интерфейс осознанно и вовремя остановиться, если следующий шаг перестал соответствовать исходной задаче.