В крипте у ошибки в коде есть цена в долларах — и она видна сразу. Обычный баг во фронтенде правят следующим релизом; баг в смарт-контракте выводит деньги за один блок и обратно их не вернуть. Поэтому вопрос «как писать web3-код в Cursor» неотделим от вопроса «как при этом не потерять деньги» — свои или пользователей.
- EVM/Solidity и Solana/Rust: два разных контура разработки
- Где ИИ ошибается опаснее всего
- Атаки на цепочку поставок целятся в вас
- Торговые боты и автоматизация: где Cursor помогает
- Как заставить Cursor писать безопаснее
- Приватные ключи — железное правило
- Риски Cursor в web3: баг в контракте необратим
- Чек-лист безопасности крипто-разработчика
- Частые вопросы
- Коротко о главном
Показательна свежая картина по опросу разработчиков Solidity (проведён в феврале–марте 2026): 88% используют ИИ-инструменты хотя бы раз в месяц, но код от ИИ сильно доверяют лишь 6%. Почти половина выражает то или иное недоверие. Это здоровый скепсис: люди активно пользуются скоростью, но не выключают голову — и правильно делают. Ниже — как настроить Cursor под крипто-разработку так, чтобы скорость не оборачивалась потерями: под какой стек какие правила, где ИИ ошибается опаснее всего, что за атаки на цепочку поставок целятся именно в крипто-разработчиков и какой чек-лист безопасности стоит держать под рукой.
Всё, что описано ниже, удобно отрабатывать на тестовой сети, где цена ошибки нулевая — поставить Cursor и попробовать можно бесплатно, а платные модели подключать уже под конкретную задачу.
EVM/Solidity и Solana/Rust: два разных контура разработки
Первая ошибка новичка — настраивать Cursor «вообще под крипту». На деле это два очень разных мира, и правила под них нужны разные.
| Контур | Языки | Фреймворки | Библиотеки |
|---|---|---|---|
| EVM (Ethereum и совместимые) | Solidity | Foundry (самый популярный), Hardhat | ethers.js, viem, wagmi, web3.py |
| Solana | Rust | Anchor | web3.js/@solana, Anchor SDK |
По данным того же опроса, у EVM-разработчиков доминирует Foundry как основной фреймворк, а из библиотек чаще всего берут ethers.js и viem (web3.js уже помечена как устаревшая — если ИИ предлагает её, это первый флаг, что он тянет старый код). Практический вывод: заведите отдельные файлы правил в .cursor/rules/ под каждый контур — один для Solidity-проекта, другой для Solana-программы, — и не смешивайте. В правилах имеет смысл жёстко зафиксировать версию компилятора, обязательные библиотеки (например, OpenZeppelin для стандартных контрактов) и запрет на устаревшие паттерны.
Вот как может выглядеть компактное security-правило под Solidity-проект (.cursor/rules/solidity.mdc):
---
description: Security-конвенции Solidity-проекта
alwaysApply: true
---
- Стандартные контракты — только на базе OpenZeppelin, не писать ERC-20/721 с нуля.
- Паттерн checks-effects-interactions обязателен; для внешних вызовов — ReentrancyGuard.
- web3.js запрещена (устарела) — использовать ethers.js или viem.
- Тесты Foundry обязательны: unit + fuzz на каждую публичную функцию.
- Приватные ключи и seed — никогда в коде; только переменные окружения.
Каждая строка тут закрывает конкретный класс ошибок из следующего раздела — правило попадает в контекст на каждый запрос и не даёт агенту «забыть» о безопасности между сессиями.
Где ИИ ошибается опаснее всего
Cursor хорошо пишет «скелет» контракта или бота, но именно в безопасности у ИИ систематические слепые зоны. Вот те, что стоят денег.
Реентранси. Классика: функция вывода делает внешний вызов до обновления баланса, нарушая паттерн checks-effects-interactions. Атакующий успевает повторно войти в контракт и вывести средства несколько раз за один вызов. ИИ воспроизводит эту ошибку регулярно, потому что «рабочий на вид» код и «безопасный» код для него неразличимы.
Уязвимости в неаудированном коде. В январе 2026 протокол Truebit потерял около $26,6 млн (8535 ETH) из-за бага в расчёте цены токена: контракт был задеплоен ещё в 2021 году, оставался закрытого кода и не проходил публичного аудита — точный класс уязвимости security-исследователи установить так и не смогли. Токен TRU обвалился почти на 100%. Мораль не про ИИ как таковой — а про то, что скорость генерации не отменяет классических багов и обязательного аудита.
Solana: адрес против PDA. Инфраструктурный провайдер Helius прямо предупреждает: ИИ-модель может не увидеть разницы между обычным адресом и PDA (program-derived address). Если она забудет обработать seeds или проверку владельца, получится корректный Rust, но некорректная Solana-программа — компилируется, выглядит правильно, а безопасность дырявая.
| Симптом | Риск | Что делать |
|---|---|---|
| Внешний вызов до обновления баланса | реентранси, вывод средств | правило checks-effects-interactions + ReentrancyGuard |
| Арифметика без проверок в старом коде | переполнение/ошибки расчёта | свежий компилятор, обязательный аудит |
| Solana: путаница адрес/PDA | контракт компилируется, но небезопасен | явная проверка seeds/ownership, ревью человеком |
| ИИ предлагает web3.js | устаревшая библиотека | правило «только ethers.js/viem» |
Атаки на цепочку поставок целятся в вас
Это самый недооценённый риск 2026 года, и он бьёт именно по крипто-разработчикам — потому что у них на машине кошельки и ключи.
Фейковые расширения. Разработчик из России установил вредоносное расширение «Solidity Language» для Cursor и потерял около $500 000 в крипте (случай задокументирован Kaspersky и рядом security-изданий). Цепочка была такой: расширение тянуло PowerShell-скрипт, ставило средство удалённого доступа, а финальной нагрузкой шли бэкдор и стилер, который выгребал браузеры, почту и крипто-кошельки. Отдельный фейк маскировался под легитимного автора (juanbIanco вместо juanblanco) и накрутил около 2 млн «скачиваний» против 61 тысячи у настоящего расширения — по счётчику загрузок отличить подделку было невозможно.
Slopsquatting. Академическое исследование (USENIX Security 2025, 2,23 млн примеров кода на 16 моделях) показало: ИИ-модели выдумывают несуществующие имена пакетов в среднем в 19,7% случаев, и — что хуже всего — 43% выдуманных имён повторяются при каждом повторе того же промпта. Детерминированная галлюцинация — подарок для атакующего: он заранее регистрирует популярное выдуманное имя, и код от ИИ сам начинает его подтягивать. Реальный кейс: пакет react-codeshift был выдуман моделью, исследователь зарегистрировал его первым — и к тому моменту на него уже ссылались 237 репозиториев на GitHub. Отдельно северокорейская группа Famous Chollima целенаправленно публикует вредоносные npm-пакеты с крипто-названиями (вроде @solana-launchpad/sdk), рассчитывая именно на разработчиков из крипты и финтеха.
Защита простая по формулировке и строгая по исполнению: не доверяйте именам, которые предложил ИИ. Расширения ставьте только от проверенного автора (сверяйте издателя, а не счётчик загрузок), а каждый незнакомый пакет проверяйте вручную в реестре перед установкой — существует ли он, кто мейнтейнер, сколько живёт.
Торговые боты и автоматизация: где Cursor помогает
Отдельная большая область — не контракты, а боты: торговые, арбитражные, мониторинговые, боты для сбора он-чейн-данных. Здесь Cursor раскрывается лучше всего, потому что задача ближе к обычной разработке на Python или TypeScript: подключить биржевой API или RPC-узел, разобрать ответы, посчитать сигнал, отправить ордер. Скелет такого бота (обвязка вокруг web3.py, ccxt или клиента конкретной сети) агент собирает быстро и в целом корректно.
Но и тут крипто-специфика меняет правила. Во-первых, ключи API и приватные ключи кошелька — только в переменных окружения, никогда в коде, который индексируется и уходит в контекст ИИ (об этом отдельно ниже — это не рекомендация, а условие). Во-вторых, у ботов, которые реально торгуют или двигают средства, цена логической ошибки та же, что у контракта: неверно посчитанный размер позиции или незакрытая проверка баланса — это прямые потери. Поэтому боевого бота стоит сначала гонять на тестовой сети или в режиме «сухого прогона» (paper trading), где ордера считаются, но не отправляются, и только потом подключать реальные средства. В-третьих, любые внешние библиотеки для работы с биржами и сетями — тот же вектор цепочки поставок: проверяйте пакет перед установкой, а не ставьте вслепую по имени, которое предложил агент.
Как заставить Cursor писать безопаснее
Хорошая новость: инструменты, которые двигают генерацию в сторону безопасности, уже есть.
- OpenZeppelin Contracts MCP. OpenZeppelin выпустил MCP-сервер, который встраивает их проверенные security-паттерны прямо в генерацию (работает с Cursor и другими редакторами): вы просите контракт, а на выходе получаете код по стандартам OpenZeppelin, а не «как придумалось модели». Для стандартных токенов (ERC-20/721/1155) и governance это резко снижает класс типовых ошибок.
- Официальный шаблон Foundry. Документация Foundry прямо даёт промпт-шаблон для ИИ: использовать только инструменты Foundry (
forge,cast,anvil,chisel), избегать небезопасных паттернов и непроверенных внешних вызовов, писать unit- и fuzz-тесты. И главная строка оттуда: «всегда ревьюйте и тестируйте сгенерированный код перед продакшеном». - Правила проекта под безопасность. В
.cursor/rules/закодируйте обязательные reentrancy guards, контроль доступа, запрет устаревших библиотек — это применяется к каждому запросу, а не живёт в голове. - Актуальные доки через @Docs. Подключите документацию вашей сети (Solidity, Anchor, конкретной цепочки) через
@Docs, чтобы агент опирался на свежие спецификации, а не на устаревшие тренировочные данные.
Отдельно про MCP-серверы: официальная документация Cursor прямо предупреждает, что MCP-сервер может исполнять код от вашего имени — ставьте только из доверенных источников, разберитесь, что сервер делает, и никогда не хардкодьте секреты, используйте переменные окружения.
Приватные ключи — железное правило
Оно короткое и не обсуждается: приватный ключ или seed-фразу нельзя вставлять ни в один облачный ИИ-чат, промпт или файл, который индексируется. Всё это уходит на внешние серверы и может осесть в истории или логах. Нет ни одного легитимного сценария, где боту, сервису или ассистенту нужна ваша seed-фраза.
Практически: заведите .cursorignore и закройте в нём .env, .env.*, файлы ключей (*.key, *.pem), приватные конфиги — чтобы они не попадали в индексацию и в контекст агента. Для ботов и деплой-скриптов держите ключи в переменных окружения или в отдельном менеджере секретов, а не в коде, который видит ИИ.
Риски Cursor в web3: баг в контракте необратим
Где подход даёт трещину:
- Цена ошибки — деньги. В отличие от обычного софта, баг в контракте необратим; «поправим потом» здесь не работает.
- ИИ не отличает рабочий код от безопасного — реентранси, переполнения, путаница PDA воспроизводятся регулярно и требуют человеческого ревью и аудита.
- Цепочка поставок под прицелом — фейковые расширения и slopsquatting целятся именно в крипто-машины; счётчик загрузок и «это же предложил ИИ» — не гарантия.
- Аудит незаменим. Никакая скорость генерации не отменяет внешнего аудита перед деплоем контракта с реальными деньгами (кейс Truebit — про это).
- Инструменты новые и меняются — MCP-серверы, правила, официальные шаблоны появились недавно; их поведение и безопасность стоит перепроверять.
Баланс: это не «не пишите крипту в Cursor». Скорость реальна и полезна — прототип бота или контракта собирается в разы быстрее. Но в web3 ИИ — это ускоритель для черновика, а не замена аудитора. Разделение простое: ИИ пишет и объясняет, человек и аудит решают, что уходит в продакшен.
Если сам подход «описал задачу — получил код» вам ещё в новинку, полезно сначала разобраться с идеей вайб-кодинга на нейтральном примере, а уже потом переносить его на код, за которым стоят деньги.
Чек-лист безопасности крипто-разработчика
- Отдельные
.cursor/rules/под EVM/Solidity и под Solana/Rust, с фиксированными версиями и библиотеками. .cursorignoreзакрывает.env, ключи, seed-фразы — приватные данные не индексируются.- Расширения — только от проверенного издателя (сверять автора, не счётчик загрузок).
- Каждый незнакомый пакет — ручная проверка в реестре перед установкой.
- OpenZeppelin Contracts MCP и официальный промпт-шаблон Foundry для генерации по стандартам.
- MCP-серверы — только из доверенных источников, секреты в переменных окружения.
- Обязательный внешний аудит контракта перед деплоем с реальными средствами.
- Приватный ключ/seed — никогда в ИИ-контекст, ни при каких условиях.
Частые вопросы
Можно ли писать смарт-контракты в Cursor? Да, и это заметно быстрее ручного старта. Но код от ИИ — черновик: реентранси, переполнения и Solana-специфика (PDA) воспроизводятся регулярно, поэтому обязательны ревью и внешний аудит перед деплоем.
Почему Cursor предлагает web3.js, если она устаревшая?
Из-за перекоса тренировочных данных: старого кода в интернете больше. Лечится правилом «только ethers.js/viem» в .cursor/rules/ и подключением свежих доков через @Docs.
Что за атаки на расширения и пакеты? Фейковые расширения (кейс с кражей около $500 000) и slopsquatting — регистрация выдуманных ИИ имён пакетов. Защита: ставить только проверенное издательство и вручную проверять каждый незнакомый пакет.
Можно ли дать боту приватный ключ через Cursor?
Нет. Ключи и seed-фразы не должны попадать в ИИ-контекст или индексируемые файлы — используйте переменные окружения и .cursorignore.
Заменяет ли ИИ аудит смарт-контракта? Нет, и это принципиально. Пример Truebit ($26,6 млн, потерянные на неаудированном контракте закрытого кода) показывает, что классические баги никуда не делись — внешний аудит обязателен для любого контракта, который держит или двигает реальные деньги, независимо от того, писал его человек целиком или частично ИИ.
Коротко о главном
Cursor реально ускоряет крипто-разработку — от прототипа бота до каркаса контракта. Но web3 отличается тем, что ошибка стоит денег и необратима, поэтому роли надо развести жёстко: ИИ пишет черновик и объясняет, а решают безопасность человек и аудит. Настройте два контура правил, закройте секреты через .cursorignore, проверяйте расширения и пакеты руками, генерируйте по проверенным паттернам (OpenZeppelin, Foundry) — и никогда не отдавайте приватные ключи ИИ. Тогда скорость останется вашим преимуществом, а не входным билетом в чужой стилер.
Все рабочие привычки — правила, .cursorignore, проверка пакетов, прогон тестов — стоит отработать на тестовой сети без риска для денег, и только потом подключать реальные средства. А если хотите сперва оценить сам редактор целиком, его сильные и слабые стороны собраны в обзоре возможностей и цен Cursor.
