Создам Telegram бота, будучи незрячим.

Привет. Меня зовут Денис. Я - незрячий программист: создаю Telegram ботов и анализирую проекты в криптосфере.
Ниже напишу, чем вам могу быть полезен.

Создам Telegram ботов для решения ваших задач.

Что можно сделать при помощи бота?

1. Систему лояльности. Пользователь общается в чате и получает баллы. Покупает товар или услугу, сканирует QR-код или отправляет ссылку, получает скидочные баллы.

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

3. Каталог. Товары или услуги в боте с возможностью связи с вами для заказа.

Этапы работы:

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

- Реализую. Срок: от двух недель. Во время работы сверяюсь с брифом для максимальной точности.

- Тестируем. Если соответствует брифу недочёт, исправляю. Это позволит избежать неточностей в работе или ошибок. Благодаря этому после сдачи заказа вам не придётся тратить время на правки или исправления ошибок у меня или кого-то ещё.

- Запускаем у вас. Это позволит не зависеть от меня. То есть вы становитесь полноправным владельцем. Нет зависимости от того, буду ли я заниматься ботами и будет ли работать сервер с ними.

Стоимость: 20 000 руб.

Интеграция с внешним сервисом: + 10 000 руб.:

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

Для заказа пишите в @blind_dev_contact_bot

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

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

Solana с нуля

2025 год подходит к концу, 61 день остался до прекрасного момента как мы вместе с вами соберемся в этом канале, для подведения итогов 2025 года

И чтобы эти 61 день прошли еще красочнее, я делаю последний донабор в наш второй поток обучения Solana

Участие абсолютно бесплатное, главное - ваша заинтересованность и готовность работать

Заполняй форму, если готов:

forms.gle/iKWBefVESm5wZo1k8
forms.gle/iKWBefVESm5wZo1k8
forms.gle/iKWBefVESm5wZo1k8

Дедлайн: Понедельник 11:11 по Киеву

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

@r8scan_bot починил пользуйтесь
если меня просто экс по айпи опять не забанят

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

первое правило дата сайнца:

нельзя отойти от компа, пока не запустил что-то обучаться или хотя бы большой SQL считаться.

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

Rug Pull

Буквально «rug pull» означает действие, при котором кто-то внезапно выдергивает коврик из-под ног другого человека, в результате чего тот неожиданно падает.

В сфере децентрализованных финансов (DeFi) rug pull означает мошенничество, при котором разработчики продвигают новый токен или платформу, а затем внезапно выводят ликвидность (LP) или продают свои активы в больших количествах, что приводит к резкому падению стоимости токена.

Это одна из форм «риска централизации». Риск централизации охватывает широкий спектр уязвимостей, таких как контроль одной организацией над обновлениями, функциями приостановки или критическими параметрами. В этой статье мы сосредоточимся конкретно на rug pull с целью вывода средств, когда администраторы используют свои привилегии для вывода средств, внесенных пользователями или хранящихся в протоколе.

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

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

Недавним примером этой уязвимости является инцидент с протоколом Zunami в мае 2025 года, в результате которого было потеряно 500 000 долларов в виде залога zunUSD и zunETH. Согласно rekt.news, это не было сложным взломом с использованием флэш-кредитов или манипуляций с ценами. Скорее, это было простое злоупотребление чрезмерно мощной функцией администратора. Лицо с «доступом в режиме бога» вызвало функцию withdrawStuckToken(), опустошив содержимое хранилища.

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

Вот пример того, как злонамеренный или скомпрометированный администратор может опустошить хранилище и осуществить rug pull:

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

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


contract VulnerableVault {
    address public admin;
    // Maps user addresses to their deposited balances
    mapping(address => uint256) public userBalances;


    constructor() {
        // The deployer of the contract becomes the admin
        admin = msg.sender;
    }


    /// @notice Allows users to deposit Ether into the vault.
    /// A 1% fee is applied to the deposit and sent to a fee pool.
    function deposit() public payable {
        require(msg.value > 0, "Deposit must be greater than zero");


        // Calculate 1% fee. This fee theoretically belongs to the protocol.
        uint256 fee = msg.value / 100; // 1% of deposited amount
        uint256 amountToDeposit = msg.value - fee;


        // User's balance is updated with their net deposit.
        userBalances[msg.sender] += amountToDeposit;
        // The 'fee' part of msg.value remains in the contract's total balance.
        // It is not explicitly tracked in a separate variable, which is a design flaw
        // if only fees should be withdrawable by admin.
    }


    /// @notice Allows users to withdraw their deposited funds.
    /// @param amount The amount to withdraw.
    function withdraw(uint256 amount) public {
        require(userBalances[msg.sender] >= amount, "Insufficient balance");


        // Decrement user's balance and transfer funds.
        userBalances[msg.sender] -= amount;
        payable(msg.sender).transfer(amount);
    }


    /// @notice Admin can withdraw *any* amount from the contract's balance.
    /// This is the rug pull vulnerability! This simulates a `withdrawStuckToken()`-like function.
    /// @param amount The amount to withdraw from the contract.
    function adminRugPullWithdraw(uint256 amount) public {
        require(msg.sender == admin, "Admin control required"); // Only admin can call.


        // NO checks to ensure 'amount' is only from accrued fees.
        // The admin can withdraw any amount up to the contract's total Ether balance (address(this).balance),
        // effectively stealing user deposits, as user deposits also contribute to address(this).balance.
        // This function treats all funds in the contract as if they are available for the admin to take.
        require(address(this).balance >= amount, "Insufficient contract balance for withdrawal");
        payable(admin).transfer(amount); // Transfer chosen amount to admin.
    }
}

В этом контракте VulnerableVault функция adminRugPullWithdraw позволяет администратору снимать любую сумму эфира с общего баланса контракта. Это критическая уязвимость. Если ключ администратора скомпрометирован или если лицо, контролирующее ключ, решает действовать злонамеренно (как это было поставлено под сомнение в деле Zunami в отношении «внутренней работы»), оно может использовать эту функцию для снятия всего эфира, депонированного в хранилище, включая средства пользователей.

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

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

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

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

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

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

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


contract SecuredVault {
    address public admin;
    // Maps user addresses to their deposited balances
    mapping(address => uint256) public userBalances;
    // This variable *only* accounts for fees that the admin can withdraw.
    // It's explicitly separated from user balances.
    uint256 public totalAccruedFees;


    constructor() {
        // The deployer of the contract becomes the admin
        admin = msg.sender;
    }


    /// @notice Allows users to deposit Ether into the vault.
    /// A 1% fee is applied to the deposit and sent to a fee pool.
    function deposit() public payable {
        require(msg.value > 0, "Deposit must be greater than zero");


        // Calculate 1% fee
        uint256 fee = msg.value / 100; // 1% of deposited amount
        uint256 amountToDeposit = msg.value - fee;


        userBalances[msg.sender] += amountToDeposit; // User's principal
        totalAccruedFees += fee; // Accrue the fee for the protocol
    }


    /// @notice Allows users to withdraw their deposited funds.
    /// @param amount The amount to withdraw.
    function withdraw(uint256 amount) public {
        require(userBalances[msg.sender] >= amount, "Insufficient balance");


        userBalances[msg.sender] -= amount;
        payable(msg.sender).transfer(amount);
    }


    /// @notice Admin can only withdraw the total accrued fees.
    /// This prevents the rug pull as admin cannot touch user principal.
    /// @param amount The amount of fees the admin wishes to withdraw.
    function adminWithdrawFees(uint256 amount) public {
        require(msg.sender == admin, "Admin control required");
        // Crucial check: Ensure admin only withdraws what's available in fees,
        // as tracked separately from user principal.
        require(totalAccruedFees >= amount, "Insufficient accrued fees for withdrawal");


        totalAccruedFees -= amount; // Deduct the withdrawn amount from available fees
        payable(admin).transfer(amount); // Transfer only the requested fee amount to admin
    }
}

В этой улучшенной версии SecuredVault функция adminWithdrawFees больше не взаимодействует напрямую с балансами пользователей. Средства пользователей защищены, поскольку они хранятся отдельно от переменной totalAccruedFees. Это снижает риск злоупотребления правами администратора в отношении пользователя, устраняя основную проблему, наблюдавшуюся при атаке Zunami.

#rugpull

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

gm. long time no see

давно не было персональных постов в канале — пора наверстывать.

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

в крипте пропал шарм

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

ai головного мозга

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

и даже сегодняшний хакер балансера настолько увлекся вайб-кодом, что забыл удалить дебаг console. log’s из продакшн кода лол https://x.com/AdiFlips/status/1985311134308573467

рынок всё ещё живой

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

из личных саксессов (или нет) в октябре, например:

yieldbasis — писал мониторинг пулов и автодепозит btc в свободные слоты (попал во все 3 волны расширений капок), legion ico благодаря 930 degen score за красивый github, застейкал всё на несколько лет

ton nft — рандомный колл от @danokhlopkov и теперь мой профиль украшает голый торс Дурова

арбитраж meteora tge + flash crash 10-го — ручной арбитраж, без автоматизации. думаю, что самые находчивые арбитражники 10 числа смогли получить оч хорошее roi

что дальше

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

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

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

из крипто нарративов вижу по прежнему интерес к перп мете, с которой понемногу начал работать как внутри 0y, так и на персональных проектах. помимо этого, с августа весь мой твиттер фид в prediction markets, думаю тоже не буду пропускать мимо себя. кстати, у Родиона Chaotic Good сегодня вышел крутой материал — классное интро для входа в направление! https://rodionlonga.medium.com/4da19615a4ed

degen.insuline.eth fw25 season coming

ps: открыл комменты

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

Самая лучшая стратегия в DeFi фарминге – следовать штанге Талеба.

80% активов мы распределяем в самые безопасные смарт-контракты и не гонимся за доходностью. Отличный пример – Balancer, ведь контракты живут уже 5 лет и вероятно команда предприняла все меры по безопасности за это время.

На оставшиеся 20% мы можем рискнуть для ассиметричных вознаграждений. К примеру, Stream дают неплохую доходность на xUSD сейчас

NFA

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

Честно говоря, даже не знаю, что вам рассказать за последнее время - разве что на днях сброшу конфиг для создания контрольной суммы и подписи а-ля keyless для скриптов Go. Но из забавного... Только вернулся из Швеции, так там некая девушка в баре очень удивилась, что есть страна Латвия и там даже говорят на латышском языке (она заявила, что впервые слышит - аналогичная история как-то была в Турции). Пришлось показывать на карте - больше того, мы соседи, лететь всего час. Невероятное рядом. https://www.youtube.com/watch?v=oskzPTiN3ew

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

А, да забыл сказать. Для тех, кто всё ещё почему-то использует angular_rails_csrf - буду продолжать его поддерживать, раз уж люди просят (хотя было большое желание пометить его как deprecated). Но что ж, продолжим хардкор с XSRF token для будущих версий Rails https://github.com/bodrovis/angular_rails_csrf/pull/56

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

Solodit запускает свое API

Самый популярный сайт для поиска уязвимостей по отчетам запускает свое API для тех, кто создает ботов и ИИ агентов по анализу смарт контрактов. Довольно горячая тема на сегодняшний день, поэтому команда прекрасно попадает в тренды запросов. По словам разработчика из команды, за первый день они собрали уже более 400 заявок на закрытое бета тестирование!

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

Во-первых, качество отчетов. На текущий момент на Solodit я нашел всего 43 486 результатов:

1. High - 6859 results
2. Medium - 12263 results
3. Low - 21032 results
4. Gas - 3332 results

Заметьте, что Low составляет большую часть. С уверенностью могу сказать, что половина Medium - будет либо повторами, либо мусором (вспомните хотя бы Medium уязвимости, которые были таковыми в 2023 году и сейчас уже в статусе QA), а также около четверти от High - (повторы и "натянутые" Medium, от аудиторов, которые хотели доказать свою значимость). В итого остается около 10 000 адекватных отчетов. Можно также смело убрать из них половину тех, где будет не качественное описание уязвимостей, без примеров кода и POC.

Я уже делал небольшой обзор на эту проблему в этом посте: https://news.1rj.ru/str/solidityset/1482

Во-вторых, проблема поиска. Как они решили проблему поиска и ранжирования уязвимостей? Да, понятно можно поискать по ключевым словам: reentrancy, replay, defi. В результате будет определенное количество уязвимостей. И да, мы можем проранжировать их через опцию High/Medium/Low, отсеяв, например, последние два. Но тогда вероятные релевантные баги из Medium будут отброшены! А это все может стать хорошей подсказкой к поиску других багов в протоколе, который вы аудируете сейчас.

В-третьих, доступы по API. С большой долей уверенности скажу, что будут немного бесплатных запросов в месяц для всех пользователей, и увеличенные лимиты - для платных подписчиков. Делать все открытым и бесплатным - значит обречь себя не нескончаемый поток запросов, каких может быть тысячи в секунду! А это большая нагрузка и на сервер и на ожидание других пользователей. Остается вопрос цены. Не думаю, что будет большой, но все же.

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

А вы будете пользоваться новым сервисом API для поиска багов? Как бы вы решили эти проблемы?

#api #bugs

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

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

несколько примеров из личной практики, чтобы было понятно:

названия эндпоинтов

хочешь получить параметры рынка — maxOi, decimals, minAmount?
логично назвать это getMarketConfiguration или getMarkets, верно?
но Lighter делает это через Order API и называет endpoint orderBooks.
всё, что тебе нужно — спрятано где-то в ордерах, удачи.

best bid / best ask / last price

вместо отдельного лёгкого эндпоинта — orderbookDetails,
где, кроме нужных трёх чисел, лежит ещё 30 лишних полей.
запрос, конечно, выполняется дольше обычного,
и, возможно, именно поэтому при каждом движении цены >3%
их API стабильно ловит performance issues.

тикеры на Hyperliquid

консистентность? зачем.
в allMids ты получаешь ключи вида:
@40, 2Z, BTC, PURR/USDC, kPEPE в одном ответе.
Tier S exchange, напомню.

подписи EIP-712

Hyperliquid честно пишет в доке:
«вы, вероятно, не разберётесь, просто используйте SDK».
ну а зачем улучшать UX подписей — пусть страдают разработчики.

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