ERC-20 против SPL и Jetton: почему «один и тот же» токен работает по-разному в каждой сети

ERC-20, SPL и Jetton дают три разных ответа на один вопрос: где хранится число, фиксирующее ваш баланс. Ethereum держит балансы всех держателей в одном общем контракте токена, Solana — в отдельном токен-аккаунте на каждого держателя, TON — в отдельном контракте на каждого держателя. Именно это различие объясняет аппрувы, комиссии и большинство сценариев сбоев, а также то, почему один и тот же тикер — это разные токены в разных сетях. Кошельки, охватывающие все три модели, например WATS, который поддерживает EVM, Solana и TON, но не Bitcoin нативно, вынуждены говорить на всех трёх грамматиках.

Что на самом деле такое «стандарт токена»

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

ERC-20, SPL и Jetton — это не три диалекта одного языка. Они дают три разных ответа на один вопрос: где живёт число, которое утверждает, что «вам принадлежит 500 токенов»? Ethereum держит его в одном общем контракте, Solana — в отдельном аккаунте на каждого держателя, TON — в отдельном контракте на каждого держателя. Эти модели хранения объясняют почти все практические странности и надстраиваются над архитектурой, которую мы сравнивали в материале EVM, Solana и TON.

ERC-20 в Ethereum: один контракт хранит балансы всех

Токен ERC-20 — это один смарт-контракт по одному адресу, внутри которого лежит реестр, сопоставляющий адреса и числа. Вы не «держите» токен: контракт хранит запись о том, что вашему адресу причитается некоторая сумма.

Перевод — это вызов к контракту токена, который уменьшает одну строку и увеличивает другую. Ваш адрес не требует никакой подготовки: вы можете получить любой ERC-20 на адрес, который никогда не соприкасался с этим токеном.

Отсюда и ситуация, когда вы владеете состоянием в токене и всё равно не можете его сдвинуть: вызов контракта стоит газа, который по умолчанию оплачивается нативным токеном сети. По состоянию на 2026 год это умолчание не абсолютно: paymaster в рамках ERC-4337 позволяет платить не владельцу аккаунта, а EIP-7702 позволяет третьей стороне отправить и оплатить транзакцию типа 4, задающую делегирование аккаунта, хотя дальнейшее спонсирование зависит от того, что реализует делегированный код. Сеть по-прежнему берёт плату за работу — меняется только плательщик.

SPL в Solana: токен-аккаунты, рента и mint

Solana разделяет задачу надвое. Mint-аккаунт описывает токен: эмиссию, число знаков после запятой и то, какая инстанция вправе чеканить или замораживать. Балансы живут в отдельных токен-аккаунтах. Данными такого аккаунта владеет Token Program, а сам аккаунт указывает держателя как своего владельца и распорядителя средств; ограничения «один аккаунт на mint» нет.

Поэтому кошельки стандартизировались на associated token account, который выводится из адреса вашего кошелька, mint и program id токена. Он должен существовать и быть профинансирован: rent-exemption блокирует в аккаунте небольшую возвратную сумму SOL, чтобы тот продолжал жить.

Получение нового SPL-токена, таким образом, является ончейн-событием, хотя большинство переводов включают создание аккаунта в ту же транзакцию. По состоянию на 2026 год Token-2022 добавляет опциональные комиссии за перевод, конфиденциальные балансы и transfer hooks; поскольку его program id участвует в выводе адреса, его mint'ы дают другой associated token account, чем у прежнего стандарта.

Jetton в TON: у каждого держателя свой контракт

TON доводит разделение до предела. У джеттона есть мастер-контракт с метаданными и эмиссией, а каждый держатель получает собственный контракт jetton-кошелька, хранящий только его баланс по этому одному токену.

Переводы — это асинхронные сообщения, а не вызовы к общему реестру: контракт вашего jetton-кошелька отправляет сообщение контракту получателя, и тот зачисляет баланс. Поскольку TON шардирован, всё это разрешается за несколько последовательных блоков, а не одним атомарным шагом.

Каждое сообщение должно нести достаточно TON для вычислений, которые оно запускает дальше по цепочке, включая деплой jetton-кошелька получателя, если тот ещё не создан; приложите слишком мало — и сообщение может отскочить или зависнуть. Такая ориентация (TEP-74, по состоянию на 2026 год) позволяет TON масштабироваться горизонтально и подводит наивный код перевода, написанный под EVM.

Аппрувы, комиссии и сценарии сбоев: где три модели расходятся

Резче всего расходятся аппрувы. В ERC-20 работает паттерн allowance: вы выдаёте контракту разрешение перемещать до определённой суммы ваших токенов, и оно действует, пока его не отозвали, — поэтому одна неосторожная подпись способна опустошить кошелёк спустя месяцы; см. объяснение аппрувов токенов и permit и как отозвать аппрувы токенов.

Solana не является противоядием: SPL-approve назначает делегата на ваш токен-аккаунт, и он переживает транзакцию, а setAuthority может и вовсе переназначить аккаунт — оба вектора известны дренерам. Транзакция в Solana перечисляет все аккаунты, которых коснётся, но это ограничивает лишь подписанную транзакцию, а не постоянные разрешения. В TON allowance в стиле ERC-20 отсутствует.

Комиссии тоже расходятся: EVM тарифицирует газ за единицу вычислений, Solana — фиксированная базовая комиссия за подпись плюс опциональная приоритетная, TON — за сообщение. Расходятся и сценарии сбоев: в EVM токены застревают в контракте, который не умеет с ними обращаться; в Solana не хватает токен-аккаунта; в TON к сообщению приложено слишком мало ценности.

Почему один и тот же тикер — это разные токены в разных сетях

Два актива с общим тикером технически не имеют между собой ничего общего. USDC в Ethereum — это адрес контракта, в Solana — адрес mint; в TON нативно выпущенный стейблкоин вроде USDT стоит за собственным jetton-мастером. Каждый из них — отдельный ончейн-объект со своей эмиссией, а мостовая версия — это уже совсем другое требование.

Отправка между экосистемами — EVM-токена на адрес Solana или TON — обычно невосстановима; в материале отправил крипту не в ту сеть: как вернуть разобрано, что вообще можно спасти. Переводы EVM → EVM часто прощают ошибку: внешне управляемый аккаунт, в том числе делегированный по EIP-7702, контролируется тем же ключом по идентичному адресу в любой сети, а смарт-аккаунт в стиле ERC-4337, не задеплоенный в сети назначения, обычно можно развернуть там с идентичной фабрикой и init-кодом. Подсказку дают форматы адресов, о них — в статье форматы криптоадресов простыми словами; а перемещается ли единая каноническая эмиссия или чеканится новое требование — в этом и состоит разница между омничейн-токенами и обёрнутыми либо мостовыми.

Что это значит для вашего кошелька (и как с этим работает WATS)

Мультичейн-кошелёк обязан говорить на всех трёх грамматиках, и вы не должны замечать разницы — но комиссии всё равно просачиваются наружу, потому что каждая сеть ждёт свой нативный газовый токен. По состоянию на 2026 год это ожидание обсуждаемо, если кошелёк изначально так спроектирован.

Именно так и устроен WATS Hot Wallet: любое действие — переводы, свопы, стейкинг — оплачивается одним токеном, ATS, вместо нативного газа сети: через paymaster ERC-4337 в EVM и эквивалентный механизм плательщика комиссии и релеера в Solana и TON, поскольку ERC-4337 работает только в EVM. ATS — это LayerZero OFT, поэтому один баланс работает в EVM, Solana и TON. Это не меняет того, сколько берёт сеть: комиссия в ATS следует за актуальной стоимостью сети — меняется лишь то, каким токеном эта стоимость оплачивается. Собранный ATS сжигается: со 100 миллионов в сторону нижней границы в 30 миллионов. Кошелёк остаётся некастодиальным: ключи держите вы, а WATS никогда не хранит ключ. WATS — первый и единственный кошелёк, который сочетает ERC-4337 и OFT-комиссии в одном токене, взимаемые вместо нативного газа, с таким сжиганием.