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

Перспективы ASTER с точки зрения токеномики.

Если кто вдруг не знает - это spot и perp dex с поддержкой Binance.

Источники, как всегда, Tokenomist и Cryptorank.

Начальное распределение:

1. Airdrop - 40.7% по Cryptorank и 53.5% по Tokenomist.
В чём различие? Cryptorank выделили отдельно Initial Airdrops 12.8%, которые полностью разблокированы на TGE.
Описание из Tokenomist:
Стимулы для трейдеров, разработчиков сообществ и ключевых заинтересованных сторон экосистемы. На TGE выпущено 704 млн, а затем линейный выпуск в течение 80 месяцев.

Много выделяется сообществу - это хорошо. Но вот количество после TGE большое, что способно вызвать давление.

Давайте подсчитаем...
40,7 / 80 = 0,50875% в месяц. В принципе нормально, но ещё надо смотреть, сколько команда и другие получают в разлоках.
80 месяцев = 6 лет и 8 месяцев.

Но смущает, что на днях распределили 4%, а в ноябре обещают 2.5% - это нифига не 0.5% в месяц!

2. Ecosystem & Community - 30%. Разблокировано 10.4%.
Это миграционный пул для владельцев APX, экосистемные гранты, маркетинговые инициативы и первоначальная ликвидность на биржах.
Из документации узнал, что разлок в течение 20 месяцев (за исключением конвертации APX).

Возьмём всю сумму, что неправильно, но пусть будет так. Разделим на 20 месяцев. Получается, что разблокировка по 1.5% от общего количества ежемесячно - это многовато.

Вместе с аэрдропами получится > 2%.

3. Team - 5%.
Радует, что < 10%, и что все пока заблокированы. Разлок через год с постепенным распределением в течение 40 месяцев. Получается, что примерно по 0.125% в месяц.
Доля команде распределена между основными участниками и консультантами Aster.

4. Treasury - 7% (всё в локе).

Средства Фонда зарезервированы для будущих инициатив по стратегическому росту, оперативных резервов и инициатив в области управления.
Средства Фонда не будут поступать в оборот после TGE и будут оставаться полностью заблокированными до тех пор, пока не будут использованы с помощью механизмов, одобренных руководством.

Как понимаете, радовался я рано: получается, что команде выделено в итоге 12%. Хоть все равно не намного больше чем 10%.

Правда непонятно, что это за механизмы. Если имеется в виду распределение командой - плохо. Если ДАО будет - хорошо. Так что тут стоит наблюдать.

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

5. Liquidity & Listing - 4.5% - все разблокированы.
Зарезервировано для размещения на биржах, чтобы облегчить загрузку ликвидности.

Как пишут в доках, в честь официального запуска $ASTER часть доходов от протокола будет направлена ​​на выкуп $ASTER:

• выделение средств Фонду Aster на долгосрочный стабилизационный выкуп;

• Распределение вознаграждений за управление с целью стимулирования участия в децентрализованной системе управления Aster.

Судя по выше написанному, ДАО будет - это хорошо. Но надо будет наблюдать.

По данным Cryptorank, 17 октября разлок 0.98% токенов. Они все выделяются на Ecosystem & Community.
И так до 17 сентября 2026, где будет в рынке 1.1%. Добавится выделение токенов на Team.

А с 17 июня 2027 разлок 0.12% лишь команде. Но стоит помнить про airdrop и Treasury, которые добавляются к указанным разблокировкам. Так что получается сумма не такая уж и маленькая.

По моим вычислениям, будет этап с 2-3% разлоком ежемесячно. А это немало. И это без учёта казначейства.

Итог:

Проект интересен тем, что команде выделяется немного и нет всплесков в разлоках.
Но токены из казначейства могут быть выделены в большом количестве в любой момент - это создаёт риск обрушения. Поэтому если решите холдить $ASTER, стоит найти кошелёк Treasury и мониторить его.
Также вызывают опасения большие суммы на аэрдроп. Разлок на 40 месяцев предполагает выделение по 0.5% ежемесячно, но в октябре и ноябре суммарно распределяют около 7% всех токенов - это создаёт дополнительный риск давления на цену.

Плюс, Aster без открытого кода и вероятно не децентрализован. Это тоже доп. риск

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

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

Как я разлюбил пополнение и вывод крипты по P2P, и что начал использовать.

В 2021 году надо было пополнить USDT. Делал это 2 дня подряд, так как появлялась такая возможность.

Первый день = первый заказ - успешно.

Следующий день. Выбираю исполнителя, получаю кошелёк Яндекс.деньги.
Пробую отправить - кнопка неактивна.

Решаю посмотреть, в чём причина:
Вставляю адрес кошелька исполнителя первого заказа - кнопка активна.
Заменяю на текущего - кнопка активная.

Отправляю.

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

В итоге пришлось просить вернуть. Вот только мне написали, что тот кошелёк заблокирован был - придётся ждать. Через месяца 2 скидывают всё же, но лишь 20-50% от суммы (не помню уже точно).

После этого понял, что лучше, когда реквизиты одни и те же, и провайдер пополнения проверенный.

Также сталкивался с тем, что в P2P иногда исполнители морозились: приходилось обращаться в поддержку за отменой сделки, а это время. И бывало, что такое 2 раза подряд!

А в 2023-2024 году понял, что не зря избегал P2P: за них начали блокировать карты.

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

Но выход есть!

Crypton exchange!

Удобный Telegram бот от Crypton и Koex, который позволяет обменивать крипту на фиат и обратно, в том числе наличкой в офисах многих стран.

Каков процесс?

1. Запускаем бота.

2. Создаём обмен.

3. Выбираем откуда и куда, сумму вводим.

4. Используем мой промокод
blind
на первый обмен.

5. С вами свяжется оператор, и скажет, куда отправлять активы для обмена.

Мне нравится. Думаю и вам тоже.

Не забывайте про промокод blind, который даст скидку на первый обмен.
Каков процент не знаю: зависит от суммы и пути обмена.

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

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

$METеорщики становитесь раком. ща ЧЕКЕРить вас будем.

Парни, пост лень писать, проверяйте свою нищету в боте или ручками на сайте метеоры.

@meteora_check_bot
@meteora_check_bot
@meteora_check_bot

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

$MET AntiDrain
Metora анонсировали чекер дропа
Дата клейма - 23 октября

Если ваш кошелек был украден и на нем стоит Авто-Вывод, то команда Degen Software готова помчь вам с клеймом аирдропа

У нас уже было три успешных кейса на подобных клеймах:
• WormHole — 45000 $W (success ~95%)
• TNSR — 25000 $TNSR (success ~95%)
• GRASS — 23156 $GRASS (success ~95%)

Что требуется от вас:
• Предоставить приватный ключ кошелька, который доступен для клейма дропа

Правила (обяз. к прочтению):
• Не отправляйте кошельки, которые не подходят под критерии дропа, я их просто пропущу

Условия работы:
• В случае УСПЕШНОГО клейма дропа команда забирает себе 30% от ваших токенов!
• Отправка ваших токенов на ваши кошельки займет Время! Это будет проходить НЕ МОМЕНТАЛЬНО

Обратите внимание:
• Мы не даем никаких гарантий на успешность клейма этого дропа
• Кто первый отправит приватные ключи, тому в случае УСПЕХА и будут отправлены токены, никаких выяснений о том, кто же на самом деле владелец кошелька ПРОХОДИТЬ НЕ БУДЕТ

Подача заявок на АнтиДрейн
В ЛС - @crose212
Форма - https://forms.gle/hE3A5Q6FHt4iXmre9

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

бля..

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

Насколько хороши аудиторские отчеты?

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

Для этого была разработана система взвешивания. Основной вклад вносили три компонента: детальное описание проблемы, рекомендации по ее устранению и наличие доказательства концепции (PoC). Наибольший вес был назначен доказательству концепции, так как его наличие существенно повышает практическую ценность отчета. Дополнительные баллы начислялись за включение фрагментов кода на Solidity и за уровень серьезности самой уязвимости.

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

Статистический анализ полученных данных выявил любопытные закономерности. Средний вес по всем отчетам составил 0.32 при медианном значении 0.27. Это означает, что половина всех проанализированных отчетов имеет оценку ниже 0.27. Распределение весов является скошенным, с явным пиком в области низких значений, что указывает на преобладание относительно кратких или неполных описаний уязвимостей.

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

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

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

#notsosmart

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

Мои #новости этой недели: разработка нового бота, исправление в Price informer Bot и другое.

1. Недели 3 назад сделал скрипт, который позволяет указать X аккаунты, а затем отфильтровать их по разным параметрам:
Moni score (минимальный и максимальный), количество смартов, минимум упоминаний, мин. упоминаний смартами, минимальный тир и число постов.
В понедельник сделал Telegram бота @moniCheckerBot. Теперь вы можете запустить, указать список, оплатить Telegram Stars, а затем получить результат.
Повторный анализ бесплатный в течение часа.

Новый опыт - получение Telegram Stars от пользователей с открытием доступа.

2. Опять перевёл статью на Английский при помощи одного сервиса и опубликовал на Medium.
В начале опубликовал в виде страницы на своём сайте, но почему-то не получилось полностью. Пришлось загружать html файл. Но в итоге опубликовал.

3. Разузнал про то, как внедрять ИИ в проект. Как буду один свой обновлять, сделаю.

4. В @price_informerBot исправил ошибку с редактированием сообщений.
После обновления ID коллбеков при нажатии стали создаваться новые сообщения вместо изменения текущего. Оказалось, что я не указал ID сообщения. Теперь всё норм.

Всё. Благодарю за внимание. Хороших выходных!

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

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

Replay атака. Часть 1

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

Для защиты от таких атак разработчики используют несколько важных инструментов:

1. Nonce («одноразовое число»): в блокчейне nonce — это уникальный последовательный счетчик, привязанный к адресу пользователя. Требуя, чтобы каждое подписанное действие включало текущее nonce пользователя, контракт может гарантировать, что каждое действие будет выполнено только один раз. После обработки nonce увеличивается, поэтому подпись не может быть использована повторно.

2. Параметры, специфичные для цепочки: с появлением нескольких блокчейнов, совместимых с Ethereum Virtual Machine (EVM) (например, Ethereum, Polygon, Arbitrum и т. д.), приватный ключ и адрес пользователя часто одинаковы во всех сетях. Подпись, созданная для контракта на Ethereum, может быть действительна для идентичного контракта на Polygon, если она не содержит данных, специфичных для этой сети. Включение block.chainid в подписанные данные связывает подпись с одной конкретной сетью, предотвращая межсетевые атаки повторного воспроизведения.

3. Разделитель домена: это криптографический механизм, стандартизированный в EIP-712, который связывает подпись с конкретным контекстом приложения. Это уникальный хеш, содержащий такую информацию, как название контракта, версия, адрес и chainid. Это гарантирует, что подпись, предназначенная для одного децентрализованного приложения (DApp), не может быть повторно использована в другом, обеспечивая надежную защиту как от межсетевых, так и от cross-DApp атак повторного воспроизведения.

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

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

Эта проверка сосредоточена на распространенном недостатке реализации: увеличение nonce пользователя только после успешного завершения транзакции. Если транзакция завершается неудачно из-за временных обстоятельств (например, в контракте недостаточно средств), nonce остается неизменным. Подписанное сообщение по-прежнему остается действительным и может быть повторно использовано любым лицом после устранения обстоятельств.

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

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

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.0;


import "openzeppelin-contracts/contracts/access/Ownable.sol";
contract RewardSystem is Ownable {
    mapping(address => uint256) public rewards;
    mapping(address => uint256) public nonces;


    constructor() Ownable(msg.sender) {}


    // For PoC simplicity, we don't use real signatures
    function claimReward(address user, uint256 amount, uint256 nonce, bytes memory signature) external {
        require(rewards[user] >= amount, "Insufficient reward balance");
        require(nonces[user] == nonce, "Invalid nonce");


        // Vulnerability: Signature can be replayed once contract has funds
        bytes32 messageHash = keccak256(abi.encode(
            user,
            amount,
            nonce
        ));


        // For PoC, use a simple signature check
        bytes32 signedHash = abi.decode(signature, (bytes32));
        require(signedHash == messageHash, "Invalid signature");


        // Attempt to transfer reward
        rewards[user] -= amount;
        (bool success,) = msg.sender.call{value: amount}("");


        // Vulnerability: Nonce is only incremented if transfer succeeds
        if (success) {
            nonces[user]++;
        } else {
            revert("Transfer failed");
        }
    }


    // Helper function to add rewards - only owner can call
    function addReward(address user, uint256 amount) external onlyOwner {
        rewards[user] += amount;
    }


    // Helper function to receive ETH
    receive() external payable {}
}

Функция claimReward увеличивает значение nonce пользователя только в случае успешного перевода ETH. Если в контракте нет ETH, msg.sender.call завершится с ошибкой, транзакция будет отменена, а значение nonces[user] не будет увеличено. Подпись пользователя, которая была действительна для этого значения nonce, остается действительной.

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

Как исправить: используйте nonce в каждом пути выполнения!

Убедитесь, что nonce используется (помечается как использованный) в каждом пути выполнения, независимо от того, завершилось ли оно успешно или неудачно. Лучшая практика заключается в том, чтобы использовать nonce сразу после его проверки и убедиться, что транзакция не будет отменена после этого момента. Таким образом, даже если транзакция завершится неудачно, nonce все равно будет увеличен, что предотвратит атаки повторного воспроизведения.

// Corrected claimReward function (inside RewardSystem)
function claimReward(address user, uint256 amount, uint256 nonce, bytes memory signature) external {
    require(rewards[user] >= amount, "Insufficient reward balance");
    require(nonces[user] == nonce, "Invalid nonce");


    // For PoC, use a simple signature check
    bytes32 messageHash = keccak256(abi.encode(user, amount, nonce));
    bytes32 signedHash = abi.decode(signature, (bytes32));
    require(signedHash == messageHash, "Invalid signature");


    // REMEDIATION 1: Consume nonce right after validating it
    nonces[user]++;


    rewards[user] -= amount;
    (bool success,) = msg.sender.call{value: amount}("");


    if (!success) {
        // Revert the reward deduction if transfer failed
        rewards[user] += amount;
    }
    // REMEDIATION 2: No revert to ensure nonce is consumed
}

С этим исправлением, даже если передача не удалась, nonce становится недействительным. Злоумышленник не может повторно использовать подпись, поскольку контракт теперь будет ожидать nonce + 1.

#replay

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

Всем привет
В среду, 22 октября в 18:00 по мск, будем разбирать очень полезный и редкий по содержанию кейс. Не сухая теория, а разбор реального проекта Resupply.fi — от архитектуры до хака.

Часто видите у проекта надпись «аудит пройден» и думаете, что всё безопасно? А зря. Мы вместе с крутым специалистом посмотрим, как это работает изнутри.

На стриме разберем реальный кейс проекта Resupply.fi
От детального анализа архитектуры и поиска уязвимостей до разбора хака, который случился после аудита.
Посмотрим, как проходит процесс due diligence, какие красные флаги можно заметить заранее, как анализировать уже имеющиеся аудиты у проектов.
Вести стрим будет Олег, аудитор из MixBytes с 15-летним опытом разработки.
Олег проводит стримы по аудиту в Guide Dao

Guide Dao это образовательное комьюнити в сфере web3 разработки с 1400+ активными участниками, где можно совместно расти и билдить проекты с опытными ребятами

1. Пожизненный доступ, изучай материал когда хочешь

2. Web-3 разработка, Solidity-разработка, DeFi-аналитика, аудит смарт-контрактов, создание AI-агентов

3. Спикеры из 1inch, Nomis, Parity, MixBytes, Pessimistic Security и др

4. Ежедневные стримы - АМА, лайвкодинги и пр.

5. Разработка собственных проектов и возможности будущего трудоустройства

Изучить подробнее и получить бесплатные бонусы можно в боте @GuideDAO_hallo_bot

По промокоду blind будет приятная скидка

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

Жду вас 22 октября (среда) в 18:00 по мск. Не пропустите

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

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

Сегодня разберём стандарты ERC-734 и ERC-735: основу ончейн-идентичности ONCHAINID. Это цифровой паспорт в блокчейне, который хранит ключи, роли и подтверждения (claims). Через него можно управлять доступами, делегировать права и проходить KYC прямо в смарт-контрактах.

ERC-734 отвечает за управление ключами и мультисиг-действиями, а ERC-735 - за работу с утверждениями: кто подтвердил, что ты прошёл верификацию, получил лицензию или право владения активом. https://youtube.com/live/lWXQne3MNTU?feature=share

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