Request

Що таке Request?

Request — це відкритий протокол запитів на криптоплатежі та звіряння платежів, який дозволяє бізнесу або окремому користувачу створювати підписаний запит на оплату, подібний до інвойсу, зберігати дані запиту в децентралізованій інфраструктурі та зіставляти подальші ончейн-платежі з цим запитом без передачі коштів у кастодіальне управління платіжному процесору. Його основна задача — не абстрактне «переміщення токенів», що й так роблять багато гаманців і платіжних шлюзів, а створення верифікованого облікового об’єкта навколо платежу: хто його запросив, яка сума була до сплати, яка валюта чи одиниця обліку використовувалась, де відбулося врегулювання та чи можна автоматично виявити й звірити платіж.

Практична конкурентна перевага протоколу — це насамперед інтеграція у робочі процеси, а не консенсус базового рівня: Request поєднує підписані платіжні запити, зберігання в IPFS, ончейн-якір для CID, події з платіжними референсами, вебхуки, API-інструменти та маршрутизацію платежів у кількох мережах у фінансовий бекофісний примітив, як це описано в документації Request Network та в огляді протоколу. docs.request.network

Request — це не домінуючий Layer 1, не ролап і не великий DeFi‑кредитний ринок; це нішевий прикладний шар для платежів і девелоперських інструментів, побудований навколо криптоінвойсингу, виявлення платежів та звіряння.

Станом на кінець травня 2026 року постачальники ринкових даних відносили REQ до всесвіту токенів з малою та середньою капіталізацією, а не до системно важливих криптоактивів: CoinMarketCap показував Request приблизно на 384‑му місці, тоді як CoinGecko і DeFiLlama наводили суттєво різні показники ринкової капіталізації через відмінні методики розрахунку обігової пропозиції та різницю в часі оновлень. Для такого типу протоколу TVL є обмеженим показником: Request Network page на DeFiLlama показує дані про казначейство і ринок токена, а не класичний TVL для кредитування/AMM, що відповідає ролі Request як платіжної інфраструктури, а не пулу депозитів користувачів. Більш релевантними метриками масштабу є платіжний обіг і оброблена бізнес‑активність: сайт фонду заявляє про понад 2 млрд доларів обсягу оброблених платежів і широку підтримку стейблкоїнів, тоді як керована спільнотою Request Activity Dashboard відстежує щоденні платежі та платіжні обсяги, але не надає чіткої DAU/MAU‑когорти користувачів, порівнюваної зі споживчими гаманцями чи біржами. (coinmarketcap.com)

Хто заснував Request і коли?

Request був заснований у 2017 році Крістофом Ласюї (Christophe Lassuyt) та Етьєном Татаром (Etienne Tatur), обидва були пов’язані з попереднім фінтех‑проєктом MONEYTIS; Y Combinator вказує Request Network як компанію зимового набору 2017 року з офісом у Парижі, де Ласюї зазначений як засновник/CFO, а Татар — як засновник/CTO. Контекст запуску має значення: REQ з’явився під час ICO‑циклу 2017 року, коли багато проєктів намагалися розширити Ethereum за межі простих токен‑трансферів у бік бухгалтерського обліку, комерції та бізнес‑автоматизації. Історичні ICO‑бази даних відносять токенсейл до жовтня 2017 року, з початковою пропозицією приблизно в один мільярд REQ, хоча поточна пропозиція є меншою через спалювання токенів і зміни в токен‑обліку. Такий «винтаж» одночасно є і перевагою, і тягарем: Request пережив кілька ринкових циклів і зберіг робоче програмне забезпечення, але водночас несе репутаційний шлейф, типовий для утилітарних токен‑проєктів епохи 2017 року, чиї ранні наративи часто випереджали близькострокове реальне впровадження. (ycombinator.com)

З часом наратив проєкту звузився.

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

Цю еволюцію видно в оновленнях фонду за 2025 рік: Request випустив API V2, часткові платежі, покращені вебхуки, крипто‑фіатні робочі процеси, пакетні платежі та кросчейн‑функціональність платежів, а не намагався стати новим блокчейном загального призначення. В інституційному вимірі це поворот від «PayPal на блокчейні» до проміжного шару (middleware) для фінансових команд, платіжних сервіс‑провайдерів і криптонативних бізнесів, яким потрібні структуровані платіжні записи в кількох мережах. request.network

Як працює Request Network?

Request не має власного proof‑of‑work, proof‑of‑stake, DAG, набору валідаторів, секвенсора чи механізму консенсусу ролапу. Це гібридний off‑chain/on‑chain протокол, який зберігає більшість даних запитів в IPFS, закріплює ідентифікатор вмісту IPFS (CID) ончейн і обробляє платежі через смартконтракти на підтримуваних ланцюгах розрахунків.

У документації зазначено, що запити створюються шляхом збереження CID у Gnosis Chain, тоді як платежі можуть здійснюватися більш ніж у 20 підтримуваних EVM‑сумісних ланцюгах або в NEAR; баланс за запитом обчислюється шляхом індексації ончейн‑подій платежів, пов’язаних із похідним платіжним референсом. У технічних термінах Request — це протокол прикладного рівня та розробницький API, який успадковує живучість і фінальність від зовнішніх мереж, таких як Gnosis, Ethereum, Base, Arbitrum, Optimism, Polygon та інші, замість того щоб мати власний бюджет безпеки базового рівня. docs.request.network

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

Система не використовує шардінг або ZK‑ролапи як нативні примітиви масштабування, а її модель верифікації ближча до розрахунків на основі індексації подій плюс підписані метадані запиту, ніж до криптографічної перевірки доказів ролапу. Вузли Request (Request Nodes) забезпечують шлюз між IPFS, смартконтрактами та The Graph; фонд експлуатує вузли для зручності розробників, але радить продакшн‑білдерам розгортати власний вузол, що важливо, оскільки залежність від вузлів та API, які хостить фонд, є вектором централізації, навіть якщо базові дані запитів і контракти мають відкритий код.

Приватні запити додають асиметричне шифрування та AES‑шифрування: вміст запиту шифрується за допомогою AES‑ключа, а цей ключ шифрується для публічного ключа кожного зі стейкхолдерів перед збереженням в IPFS. docs.request.network

Які токеноміка та параметри пропозиції у REQ?

REQ — це токен стандарту ERC‑20, спочатку запущений з приблизно одним мільярдом одиниць; його профіль пропозиції доцільніше розглядати як переважно фіксований із помірним механізмом спалювання, а не як інфляційний актив із регулярними емісіями. Станом на кінець травня 2026 року Etherscan вказував контракт ERC‑20‑токена за адресою 0x8f8221afbb33998d8584a2b05749ba73c37a938a з максимальною загальною пропозицією близько 999,416 млн REQ, тоді як CoinMarketCap повідомляв про обігову пропозицію на рівні приблизно 796,7 млн REQ, а CoinGecko показував іншу цифру обігової пропозиції, підкреслюючи, що «обігова» пропозиція залежить від того, як класифікуються резерви, мости та неактивні баланси.

Дані спільнотного дашборду показували, що було спалено приблизно 583 000 REQ — невелику частину від початкової пропозиції, тож дефляційний ефект існує, але сам по собі недостатній, щоб бути центральною інвестиційною тезою. (etherscan.io)

Вартість REQ акумулюється опосередковано, і до цього варто ставитися обережно.

У документації зазначено контракти токена REQ і механізму спалювання, які можуть блокувати, мостити та спалювати REQ під час збереження запитів, тоді як API‑документація описує протокольну комісію в розмірі 5 базисних пунктів на платежі, що обробляються через API, із верхньою межею близько 25 доларів або 25 євро для основних стейблкоїнів, забезпечених USD та EUR.

Це не те саме, що звичайна дохідність від стейкінгу в PoS, і безпека Request не забезпечується стейкінгом REQ так, як безпека Ethereum забезпечується валідаторами ETH. Деякі сторонні описи пояснюють утилітарність REQ у термінах антиспаму, управління (governance), стейкінгу, знижок і незалежності, але поточна офіційна технічна документація не демонструє великого ліквідного ринку стейкінгу, графіка винагород валідаторів чи програми регулярних емісій для власників REQ.

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

Хто користується Request?

Різниця між спекулятивною торгівлею REQ на біржах та реальною утилітарністю мережі Request є суттєвою. Обсяги торгів токена на біржах відображають ліквідність ринку й ротацію інвесторів, тоді як використання протоколу коректніше вимірювати за кількістю створених запитів, виявлених платежів, платіжних обсягів, рівнем прийняття API та інтеграцією у фінансові робочі процеси.

У власному оновленні екосистеми за травень 2025 року Request явно змістив акцент у звітності з загальної кількості транзакцій на «кількість платежів», оскільки створення інвойсів, їх затвердження, відхилення та інші дії можуть роздувати метрики транзакцій без відображення реальної розрахункової активності.

Спільнотний дашборд також показує платіжні обсяги й кількість платежів у підтримуваних мережах, але це волатильні денні індикатори, які не слід інтерпретувати як стабільні показники активних користувачів. У розрізі секторів Request розташований на перетині криптоплатежів, стейблкоїн‑розрахунків, інвойсингу, зарплатних виплат, бухгалтерського обліку та казначейських операцій, а не DeFi‑ліквідності, геймінгу чи NFT‑спекуляцій. request.network

Найпереконливіші докази впровадження — це інтеграції з впізнаваними продуктами для фінансів або крипто‑операцій, а не анонімні лічильники гаманців. Request’s Оновлення екосистеми за 2025 рік відзначали активних білдерів, серед яких Animal Social Club, intrXn, 0 Finance, Allora та Request Finance, тоді як у попередніх оновленнях також згадувалися Huma Finance, BSOS, Joba Network та інші учасники екосистеми.

У жовтні 2025 року Kryptos оголосила, що інтегрувала Request Network API для забезпечення інвойсингу всередині Kryptos Enterprise, при цьому Request надає створення інвойсів, ончейн-розрахунки, вебхуки подій та звірку; в цьому анонсі також зазначався власний знімок впровадження Kryptos із понад 200 000 зареєстрованих користувачів, більш ніж 50 Web3-бізнесами, підключеними на ранніх етапах, та тисячами інтеграцій гаманців, CEX, DeFi й блокчейнів. Ці показники слід розглядати як масштаб партнерської платформи, а не як пряме впровадження з боку власників REQ, але вони все ж значно змістовніші за непідтверджені чутки про партнерства. request.network

Які ризики та виклики стоять перед Request?

Регуляторний ризик для Request є більш тонким, ніж для біржі, кредитного протоколу чи міксера конфіденційності, але він не дорівнює нулю. Публічні пошукові запити та тексти скарг SEC, доступні через результати пошуку, не показують REQ як названий токен у великих позовах SEC проти Coinbase або Binance 2023 року, і станом на кінець травня 2026 року не повідомлялося про широко відомий активний судовий позов SEC, спрямований безпосередньо проти Request Network.

Це не означає наявність «безпечної гавані» з точки зору регулювання. REQ продавався в епоху ICO 2017 року, торгується на вторинних ринках, а регулятори США історично ретельно перевіряли токени, що розповсюджувалися для фінансування розробки протоколів.

Платіжний бізнес протоколу також перетинається з питаннями AML, санкційного скринінгу, KYC, регулювання стейблкоїнів, грошових переказів та податкової звітності, особливо там, де Request підтримує крипто-фіатні розрахунки, скринінг гаманців і бізнес-інвойсинг. Ризик централізації також має практичний, а не суто теоретичний характер: керовані фондом API, дашборд, захищена сторінка платежу, вузли Request та інфраструктура детекції платежів можуть створювати операційну залежність, навіть якщо контракти, SDK та модель даних залишаються з відкритим кодом. sec.gov

Конкуренція є інтенсивною, оскільки проблему кінцевого користувача, яку вирішує Request, можна атакувати з кількох сторін. Традиційні платіжні процесори додають стейблкоїн-розрахунки; централізовані криптопроцесори платежів можуть пропонувати комплаєнс, політику чарджбеків, фіатні оф-рампи та мерчант-дашборди; гаманці та біржі можуть додавати платіжні посилання безпосередньо; а постачальники корпоративного криптообліку можуть вбудовувати звірку інвойсів у власні стеки. У межах Web3 продукти на кшталт Safe, сервіси на зразок Coinbase Commerce, мультисиг-скарбниці, платформи для нарахування зарплати, провайдери стейблкоїн-чекаутів, ончейн-дашборди обліку та кросчейн-роутинг-API можуть кожен «поглинути» частини робочого процесу Request.

Економічна загроза полягає в тому, що комісія Request у 5 базисних пунктів і прив’язане до неї спалення REQ можуть бути «вибиті» конкуренцією, якщо маршрутизація платежів і звірка стануть стандартизованими, «комодитизованими» API-функціями. Захищеність Request залежить від того, чи сприйматимуть розробники об’єкт інвойсу Request, стандарт платіжного референсу та інструменти звірки як стійкий інтеграційний шар, а не як замінну обгортку зручності. docs.request.network

Які перспективи розвитку Request?

Короткостроковий дорожній план Request, схоже, зосереджений на глибині продукту, а не на переосмисленні шару консенсусу. Підтверджена документація за 2025 рік та початок 2026 року вказує на міграцію до API V2, кросчейн-платежі в стейблкоїнах, пакетні платежі, часткові платежі, крипто-фіатні робочі процеси, регулярні (recurring) платежі, кастомізацію комісій, покращення перемикання гаманців і мереж, розширене відстеження платежів та підтримку понад 25 мереж через API-інтерфейс. Кросчейн-платежі особливо важливі, оскільки вони вирішують реальний операційний біль: платники можуть тримати USDT на Optimism, тоді як інвойси виставляються в USDC на Base, і фінансові команди не хочуть вручну управляти бриджами, свопами, газ-токенами й звіркою.

Документація Request зазначає, що кросчейн-платежі підтримують USDC (USDC), USDT (USDT), та DAI (DAI) у мережах Ethereum (ETH), Arbitrum One (ARB), Base та OP Mainnet (OP), при цьому маршрути ранжуються за розміром комісій за транзакції та швидкістю обробки; публічна сторінка продукту для кросчейн-платежів стверджує, що Request використовує маршрутизацію LI.FI, зберігаючи уніфіковану логіку детекції платежів і вебхуків. request.network

Структурною перешкодою є щільність впровадження. Request не потрібно обігнати Ethereum, Visa, Stripe або кожного процесора стейблкоїн-платежів у широкому сенсі; йому потрібна достатня кількість бізнес-додатків, бухгалтерських продуктів, PSP і крипто-нативних фінансових команд, які стандартизуються навколо його шару запитів та звірки. Песимістичний сценарій полягає в тому, що стейблкоїн-платежі вбудовуються безпосередньо в гаманці, банки та біржові API, залишаючи Request невеликим інструментом для розробників з обмеженим впливом на вартість токена.

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

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