Кожен матеріал на solana.org.ua проходить перевірку фактів до публікації. Ця сторінка пояснює, як саме ми верифікуємо дані, які джерела вважаємо достовірними і хто несе відповідальність за фінальне рішення. Сайт є незалежним українським освітнім хабом і не є офіційним представництвом Solana Foundation.
Джерела інформації
Первинні джерела та офіційна документація
Базовим стандартом для нас є звернення до першоджерел. До них належать офіційна документація Solana (Solana Docs), специфікації протоколів, офіційні блоги розробників та пропозиції щодо покращень (SIMD). Якщо твердження стосується механіки мережі — наприклад, роботи консенсусу Proof of History або моделі тарифів (rent) — ми очікуємо, що автор спирається безпосередньо на технічну документацію, а не на перекази з третіх сайтів.
Типова помилка — посилатися на статтю іншого медіа як на «офіційне джерело». Навіть якщо той ресурс якісний, це вторинне джерело, і воно не замінює перевірку за оригінальним текстом документації.
Експертні джерела та інтерв'ю
Коли ми використовуємо експертні оцінки, коментарі розробників або інтерв'ю, обов'язково вказуємо контекст: хто говорить, яка його роль у проєкті чи екосистемі, чи є це офіційною позицією чи особистою думкою. Експертна думка не прирівнюється до факту — ми чітко розмежовуємо ці два типи тверджень у тексті.
Перевірка технічних тверджень
Верифікація коду, конфігурацій та адрес
Технічні матеріали — інструкції, огляди смарт-контрактів на Anchor, пояснення механік PDA (Program Derived Address) чи CPI (Cross-Program Invocation) — потребують особливого підходу. Кожен фрагмент коду, наведений у статті, має бути перевірений на синтаксичну коректність і відповідність заявленій версії інструментарію. Якщо вказано конкретну адресу контракту в мережі Solana, вона верифікується через блокчейн-експлорери.
Приклад: якщо стаття описує розгортання програми на Anchor і вказує команду з конкретними прапорцями, редактор перевіряє, чи ці прапорці відповідають версії Anchor, зазначеній у матеріалі. Невідповідність між версією та синтаксисом — це причина повернути матеріал на доопрацювання.
Перехрестя з офіційними репозиторіями
Коли ми описуємо поведінку програм або бібліотек, намагаємося зіставити твердження з актуальним станом відповідного репозиторію на GitHub. Це допомагає виявити застарілу інформацію: API могло змінитися, метод міг бути позначений як застарілий (deprecated), а логіка — refactorена. Якщо точна перевірка неможлива на момент публікації, ми прямо вказуємо це в тексті.
Перевірка мінливих даних
Курси, ринкові показники, статистика мережі
Дані, що змінюються в реальному часі — курс SOL, TVL (загальна вартість заблокованих коштів) протоколів, кількість транзакцій, активних валідаторів — є найвразливішими до швидкого застарівання. Ми не публікуємо точні поточні значення таких показників як незмінні факти. Натомість дотримуємося таких правил:
- Якщо показник наведено для ілюстрації тренду, вказуємо дату й джерело, з якого взято значення.
- Уникайте формулювань на кшталт «зараз курс становить...» без часової прив'язки.
- Для аналітичних матеріалів перевагу надаємо відносним змінам і діапазонам, а не точним абсолютним цифрам.
Правила оновлення часових даних
Мінливі дані в уже опублікованих матеріалах періодично перевіряються. Якщо показник суттєво змінився і це спотворює сенс статті, ми оновлюємо його з чіткою позначкою дати зміни. Процедура оновлень описана окремо на сторінці Політика виправлень і оновлень — тут ми лише наголошуємо, що наявність часових даних у тексті автоматично створює зобов'язання періодично їх перевіряти.
Хто здійснює перевірку та фінальне затвердження
Процес перевірки фактів розподілений залежно від типу матеріалу:
- Загальноосвітні статті. Автор несе первинну відповідальність за достовірність. Редактор перевіряє ключові факти, джерела та логічну цілісність перед публікацією.
- Технічні матеріали (інструкції, розбір коду, архітектурні огляди). Окрім редактора, залучається технічний рецензент з практичним досвідом розробки на Solana. Рецензент верифікує коректність коду, точність опису механік та відповідність заявленим передумовам і середовищу.
- Аналітичні та ринкові матеріали. Підлягають подвійній перевірці: редакторної та фактичної. Фактична перевірка фокусується на коректності даних, джерел та відсутності завищених або непідтверджених тверджень щодо прибутковості чи надійності проєктів.
Фінальне рішення про публікацію приймає редактор. Якщо між автором і рецензентом виникає розбіжність щодо факту, публікація відкладається до з'ясування. Ми не публікуємо спірні твердження з приміткою «можливо, це не так» — або факт підтверджено, або він не входить до тексту.
solana.org.ua — незалежний ресурс, і ця політика перевірки фактів є нашим внутрішнім стандартом, а не зовнішнім юридичним зобов'язанням. Ми вдосконалюємо її, коли стикаємося з новими типами інформаційних ризиків у екосистемі Solana.