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

Что проверять перед любым крипто-переводом: короткий anti-fail чеклист

Большая часть проблем с крипто-переводами возникает не из-за “сложности блокчейна”, а из-за слишком бытовых ошибок.

Не ту сеть выбрали. Скопировали адрес, но не сверили хвост. Забыли про memo/tag. Отправили “впритык”, а после комиссии сумма стала ниже минимального порога. Итог всегда один: деньги вроде бы отправлены, но дальше начинается нервный квест. Парадокс в том, что большинство таких ошибок можно поймать за 30–60 секунд до отправки.

Ниже короткий anti-fail чеклист, который реально стоит прогонять перед любым крипто-переводом, особенно если сервис новый, сумма чувствительная или вы работаете в спешке.

Первое: сеть.

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

Второе: адрес.

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

Третье: связка “актив + сеть”.

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

Четвёртое: комиссия и итоговая сумма.

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

Пятое: минимальная сумма зачисления.

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

Шестое: memo, tag или дополнительный идентификатор.

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

Седьмое: тестовый перевод.

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

Если упростить всё до одной мысли, то крипто-перевод это не место, где стоит доверять автопилоту. Одна минута проверки почти всегда дешевле, чем потом разбираться, куда “ушли” деньги и почему они не дошли туда, куда должны были.

TON Smart Contracts: базовый минимум за 5 минут

Если бы я наткнулся на эту статью в самом начале работы с блокчейном ТОН, это бы сэкономило мне кучу времени на понимание архитектуры и принципов работы смарт контрактов.

Что такое смарт контракт с точки зрения разработчика.

Я постараюсь уберечь вас от терминологии блокчейна, вместо этого на пальцах показать из чего состоит смарт контракт и как его собрать. Если говорить совсем просто, то смарт контракт - это ячейка в памяти, хранящая в себе:

• Адрес

• Баланс

• Любые данные, которые вы туда запишите

• Код смарт контракта

• Текущий статус смарт контракта

Ну или если перевести вышесказанное в код, то:

class SmartContract{ 
   readonly address: string; 
   readonly balance: number; 
   readonly code: string; 
   readonly status: 'uninitialized' | 'active' | 'frozen'; 

   storage: object; 
   ... 
}

Плавное погружение...

Представьте, вы написали код класса на своем любимом языке программирования, как полагается, с полями и методами, и превратили этот код в строку. Code - это и есть код вашего смарт контракта. Он будет выполняться в блокчейне. Точкой входа в таком коде будет метод onInternalMessage или onExternalMessage. Чтобы состояние полей класса можно было сохранять и перезаписывать, к смарт контракту прилагается объект Storage , в котором хранятся значения ваших полей.

При сохранении смарт контракта в блокчейн вы отправляете { code, data } , где code - это код вашего смарт контракта, data - начальные данные. По этим двум полям вычисляется будущий адрес смарт контракта: address = hash({ code, data }). По этому адресу будет доступен ваш смарт контракт в блокчейне ТОН. На него можно совершать переводы, просматривать историю транзакцию, с него может переводить средства и вызывать другие смарт контракты.

Как происходит деплой смарт контракта.

Каждый смарт контракт платит немного комиссии по факту своего существования, в пример вспоминается налог на недвижимость. Чем больше жилплощадь - тем больше налог. Но в рамках ТОН вы платите за количество данных, которое хранит ваш смарт контракт, включая сам код вашего смарт контракта. Поэтому при создании на нем должно лежать как минимум чуть-чуть ТОН(как правило копейки). Создать смарт контракт можно 2 способами:

1) Другой смарт контракт делает перевод ТОН, прикрепляя код вашего смарт контракта вместе с начальными значениями(data) в поле Init = { code, data }. Блокчейн видит в переводе это поле и автоматически делает деплой. Статус смарт контракта становится "active".

2) Другой смарт контракт так же делает перевод ТОН, но только не прикрепляя ничего. В таком случае средства останутся висеть на адресе пустого смарт контракта, который будет выглядеть примерно так:

{ 
   "address": "401bf...3004", 
   "balance": 3000, 
   "code": "", 
   "storage": {}, 
   "status": "uninitialized" 
}

Он ждет внешнее сообщение, где в него передадут код и начальные данные таким образом, чтобы address = hash({ code, data }), только тогда он сохранит код и сможет выполняться. Для вызова внешнего сообщения используется обычное API, где передается адрес и Init = { code, data } . Запрос сначала попадет в блокчейн, после чего при совпадении адреса address = hash({ code, data }) произойдет деплой, и статус станет "active".

Заключение

В этой статье мы с вами закрепили азы архитектуры блокчейна ТОН, где каждый адрес является адресом смарт контракта. Разобрали структуру и механику создания. Рады вашему фидбеку или вопросам! Следите за нашими анонсами и новостями в Telegram.

Почему “лучший курс” часто оказывается самой дорогой ошибкой

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

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

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

В итоге человек выбирает не самый выгодный сценарий, а самый привлекательный заголовок.

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

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

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

С точки зрения интерфейса всё выглядит честно: цифра показана. Но с точки зрения пользователя это часто превращается в когнитивную ловушку. Он уже увидел «выгоднее» и перестал смотреть на остальное.

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

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

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

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

Почему KYC воспринимается как препятствие, а не как защита

KYC это одна из самых раздражающих частей любого финтех- или криптосервиса.

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

С точки зрения пользователя это выглядит просто: «Я хочу сделать операцию, почему вы тормозите процесс?»

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

И в какой-то момент вопрос уже не в удобстве. Вопрос в выживании.

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

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

Отсюда и главный конфликт: сервис считает, что защищает процесс, а пользователь считает, что его просто остановили на финише.

На практике раздражает не только сам факт проверки, а четыре вещи.

Первая – внезапность. Если KYC появляется слишком поздно, это почти всегда вызывает негатив.

Вторая – неопределённость. Пользователь не понимает, зачем это нужно именно сейчас, сколько это займёт времени и что будет дальше.

Третья – ощущение недоверия. Особенно если интерфейс подаёт проверку сухо, без нормального объяснения.

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

Именно поэтому один и тот же KYC может восприниматься по-разному в разных сервисах. Где-то пользователь проходит его спокойно, а где-то уходит с раздражением ещё до завершения.

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

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

Поэтому KYC сегодня – это уже не только юридическая или антифрод-задача. Это ещё и продуктовая задача. Сервису недостаточно просто «включить проверку». Ему нужно встроить её так, чтобы она не ломала доверие быстрее, чем защищала бы бизнес.

На практике пользователей раздражает не сам факт проверки, а то, как и в какой момент она появляется. Поэтому KYC давно перестал быть только задачей безопасности: теперь это ещё и вопрос интерфейса, коммуникации и доверия.

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

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

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