Як відкритий API Foreso перетворює ринок прогнозів на екосистему розробників Є момент у дозріванні кожної серйозної фінансової платформи, коли вона перестає бути продуктом і стає інфраструктурою. Цей момент настає, коли платформа відкриває свої основні функції зовнішнім розробникам через публічний API, запрошуючи створювати додатки, інструменти та інтеграції на основі того, що платформа вже побудувала. Для @ForesoGlobal цей момент настав. Керівництво з інтеграції відкритого API Foreso тепер доступне, і воно описує не обмежений потік даних чи інтерфейс лише для читання запитів ринку. Це повний, автентифікований, криптографічно безпечний торгівельний API, який надає розробникам повний програмний доступ до всіх основних функцій платформи. Це має значення не лише як технічна віху, а й як стратегічний сигнал про те, до чого прагне Foreso. Платформи, які відкривають свої API на цьому етапі розвитку, чітко передають повідомлення: вони будують для екосистеми, а не лише для аудиторії. Вони закликають розробників розширювати платформу в напрямках, яких не передбачала основна команда, створювати інструменти для конкретних сегментів користувачів та інтегрувати інфраструктуру ринку прогнозів Foreso до додатків, що досягають нових аудиторій. API — це перший крок до того, щоб Foreso став базовим рівнем для ширшого сукупності продуктів ринку прогнозів. Що дозволяє цей API Відкритий API @ForesoGlobal охоплює повний життєвий цикл участі на платформі. Починаючи з подачі запиту на ключ API та автентифікації, через ініціалізацію гаманця та верифікацію особи на основі JWT, до розміщення ордерів з криптографічним підписом EIP-712, запитів балансу активів та видачі винагород. Розробник, який повністю інтегрує цей API, може створити повний додаток для торгівлі на ринку прогнозів на основі інфраструктури Foreso, не торкаючись веб-інтерфейсу Foreso взагалі. Архітектура автентифікації побудована на системі підпису HMAC-SHA256 з трьома заголовками. Кожен запит API повинен містити ID ключа API, мітку часу Unix та підпис запиту, обчислений з HTTP-методу, шляху ендпоїнта, мітки часу та тіла запиту. Підпис обчислюється за допомогою HMAC-SHA256 з секретним ключем і передається у вигляді шестнадцяткового рядка з префіксом sha256=. Ця архітектура забезпечує автентифікацію, часову мітку та виявлення будь-яких змін у запитах. Сервер встановлює допустимий розбіг годинників у ±3 секунди, що запобігає повторним атакам та враховує прийнятний розбіг між клієнтом і сервером. Архітектура гаманця: EOA та Safe Proxy Одним із найбільш архітектурно складних аспектів API #Foreso є його двохгаманцева модель. Кожен користувач працює з основним EOA-гаманцем — зовнішньо власним обліковим записом, який підписує транзакції — та Safe proxy-гаманцем — адресою, яка фактично зберігає активи та вказується як мейкер у ордерах. Ця модель походить від фреймворку Gnosis Safe з багатопідписовими гаманцями та забезпечує значущу безпеку, якої не має проста одногаманцева модель. Safe proxy-гаманець створюється через ендпоїнт enable-trading і повинен пройти триетапну процедуру ініціалізації перед використанням для торгівлі: увімкнення модуля торгівлі, увімкнення конкретного модуля CTF-обміну через процес підпису EIP-712 SafeTx та налаштування білого списку затверджених адрес контрактів. Кожен з цих етапів вимагає специфічних криптографічних операцій підпису, а документація API містить важливі технічні зауваження, якими розробники мають точно дотримуватися, щоб уникнути невдалих перевірок підпису. Особливо важливим є крок з белим списком: значення nonce, повернуте ендпоїнтом prepare, має бути зсунуте вліво на 12 бит перед використанням у операції підпису EIP-712. Це означає, що nonce_for_signing дорівнює цілому значенню nonce, зсунутому вліво на 12 бит. Кррм того, структура EIP-712 використовує поле deadline, тод як параметр API має назву expiration. Саме такими деталями реалiзацiї легко знехтувати — і саме тому документацiя чiтко їх пояснює, що й має робити добре написане керiвництво з інтеграцiї. Розмiщення ордерiв та пiдпис EIP-712 Ендпоїнт розмiщення ордерiв — це найбiльш технiчно складна частина інтеграцiї. Ордери розмiщуються через POST до /v1/orders і вимагають одночасної автентифiкацiї за JWT та пiдписом API. Структура ордеру мiстить ID ринку, ID опцiї, ID позицiї, суму, акцiї, цiну, сторону та тип ордеру, а також пiдпис EIP-712 та повiдомлення для пiдпису. Найважливiше технiчне зауваження у всьому документi стосується того, як має бути побудований пiдпис EIP-712 для ордеру. Документацiя чiтко попереджає: розробники не повиннi використовувати метод encode_typed_data для побудови пiдпису ордеру. Замiсть цього пiдпис має бути побудований за допомогою ручного ABI-кодування. Причина цього вимоги полягає в тому, що перевiрка пiдпису на ланцюжку використовує специфiчний формат кодування, а допомiжний метод encode_typed_data у поширених бiблiотеках Ethereum не генерує вихiднi данi, якi вiдповiдають очiкуваному формату перевiрки на ланцюжку. Будь-який розробник, який проiгнорує це зауваження та використовуватиме стандартний допомiжний метод, отримуватиме пiдписи, якi завжди будуть невдалими при перевiрцi. Ордер також вимагає встановлення поля signatureType на значення 2, що вказує на тип пiдпису SAFE, що вiдповiдає архiтектурi Safe proxy-гаманця. Поле maker має мiстити адресу Safe proxy-гаманця, а не EOA-адресу, хоча саме EOA є суб’єктом, який фактично виконує пiдпис через поле signer. Управлiння балансом та розрахунок блокування API надає практичне й важливе зауваження щодо управлiння балансом, яке повинен зрозумiти кожен розробник, що інтегрує функцiонал торгiвлi. Справжнiй доступний баланс гаманця — це не просто загальна сума USDT на ланцюжку. Вiдкритi ордери блокують частину балансу на майбутню оплату, і ця заблокована сума не врахована у сирому загальному балансi на ланцюжку. Розробник, який запитуватиме лише баланс на ланцюжку й використовуватиме його для визначення доступних коштiв, перебольшить доступний баланс і отримуватиме помилки “недостатньо коштiв” при надсиланнi ордеру. Правильний розрахунок передбачає запит як загального балансу на ланцюжку, так і значення pending_buy_usdt з ендпоїнту query_lock_balance. Справжнiй доступний баланс дорiвнює загальному балансu USDT на ланцюжку мiнус pending_buy_usdt. Включення цього розрахунку до будь-якого додатка для торгiвлi — не додаткова опцiя. Це роздiляє додаток, який працює над可靠но, вiд того, що генерує плутанину й важко дебагиться. Чому це має значення для екосистеми Foreso Вiдкриття API @ForesoGlobal означає початок нового етапу для платформи. Алгоритмичнi трейдери тепер можуть створювати систематичнi стратегii, якi програмно виражають оцiнки ймовiрностей одночасно на багатьох ринках. Розробники можуть створювати мобiльнi додатки, розширення для браузерiв, трекери портфелiв та аналiтичнi інструменти, якi отримують актуальнi данi ринку та взаємод iють з торговою інфраструктурою платформи. Сторонн i платформи можуть інтегрувати функцii ринку прогнозiv Foreso до своїх наявних продуктiv, направляючи своїх користувачiv на ринки Foreso без необхidност i прямого в iдв iдування iнтерфейсу Foreso. Кожен із цих сценарivs розширює охоплення платформи й поглиблює її ликвидн iсть. Б iльше алгоритм iчної участ i означає б iльше активних книг ордерiv та б iльш точн i ц iни. Б iльше сторонн iх інтеграц iй означає б iльше користувачiv, як i знаходять i беруть участь у ринках Foreso.Більше інструментів для розробників означає нижчий бар’єр для входу для наступної хвилі розробників, які хочуть взаємодіяти з платформою програмно. API вже працює. Документація детальна. Інфраструктура готова. Для розробників, які спостерігали за #Foreso й чекали на правильний момент, щоб почати розробку, цей момент — зараз. Почніть торгувати та розробляти на Foreso https://t.co/cfQVL9FGFG