Как я ищу проекты и анализирую их в TCCC AI

Решил специально взять проект с доходностью 2000-4000%, чтобы проверить, что будет не так.

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

Обычно схема простая:
захожу на главную, открываю Old Menu -> Yields -> All Projects и попадаю на страницу DeFi Yield Projects & Protocols.

Дальше сортирую по Median APY и смотрю, что находится сверху.
В этот раз я выбрал Zeebu. У него средний процент на момент написания поста около 4000%!

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

Дальше я перешёл на страницу проекта в DefiLlama, открыл сайт zeebu.fi, вставил его в tcccai.xyz, оплатил аудит и дождался результата.

Результат аудита:
https://tcccai.xyz/output/tccc-modwomobzo7nn/index.html

Что он показал.

1. Команда раскрыта только частично

Отдельные имена, LinkedIn и данные о компании найти можно. Но целостной и понятной структуры управления я не увидел. Для проекта с такими амбициями это уже минус.

2. Идея у Zeebu есть, но вопросов всё равно много

По документации видно, что у Zeebu есть рабочая схема. Описаны роли участников, модель с veZBU, распределение комиссий и условия входа для ключевых участников.

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

3. По метрикам есть серьёзные вопросы

Проект заявляет более 9-10 млрд долларов объёма расчётов и 140+ организаций.

Но при этом на главной странице сайта в момент проверки отображались нулевые значения по Protocol Revenue, Volume Processed и Protocol Yield, а APY и TVL (объём средств в протоколе) были показаны прочерками.

В DefiLlama картина тоже странная: TVL = 0, хотя застейкано около 2.74 млн долларов.
То есть публичные цифры между собой не сходятся.

4. Токеномика выглядит неполной

У ZBU заявлено широкое применение: расчёты, награды, стейкинг, veZBU (заблокированная версия токена с правами/бонусами). Также заявлена комиссия 2% внутри экономики протокола. Но если выручка на практике не подтверждается, то и реальная ценность токена остаётся под вопросом.
Под реальной ценностью считаю то, что создаёт спрос. А реальная прибыль протокола может его формировать через выкупы или награды стейкерам.

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

5. Аудиты есть, но обзор неполный

Аудиты отдельных компонентов - это плюс. Но ключевые части протокола публично раскрыты не полностью.
В итоге проверялись отдельные элементы, а не вся система целиком.

6. Есть риски централизации и управления

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


Вывод

Я выбрал Zeebu специально как показательный пример.
Когда у проекта заявлена доходность на уровне 2000-4000%, для меня это не повод заходить, а повод разбирать его особенно внимательно.

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

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

А вы в каком проекте последний раз участвовали? И для вас доходность 2000-4000% - это ещё возможность или уже сразу красный флаг?



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

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

В этом видео поговорим о том, как сделать проксирование через два сервера, на которых установлено решение Xray. https://www.youtube.com/watch?v=kJxUyVwHZ6c

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

Меня там зун тегнул, достали уже уведомления от лайков

Кому интересно:
https://x.com/nazavod777/status/2049889125424156695
https://x.com/Zun2025/status/2049893401370517986

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

ВАРТКОЛ ОБЩАЕТСЯ

ЗАПУСКАЮ КОНСУЛЬТАЦИИ ПО ВСЕЙ WEB3 ДВИЖУХЕ

ПИШИТЕ

@JERSKREW

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

Сегодня поговорим о том, как настроить MTProxy с Telemt для Telegram, пропустив трафик через промежуточный сервер с помощью XRay (XHTTP). https://www.youtube.com/watch?v=qAYdoyjXr3A

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

Опытные вайбкодеры поймут.

У вас проект. Вроде как все желанные таски сделали.

Иногда хочется закинуть туда промпт а-ля

Почисти код там туда-сюда. Улучши что-нибудь. Сделай то, что я подсознательно хочу, но явно не говорю. Make no mistakes

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

https://github.com/mattpocock/skills/tree/main/skills/engineering/improve-codebase-architecture

А у вас есть такие промты формата “сделай лучше”? Скиньте в чат

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

Как капча снова превратилась в квест

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

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

Для незрячего человека всё работает совсем иначе.

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

Недавно я заполнял форму обратной связи у Kaspersky.

Там нужно было ввести капчу.

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

Раньше в таких случаях мне очень помогал ИИ.

Я мог отправить скриншот страницы в ChatGPT или OpenClaw и попросить прочитать текст с картинки. Это было не идеально, но часто реально выручало.

А недавно это начали запрещать.

Теперь всё чаще получаешь ответ в духе: я не могу распознавать капчу, потому что она создана для защиты от автоматизированных систем.

И вот тут уже становится особенно неприятно.

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

Что остаётся сейчас:

• лезть в код страницы и пытаться найти картинку там;
• пробовать сервисы вроде anti-captcha;
• просить чью-то помощь.

Но и здесь всё не так просто.

Тому же anti-captcha обычно нужна сама картинка капчи, а не просто скрин всей страницы. А достать именно её бывает отдельной задачей.

И я тут ещё не говорю про сложные капчи, где надо что-то перетаскивать или выбирать.

Капча никуда не делась. Просто какое-то время ИИ реально помогал с ней справляться. А теперь и это начали закрывать.

И да, меня это правда бесит.

Но один более удобный обход я всё-таки нашёл.
Для NVDA есть дополнение Cloud Vision на основе Be My Eyes. Оно умеет скринить всё окно и выдавать по нему содержимое. Дальше я просто нахожу капчу и ввожу её вручную.

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

#AI #доступность

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

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

В этом уроке пошагово настраиваем:

Xray на обоих серверах
Caddy как TLS reverse proxy
WARP (WireGuard) как выходной канал
Связку VLESS + XHTTP + TLS без палевного трафика


https://www.youtube.com/watch?v=YdV-09GmezA

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

Примерный список команд из прошлого видео тут https://gist.github.com/bodrovis/4c65951e81e9139585aa2b351eb8203c

Но это самый базовый набор, в идеале ещё врубить BBR, разобраться с DNS, защитить сервер и прочее

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

В этом уроке поднимаем резервный туннель Slipstream. В этом случае трафик будет ходить через DNS с транспортом QUIC. https://www.youtube.com/watch?v=XVtw2UhEDBY

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

Как самому собрать портфель без паники

Когда люди начинают инвестировать, почти всегда приходят одни и те же мысли: а вдруг потеряю всё? что вообще покупать? как не набрать лишнего?

Мой базовый подход простой: портфель должен быть диверсифицирован, а риск - ограничен заранее.

Что это значит на практике:

• высокорисковый актив: обычно не больше 1-2% портфеля;
• вся высокорисковая часть: до 20%;
• средний риск: около 25%;
• основные активы: около 25%;
• стейблкоины: около 30% как резерв.

Если говорить о DeFi, я бы ограничивал его долей до 25% портфеля. И распределял бы эту долю внутри всех категорий, а не как отдельную корзину.

То есть:

• из стейблов часть можно держать в DeFi;
• из основных активов - тоже;
• из среднего и высокого риска - аналогично.

Но есть важное ограничение: даже если протокол кажется надёжным, в один DeFi-проект я бы не закладывал больше 1-2% всего портфеля. Причина простая: протокол могут взломать или заблокировать регуляторы.

Как это может выглядеть в цифрах:

1. 30% - стейблкоины.
Например: USDC, USDT, DAI, USDS и другие.
Это резерв, из которого часть можно держать в DeFi, а часть - вне протоколов.
2. 25% - основные активы.
Базовый вариант: BTC и ETH.
Если хочется добавить что-то ещё вроде SOL или HYPE, я бы делал это с меньшим процентом.
3. 25% - средний риск.
Это уже история про отдельные тезисы: LINK, AAVE, UNI, ENS, NEAR и подобные активы.
Обычно здесь разумнее держать по 2-3% на позицию.
4. 20% - высокий риск.
Вот здесь уже могут быть мемкоины, RWA-токены, отдельные DeFi-истории, AI-токены и другие более агрессивные идеи.
Тут те же 1-2% на актив часто выглядят здоровее, чем попытка угадать одного победителя.

Если держать в DeFi до 25% портфеля, распределение будет примерно таким:

• 7.5% из стейблов,
• 6.25% из основных активов,
• 6.25% из среднего риска,
• 5% из высокого риска.

Я бы распределял эту долю между несколькими протоколами.

Это не рекомендация к покупке, а пример логики распределения риска.

Я не призываю копировать такую структуру один в один. Но сама логика для меня рабочая: основа, резерв и жёсткое ограничение риска на одну идею.
А у вас как устроено распределение?

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

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

Сегодня нашёл интересную штуку (с трудом, так как наши друзья, разрабатывающие xray-core, очень любят писать весь changelog на китайском).

Оказывается буквально несколько дней назад они добавили поддержку Finalmask - это дополнительный слой маскировки трафика поверх обычных транспортов вроде XHTTP/REALITY/TLS.

Там есть несколько вариантов работы. Самый простой это fragment - "мягкая" фрагментация начала соединения. Он режет стартовые пакеты, например TLS ClientHello, на несколько частей с небольшими задержками. За счёт этого DPI сложнее распознать протокол по первому крупному и "красивому" пакету. Плюс fragment в том, что он почти не ломает совместимость и обычно даёт минимум побочек. Это, конечно, не волшебная таблетка, но в целом штука неплохая.

Например, можно при желании использовать это на участке между двумя вашими серверами. Для этого на промежуточном сервере просто пишется вот такое в раздел streamSettings (для outbound)

        "finalmask": {
          "tcp": [
            {
              "type": "fragment",
              "settings": {
                "packets": "tlshello",
                "length": "100-200",
                "delay": "10-20",
                "maxSplit": "3-6"
              }
            }
          ]
        }

На сервере-получателе ничего менять не надо. Учтите, что xray нужно обновить по крайней мере до версии 26.3.27.

Есть и более мощная штука, называется sudoku. Она не просто дробит поток, а меняет его внешний вид по согласованному правилу/паролю между клиентом и сервером. Это сложнее, поэтому обе стороны должны поддерживать sudoku и иметь одинаковые настройки. Плюс sudoku в том, что трафик становится менее похож на стандартный Xray/REALITY/XHTTP и хуже ловится простыми сигнатурами.

Увы, похоже на участке между двумя серверами это особо работать не будет, если на сервере-получателе (сервер Б) стоит caddy и работает как reverse proxy. Зато это можно настроить между клиентом и первым сервером вот так, тоже в streamSettings, но для inbound:

  "finalmask": {
    "tcp": [
      {
        "type": "fragment",
        "settings": {
          "packets": "tlshello",
          "length": "100-200",
          "delay": "10-20",
          "maxSplit": "3-6"
        }
      },
      {
        "type": "sudoku",
        "settings": {
          "password": "длинный пароль",
          "paddingMin": 8,
          "paddingMax": 64
        }
      }
    ]
  }

Но на клиенте обязательно тоже нужно настроить finalmask. Так, v2rayn это уже умеет, там просто жмётся в расширенных настройках finalmask и вставляется json вот такой

{
  "tcp": [
    {
      "type": "sudoku",
      "settings": {
        "password": "тот же пароль",
        "paddingMin": 8,
        "paddingMax": 64
      }
    },
    {
      "type": "fragment",
      "settings": {
        "packets": "tlshello",
        "length": "100-200",
        "delay": "10-20",
        "maxSplit": "3-6"
      }
    }
  ]
}

Далее там можно сформировать share link (она довольно большая тк кодируется json). Другие клиенты это умеют не все. Streisand - нет, happ - для винды вроде да, для мака не похоже, onexray - да, v2rayng - вроде должен, но там судя по всему только в пре-релизной версии. Но думаю в ближайшие месяцы это добавят много где

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