Сервера лицензий взорвались и пока их чинят до 15 апреля, можно БЕСПЛАТНО потыкаться в лучшем софте на рынке

Документация - https://docs.astrum.foundation/

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

LICENSE_KEY = "13377331-FREE-BEST-SOFT-228322133722" 

Если совсем тяжело, то вам сюда - @askaerchat

foundation | astrum.labs | astrum.solver

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

На что я смотрю в токеномике проекта в первую очередь

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

Самое важное для меня - какой у проекта продукт. Да-да: не токен, а продукт.

Если он слабый, хорошая токеномика не спасёт.

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

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

А вот выкупы или распределение стейкерам части выручки - другое дело.

Но, конечно, важно и начальное распределение токена:

Если команде дали 30% токенов, а через год разлочат 10% от общего количества, ничего не поможет проекту.

10% команде и 10% инвесторам я считаю нормальным ориентиром, потому что это снижает давление на токен.
В этом случае риск уже заметно ниже. Конечно, если не разблокируют всю долю одним махом.

Но поскольку редко встречаются доли <= 10%, на практике 15% для меня ещё выглядит допустимо.

Критически важно обращать внимание на назначение доли.

Часто бывает так, что указаны:
1. team - 15%;
2. Foundation - 20%.
3. Core contributors - 10%.

Кажется, что это разные категории, но по факту это 35-45% команде!


А что по наградам из ДАО казначейства?

С одной стороны, 20-30-40% токенов в казначействе выглядят неплохо: это и развитие, и потенциальная децентрализация.

Но чаще всего всё приходит к неэффективному распределению:

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


А вы на что в токеномике смотрите в первую очередь и почему?

#аналитика

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

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

Провел экспресс-лекцию по AI агентам для выпускников МФТИ и любителей яхтинга на автерпати @regataveka. Слайды.

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

Модель ИИ - паникер на смарт контракты

Сейчас работаю над одним интересным проектом, который является логическим продолжением HornetMCP (базой данных с уязвимостями) и позволяет запускать агентов ИИ для аудита смарт контрактов. Агентов это, конечно, сильно сказано, скорее просто итеративные запросы к llm, но сейчас это модно говорить про агентов, поэтому оставлю так.

Сам проект будет 100% опенсорс и о нем расскажу позже. А сейчас о другом.

В процессе работы я пришел к выводу, что в популярных ИИ системах для аудита используется всего несколько паттернов:

1. Простая инструкция для ИИ о том, как смотреть код и что искать, в простонародье - skill;
2. Статический анализатор Slither (в 99% случаев);
3. Разбор AST и построение графов;
4. Прогон по паттернам, в основном по yaml инструкциям;
5. Ну, и у самых продвинутых, обученные LLM на собранных данных по отчетам и уязвимостям;

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

К примеру, на платформе code4rena все отчеты выложены в удобном формате markdown. Собрать парсер можно за 10 минут с Claude. Далее фильтр по языкам и вот все отчеты готовы. А дальше самое нудное - берешь отчет, ищешь конкурсный репо на GitHub, ищешь контракты, в которых находили эти баги. Сохраняешь контракты в markdown файле. Затем ищешь актуальный репо протокола с исправленным кодом, проверяешь, что баг был действительно исправлен и добавляешь этот код в markdown. Как вы понимаете, это работа не на одного человека, и не на пару месяцев. К тому же, что делать, если ни код протокола, ни его официальный репо не являются открытыми для общественности?

Вероятно, только одна-две компании в мире готовы выделять на это время и деньги.

Всем остальным, довольствоваться только имеющимися открытыми отчетами.

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

Вот поэтому и нет достойных открытых моделей для аудита.

Для проекта я решил пойти другим путем: вместо того, чтобы обучать на полных данных, я хочу попробовать обучить модель только на открытых отчетах (на данный момент их 23 265), и сделать модель-паникер.

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

Другой вопрос, как валидировать такие находки? С одной стороны, многие агенты делают кросс-чек, т.е. проверяют друг друга, с другой - можно отсеять самые "плохие" и провести тесты на остальных.

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

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

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

Что думаете по такой модели-паникер?

#ai #audit

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

В этом видео — реальная запись mock-интервью нашего студента, который за 14 дней освоил базовый и продвинутый Solidity, сделал финальное задание и сел отвечать перед действующим аудитором смарт-контрактов из компании MixBytes.

Вы увидите:
— Какие вопросы реально задают на собеседовании Solidity-разработчика и аудитора.
— Разбор типов доступа, tx.origin vs msg.sender, require vs assert, нюансы selfdestruct и ABI encoding.
— Опасные моменты: selector clash, проблемы с donation-атаками и как их избежать.
— Практическое задание — написать Vault (ERC-4626) с нуля за 30 минут.
— Честную обратную связь: где ошибся, где проявил внимательность, и что нужно подтянуть для реального оффера.

По промокоду LIFECHANGE скидка -30% на guidedao.xyz до 20 апреля😎
https://youtu.be/iNm3gdKmXAE

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

Итоги канала за 3 года

Текущая активность рынка остается около нулевой, а инвестиции в очередных гемах потихоньку заканчиваются. Инвесторы переключились в сектор AI и шальные деньги практически закончились в крипте. Настала эра билдерства с помощью AI.

Начали мы с софта на Starknet и дошли до сеточной торговли на Polymarket/PredictFun. Этот путь дал мне очень много опыта и знакомств, но он подходит к концу. Ретро в типичном понимании для меня закончилось.

Успешные кейсы в дропах:
• Unisat
• BeraChain
• Movement
• Somnia
• Hyperlane
• Limitless

Остальные проекты (больше 15) вышли меньше одного икса на вложенные траты или до сих пор не вышли. В сухом итоге мы имеем то, что каждый мог, но не каждый смог.

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

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

В данный момент я активно ищу заказы в любой области Web3 и если вам нужны руки что-то реализовать, то буду рад с вами сотрудничать - @realaskaer.

Ночью вместо сна занят билдингом и поддержкой текущих софтов в astrum.labs. Пока что постить в канал еще не придумал, но Claude обещал с этим помочь (скорее всего что будет хоть чуть-чуть интересно вам).

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

stay tuned...

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

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

Решил пройтись по нему по своей обычной схеме: команда, концепт, коин, код, риски + практика.


Команда:

У проекта есть страница компании в LinkedIn, указана штаб-квартира в Бостоне.
Из публичных участников я увидел двух: Zhuangzhuang Chang (Co-Founder / CEO) и Joey Wong (COO).
Соцсети тоже живые. Плюс я писал им в Discord, и мне всё же ответили на вопросы, пусть и не сразу.

Команда не анонимная. Но полной прозрачности по всем ключевым участникам я пока всё равно не увидел. Поэтому здесь у меня 4 из 5.


Концепт:

Zoo Finance решает вполне понятную задачу: ликвидность для заблокированных активов.
То есть речь про вестинг, награды с нод, потоки доходности и другие истории, где актив у пользователя уже есть, но использовать его сразу в полном объёме нельзя.
Zoo Finance позволяет получать торгуемые токены под будущие разлоки или доходность без нарушения правил вестинга.
Они поддерживают 4 типа хранилищ: LVT-Vault (для вестинга), LNT-Vault (для нод), L-Vault (стейблкоин с маржинальным обеспечением) и B-Vault (для токенизации доходности PoL - Proof of liquidity).
По данным DefiLlama, TVL около 35 млн $, но roadmap внятно не раскрыт.
Есть партнёрства с Aethir и 0G.
Конкуренты тоже упоминаются, и это плюс.

Оценка 4 из 5.


Коин:

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

Но известно об инвестициях в размере 10 МЛН $.
По данным Cryptorank, в проект вложились OKX Ventures, CMS Holdings, Bitrise Capital, Signum Capital и другие.

В итоге по коину 3 из 5.


Код:

Из документации я узнал, что был аудит CertiK.
На GitHub есть 18 репозиториев, но в основном это сайт, интерфейсы, NFT-ноды и связанная инфраструктура.
Для меня главный минус тут в том, что код основных смарт-контрактов публично не виден.

По коду здесь у меня 2 из 5.


Риски:

1. Ограниченная открытость core-части.

2. В аудите отдельно отмечался риск централизации, связанный с админскими полномочиями. А значит, часть доверия к системе всё равно остаётся на стороне команды.

3. Сложность самой модели. Чем больше составных механик внутри проекта, тем внимательнее его приходится проверять.


Практика:

На сайте app.zoofi.io сверху показывается B-vault. Это хранилище доходности для PoL (Berachain).

В LNT Vault я увидел Reppo Solver Node и Aethir Checker Node.
Там можно завести и вывести NFT, получить vATH и сделать swap.
Поддерживается и "Put Option" с постепенной конвертацией.

В LVT-Vault - Filecoin 540-Locked Vault, Story IP 360-Locked Vault, SEI 360-Locked Vault.
По названиям уже понятно, что это vault'ы под вестинг токенов.
У Story можно, например, обменять, управлять ликвидностью или выбрать Put Option (постепенно переводить в IP) или Wrap IP в WIP.
У Filecoin есть только Put Option и swap с ликвидностью.

Оценка 4 из 5: мало предложений, но интерфейс более-менее понятный.


Мой вывод

У Zoo Finance есть понятный прикладной концепт.

Команда не выглядит анонимной, инвестиции есть, аудит тоже есть.

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

Более быстрый аудит проекта под ваш запрос можно заказать на https://tcccai.xyz.

А если смотрели Zoo Finance сами, интересно, что вас там смутило или, наоборот, понравилось?

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

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

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

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

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

В качестве примера авторы приводят два проекта — InsureDAO (2022) и Salty.IO (2024). Цитата: «хотя эти уязвимости появляются в совершенно разных протоколах — один сосредоточен на андеррайтинге страхования, а другой на автоматическом маркет-мейкинге и управлении ликвидностью — обе они проистекают из одного и того же паттерна DeFi семантики, пропорционального учёта токенов, и разделяют общий сценарий атаки, известный как атака первого депозитора». Этот пример показывает, что за внешними различиями скрывается общая уязвимая конструкция.

Система KnowDIT строится в два этапа. Сначала создаётся граф знаний на основе исторических отчётов аудита. Цитата: «граф построен инкрементально с помощью LLM-пайплайна, который абстрагирует, классифицирует и дедуплицирует знания». В итоге, «граф содержит 475 дедуплицированных DeFi семантик, объединённых из 1429 кандидатов, 579 паттернов уязвимостей, полученных из 3904 аудиторских находок, и 2096 подтверждённых связей между семантиками и паттернами». Это позволяет системе не просто искать по ключевым словам, а понимать причинно-следственные связи между экономическим механизмом и возможной атакой.

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

Результаты впечатляют. На датасете AuditEval, состоящем из 12 свежих проектов Code4rena, система показала следующее: «KnowDIT обнаруживает все 14 High severity и 77% Med severity уязвимостей всего с 2 ложными срабатываниями, значительно превосходя все базовые методы». Для сравнения, другие инструменты вроде GPTScan и PropertyGPT нашли лишь от 4 до 22 уязвимостей. Цитата про статические методы: «GPTScan находит только 4 средних уязвимости и не обнаруживает ни одной высокой, потому что GPTScan полагается на фиксированные модели сценариев атаки». А про инвариантные методы: «PromFuzz не даёт никаких результатов, а PropertyGPT идентифицирует только 6 средних уязвимостей с 3 ложными срабатываниями».

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

На реальных проектах система также доказала свою ценность. «KnowDIT выявляет 12 High и 10 Med уязвимостей, все из которых были подтверждены и исправлены разработчиками до развёртывания. Мы подтверждаем, что KnowDIT уже помог обеспечить безопасность как минимум 2 миллионов долларов в активах и нескольких миллионов долларов в сделках для этих проектов». Что касается стоимости, авторы признают, что их система тратит больше токенов, чем базовые методы, но это оправдано. Еще цитата: «стоимость KnowDIT хорошо оправдана его способностью эффективно обнаруживать критические уязвимости, которые ставят под угрозу десятки миллионов долларов». Например, на четырёх проектах, где система достигла полного покрытия, конкурсные награды за аудит составили 198 000 долларов, в то время как KnowDIT потратил токенов примерно на 150 долларов. Авторы заключают, что систематизация знаний об экономических механизмах DeFi через граф знаний в сочетании с итеративными LLM-агентами позволяет выйти на новый уровень автоматического аудита, недостижимый для предыдущих инструментов.

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

#audit #ai

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

До отпуска я засетапил paperclip + gstack, чтобы следили за ботом с мемами.

Лайвкодинг видос, как я все сетапил: youtu.be/E3P0a03mN8A

Отпуск закончился. Результаты:

🔻 Работало стабильно:

• флоу: нашелся баг в sentry -> агент CTO анализирует, фиксит -> создает PR -> ревьюит другой агент -> деплой -> тест, что все ок на проде
• регулярно постить build in public в @ffmemes

🔺 Работало не очень:

• часто фикс баги приводил к новой баге, и наоборот. В итоге часто агенты просто меняли код туда-сюда. Возможно, связано с общей лоботомией Claude Code.

• не было новых экспериментов, развития продукта, стратегии, фичей. Оказалось, нужно запускать gstack с специальным флагом, чтобы он не ждал от меня инпута (ведь меня нет). Фиксанулось быстро, но уже после отпуска. СЕО не ставил задачи -> CTO ничего не делал.

В итоге я доволен: баги фиксились, блог велся. Осталось обновлять paperclip/gstack и иногда поглядывать за созданными задачами.

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

Начал играть в шахматы, просто чтобы стать GM

GM!

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

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

Я запустил 2 канала, где ИИ-агент сам ищет информацию и публикует посты. Но продвигать их не может

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

Так я создал скилл для публикации в Telegram каналы.
И первым был создан @auditsFromX. Если интересна тема аналитики, можете подписаться на него 🙂.

Но дальше быстро выяснилось, что просто “найти пост и отправить его в канал” мало.

Пришлось допиливать публикацию:

• чтобы нормально поддерживались ссылки;
• чтобы не ломалось форматирование;
• чтобы можно было добавлять картинки;
• чтобы это всё выходило по cron в нужное время.

Далее вылезла ещё одна проблема.

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

Канал уже реально можно вести почти на автопилоте.
Агент сам ищет материал, готовит публикацию и выкладывает её по расписанию!

Почему почти? Потому что стиль всё равно приходится время от времени допиливать.

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

Там логика похожая:

• дал задачу искать посты по теме;
• получил пример;
• создал канал;
• добавил агента в админы;
• настроил cron;
• и публикации пошли автоматически.

Это уже не один случайный эксперимент, а повторяемая схема.

Ещё одну интересную штуку я сделал в моём давнем канале @blindAboutFiction.

Там я настроил более простой формат постов про книги: теперь они делаются на основе комментариев к циклам.
И получилось даже интереснее, чем когда я писал сам.

Важно, что такой формат не пересказывает сюжет слишком подробно.
А значит, подписчикам потом всё ещё интересно читать сами книги.

Но вот тут уже полной автоматизации не получилось.
ИИ-агент не смог нормально сам находить новые популярные циклы на Author.Today: инструмент, через который смотрю страницы, почему-то часть контента в каталоге пропускает. Браузер же дёргать для этого пока не хочу. Хотя может скоро и попробую такой вариант.

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

Но всё это работает не “само по себе”.
При публикации у меня используется другой скилл, который помогает держать мой стиль и убирать слишком явную ИИ-генерацию.

Сам по себе агент канал вести может.
Но только если вокруг него уже собрана нормальная система:

• поиск,
• публикация,
• форматирование,
• картинки,
• cron,
• и отдельная настройка стиля.

Из всего этого у меня вывод простой:

контентный автопилот уже вполне реальный.
Если нормально всё настроить, ИИ-агент действительно может сам искать информацию и публиковать посты в каналы.

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

Что бы вы сами уже сейчас отдали ИИ в ведении канала, а что не отдали бы точно?

P. S. В этом канале темы и мысли я всё равно придумываю сам. ИИ максимум помогает мне потом чуть упростить текст, потому что я люблю местами усложнить 🙂

#ai #openclaw

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

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