У крипті помилка в коді має ціну в доларах — і вона видна одразу. Звичайний баг у фронтенді виправляють наступним релізом; баг у смарт-контракті виводить гроші за один блок, і повернути їх назад уже не вийде. Тому питання «як писати 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.
