2 ИИ провели аудит ETH Strategy по 4К: сравниваю ответы и проверяю.

А также изучил функционал, добавив оценку по практике.
Использовал Parallel AI и AskSurf.

Этот пост публикую в рамках темы 4К+ анализа проектов с ИИ. Ваши из комментариев - на следующих неделях.


Что за проект?
ETH Strategy - это DeFi-протокол казначейства на Ethereum, который даёт экспозицию с кредитным плечом на ETH без рисков ликвидации. Идея - DeFi-аналог MicroStrategy (MSTR).

Протокол работает так: пользователи покупают Long Bonds (конвертируемые ноты), отдают USDC и получают CDT (debt token) + NFT option. Это 0% процентный долг - протокол берёт в долг бесплатно, потому что даёт опцион.

Казна растёт через выпуск облигаций и lending (размещает ETH в Morpho, получая проценты).

Цена STRAT: $0.14 (-83.81% от максимума), Market Cap: ~$690K.


Команда:
- AskSurf: 3/5 (соцсети есть, но без имён)
- Parallel: 2/5 (полная анонимность)
Оба сошлись - команды нет в LinkedIn.

Концепт:
- AskSurf: 4/5
- Parallel: 5/5
Оба признают уникальность - DeFi-аналог MSTR.

Интересно, что по данным DefiLlama, TVL основного хранилища 3.8 МЛН $ - это не много, но и не мало. При этом, он не падает, и даже растёт (на 2% за месяц).

На сайте написано, что у них вложено 11778 ETH - это вообще около 23,5 МЛН $.

А mGAV - 0.80X, Net Leverage - 1.15X.
Доходность ETH с момента запуска - +6.8%.

Коин:
- AskSurf: 3/5
- Parallel: 2/5
Самое интересное! Parallel нашёл то, чего нет у AskSurf: 75.5% токенов разлочится за 2 месяца - это огромный риск. AskSurf просто не нашёл данных.

Критичный момент по токеномике:
Ни я в документации, ни оба ИИ не нашли данных о том, кому сколько распределили на TGE. Есть только Total Supply (107.87M) и Circ Supply (4.86M = 4.5%). Кто владеет остальными 95.5% - непрозрачно. Это красный флаг.

Код:
- AskSurf: 2/5 (только токен открыт)
- Parallel: 5/5 (якобы есть GitHub)
Тут Parallel СГЛАЗИЛ 🙂! Нашёл GitHub, но это оказался ДРУГОЙ ПРОЕКТ - $ETHXR, а не $STRAT. Это разные токены. В docs.ethstrat.xyz нет ссылки на GitHub репозитория - только аудит Nethermind.

Что упустили оба ИИ:
ESPN - отдельный vault для доходности (Perpetual Note). ESPN уже прошёл аудит Nethermind. Аудит core protocol (2 штуки) обещают опубликовать при запуске permissionless bonding.

Итог:
- AskSurf: 3/5
- Parallel: 14/20 (~3.5/5), но с ошибкой в коде
AskSurf оказался честнее - сказал что код закрыт, и это правда. Parallel ошибся с GitHub.
Главный риск: непрозрачная токеномика + анонимная команда.


Дополнение - практика:

Зашёл в их веб приложение - довольно удобно всё:
На STRAT - стейкинг и онстейкинг токена.

На ESPN (хранилище) есть минт и Redeem. APR - 18.01%.

В Mint надо отправить USDS, чтоб получить ESPN.
USDS покупать можно в CoW Swap.

Считаю это минусом, что не поддерживают USDC и другие стейблы.

Так вот: купил, обновил страницу, указал сумму, нажал "Approve".
После подтверждения транзакции кнопка стала "Deposit USDS".

Странно, что в ESPN не пишет, сколько получу. Но в кошельке увидел, что на 0.016851 (примерно на 1.82 $) - норм.

Approve, кстати, был на нормальную сумму, что указана. А то часто многие протоколы берут разрешение на максимум токенов, из-за чего пользователи потом страдают.

Redeem - стандартная форма с указанием количества ESPN.
Но в USDS не пишут, сколько получу - минус.

(скриншоты будут в первом комменте)

В итоге, поставлю за практику оценку 4 из 5: удобно и понятно, но не выводит сумму получения.


Как думаете, стоит ли доверять проекту без раскрытия команды и распределения токенов?

😎 Незрячий web3 программист (подписаться)
Чат | бот

📟 Прилетело из @blind_dev

Рынок ожил

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

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

Поэтому рекомендую обзавестись подпиской:

Купить пеликана через наш маркет (так дешевле):
🔗 1 месяц - $40.00
🔗 3 месяца - $110.00
🔗 12 месяцев - $409.00

Купить пеликана через сервисы:
🔗 Crypto Bot
🔗 Pay2Pass

📟 Прилетело из @hidden_coding

Это видео было сгенерировано одним промптом:

Сгенерируй короткое видео в стиле YouTube Poop с помощью Python и ffmpeg. Вложи в него свою личность — пусть оно передаёт каково это быть языковой моделью.

@danokhlopkov

📟 Прилетело из @danokhlopkov

Алгоритмы. Динамическое программирование

Динамическое программирование (ДП) — это метод решения сложных задач путем разбиения их на более простые подзадачи, с тем важным условием, что эти подзадачи перекрываются. Представь, что тебе нужно посчитать количество возможных маршрутов из левого верхнего угла сетки в правый нижний. В процессе подсчета ты заметишь, что постоянно пересчитываешь одни и те же участки пути. Динамическое программирование предлагает элегантное решение: вместо того чтобы вычислять одно и то же многократно, мы сохраняем результат каждой подзадачи и используем его как строительный блок для решения более крупных задач. Формально говоря, этот подход работает в три этапа: задача разбивается на перекрывающиеся подзадачи (одни и те же маленькие задачи встречаются в решении снова и снова), каждая подзадача решается ровно один раз, а её результат сохраняется и переиспользуется при необходимости. Именно наличие перекрывающихся подзадач — верный сигнал о том, что ДП применимо.

Чтобы понять, почему без ДП возникают проблемы, рассмотрим классический пример — вычисление чисел Фибоначчи, где каждое следующее число является суммой двух предыдущих. При наивном рекурсивном подходе мы сталкиваемся с катастрофической неэффективностью. Например, при вычислении F(5) дерево вызовов будет выглядеть так: F(5) раскладывается на F(4) и F(3), те в свою очередь на свои составляющие, и в итоге F(3) вычисляется дважды, а F(2) — целых три раза. При росте n количество повторных вычислений взрывается, и сложность алгоритма становится экспоненциальной — O(2ⁿ). Динамическое программирование решает эту проблему кардинально: «посчитал F(3) — запиши, понадобился снова — возьми из записей».

Существует два основных способа реализовать эту идею. Первый способ — мемоизация, или подход «сверху вниз» (top-down). Это всё та же рекурсия, но с использованием блокнота (кэша, обычно словаря). Перед тем как вычислить значение, функция проверяет: «А я это уже считал?». Если ответ найден в словаре, она сразу его возвращает, избегая повторных вычислений. Каждое уникальное значение вычисляется строго один раз.

def fibonacci_dp(n, memo=None):
    """Вычисление чисел Фибоначчи с помощью ДП (мемоизация)."""
    if memo is None:
        memo = {}
    if n in memo:
        return memo[n]
    if n <= 1:
        return n
    memo[n] = fibonacci_dp(n - 1, memo) + fibonacci_dp(n - 2, memo)
    return memo[n]

print(fibonacci_dp(10))  # 55

Второй способ — табуляция, или подход «снизу вверх» (bottom-up). Здесь мы отказываемся от рекурсии и начинаем строить решение с самых маленьких, очевидных подзадач, постепенно заполняя таблицу (обычно массив) и двигаясь к искомому результату. Мы точно знаем, что для вычисления следующего значения нам нужны только предыдущие, поэтому просто идем по порядку.

def fibonacci_tabulation(n):
    """Вычисление чисел Фибоначчи с помощью ДП (табуляция)."""
    if n <= 1:
        return n
    dp = [0] * (n + 1)
    dp[0] = 0
    dp[1] = 1
    for i in range(2, n + 1):
        dp[i] = dp[i - 1] + dp[i - 2]
    return dp[n]

print(fibonacci_tabulation(10))  # 55

Для вычисления числа Фибоначчи мы можем пойти дальше и оптимизировать использование памяти. Так как для текущего значения нужны только два предыдущих, можно хранить лишь их, а не всю таблицу. Это снижает затраты памяти с O(n) до O(1).

def fibonacci_optimized(n):
    if n <= 1:
        return n
    prev2, prev1 = 0, 1
    for _ in range(2, n + 1):
        current = prev1 + prev2
        prev2 = prev1
        prev1 = current
    return prev1

print(fibonacci_optimized(10))  # 55

📟 Прилетело из @solidityset

Важно понимать разницу между динамическим программированием и подходом «Разделяй и властвуй». Оба метода дробят задачу, но делают это по-разному. В «Разделяй и властвуй» подзадачи независимы и не перекрываются — каждая решается отдельно и больше не встречается. Классический пример — сортировка слиянием (Merge Sort), где массив делится на независимые половины, которые сортируются сами по себе и никогда не влияют на вычисление друг друга. В динамическом программировании подзадачи обязательно перекрываются: результат одной и той же маленькой задачи требуется при решении нескольких более крупных. Правило выбора подхода простое: если подзадачи перекрываются — используем ДП, если нет — «Разделяй и властвуй».

Классической задачей на ДП является задача о рюкзаке (Knapsack problem). Представь, что у тебя есть рюкзак вместимостью W и набор из n предметов, каждый из которых имеет свой вес w[i] и ценность v[i]. Цель — набрать предметы так, чтобы их суммарная ценность была максимальной, а суммарный вес не превысил W. Например, при вместимости рюкзака W = 7 и предметах с весами и ценностями (1, 1), (3, 4), (4, 5), (5, 7) лучшим выбором будут предметы 2 и 3 (вес 3+4=7, ценность 4+5=9). Почему это задача ДП? Потому что при решении вопроса «брать или не брать предмет i» мы приходим к подзадачам, которые будут переиспользоваться. Если мы берем предмет, нам нужно решить ту же задачу для оставшихся предметов с вместимостью W - w[i]. Если не берем — для оставшихся предметов с той же вместимостью W. Эти подзадачи постоянно повторяются в разных комбинациях. Решается задача методом табуляции. Мы создаем таблицу dp[i][w], где значение в ячейке — это максимальная ценность, которую можно получить, используя первые i предметов при вместимости рюкзака w. Логика заполнения таблицы такова: если вес текущего предмета больше текущей вместимости w, он просто не помещается, и мы берем значение сверху (без этого предмета): dp[i][w] = dp[i-1][w]. Если же предмет помещается, у нас есть два варианта: не брать его (dp[i-1][w]) или взять, добавив его ценность к оптимальному решению для оставшегося места (dp[i-1][w - w_i] + v_i). Выбираем максимум.

def knapsack(weights, values, W):
    """
    Решение задачи о рюкзаке методом ДП (табуляция).
    
    weights — список весов предметов
    values  — список ценностей предметов
    W       — вместимость рюкзака
    """
    n = len(weights)
    dp = [[0] * (W + 1) for _ in range(n + 1)]

    for i in range(1, n + 1):
        w_i = weights[i - 1]
        v_i = values[i - 1]

        for w in range(W + 1):
            dp[i][w] = dp[i - 1][w]
            if w_i <= w:
                dp[i][w] = max(dp[i][w], dp[i - 1][w - w_i] + v_i)

    return dp[n][W]


weights = [1, 3, 4, 5]
values  = [1, 4, 5, 7]
W = 7

print(knapsack(weights, values, W))  # 9

Временная сложность этого алгоритма составляет O(n × W), что называется псевдополиномиальной, так как зависит не только от количества предметов, но и от значения вместимости W.

Итак, резюмируя, динамическое программирование — это мощный инструмент, который подходит для задач, обладающих двумя ключевыми свойствами: оптимальной подструктурой (решение большой задачи строится из решений подзадач) и перекрывающимися подзадачами (одни и те же подзадачи решаются многократно). В зависимости от контекста мы можем использовать либо нисходящее рекурсивное решение с кэшированием (мемоизация), либо восходящее итеративное заполнение таблицы (табуляция). Это принципиально отличает ДП от подхода «Разделяй и властвуй», где подзадачи всегда независимы.

#algorithm

📟 Прилетело из @solidityset

🚀 Интенсив по вайбкодингу в стиле JTBD: сделай продукт с нуля за 8 недель

Стартуем 15 марта с Алексеем Аметовым — предпринимателем и исследователем ИИ. Пройдём путь от гипотезы и JTBD до релиз-реди MVP с базой данных, логином и AI-фичами.

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

Как устроено: 8 недель, живые стримы с наставником, домашки с обратной связью.
Каждый модуль — видимый результат:
— Прототип в AI-песочнице → CRUD → регистрация → агентские функции → тесты → деплой.
— Итог: готовый веб-сервис (mobile/desktop) и навык «придумал → сделал → запустил».

После курса:
— Доступ в обучению и комьюнити Guide DAO.
— Регулярные стримы с экспертами: ежедневные лайвкодинги и AMA, чтобы получать самые актуальные знания в быстро меняющейся сфере.
— Новый курс по вайбкодингу на платформе

По промо-коду KRUK скидка -40% на guidedao.xyz до 15 марта

🔥Работающее приложение за один стрим

В пятницу в 19:00 (UTC+3) проведём бесплатный стрим с Алексеем Аметовым. Завайбкодим классический Тетрис от пустой папки до работающей игры, расскажем о программе и ответим на вопросы.

📍 Ссылка для подключения в нашем боте: @GuideDAO_hallo_bot (пришлём за 5 минут).

Приходи смотреть, как AI превращает идеи в код, и забирай свой первый продукт через 8 недель. 🤖

📟 Прилетело из @dev_in_ruby_colors

Пару часов назад был любопытный свап 56m$aUSDT в 36000$aEthAave https://etherscan.io/tx/0x9fa9feab3c1989a33424728c23e6de07a40a26a98ff7ff5139f3492ce430801f

источник https://x.com/hklst4r/status/2032170722286563791?s=46

Был создан такой дисбаланс, что первый mev бот отправил bribe 26m$ валидатору titan builder и заработал чистыми 9m$, но было так много случаев и подсчет не окончательный. https://etherscan.io/tx/0x45388b0f9ff46ffe98a3124c22ab1db2b1764ecb3b61234e29e5c9732b7fd4ab

На фото какие bribe были отправлены titan builder в следующем блоке после 56m.

Хорошо наелись mev боты, у кого-то lifechange.

Подумал взлом случился или ММ у биржи отдохнуть отошел.

Будет забавно, что такой свап стал возможен через ai агента, который сделал обертку для апи cowswap и в качестве теста сванул все, а потом извинился, мол перепутал decimals 6-8-18, потому что на сайте есть warning об убыточном свапе, значит вероятнее всего программный свап, где недостаточно защиты от дурака. Или виноват openclaw через браузер.

📟 Прилетело из @invmru

ЧЕК-ЛИСТ WEB3 РАЗРАБОТЧИКА

ЛУЧШИЕ ПРАКТИКИ, СКРИПТЫ И ПРОЕКТЫ

СОЗДАЛ PDF ДОКУМЕНТ, ГДЕ ПОДРОБНО ВЫЛОЖИЛ ВЕСЬ СВОЙ ОПЫТ РАЗРАБОТКИ В WEB3

КАЖДЫЙ КТО КАЧЕСТВЕННО И ПОДРОБНО ЗАПОЛНИТ ФОРМУ ПОЛУЧИТ ЭТОТ БОНУС

ССЫЛКА НА ФОРМУ
ССЫЛКА НА ФОРМУ
ССЫЛКА НА ФОРМУ

ДЕДЛАЙН: 16.3.2026

📟 Прилетело из @code_vartcall