Цей розділ об’єднує готові практичні ресурси для роботи з екосистемою Solana: чек-листи безпеки, шаблони для розробки й стартапів, калькулятори для стейкінгу та валідаторів, а також редакційні інструменти. Кожен пункт нижче стисло пояснює призначення ресурсу й веде до окремої активної сторінки з повною версією.
Чек-листи та шаблони безпеки користувача
Ресурси цього блоку допомагають перевірити безпеку гаманця, транзакцій та seed-фрази до того, як ви здійсните дію. Вони не замінюють аудит смарт-контрактів, а закривають типові вектори атак на кінцевого користувача.
Чек-лист безпеки перед транзакцією
Призначення: перевірка транзакції на наявність підозрілих інструкцій перед підписом.
Вхідні дані: деталі транзакції (відправник, одержувач, список інструкцій, токени, суми).
Порядок використання: відкрити чек-лист, пройти крок за кроком, відзначити кожен пункт. Якщо хоча б один пункт не проходить — скасувати транзакцію.
Обмеження: не виявляє складні експлойти всередині програм (smart contract exploits), лише поверхневі ознаки фішингу й підміни адрес.
Матеріал: відкрити окремий практичний ресурс.
Шаблон плану відновлення гаманця
Призначення: документування процесу відновлення доступу до гаманця у разі втрати пристрою.
Вхідні дані: тип гаманця (Phantom, Solflare, інший), спосіб зберігання seed-фрази, наявність додаткових методів відновлення.
Порядок використання: заповнити поля шаблону, зберегти документ у зашифрованому вигляді окремо від seed-фрази.
Обмеження: не підходить для гаманців, де seed-фраза не зберігалася (наприклад, Ledger без резервної копії).
Матеріал: відкрити окремий практичний ресурс.
Чек-лист перевірки фішингового сайту
Призначення: швидка діагностика сайту, що імітує інтерфейс Solana-гаманця чи dApp.
Вхідні дані: URL сайту, скріншот сторінки, поведінка сторінки (вимоги підключити гаманець, запити на підпис).
Порядок використання: пройти пункти послідовно. Два й більше «так» у підозрілих пунктах — високий ризик фішингу.
Обмеження: не захищає від zero-day атак і компрометації самого домену через DNS-спуфінг.
Матеріал: відкрити окремий практичний ресурс.
Чек-лист резервного копіювання seed-фрази
Призначення: контроль створення фізичної резервної копії seed-фрази без цифрового сліду.
Вхідні дані: seed-фраза (працює лише в офлайн-середовищі), матеріал для запису.
Порядок використання: виконати кроки в офлайн-режимі, відзначити кожен пункт, знищити проміжні записи.
Обмеження: не вирішує проблему фізичного знищення чи крадіжки носія. Не замінює апаратний гаманець.
Матеріал: відкрити окремий практичний ресурс.
Шаблон плану реагування на інцидент
Призначення: покроковий план дій після підозри на компрометацію гаманця.
Вхідні дані: тип інциденту (підпис підозрілої транзакції, втрата пристрою, витік seed-фрази), залишок на гаманці.
Порядок використання: діяти строго за кроками шаблону, не пропускаючи етапи ізоляції.
Обмеження: якщо кошти вже виведено, план допомагає лише запобігти подальшим втратам, а не повернути активи.
Матеріал: відкрити окремий практичний ресурс.
Дорожні карти, тести та шаблони для навчання й кар'єри
Ресурси для структурованого входу в екосистему Solana: від першої програми на Rust до першого контриб'ютора у відкритий проєкт.
Навчальна дорожня карта Solana
Призначення: послідовний маршрут від базових понять блокчейну до самостійної розробки на Solana.
Вхідні дані: поточний рівень (початковий, середній, досвідчений розробник з іншого стеку), доступний час на тиждень.
Порядок використання: визначити стартову точку на карті, рухатися за зв'язками між модулями, відзначати пройдене.
Обмеження: не враховує індивідуальні прогалини в конкретних темах (наприклад, відсутність досвіду з Rust).
Матеріал: відкрити окремий практичний ресурс.
Шаблон портфоліо контриб'ютора
Призначення: структура для оформлення внесків у Solana-проєкти (PR, баунті, аудит).
Вхідні дані: список внесків, посилання на PR, опис ролі в кожному.
Порядок використання: заповнити секції шаблону, додати конкретні метрики (кількість виправлень, охоплений функціонал).
Обмеження: не компенсує відсутність реальних внесків — шаблон працює лише з наявним матеріалом.
Матеріал: відкрити окремий практичний ресурс.
Шаблон індивідуального плану розвитку
Призначення: планування навичок на квартал із прив'язкою до ролей в екосистемі (розробник, аудитор, ком'юніті-менеджер).
Вхідні дані: цільова роль, поточний рівень, доступні ресурси для навчання.
Порядок використання: обрати роль, заповнити матрицю навичок, встановити терміни для кожного етапу.
Обмеження: не містить самого навчального контенту — лише структурує процес.
Матеріал: відкрити окремий практичний ресурс.
Чек-лист самодіагностики рівня знань
Призначення: швидка оцінка готовності до розробки на Solana без зовнішнього тестування.
Вхідні дані: чесні відповіді на перелік питань за темами.
Порядок використання: пройти всі блоки, підрахувати частину позитивних відповідей у кожному. Блоки з результатом нижче 70% — зони для підвищення.
Обмеження: спирається на самооцінку, тому схильний до переоцінки чи недооцінки.
Матеріал: відкрити окремий практичний ресурс.
Шаблон профілю розробника для спільноти
Призначення: уніфікований формат представлення в Solana-спільнотах (Superteam, Colosseum, GitHub).
Вхідні дані: стек, досвід, наявні проєкти, контактні дані.
Порядок використання: заповнити поля, адаптувати під конкретну платформу, опублікувати.
Обмеження: не гарантує отримання проєктів чи баунті — лише стандартизує подачу.
Матеріал: відкрити окремий практичний ресурс.
Чек-листи та шаблони для розробки на Solana
Інструменти для кожного етапу життєвого циклу програми на Solana: від написання коду до розгортання в mainnet. Орієнтовані на стек Anchor + Rust.
Чек-лист security review програми
Призначення: попередня перевірка програми перед професійним аудитом або деплоєм.
Вхідні дані: вихідний код програми, список PDA (Program Derived Address — похідні адреси програми), конфігурація Anchor.
Порядок використання: пройти кожен пункт щодо перевірки авторизації, обробки помилок, переповнення та логіки CPI (Cross-Program Invocation — міжпрограмні виклики).
Обмеження: не замінює формальний аудит. Не виявляє економічні вразливості моделі токена.
Матеріал: відкрити окремий практичний ресурс.
Шаблон README для open-source проєкту
Призначення: стандартна структура документації для Solana-програм у відкритому доступі.
Вхідні дані: назва проєкту, опис, інструкції збірки, приклади використання, ліцензія.
Порядок використання: заповнити секції шаблону, видалити порожні блоки, додати специфічні для Solana розділи (розгортання, клієнтські інструкції).
Обмеження: не генерує сам контент — лише структурує його.
Матеріал: відкрити окремий практичний ресурс.
Чек-лист code review
Призначення: уніфікований перелік критеріїв для перегляду PR у Solana-проєкті.
Вхідні дані: diff PR, контекст завдання.
Порядок використання: перевірити кожен критерій (безпека, газ-ефективність, обробка помилок, відповідність архітектурі), зафіксувати зауваження.
Обмеження: ефективний лише за наявності базового розуміння моделі обліку Solana.
Матеріал: відкрити окремий практичний ресурс.
Чек-лист deployment на mainnet
Призначення: контрольний список дій перед деплоєм програми в основну мережу.
Вхідні дані: скомпільований .so файл, ключі деплоєра, конфігурація програми, результати тестів на devnet.
Порядок використання: пройти кроки послідовно: перевірка середовища, балансу, ідентифікаторів програми, тестова транзакція, фінальний розгортання.
Обмеження: не враховує специфічні вимоги окремих інфраструктурних провайдерів (Helius, Triton тощо).
Матеріал: відкрити окремий практичний ресурс.
Чек-лист debugging Solana-програми
Призначення: систематичний підхід до пошуку причин невдалих транзакцій.
Вхідні дані: ID транзакції, логи програми, очікувана та фактична поведінка.
Порядок використання: перевірити логи за стандартним порядком (підписи → інструкції → логи програми → слоти), виключити типові причини (insufficient funds, instruction fallback, slab mismatch).
Обмеження: не допомагає з проблемами на стороні клієнта (frontend, RPC-провайдер).
Матеріал: відкрити окремий практичний ресурс.
Шаблони та чек-листи для стартапів і хакатонів
Ресурси для команд, що готуються до Solana-хакатонів (Colosseum, Hyperdrive) або запускають продукт на ранній стадії.
Шаблон перевірки стартап-ідеї
Призначення: швидка оцінка життєздатності ідеї в контексті екосистеми Solana.
Вхідні дані: опис проблеми, запропоноване рішення, цільова аудиторія, наявні конкуренти в Solana.
Порядок використання: заповнити кожен критерій, оцінити за шкалою. Сума нижче порогу — ідея потребує переформулювання.
Обмеження: не замінює валідацію з реальними користувачами.
Матеріал: відкрити окремий практичний ресурс.
План MVP на чотири тижні
Призначення: розбивка мінімально життєздатного продукту на тижневі етапи для хакатонного чи раннього стартап-циклу.
Вхідні дані: список функцій MVP, розмір команди, технічний стек.
Порядок використання: розподілити функції за тижнями, призначити відповідальних, встановити контрольні точки.
Обмеження: припускає, що команда має базову компетенцію в обраному стеку. Не враховує непередбачувані блокери.
Матеріал: відкрити окремий практичний ресурс.
Шаблон pitch deck
Призначення: структура презентації для інвесторів чи хакатонного журі в екосистемі Solana.
Вхідні дані: опис продукту, ринкові дані, команда, запит коштів.
Порядок використання: заповнити слайди за шаблоном, адаптувати обсяг під формат (3 хвилини для хакатону, 15 для інвестора).
Обмеження: не містить дизайн-системи — лише структуру контенту.
Матеріал: відкрити окремий практичний ресурс.
Робочий чек-лист submission для Solana-хакатону
Призначення: перевірка повноти подачі проєкту перед дедлайном.
Вхідні дані: вимоги конкретного хакатону (перевіряються актуальними правилами на сайті заходу), посилання на репозиторій, демо, відео.
Порядок використання: пройти кожен пункт, переконатися, що всі обов'язкові елементи подачі на місці.
Обмеження: вимоги хакатонів змінюються від сезону до сезону — чек-лист треба звіряти з актуальними правилами.
Матеріал: відкрити окремий практичний ресурс.
Шаблон README для хакатонного проєкту
Призначення: скорочений формат README, оптимізований для журі хакатону.
Вхідні дані: назва, опис, інструкція запуску, посилання на демо, відео-пітч.
Порядок використання: заповнити секції, переконатися, що демо запускається без додаткових налаштувань.
Обмеження: не підходить для повноцінного open-source проєкту — спеціалізований саме для хакатонної подачі.
Матеріал: відкрити окремий практичний ресурс.
Калькулятори та чек-листи для стейкінгу й валідаторів
Ресурси для операторів валідаторів і користувачів, що делегують SOL. Усі фінансові розрахунки мають інформаційний характер і не є індивідуальною інвестиційною порадою.
Калькулятор стейкінгу
Призначення: оцінка прибутку від делегування SOL з урахуванням комісії валідатора та інфляції мережі.
Вхідні дані: сума делегування (SOL), комісія валідатора (%), поточна інфляційна ставка (перевіряється на актуальних дашбордах мережі).
Порядок використання: ввести параметри, отримати орієнтовний річний дохід у SOL. Звірити результат із реальними виплатами за кілька епох.
Обмеження: не враховує складні відсотки з точністю до епохи, зміни інфляції, slashing (покарання валідатора) та податкові наслідки. Для фінансових рішень потрібна експертна перевірка.
Матеріал: відкрити окремий практичний ресурс.
Калькулятор беззбитковості валідатора
Призначення: розрахунок мінімального стейку, при якому валідатор покриває витрати на інфраструктуру.
Вхідні дані: місячні витрати на сервер (USD), курс SOL/USD (перевіряється актуальною ціною), комісія валідатора, очікувана APY мережі.
Порядок використання: ввести дані, отримати мінімальний обсяг делегованого SOL для покриття витрат.
Обмеження: розрахунок чутливий до волатильності курсу SOL та коливань APY. Не враховує одноразові витрати (налаштування, аудит). Для фінансових рішень потрібна експертна перевірка.
Матеріал: відкрити окремий практичний ресурс.
Чек-лист оновлення валідатора
Призначення: безпечне оновлення ПО валідатора без простою та пропущених слотів.
Вхідні дані: поточна версія валідатора, цільова версія, тип оновлення (patch, minor, major).
Порядок використання: виконати кроки послідовно: бекап, перевірка реліз-нотаток, тестове оновлення на тестнеті, оновлення з відкатом.
Обмеження: не враховує специфічні конфігурації інфраструктурних провайдерів. Для major-оновлень рекомендується додатковий аудит процесу.
Матеріал: відкрити окремий практичний ресурс.
Чек-лист підготовки сервера валідатора
Призначення: перевірка відповідності сервера системним вимогам Solana перед установкою.
Вхідні дані: специфікація сервера (CPU, RAM, NVMe, мережа), ОС.
Порядок використання: звірити кожен параметр із мінімальними та рекомендованими вимогами, виконати базові налаштування (sysctl, filesystem, моніторинг).
Обмеження: системні вимоги змінюються з релізами — треба звіряти з актуальною документацією Solana.
Матеріал: відкрити окремий практичний ресурс.
Аварійний runbook валідатора
Призначення: покрокова інструкція для типових аварійних ситуацій (відсторонення, втрата синхронізації, апаратна відмова).
Вхідні дані: тип інциденту, логи валідатора, доступ до сервера.
Порядок використання: ідентифікувати тип інциденту за симптомами, виконати відповідний розділ runbook, зафіксувати результат.
Обмеження: не покриває нетипові сценарії (компрометація ключів, DDoS на рівні провайдера). У таких випадках потрібна оперативна участь адміністратора.
Матеріал: відкрити окремий практичний ресурс.
Редакційні шаблони та дослідницькі ресурси
Інструменти для авторів, дослідників і аналітиків, що створюють контент про екосистему Solana.
Шаблон пакета першоджерел (source pack)
Призначення: стандартизована збірка первинних джерел для аналітичного матеріалу.
Вхідні дані: тема матеріалу, список знайдених джерел (посилання, дашборди, офіційна документація, постійні посилання на блоки).
Порядок використання: додати кожне джерело у відповідну категорію шаблону, позначити тип і надійність, зафіксувати дату звернення.
Обмеження: не виконує пошук автоматично — лише структурує зібране вручну.
Матеріал: відкрити окремий практичний ресурс.
Шаблон фактчекінгу статті
Призначення: перевірка фактичних тверджень у матеріалі про Solana перед публікацією.
Вхідні дані: чернетка статті, пакет першоджерел.
Порядок використання: для кожного фактичного твердження знайти відповідне джерело в пакет першоджерел, позначити статус перевірки.
Обмеження: ефективний лише за наявності якісних первинних джерел. Не замінює експертне рецензування.
Матеріал: відкрити окремий практичний ресурс.
Порівняльна матриця інструментів
Призначення: уніфікована таблиця для порівняння Solana-інструментів у межах однієї категорії (RPC-провайдери, гаманці, фреймворки).
Вхідні дані: список інструментів, критерії порівняння (ціна, швидкість, функціональність, відкритий код).
Порядок використання: заповнити комірки матриці, додати примітки там, де просте «так/ні» недостатньо.
Обмеження: дані швидко застарівають — кожну матрицю треба датувати й періодично оновлювати.
Матеріал: відкрити окремий практичний ресурс.
Шаблон кейсу проєкту
Призначення: структура для написання детального розбору Solana-проєкту (архітектура, економіка, результати).
Вхідні дані: інформація про проєкт (ончейн-дані, документація, інтерв'ю).
Порядок використання: заповнити розділи шаблону послідовно, додати ончейн-докази до кожного твердження.
Обмеження: якість кейсу прямо залежить від доступності даних проєкту. Для закритих проєктів шаблон використовується частково.
Матеріал: відкрити окремий практичний ресурс.
Чек-лист підготовки матеріалу до публікації
Призначення: фінальна перевірка статті перед публікацією на solana.org.ua.
Вхідні дані: готовий текст, ілюстрації, метадані.
Порядок використання: пройти пункти: мовна якість, технічна точність, форматування, посилання, метадані. Усі пункти — «так» перед публікацією.
Обмеження: не замінює редакторське рецензування — це самоперевірка автора.
Матеріал: відкрити окремий практичний ресурс.