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

Багато хто при першому знайомстві з APRO автоматично класифікує його як "ще один децентралізований оракул". Це судження не є хибним, але якщо зупинитися лише на цьому, можна легко пропустити основну проблему, яку він намагається вирішити.

З іншого боку, APRO більше схожий на "нижчий рівень архітектури, що надає можливість системам на ланцюгу приймати складні рішення".

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

Традиційні оракули зазвичай вирішують питання "чи є дані". Але справжня проблема полягає у тому, чи можна довіряти цим даним.

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

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

У практичному застосуванні режим push підходить для сценаріїв із найжорсткішими вимогами до оперативності даних — наприклад, для розрахунку цін деривативів або тригера для кредитних розрахунків у мілісекундному режимі; режим pull створений для застосунків, які потребують викликів за потребою і чутливі до вартості. Такий двонапрямний дизайн дозволяє різним типам протоколів знаходити свої оптимальні рішення.