Крупные DeFi-взломы редко ломают «код» — чаще ломают процессы, права и контроль над ключами

За ретроспективой почти всегда виден один и тот же набор ошибок: лишние права у админ-кошелька, слабая проверка оракулов, баг в логике мостов и слишком сложная схема апгрейда. Атакующему не нужен «взлом всего протокола» — достаточно найти точку, где контракт доверяет внешнему входу без достаточной валидации.

Повторяющиеся паттерны уязвимостей:
• bridge-мосты и кроссчейн-обёртки
• оракулы с низкой устойчивостью к манипуляции
• reentrancy и ошибки в расчёте долей
• неограниченные mint/burn-функции
• компрометация multisig или seed-фраз

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

Для команд и аудиторов полезен простой чек-лист: минимизировать привилегии, разделять hot- и cold-доступ, ставить лимиты на критические операции, тестировать негативные сценарии, а не только happy path, и держать мониторинг аномалий по on-chain-событиям. В DeFi чаще всего спасает не одна «супер-проверка», а набор скучных ограничений.

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

5 сигналов, по которым листинг на топ-бирже можно заметить раньше большинства

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

Дальше полезно держать список наблюдений:
• анонсы интеграций кошельков, сетей и маркет-мейкера
• рост числа упоминаний токена в документации и FAQ
• резкие правки в разделе support у биржи
• массовые проверки контракта и metadata в обозревателях

Отдельно стоит отслеживать не только саму биржу, но и окружение: мосты, сети, launchpad, custody-провайдеров, статус-страницы и страницы комиссии. Если у нескольких элементов цепочки одновременно меняется статус, вероятность листинга выше, чем у одиночного намёка.

Не путайте подготовку к листингу с шумом в соцсетях: надёжнее сверять публичные API, страницы активов и официальные каналы обеих сторон. Один подтверждённый источник лучше десяти пересказов.

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

Restaking: 6 вещей, которые пользователь должен проверить до депозита в протокол

Restaking — это повторное использование уже застейканных активов или их ликвидных производных для получения дополнительной доходности. Для пользователя ключевой вопрос не в «доходе», а в том, какие обязательства он принимает вместе с ним.

• Источник дохода: вознаграждение может идти не только от базового staking, но и от дополнительных сервисов, которые вы поддерживаете.
• Риск слэшинга: один актив может быть задействован в нескольких слоях, и ошибка на любом уровне может повлиять на итоговый баланс.
• Ликвидность: часть решений даёт токен-представитель, но его погашение и обмен зависят от правил конкретного протокола.
• Контрагентский риск: чем больше промежуточных контрактов и операторов, тем важнее аудит, лимиты и модель распределения ролей.

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

Для пользователя restaking полезен только тогда, когда понятны не только выплаты, но и сценарий потери доступа к средствам. Сначала читают правила риска, потом считают доходность.

ЕЮ Иванов продолжает кошмарить АффПапу, конторку, которая накинула говна на вентилятор этим летом. Тогда в AffPapa не знали, с каким говном идут бодаться, поэтому заслуженно проиграли. 😏

На этот раз ЕЮ зарегал товарный знак AffPapa — совсем скоро имя компании будет официально принадлежать ему. Чтобы убедиться в трушности мува, переходим по ссыл-Очке и вводим серийный номер: 2026793242. Там видим, что заявка на регистрацию подана лично Евгением Юрьичем.

Всё это выглядит забавно, но давайте не забывать, в какой сфере мы работаем и что реально может произойти с жирным троллем за воровство нейминга. Впрочем, толстому не привыкать отхватывать пиздов за проделки в интернете, поэтому ждем очередную фотку разбитого ебала и длинный пост с извинениями. 😏😏😏

В арбитраже денег нет 💵

FATF travel rule: что должен хранить и передавать криптообменник без лишних ошибок

Travel Rule требует сопровождать перевод данными об отправителе и получателе, если операция проходит через VASP/обменник. Для криптообменника это не «доп. поле в форме», а отдельный процесс: сбор, проверка, передача и хранение сведений по правилам комплаенса.

Что обычно нужно предусмотреть:
— идентификацию клиента до отправки;
— передачу имени, номера счёта/кошелька и реквизитов контрагента;
— проверку, является ли другая сторона VASP;
— сценарий для self-hosted wallet, где у провайдера меньше данных для обмена.

Частые ошибки — передавать неполный набор полей, хранить данные в разных системах без единого лога и не разделять внутренние переводы, P2P и внешние транзакции. Из-за этого обменник теряет трассируемость и не может быстро ответить на запрос комплаенса или регулятора.

Минимальный чек-лист: карта потоков данных, правила по порогам и исключениям, журнал передачи travel rule-метаданных, понятный SLA на ответы по запросам, и отдельная процедура на случаи, когда контрагент не поддерживает обмен данными.

Если обменник строит процесс сразу вокруг трассируемости, а не «докрутим потом», он экономит время на проверках и меньше рискует сломать операционку на ровном месте.

Российский ЦБ по крипте: как читать позицию регулятора без лишних трактовок

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

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

Для проектов это означает, что любая модель с криптой должна заранее проходить проверку на AML/KYC, роль посредника и юридическую квалификацию токена или сервиса. Для пользователей — отдельный учёт рисков: хранение, маршруты ввода-вывода, документы по сделкам и понимание, что спор с банком чаще решается не словами, а подтверждающими бумагами.

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

KYC tier-based на биржах: как устроен доступ по уровням и где чаще всего ошибаются

Биржи обычно не делают KYC «всё или ничего»: доступ делят по уровням. На базовом уровне хватает почты и телефона, дальше добавляют документ, селфи, адрес, иногда источник средств. Чем выше лимит на ввод, вывод и p2p-операции, тем глубже проверка.

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

Типовые ошибки: загружать документы с несоответствием имени, использовать адрес из старого паспорта, не совпадать по стране проживания, пытаться пройти верификацию на чужие данные. Ещё одна частая проблема — пропуск proof of address: выписка, счёт за коммунальные услуги или банковский документ должны быть читаемыми и не старше требований площадки.

Для проекта или аффилиата полезно помнить: tier-based модель — это не формальность, а часть продуктовой архитектуры. На разных уровнях меняются комиссии, лимиты, доступ к OTC, API, p2p и выводу средств; если это не объяснить заранее, саппорт получает лишнюю нагрузку, а конверсия падает.

Практика одна: заранее сравнивайте, какие документы нужны на каждом уровне, и держите их в актуальном виде.

Liquid staking токены: где удобство превращается в дополнительный слой риска

Liquid staking токен — это производный актив, который отражает застейканные монеты и начисленный доход. Пользователь получает ликвидность, а протокол — делегированный стейк; на практике между активом и базовым депозитом появляется ещё одна точка отказа.

Риски здесь обычно не одинарные:
— смарт-контракт может содержать ошибку;
— механизм обмена токена на базовый актив может работать с задержкой;
— цена LST на рынке может отходить от стоимости underlying;
— валидаторский риск и слешинг остаются на стороне стейка.

Отдельно стоит смотреть на концентрациею: если большой объём застейкан через один протокол, уязвимость становится системной. Тогда проблема одного контракта быстро превращается в риск для DeFi-пулов, лендинга и любых стратегий, где LST используется как залог.

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

↩️ Пост из @SellerBriefPro:

В июне РКН, судя по массовым сбоям, перешёл к более точечной схеме ограничения трафика: под удар попали не только «тяжёлые» протоколы, но и связка xray + VLESS + REALITY, на которой держались многие обходные решения.

Что важно по технике:
— атака шла не на один сервис, а на сам паттерн соединения;
— проблема проявлялась массово, но не синхронно: часть конфигов отваливалась сразу, часть — через время;
— ломалась не вся инфраструктура, а именно стабильность установления и поддержания сессии.

Для ecom-команд это сигнал не про «VPN как удобство», а про зависимость рабочих контуров от внешних сетевых обходов: кабинеты, аналитику, CRM, удалённый доступ, уведомления. Если рабочий процесс завязан на один способ подключения, риск простоя становится системным.

Что проверить в кабинете и у команды:
1) есть ли резервный канал доступа;
2) можно ли зайти в критичные сервисы без основного обхода;
3) зафиксированы ли альтернативные конфиги и сценарии переключения.

Вывод простой: в 2026-м устойчивость сетевой инфраструктуры — это уже операционный риск, а не ИТ-деталь ⚠️

Liquid staking токены: за что их ценят и где чаще всего ошибаются

Liquid staking token — это не «второй ETH», а отдельное требование к базовому активу. Пользователь вносит монету в стейкинг и получает ликвидный токен, который можно использовать в DeFi, пока исходный актив продолжает приносить доход через валидаторов.

Ретроспектива у этой модели простая: она сняла часть боли классического стейкинга, где активы заморожены, но добавила новый слой рисков. Самый частый из них — расхождение цены LST и базового актива: на рынке ликвидности токен может торговаться с дисконтом или премией, и это отдельный риск для тех, кто использует его как залог.

Важно проверять не только протокол, но и механику вывода: есть ли очередь на анстейк, кто контролирует смарт-контракт, как устроены слэшинг-риски и что происходит при сбое валидаторов. Отдельный пункт — интеграции: чем больше DeFi-протоколов принимает LST, тем выше системная зависимость от одного стандарта.

Перед использованием полезно держать короткий чек-лист: есть ли аудит, как распределены ключи управления, можно ли быстро обменять LST обратно, и не завязан ли доход целиком на одну инфраструктуру. Если ответов нет, ликвидность может оказаться только на словах.

Restaking для пользователя: где появляется доходность и где появляется риск

Restaking — это повторное использование уже застейканных активов или LST/LRT-токенов для защиты других сервисов: оракулов, мостов, rollup-инфраструктуры, data availability и похожих сетей.

Что получает пользователь:
— дополнительную доходность сверх базового staking;
— доступ к поинтам или будущим вознаграждениям протокола;
— ликвидный токен, который можно держать в кошельке или использовать в DeFi.

Где риск выше обычного staking:
— slashing может прийти не только от базовой сети, но и от внешнего сервиса;
— смарт-контракт LRT-протокола добавляет отдельную точку отказа;
— ликвидный токен может торговаться с дисконтом к базовому активу;
— условия вывода могут зависеть от очередей и правил протокола.

Перед входом стоит проверить три вещи: кто оператор, какие сервисы получают безопасность, как прописаны slashing и вывод. Если эти пункты не раскрыты явно, пользователь принимает риск «чёрного ящика».

Restaking — не просто «ещё один процент доходности», а слой дополнительных обязательств поверх staking. Чем больше протоколов в цепочке, тем важнее понимать, где именно лежит риск.

Регуляторика США по stablecoin: как читать требования без лишней воды

В США stablecoin обычно смотрят через три вопроса: кто выпускает токен, чем он обеспечен и можно ли его использовать как платёжный инструмент. Если эмитент принимает депозиты, хранит резервы и обещает погашение 1:1, к нему могут применяться правила не только по цифровым активам, но и по платежам, ценным бумагам, трастам и AML.

Базовый чек-лист для проекта: • понятная правовая форма эмитента; • раздельное хранение резервов; • политика выкупа без скрытых ограничений; • регулярная отчётность по обеспечению; • процедуры KYC/AML для каналов входа и выхода. Отдельно проверяют, не создаёт ли продукт ожидание доходности или права на прибыль.

Если stablecoin используется в экосистеме биржи, кошелька или DeFi, внимание смещается на комплаенс-процессы: санкционные фильтры, контроль адресов, раскрытие рисков, ограничения для некоторых клиентов и сценарии блокировки при нарушении правил. Для маркетинга важно не обещать «эквивалент доллара» без оговорок о редемпшене и эмитенте.

Для команды полезнее всего держать в одном файле карту обязанностей: эмитент, кастодиан, посредник, пользовательские ограничения и сценарий выкупа. Когда эти роли разделены и описаны, проверка регуляторики проходит заметно спокойнее.