Request

Что такое Request?

Request — это открытый протокол криптоплатежных запросов и сверки, который позволяет бизнесу или пользователю создавать подписанный платёжный запрос, похожий на инвойс, хранить данные запроса в децентрализованной инфраструктуре и сопоставлять последующие ончейн‑платежи с этим запросом без передачи контроля над средствами платёжному провайдеру. Его основная задача — не абстрактное «перемещение токенов», чем уже занимаются многие кошельки и платёжные шлюзы, а создание проверяемого учётного объекта вокруг платежа: кто его запросил, какая сумма была к оплате, какая валюта или единица учёта использовалась, где произошёл расчёт и может ли платёж быть автоматически обнаружен и сверен.

Практическое конкурентное преимущество протокола — это интеграция в рабочие процессы, а не консенсус базового уровня: Request объединяет подписанные платёжные запросы, хранение в IPFS, ончейн‑якорение CID, события payment-reference, вебхуки, 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 как компанию набора Winter 2017 из Парижа, с Лассюи в роли Founder/CFO и Татюром в роли Founder/CTO. Контекст запуска имеет значение: REQ появился во время ICO‑цикла 2017 года, когда многие проекты пытались расширить применение Ethereum за пределы простых переводов токенов в сторону бухгалтерского учёта, коммерции и бизнес‑автоматизации. Исторические ICO‑базы данных относят токенсейл к октябрю 2017 года с начальным предложением примерно в один миллиард REQ, хотя текущее предложение ниже после сжиганий и изменений токен‑учёта. Эта «эпоха» одновременно даёт и преимущество, и обременение: Request пережил несколько рыночных циклов и сохранил рабочее ПО, но также несёт репутационный шлейф утилити‑токенов образца 2017 года, чьи ранние нарративы часто опережали краткосрочное внедрение. (ycombinator.com)

Со временем нарратив проекта сузился.

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

Эта эволюция заметна в обновлениях фонда за 2025 год: Request выпустил API V2, частичные платежи, улучшенные вебхуки, сценарии crypto‑to‑fiat, пакетные платежи и кроссчейн‑платежный функционал вместо попыток стать новой блокчейн‑платформой общего назначения. В институциональных терминах поворот идёт от «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 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 через антиспам‑функцию, голосование, стейкинг, скидки и независимость, но в текущей официальной технической документации не представлено ни крупного ликвидного рынка стейкинга, ни расписания наград валидаторам, ни регулярной программы эмиссии для держателей REQ.

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

Кто использует Request?

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

В собственном обновлении экосистемы за май 2025 года Request явно сместил акцент отчётности с общих чисел транзакций на «количество платежей», поскольку создание, одобрение, отклонение инвойсов и другие действия могут раздувать метрики транзакций, не отражая реальной расчётной активности.

Дашборд сообщества также показывает платёжный объём и количество платежей в поддерживаемых сетях, но эти показатели волатильны по дням и не должны интерпретироваться как стабильные метрики активных пользователей. С точки зрения отраслей Request находится на пересечении криптоплатежей, расчётов в стейблкоинах, инвойсинга, payroll, бухгалтерского учёта и казначейских операций, а не 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, мультисига для казначейств, платформ для payroll, провайдеров стейблкоин‑checkout, ончейн‑дашбордов для бухгалтерии и кроссчейн‑routing API могут по отдельности поглощать части рабочего процесса Request.

Экономическая угроза состоит в том, что комиссия Request в 5 базисных пунктов и связанный с ней механизм сжигания REQ могут быть «выжаты» конкуренцией, если маршрутизация платежей и сверка станут стандартизированными, малоотличимыми API‑функциями. Защищённость 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 или каждого процессора стейблкоин‑платежей в широком смысле; ему нужно, чтобы достаточное количество бизнес‑приложений, бухгалтерских продуктов, платёжных провайдеров и крипто‑нативных финансовых команд стандартизировались вокруг его слоя запросов и сверки. Медвежий сценарий заключается в том, что стейблкоин‑платежи будут встроены непосредственно в кошельки, банки и биржевые API, а Request останется небольшим инструментом для разработчиков с ограниченным захватом стоимости токена.

Бычий сценарий более сдержан, чем чисто ценовой нарратив: если стейблкоин‑расчёты продолжат расширяться и финансовым командам понадобятся проверяемые, некостодиальные, мультичейн‑записи платежей, сочетание Request из подписанных запросов, платёжных ссылок, вебхуков, пакетных потоков, регулярных платежей и кроссчейн‑маршрутизации может оставаться жизнеспособной инфраструктурой.

Будущее проекта, таким образом, в меньшей степени зависит от спекулятивного спроса на REQ и в большей степени от того, сможет ли Request конвертировать свою длинную операционную историю в устойчивые интеграции, прозрачные метрики использования и токен‑модель, чья экономическая связь с реальными платежами достаточно ясна для того, чтобы институциональные пользователи и держатели токена могли её «андеррайтить».