Нещодавно виявлено болючу тенденцію: купа розробників смарт-контрактів при підключенні до таких топових оракулів, як Apro, думає, що достатньо просто "підключити і все". Здається, що якщо джерело даних зламається, можна просто перекласти провину.

Мрії. Насправді ж реальність набагато жорсткіша: у ту секунду, коли ви підключаєтеся до джерела даних, ви стаєте останнім бар’єром безпеки. Оракул надає "перевірені на блокчейні факти", але як ви їх використовуєте і в яких цілях — це вже ваша відповідальність.

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

Розробники повинні пам’ятати ці чотири залізні правила:

**Перше: дані — це лише сировина, розробник — справжній капітан**

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

Наприклад, раптовий стрибок або падіння ціни, що виходить за межі теоретичних коливань — чи налаштовано у вашому контракті механізм автоматичного обмеження? Чи дозволяєте ви цій аномальній ціні викликати масштабне ліквідацію? Коли мережа збоїть або дані затримуються, ви просто чекаєте, чи автоматично переключаєтеся на резервний безпечний план? Ці речі джерело даних не може контролювати.

**Друге: якість коду визначає все**

Найкращі дані — це марна справа, якщо код має вразливості. Не можна використовувати функцію, яка не пройшла ретельного тестування і має ризик переповнення пам’яті, для обробки цінової інформації з реальними грошима.

Говорячи простою мовою, рівень вашого коду має відповідати обраним даним. Це не опція, а основа.