Як редакція солана.укр перевіряє продукти: методика, докази й межі висновків

Що потрібно зрозуміти спочатку

Щоб зрозуміти, чи підходить певний продукт для конкретного завдання, недостатньо переказати його лендинг. Методика солана.укр розділяє три речі: те, що підтверджено первинним джерелом, те, що реально перевірено у власному тесті, і те, що залишається критерієм для майбутньої перевірки. Оцінки на кшталт «найкращий» або універсальне «рекомендуємо» без заданого сценарію тут не використовуються.

Кожен матеріал у розділі Продукти Solana будується за одним принципом: від завдання людини — через критерії — до компромісів і меж, де наш висновок більше не працює.

Процес поетапно

Перевірку варто починати не з опису продукту, а з питання: яке конкретне завдання намагається вирішити людина і які ризики або залежності виникають саме в цьому сценарії?

Від сценарію до критеріїв

Огляд доцільно прив’язати до сценарію використання. Наприклад: «мені потрібно переказати токени з телефона без комп’ютера» або «мені треба делегувати стейк і зберегти можливість повернути контроль над активами». Саме сценарій визначає, що потрібно перевіряти, а не список функцій на лендингу.

Далі ми формуємо критерії. Це не абстрактний список «безпека, зручність, швидкість». Це конкретні питання, на які має відповідати продукт у межах цього сценарію:

• Контроль над коштами. Хто може підписати транзакцію? Чи потрібен сторонній сервіс для здійснення платежу?
• Відновлення доступу. Що відбувається, якщо втрачено пристрій або seed-фразу? Чи можна відновити доступ без участі команди продукту?
• Дозволи гаманця. Які саме дозволи вимагає підключення, і чи можна їх відкликати?
• Комісії та прозорість. Чи видно користувачеві розмір комісії до підтвердження транзакції? Чи є приховані збори?
• Межі використання. Для кого продукт працює добре, а для кого — ні або взагалі не призначений?

Що є доказом

У матеріалі варто розрізняти три рівні доказовості:

1. Фіксований факт. Щось, що можна побачити в інтерфейсі, документації або смарт-контракті прямо зараз. Наприклад: «у версії інтерфейсу, доступній на момент перевірки, комісія відображалася до підтвердження».
2. Критерій перевірки. Твердження, для якого ще немає достатнього доказу, але зрозуміло, як його перевірити. Наприклад: щоб з’ясувати, чи код після аудиту змінився суттєво, потрібно зіставити ідентифікатор/версію перевіреного артефакту з тією версією, яка фактично працює зараз.
3. Межа знання. Те, чого доступні джерела або проведений тест не дозволяють установити. Наприклад: публічний інтерфейс не доводить, як команда організувала внутрішній контроль ключів, якщо це не підтверджено окремим первинним джерелом.

Ритм висновку

Для матеріалу з власним тестом робоча схема така: сценарій → спостереження → доказ → ризик → межа висновку. Для матеріалу без власного тесту слово «спостереження» замінюється на підтверджене первинним джерелом твердження або чіткий критерій перевірки.

Кому це справді потрібно

Різні типи читачів потребують різної глибини перевірки. Ми намагаємося побудувати матеріал так, щоб кожен знайшов свій рівень:

Тип читача	Що шукає	Де це в матеріалі
Початківець (A0–A1)	Чи безпечно підключити гаманець і чи не втратлю я кошти	Блок «Ризики» та чітко виділені попередження
Активний користувач (A2–A4)	Чи підходить продукт для мого завдання, які компроміси	Критерії за сценаріями, порівняння умов
Продуктовий або бізнес-аналітик (A5–A6)	Межі висновків, методологія, що саме перевірено	Блоки «Межа знання», «Критерій перевірки», фактчек

Якщо ви тільки знайомитеся з екосистемою, варто почати з загального огляду Перевірка продуктів Solana: критерії, сценарії й межі. Там описаний загальний каркас, який застосовується до кожного окремого огляду.

Що може піти не так

Що ми не робимо

• Не проводимо власний аудіт смарт-контрактів. Це завдання спеціалізованих безпекових компаній. Ми можемо посилатися на наявні аудити, але не замінюємо їх.
• Не оцінюємо фінансову дохідність. Будь-які згадки APY, прибутковості чи доходів — це дані з інтерфейсу продукту на момент перегляду, а не наша оцінка або прогноз.
• Не перевіряємо юридичний статус проєктів. Питання регуляції, податків і ліцензування вимагають індивідуальної юридичної консультації.
• Не стверджуємо, що продукт «безпечний». Ми фіксуємо, що саме вдалося перевірити, і де закінчуються наші дані.

Типові помилки при читанні оглядів

Помилка 1: сприймати відсутність згадки про ризик як підтвердження безпеки. Якщо ми не написали про певний ризик, це може означати, що він не стосується цього сценарію — або що ми не мали даних для його перевірки. Завжди дивіться блок «Межа знання».

Помилка 2: ігнорувати регіональні обмеження. Продукт може працювати коректно в одному юрисдикційному контексті й бути недоступним або обмеженим в іншому. Ми фіксуємо регіон перевірки, якщо це релевантно.

Помилка 3: прирівнювати зручність інтерфейсу до надійності. Зручний UX не гарантує безпеку коштів. Ми оцінюємо їх окремо.

Помилка 4: не перевіряти дозволи гаманця після оновлення. Продукт може змінити запитувані дозволи в новій версії. Наш висновок стосується конкретної версії на момент перевірки. Детальніше про це — в матеріалі про Вихід із сервісу: як заздалегідь оцінити можливість забрати активи й відкликати дозволи.

Що фіксувати, якщо проведено власний тест

Коли матеріал справді спирається на власний тест продукту, для відтворюваності варто зафіксувати:

• дату тесту;
• платформу, версію застосунку або інтерфейсу, якщо це релевантно;
• регіон/юрисдикцію, якщо вони впливають на доступність;
• точний сценарій і зроблені кроки;
• що було видно безпосередньо, а що взято з документації;
• що залишилося непідтвердженим.

Якщо такого журналу немає, матеріал не повинен називати методологічний чек-лист «проведеним тестом».

Як перевірити це на практиці

Редакційний матеріал — це стартова точка, а не заміна перевірки перед реальною дією. Перед підключенням гаманця, переказом коштів або делегуванням активів:

1. Перевірте актуальність. Якщо матеріал містить датований власний тест — звірте його версію з поточною. Якщо ні, перевірте поточну документацію та критичні екрани продукту безпосередньо перед дією.
2. Перевірте дозволи. Відкрийте налаштування свого гаманця й подивіться, які саме дозволи має підключений сервіс. Чи відповідають вони тому, що описано в огляді?
3. Зробіть тестову транзакцію. Переказайте мінімальну суму перед тим, як працювати з основними коштами.
4. Оцініть можливість виходу. Переконайтеся, що ви розумієте, як вивести кошти й відкликати дозволи, якщо щось піде не так.
5. Зверніться до фахівця для питань, що стосуються податків, регуляції або значних сум.

Якщо ви хочете зрозуміти загальний каркас перевірки — почніть з Перевірка продуктів Solana: критерії, сценарії й межі. Якщо вас цікавить безпека на рівні мережі — це окремий розділ: Безпека Solana: спокійно, конкретно, перевірено. А якщо ви самі будуєте продукт — дивіться Будувати на Solana: від ідеї до працюючого продукту.

Редакція солана.укр