Криптовалюты

7 вещей, которые нужно проверить перед любым крипто-переводом

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

Первое — сеть. Один и тот же актив может существовать в нескольких сетях. Например, USDT можно отправить через ERC-20, TRC-20, BEP-20 и другие варианты. На экране это выглядит как тот же токен, но по факту это разные маршруты. Ошибка здесь — одна из самых дорогих.

Второе — адрес. Недостаточно просто скопировать его и вставить. Стоит хотя бы сверить первые и последние символы. Ошибки в буфере, невнимательность или банальная спешка — классика.

Третье — актив и сеть должны совпадать одновременно. Многие проверяют только монету или только сеть, а ошибка обычно возникает именно в связке.

Четвёртое — комиссия и итоговая сумма. Особенно если перевод идёт “впритык”. Иногда пользователь уверен, что отправляет нужную сумму, а после комиссии оказывается ниже минимального порога.

Пятое — минимальная сумма зачисления. Во многих сервисах слишком маленький перевод может прийти в сеть, но не зачислиться автоматически. И человек просто сидит и ждёт, не понимая, что произошло.

Шестое — memo, tag или дополнительный идентификатор, если он нужен. Для некоторых активов одного адреса недостаточно. Если забыть это поле, перевод может пройти, но деньги не будут привязаны к аккаунту без ручной поддержки.

Седьмое — тестовый перевод. Самый скучный совет, но самый дешёвый способ не потерять крупную сумму. Если сервис новый, сеть новая или сумма чувствительная — сначала лучше отправить небольшую часть.

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

Написал небольшой микросервис на FastAPI, помогающий взаимодействовать с блокчейном Litecoin для принятия платежей. Сервис напрямую подключается к любой ноде на протоколе ElectrumX.

Список нод можно взять здесь: https://1209k.com/bitcoin-eye/ele.php?chain=ltc
Либо же можно захостить свою ноду, но пока нам будет достаточно удалённой.

Принимая платежи таким способом, мы контролируем "ключи", не зависим от сторонних платежных систем, нам не нужно никому доверять наши средства и отдавать процент от выручки.

Можем взглянуть на исходный код и перейдём к обзору функционала.
https://github.com/CryptoWrapAPI/litecoin-wallet-rpc

Для начала нужно получить свой ключ к блокчейну, проще говоря, сид-фразу.
Но не каждая сид фраза подойдёт, вкратце, нужна сид фраза стандарта BIP39.
Такую сид фразу можно сгенерировать с помощью new_wallet.py

Для этого нам понадобится Python версии 3.12, потому что библиотека bip_utils пока что поддерживает только эту версию.

Mnemonic string: 
rather nasty bright aisle craft spare blood room village resource special region winter gesture despair slender tiger wall state fashion grass trophy crack monster

Master key (bytes): 865fcb279555a25bf50e2e33d37ef68b363b3eb322a68456609526f80be28a7e
Master key (extended): zprvAWgYBBk7JR8GkiSjUUwyhei9mSTEMd5ENS9xywYxsf6WLuFvq9eJjE7eFCjw3sT4AreK7cRiBgF4x8CiL5sPUhwZA3rBhFbKD1poA3iWQCg
Master key (WIF): T7ZBZxkT8ebmYHyz1vHdG9G4of2UPJm2hVky1x19kX2xtQSKKCu4

Далее для деривации (создания отдельных адресов для принятия платежей) нам понадобится extended мастер-ключ.

Отправляем его вместе с account index и address index на эндпоинт /derive (запустим тест python tests/test_derive.py)

Индексы мы можем представить как координаты адреса по оси X и Y

============================================================
TEST: Address Derivation
============================================================
XPRV: zprvAWgYBBk7JR8GkiSj...
Account index: 0
Address index: 0

Status: 200
Response:
{
  "address": "ltc1qt25zdkgj4shgyp4xw770hsjtdph6kn70zz8h06",
  "account_index": 0,
  "address_index": 0,
  "chain": "external"
}

✓ Derived address: ltc1qt25zdkgj4shgyp4xw770hsjtdph6kn70zz8h06
============================================================

Теперь этот адрес кошелька можно отправить клиенту нашего сервиса.

Чтобы проверить, поступил ли платеж, мы можем обратиться к методу get_history
https://electrumx.readthedocs.io/en/latest/protocol-methods.html#blockchain-scripthash-get-history

// В этом примере адрес начинается с tltc1 вместо ltc1 
// Потому что это testnet блокчейн :)
// Сменить testnet/mainnet можно в .env

  "tltc1qayq6ppmzztpgy354r45lkp8vjdafnhtf0yhutm": {
    "transactions": [
      {
        "tx_hash": "6803c0769c89e2cd9bbbda1d1e8715c5b11c1e69f8f9a7d46c1cd6adc2103c6a",
        "height": 4672171
      },
      {
        "tx_hash": "10bdb766e7c8a42e468862a97b10260955fafe7a0fcd219f025b4dd105077e5e",
        "height": 4672208
      }
    ],
    "count": 2,
    "timestamp": "2026-04-10T01:23:37.448442+00:00"
  }

Мы видим две транзакции, height здесь - это номер блока, в который включена транзакция, если она всё ещё находится в мемпуле (ожидает подтверждения майнерами), то мы увидим -1 или 0.

Частота блоков в Litecoin составляет ~2 минуты. То есть примерно через 2 минуты транзакция будет включена в цепочку блоков.

Узнать детали транзакции можно с помощью эндпоинта /transactions
Там будет подробное описание транзакции, включая все "входы" и "выходы", количество отправленных монет, комиссию сети, заплаченную отправителем и так далее.

На этом у меня всё, спасибо за внимание!

Анализ истории сделок на предмет перекоса шортистов/лонгистов

Ссылка на GitHub

В backtest-kit модуль volume-anomaly используется как источник в графе сигналов - параллельно с GARCH. Если GARCH отвечает на вопрос «достаточно ли ожидаемое движение», то volume-anomaly отвечает на вопрос «является ли прямо сейчас статистически необычным моментом в микроструктуре рынка».

Пример кода

import { sourceNode, outputNode } from '@backtest-kit/graph';
import { predict } from 'volume-anomaly';
import { getCandles } from 'backtest-kit';

const ANOMALY_CONFIDENCE = 0.75;
const N_TRAIN  = 1200; // обучающее окно — должно быть без аномалий
const N_DETECT = 200;  // окно детекции

const reversalSource = sourceNode(
  async (symbol) => {
    // Важно: recent не должен пересекаться с historical
    const all        = await getAggregatedTrades(symbol, N_TRAIN + N_DETECT);
    const historical = all.slice(0, N_TRAIN);  // старые сделки — baseline
    const recent     = all.slice(N_TRAIN);     // новые — без overlap

    return predict(historical, recent, ANOMALY_CONFIDENCE);
    // {
    //   anomaly:    true,
    //   confidence: 0.81,
    //   direction:  'long' | 'short' | 'neutral',
    //   imbalance:  0.61,
    // }
 },
);

const entrySignal = outputNode(
  async ([reversal, ...]) => {
    if (!reversal.anomaly) return null;
    if (reversal.direction === 'neutral') return null;

    const position = reversal.direction; // 'long' | 'short'

    return {
      id: randomString(),
      position,
      priceTakeProfit: ...
      priceStopLoss: ...
      minuteEstimatedTime: 60,
    };
  },
  reversalSource,
  ...
);

Ключевые детали

• Hawkes Process - кластеризация ордеров

• CUSUM- сдвиг buy/sell дисбаланса относительно исторической нормы

• BOCPD- смена режима: момент когда распределение дисбаланса само меняется

Как использовать

Классическая проблема DCA - ты усредняешься в падающий нож. Цена идёт против, ты докупаешь, а она продолжает падать. volume-anomaly заточен именно под это: докупать не по расписанию или по сетке уровней, а только когда ордерфлоу показывает разворот агрессии.

О прогнозе нейтрального тренда актива

Ссылка на GitHub

В backtest-kit GARCH используется как один из источников в графе сигналов. Идея: вход открывается только если GARCH-канал достаточно широк, чтобы TP и SL уместились с запасом над комиссиями.

Например, этим можно законтрить боковик, который был на BTCUSDT в Феврале 2024

• 5–10 февраля, 73% нейтральных баров

• 11–16 февраля, 63% нейтральных баров

• 19–24 февраля, 75% нейтральных баров

• 26–29 февраля, 69% нейтральных баров

Пример кода

import { sourceNode, outputNode } from '@backtest-kit/graph';
import { predict } from 'garch';
import { getCandles } from 'backtest-kit';

const CANDLES_FOR_GARCH = 300;
const GARCH_CONFIDENCE = 0.6827; // ±1σ

const garchSource = sourceNode(
  Cache.fn(
    async (symbol) => {
      const candles = await getCandles(symbol, '8h', CANDLES_FOR_GARCH);
      return predict(candles, '8h', null, GARCH_CONFIDENCE);
    },
    { interval: '8h', key: ([symbol]) => symbol },
  ),
);

const entrySignal = outputNode(
  async ([trend, volume]) => {
    // Пропускаем если модель не сошлась
    if (!volume.reliable) return null;

    // Проверяем что до границ канала достаточно места
    const upperDiff = percentDiff(trend.close, volume.upperPrice);
    const lowerDiff = percentDiff(trend.close, volume.lowerPrice);

    if (upperDiff < TAKE_PROFIT_PERCENT) return null;
    if (lowerDiff < STOP_LOSS_PERCENT) return null;

    // TP и SL по границам GARCH-канала
    const tp = trend.position === 'long' ? volume.upperPrice : volume.lowerPrice;
    const sl = trend.position === 'long' ? volume.lowerPrice : volume.upperPrice;

    return { position, priceOpen: trend.close, priceTakeProfit: tp, priceStopLoss: sl };
  },
  trendSource,
  garchSource,
);

GARCH здесь не генерирует направление. Он отвечает только на вопрос «достаточно ли ожидаемое движение». Направление приходит от другого источника (это может быть Pine Script через @backtest-kit/pinets или LLM через @backtest-kit/ollama)

Ключевые детали

• Parkinson estimator для per-candle RV: (1/4ln2) · ln(H/L)² — в ~5× эффективнее squared returns

• Log-normal bands: P·exp(±z·σ) — не линейное приближение, правильное маппирование в ценовое пространство

• reliable: true когда: оптимизатор сошёлся + persistence < 0.999 + Ljung-Box p ≥ 0.05

• Оптимизация: multi-start Nelder-Mead, GARCH — 4 рестарта, NoVaS — 7 (11-мерная задача)

• 932 теста, включая ground-truth тест с синтетическими данными известной волатильности

Добавил поддержку типов System.UInt128 и System.Int128 в основную web3-библиотеку для шарпистов/дотнетчиков,— Nethereum. Уже ушло в master, так что если активно используете Nethereum для работы с протоколами, где широко представлены 128-битные типы в событиях/параметрах/результатах вызова функции и страдаете от избыточного потребления памяти BigInteger, то можно уже переключаться на версию из master (для сборки необходим nuget.exe). Особенно это актуально для AAVE, Balancer и Velodrome/Aerodrome (в последних не забывайте использовать packed-кодирование при работе с роутером).

Сейчас обсуждаем с мейнтейнером Хуаном Бланко повышение производительности и снижение потребления памяти при кодировании/декодировании целых чисел в Nethereum, после чего я подготовлю ещё один Pull Request с реализацией и ориентировочно всё эти изменения войдут в следующий релиз.

Если есть идеи, что ещё можно было бы сделать/улучшить, присоединяйтесь к обсуждению в Discord проекта (на английском/испанском) или в issues в репозитории на github.

Сложность майнинга биткоина снизилась на 11,16%. Это самое существенное изменение с момента обвала рынка после запрета майнинга в Китае в 2021 году.

Стажёр криптобиржи Bithumb случайно сделал 240 человек миллионерами — он по ошибке отправил им биткоины вместо корейских вон.

Клиенты платформы могли купить наборы Random Box, из которых могли выпасть 2000–50000 вон, но случилась небольшая ошибка: когда сотрудники начали рассылку призов, кто‑то случайно изменил воны (KRW за $1,35) на BTC. В итоге из 700 покупателей Random Box 240 открыли их и получили по 2000 ВТС на свои кошельки. Получатели бросились их продавать. Из‑за массового оттока крипты, курс BTC внутри биржи временно улетел на 10% ниже глобальной. Биржа попыталась вернуть всё на место, но счастливчики успели вывести 3 млрд вон.

В результате при распределении эирдропа биткоин на Bithumb просел на 10% относительно других рынков. Bithumb является второй крупнейшей криптобиржей Южной Кореи.

Основатель Binance написал, что «снова стал бедным». В прошлый раз он писал это, когда биткоин упал с примерно $67 тысяч до около $30 тысяч.

Тем временем биткоин обвалился на 54% относительно своего октябрьского пика 2025 года. Сегодня биткоин рухнул сразу на 14% за сутки. Аналитики Stifel прогнозируют обвал биткоина до $38 тыс.

Малазийские власти изъяли 1069 машин для майнинга биткойнов и уничтожили их с помощью катка. По утверждению следствия, это оборудование позволило украсть электроэнергии на $2 млн, его уничтожили по решению суда.

TradingView представила кольцо для криптотрейдеров — Moodring будет вибрировать и менять цвет, если криптовалюта в портфеле пользователя изменит цену.

Пятого ноября все модельки, в рамках эксперимента Alpha Arena ушли в минус (Пост), шестого ноября, с проекта удалили эти данные и закрыли сезон бенчмарка третьим ноября, пока две модельки еще были в небольшом плюсе:

Выводы очевидны

Приветствую всех. Занимаюсь понемногу арбитражем dex-cex и недавно увидел токен, который просел на 1500% и снова вернулся (почти) к исходной цене. Стало интересно почему так произошло. Покопавшись в polygonscan, было обнаружено что из адреса нулл было переведено 5 миллионов токенов и большая часть продана через uniswap. Но я думал что из null адреса нет обратного пути? Кто знает что это была за махинация и как это произошло? Токен Dimo 0xe261d618a959afffd53168cd07d12e37b26761db

Крипторынок в ночь с 10 на 11 октября потерял $19 млрд. Такого не было даже в ковидное время — тогда криптовалютный фонд потерял $1,2 млрд, сейчас — в 16 раз больше.

Telegram Wallet Кошелек скам? Заблокировали средства и уже 2 недели "проверяют"!

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

Уже 2 недели как "отклонили верификацию" и "ограничили доступ к аккаунту", идет общение с поддержкой и "проверка". Примечательно, помимо немалой суммы, что аккаунту полтора года и за это время ничего (!), кроме 8 пополнений из других моих кошельков не было. То есть никаких расходов, P2P транзакций, никаких бирж, НИЧЕГО, к чему можно было бы даже теоретически придраться. Соблазнился стейкингом по 17% на USDT и удобным интерфейсом. При этот аккаунт был верифицирован на уровне "плюс", это паспорт и фото. 

Да, кастодиальный сервис, но в Телеграме все устроено, чтобы показать, что этот сервис родной, вы видите его в настройках мессенжера, и даже анимация в нем фирменная телеграмовская с "уточкой". Разве мы не доверяем Телеграму и Павлу Дурову?!)

В общем сначала "верификация отклонена", после общения с поддержкой в боте 8 дней, наконец-то потом появилась форма запроса данных, сразу внес туда документы "подтверждающие доход", статус изменился на "Аккаунт на проверке", и снова тишина почти неделю... хотя и в форме и FAQе написано, что такое проверяется до 24 часов.

Как обещал, написал простой, но легко расширяемый торговый бот, использующий ML-сигналы от API AIgnal.tech.

Репозиторий: aignal-trading-bot

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

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

А я продолжаю допиливать API для доставки следующих инструментов.

Поиск скомпрометированных зависимостей через Dependency Track

На днях стало известно о компрометации почти 2-х десятков npm-пакетов (подробнее в этой статье). Зловредный код может похищать криптовалюту. Это не первый раз, когда в зависимости попадает зловред (например, в 2022 году зловред удалял данные).

Один из вариантов поиска наличия скомпрометированных пакетов среди сотен проектов - использование Dependency Track. При этом поиск возможен и в транзитивных зависимостях тоже. На картинке ниже показан процесс. Заходим в раздел "Components", вводим название в формате "pkg:npm/$name$". Далее остаётся отсортировать по версии и найти среди них скомпрометированную (сейчас это легко - нужно смотреть самую старшую версию). Можно поиск производить сразу по конкретной версии. Пример:

pkg:npm/simple-swizzle@0.2.3

Если пакет нашёлся - можно не только узнать в каком именно проекте, но и увидеть где именно в дереве зависимостей проекта используется (нажать на иконку, обведённую красным).

Если знаете альтернативные варианты поиска скомпрометированных пакетов другими средствами - напишите в комментариях.

В 2018 году экономист из Гарварда заявил телеканалу CNBC, что вероятность обвала биткоина до $100 выше, чем вероятность достижения им $100 000.

В 2025 год Гарвард купил 1000 биткоинов по 116 000 долларов за штуку через BlackRock’s iShares Bitcoin Trust ETF.

Вайбкодером быть не хочу, ибо люблю говнокодить лично. Буду вайбинвестором.

Провел с gpt-другом исследование для долгосрочных инвестиций в крипту, с удовольствием делюсь с вами диверсифицированным json-криптопортфелем.

Что скажете, кожаные?

{
  "portfolio": [
    {
      "name": "Bitcoin",
      "symbol": "BTC",
      "allocation_percent": 35,
      "risk": "low",
      "category": "Store of Value",
      "notes": "Основной актив, защита от инфляции, институциональный интерес"
    },
    {
      "name": "Ethereum",
      "symbol": "ETH",
      "allocation_percent": 20,
      "risk": "low",
      "category": "Smart Contracts",
      "notes": "Лидер в области DeFi, L2 и NFT"
    },
    {
      "name": "Solana",
      "symbol": "SOL",
      "allocation_percent": 10,
      "risk": "medium",
      "category": "Layer 1",
      "notes": "Высокая пропускная способность, активное развитие DeFi/NFT"
    },
    {
      "name": "Chainlink",
      "symbol": "LINK",
      "allocation_percent": 5,
      "risk": "medium",
      "category": "Oracle",
      "notes": "Интеграции с TradFi и ключевая роль в инфраструктуре Web3"
    },
    {
      "name": "Arbitrum",
      "symbol": "ARB",
      "allocation_percent": 5,
      "risk": "medium",
      "category": "Layer 2",
      "notes": "Популярный L2 для Ethereum, высокая активность пользователей"
    },
    {
      "name": "Injective",
      "symbol": "INJ",
      "allocation_percent": 5,
      "risk": "medium",
      "category": "DEX Infrastructure",
      "notes": "Поддержка Binance, ориентирован на производные и деривативы"
    },
    {
      "name": "Kaspa",
      "symbol": "KAS",
      "allocation_percent": 5,
      "risk": "medium",
      "category": "Layer 1 PoW",
      "notes": "Высокая скорость транзакций, перспективный консенсус GHOSTDAG"
    },
    {
      "name": "Celestia",
      "symbol": "TIA",
      "allocation_percent": 5,
      "risk": "high",
      "category": "Modular Blockchain",
      "notes": "Инновационный подход к масштабированию, модульная архитектура"
    },
    {
      "name": "Render",
      "symbol": "RNDR",
      "allocation_percent": 5,
      "risk": "high",
      "category": "AI / DePIN",
      "notes": "GPU-рендеринг для Web3 и метавселенных, интерес со стороны AI-сектора"
    },
    {
      "name": "Starknet",
      "symbol": "STRK",
      "allocation_percent": 5,
      "risk": "high",
      "category": "Layer 2 ZK",
      "notes": "ZK-rollup на Ethereum, сильная техническая команда"
    }
  ],
  "strategy": {
    "rebalance_frequency": "6-12 months",
    "stablecoin_buffer_percent": 5,
    "rebalancing_criteria": [
      "Изменения в фундаментальных показателях",
      "TVL и активность в сети",
      "Развитие экосистемы",
      "Регуляторные риски"
    ]
  }
}

✍ Топ 5 ошибок в работе с подписью на смарт-контрактах

Стандарту EIP-712 в Ethereum не один год и даже не три. Каждый кто работает с кошельками так или иначе сталкивался с ним воочию. Основная цель стандарта заключается в улучшение пользовательского опыта, позволяя кошелькам показывать человекочитаемые данные подписи.

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

1️⃣ Отсутствие поля TYPE_HASH в составе подписи

Приводит к несовместимости со стандартом EIP-712, что влечет за собой невозможность использовать классические инструменты для создания подписи.

2️⃣ Пропуск полей в TYPE_HASH при кодировании

TYPE_HASH добавили, но описали не все поля.

// Забыли поле expiredTime, но ниже поле используется
bytes32 private constant TYPE_HASH = keccak256("Order(address user,uint256 nonce)");

...

// recoverSignature(user, nonce, expiredTime);

Часто бывает и наоборот, TYPE_HASH описан правильно, но при восстановление подписи пропустили пару полей.

3️⃣ Ошибка кодирования динамических типов

Всегда нужно помнить, что поля типа string и bytes кодируются особым образом.

keccak256(args.data) // encode bytes
keccak256(abi.encodePacked(args.str)) encode string

4️⃣ Ошибка кодирования ссылочных типов

Это подобная ошибка, как и с динамическими типами, только касается массивов и структур данных.

В кодировании массивов разработчики часто забывают, что это должен быть хеш от набора байт всех элементов массива keccak256(abi.encodePacked(array)).

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

keccak256(abi.encode(
    PARENT_TYPE_HASH,
    keccak256(abi.encode(
        CHILD_TYPE_HASH, 
         ... // chield fields
     )),
      ... // parent fields
))

5️⃣ Подпись не защищена от повторного использования

Зачастую подпись не должна иметь возможность быть использованной повторно.

Для того, чтобы этого не произошло в тело подписи вводится одноразовый счетчик nonce, который делает подпись уникальной. После использования подписи на смарт-контракте счетчик увеличивается.

Вывод

Я сам помню на сколько мне тяжело давалось чтение спецификации стандарта EIP-712, когда я был молодым. Я тоже допускал ошибки, поэтому призываю не осуждать).

Копнуть EIP-712 поглубже можно со мной в нашем wiki.

@pnaydanovgoo

Во что сегодня превратился бы 1 доллар, вложенный в биткоин и золото в 2009 году.