Request

Czym jest Request?

Request to otwartoźródłowy protokół żądań płatności w kryptowalutach oraz uzgadniania płatności, który umożliwia firmie lub użytkownikowi stworzenie podpisanego żądania płatności przypominającego fakturę, zapisanie danych tego żądania w zdecentralizowanej infrastrukturze oraz dopasowanie późniejszych płatności on-chain do tego żądania bez przekazywania opieki nad środkami procesorowi płatności. Jego głównym celem nie jest „przesuwanie tokenów” w oderwaniu od kontekstu – co już robi wiele portfeli i bramek płatniczych – lecz stworzenie weryfikowalnego obiektu księgowego wokół płatności: kto jej zażądał, jaka kwota była należna, jaka waluta lub jednostka rozrachunkowa została użyta, gdzie nastąpiło rozliczenie oraz czy płatność może zostać automatycznie wykryta i uzgodniona.

Praktyczną przewagą protokołu jest więc integracja z procesami biznesowymi, a nie konsensus warstwy bazowej: Request łączy podpisane żądania płatności, przechowywanie w IPFS, kotwiczenie identyfikatorów treści (CID) on-chain, zdarzenia z referencjami płatności, webhooki, narzędzia API oraz wielołańcuchowe kierowanie płatności w prymityw finansowo‑backoffice’owy, jak opisano w dokumentacji Request Network i przeglądzie protokołu. docs.request.network

Request nie jest dominującą siecią Layer 1, rollupem ani dużym rynkiem pieniężnym DeFi; to niszowa warstwa aplikacyjna zorientowana na płatności i narzędzia developerskie, zbudowana wokół fakturowania w krypto, wykrywania płatności i uzgadniania rozliczeń.

Pod koniec maja 2026 r. dostawcy danych rynkowych klasyfikowali REQ jako token z segmentu small‑/mid‑cap, a nie jako aktywo kryptowalutowe o znaczeniu systemowym: CoinMarketCap plasował Request w okolicach miejsca #384, podczas gdy CoinGecko i DeFiLlama raportowały istotnie różne wartości kapitalizacji rynkowej z powodu odmiennych metodologii oraz momentu pomiaru podaży w obiegu. Dla tego typu protokołu TVL jest ograniczonym miernikiem: Request Network page w DeFiLlama prezentuje dane o skarbcu i rynku tokena zamiast klasycznego TVL z pożyczek/AMM, co jest spójne z rolą Request jako infrastruktury płatniczej, a nie puli depozytów użytkowników. Bardziej relewantnymi wskaźnikami skali są wolumen płatności i przetwarzana aktywność biznesowa; strona fundacji podaje ponad 2 mld USD przetworzonego wolumenu i szerokie pokrycie stablecoinów, podczas gdy prowadzony przez społeczność Request Activity Dashboard śledzi dzienne płatności oraz ich wolumen, ale nie dostarcza przejrzystych kohort DAU/MAU porównywalnych z portfelami konsumenckimi czy giełdami. (coinmarketcap.com)

Kto i kiedy założył Request?

Request został założony w 2017 r. przez Christophe’a Lassuyta i Etienne’a Tatura, związanych wcześniej z projektem fintech MONEYTIS; Y Combinator wymienia Request Network jako spółkę z batchu Winter 2017 z siedzibą w Paryżu, z Lassuytem jako Founder/CFO i Tat urem jako Founder/CTO. Kontekst startu ma znaczenie: REQ powstał w trakcie fali ICO w 2017 r., gdy wiele projektów próbowało rozszerzyć zastosowania Ethereum poza transfery tokenów na obszary księgowości, handlu i automatyzacji procesów biznesowych. Historyczne bazy danych ICO lokują sprzedaż tokena w październiku 2017 r., z początkową podażą około jednego miliarda REQ, choć obecna podaż jest niższa po spalaniach i zmianach w księgowaniu tokenów. Taka „rocznikowa” metryka niesie zarówno zalety, jak i obciążenia: Request przetrwał kilka cykli rynkowych i utrzymał działające oprogramowanie, ale ciąży na nim reputacyjny balast typowy dla projektów tokenów użytkowych z 2017 r., których wczesne narracje często wyprzedzały realną adopcję w krótkim terminie. (ycombinator.com)

Narracja projektu z czasem się zawęziła.

Pierwotna rama koncepcyjna opisywała szeroką zdecentralizowaną sieć płatniczą dla faktur, ścieżek audytowych, zgodności z prawem handlowym i globalnych żądań płatności; obecny nacisk produktowy jest bardziej operacyjny i mniej ideologiczny, skoncentrowany na płatnościach krypto przez API, fakturowaniu on-chain, wykrywaniu płatności, routingu międzyłańcuchowym, płatnościach zbiorczych, płatnościach cyklicznych i uzgadnianiu rozliczeń.

Ta ewolucja jest widoczna w aktualizacjach fundacji z 2025 r.: Request wprowadził API V2, płatności częściowe, ulepszone webhooki, przepływy krypto‑na‑fiat, płatności zbiorcze oraz funkcjonalność płatności międzyłańcuchowych, zamiast próbować stać się nowym, ogólnego przeznaczenia blockchainem. W kategoriach instytucjonalnych oznacza to zwrot od „PayPal na blockchainie” w stronę warstwy pośredniej (middleware) dla zespołów finansowych, dostawców usług płatniczych oraz firm krypto‑native potrzebujących ustrukturyzowanych zapisów płatności na wielu łańcuchach. request.network

Jak działa Request Network?

Request nie posiada własnego mechanizmu konsensusu proof‑of‑work, proof‑of‑stake, DAG, zestawu walidatorów, sekwencera ani rollupu. To hybrydowy protokół off‑chain/on‑chain, który zapisuje większość treści żądania w IPFS, kotwiczy identyfikator treści IPFS (CID) on-chain i przetwarza płatności za pośrednictwem smart kontraktów na obsługiwanych łańcuchach rozliczeniowych.

Dokumentacja wskazuje, że żądania są tworzone poprzez zapisywanie CID‑ów w Gnosis Chain, podczas gdy płatności mogą być wykonywane na ponad 20 obsługiwanych łańcuchach EVM‑kompatybilnych lub w NEAR; saldo żądania jest następnie obliczane poprzez indeksowanie zdarzeń płatności on-chain powiązanych z pochodną referencją płatności. Technicznie rzecz biorąc, Request jest protokołem warstwy aplikacyjnej i API developerskim, które dziedziczy „liveness” i finalność z zewnętrznych sieci, takich jak Gnosis, Ethereum, Base, Arbitrum, Optimism, Polygon i inne, zamiast zapewniać własny budżet bezpieczeństwa warstwy bazowej. docs.request.network

Charakterystycznym mechanizmem protokołu jest referencja płatności. W zalecanym modelu opartym na referencjach unikalny identyfikator wyprowadzony z danych żądania łączy płatność w blockchainie z podstawową fakturą lub żądaniem płatności; kontrakty‑proxy przekazują środki odbiorcy i emitują zdarzenia zawierające kwotę płatności oraz referencję, a subgrafy indeksują te zdarzenia na potrzeby późniejszego uzgadniania.

System nie wykorzystuje shardingu ani ZK‑rollupów jako natywnych prymitywów skalujących, a jego model weryfikacji jest bliższy rozliczaniu opartemu na indeksowaniu zdarzeń oraz podpisanych metadanych żądania niż weryfikacji kryptograficznych dowodów rollupowych. Request Nodes zapewniają bramę pomiędzy IPFS, smart kontraktami i The Graph; fundacja uruchamia węzły dla wygody developerów, ale doradza podmiotom produkcyjnym uruchamianie własnych węzłów, co jest istotne, ponieważ poleganie na bramkach i API hostowanych przez fundację stanowi wektor centralizacji, nawet jeśli bazowe dane żądań i kontrakty są open‑source.

Prywatne żądania dodają szyfrowanie asymetryczne i AES: treść żądania jest szyfrowana kluczem AES, a ten klucz jest szyfrowany dla klucza publicznego każdej strony przed zapisaniem do IPFS. docs.request.network

Jakie są tokenomiki REQ?

REQ to token ERC‑20 pierwotnie uruchomiony z podażą około jednego miliarda jednostek; jego profil podaży najlepiej opisać jako w dużej mierze stały, z umiarkowanym mechanizmem spalania, a nie jako aktywo z inflacyjną emisją. Pod koniec maja 2026 r. Etherscan wskazywał kontrakt tokena ERC‑20 pod adresem 0x8f8221afbb33998d8584a2b05749ba73c37a938a z maksymalną całkowitą podażą około 999,416 mln REQ, podczas gdy CoinMarketCap raportował podaż w obiegu na poziomie ok. 796,7 mln REQ, a CoinGecko prezentował inny poziom podaży w obiegu, podkreślając, że „cyrkulująca” podaż zależy od sposobu klasyfikacji rezerw, mostów i nieaktywnych sald.

Dashboard społecznościowy raportował spalonych około 583 000 REQ, co stanowi niewielki ułamek pierwotnej podaży, więc efekt deflacyjny istnieje, ale sam w sobie nie jest na tyle duży, by mógł stanowić centralną tezę inwestycyjną. (etherscan.io)

Akumulacja wartości przez REQ jest pośrednia i powinna być oceniana ostrożnie.

Dokumentacja identyfikuje kontrakty tokena REQ i mechanizmu spalania, które mogą blokować, mostkować i spalać REQ, gdy żądania są przechowywane, podczas gdy dokumentacja API opisuje opłatę protokołu w wysokości 5 punktów bazowych od płatności przetwarzanych przez API, ograniczoną do ok. 25 USD lub 25 EUR dla głównych stablecoinów zabezpieczonych USD i EUR.

Nie jest to to samo, co klasyczna stopa zwrotu z PoS ze stakowania, a bezpieczeństwo Request nie jest oparte na stakowaniu REQ w taki sposób, w jaki Ethereum jest zabezpieczone przez walidatorów ETH. Niektóre opisy tworzone przez podmioty trzecie przedstawiają użyteczność REQ w kategoriach ochrony przed spamem, zarządzania (governance), stakowania, zniżek i niezależności, ale aktualna oficjalna dokumentacja techniczna nie prezentuje dużego, płynnego rynku stakowania, harmonogramu nagród dla walidatorów ani programu stałych emisji dla posiadaczy REQ.

Najbardziej obronna interpretacja tokenomiki jest zatem taka, że REQ to „legacy” token użytkowo‑governance’owy z ograniczoną podażą i elementami spalania powiązanymi z użyciem, podczas gdy większość krótkoterminowych korzyści z użytkowania protokołu może przypadać bardziej bezpośrednio warstwie produktowej i obsługiwanym przez fundację usługom API niż automatycznie biernym posiadaczom tokena. docs.request.network

Kto korzysta z Request?

Różnica między spekulacyjnym handlem REQ na giełdach a faktyczną użytecznością Request Network jest istotna. Wolumen tokena na giełdach odzwierciedla płynność rynkową i rotację inwestorów, podczas gdy wykorzystanie protokołu lepiej mierzyć liczbą utworzonych żądań, wykrytych płatności, wolumenem płatności, adopcją API oraz integracją z procesami finansowymi.

W swoim ekosystemowym raporcie z maja 2025 r. Request wprost przesunął akcent raportowania z ogólnej liczby transakcji na „liczbę płatności”, ponieważ tworzenie faktur, ich zatwierdzanie, odrzucanie i inne działania mogą zawyżać statystyki transakcyjne, nie odzwierciedlając rzeczywistej aktywności rozliczeniowej.

Dashboard społecznościowy raportuje także wolumen płatności i ich liczbę na obsługiwanych łańcuchach, ale są to zmienne wskaźniki dzienne, których nie należy interpretować jako stabilnych liczb aktywnych użytkowników. Sektorowo Request lokuje się na przecięciu płatności krypto, rozliczeń w stablecoinach, fakturowania, list płac, księgowości oraz operacji skarbowych, a nie w obszarze płynności DeFi, gier czy spekulacji NFT. request.network

Najmocniejszym dowodem adopcji są integracje z rozpoznawalnymi produktami dla finansów i operacji krypto, a nie anonimowe liczby portfeli. Request’s Aktualizacje ekosystemu na 2025 rok wymieniły aktywnych budujących, w tym Animal Social Club, intrXn, 0 Finance, Allora i Request Finance, podczas gdy wcześniejsze aktualizacje odnosiły się również do Huma Finance, BSOS, Joba Network i innych uczestników ekosystemu.

W październiku 2025 r. Kryptos ogłosiło, że zintegrowało Request Network API, aby obsługiwać fakturowanie w Kryptos Enterprise, przy czym Request zapewnia wystawianie faktur, rozliczenia on-chain, webhooki zdarzeń oraz uzgadnianie płatności; w tym ogłoszeniu przywołano także własny „snapshot” adopcji przez Kryptos: ponad 200 000 zarejestrowanych użytkowników, ponad 50 firm Web3 wdrożonych we wczesnych fazach oraz tysiące integracji z portfelami, CEX, DeFi i łańcuchami. Te dane należy odczytywać jako skalę platformy partnerskiej, a nie bezpośrednią adopcję przez posiadaczy REQ, ale wciąż są one bardziej konkretne niż nieudokumentowane plotki o partnerstwach. request.network

Jakie są ryzyka i wyzwania dla Request?

Ryzyko regulacyjne dla Request jest subtelniejsze niż w przypadku giełdy, protokołu pożyczkowego czy miksera prywatności, ale nie jest zerowe. Publiczne wyszukiwania oraz treść skarg SEC dostępna w wynikach wyszukiwania nie wskazują, aby REQ był wymieniony jako nazwany token w głównych skargach SEC przeciwko Coinbase lub Binance z 2023 r., i według stanu na koniec maja 2026 r. nie ma szeroko opisywanego, aktywnego pozwu SEC skierowanego konkretnie przeciwko Request Network.

Nie oznacza to jednak bezpiecznej przystani regulacyjnej. REQ był sprzedawany w erze ICO w 2017 r., jest przedmiotem obrotu na rynkach wtórnych, a amerykańscy regulatorzy historycznie bacznie przyglądają się tokenom, które były dystrybuowane w celu finansowania rozwoju protokołu.

Działalność płatnicza protokołu dotyka również kwestii AML, screeningu sankcyjnego, KYC, regulacji stablecoinów, świadczenia usług przekazu pieniężnego oraz raportowania podatkowego, szczególnie tam, gdzie Request wspiera rozliczenia krypto–fiat, screening portfeli i fakturowanie biznesowe. Ryzyko centralizacji ma także wymiar praktyczny, a nie wyłącznie teoretyczny: obsługiwane przez fundację API, panel (dashboard), bezpieczna strona płatności, Request Nodes i infrastruktura wykrywania płatności mogą tworzyć zależność operacyjną, nawet jeśli kontrakty, SDK i model danych pozostają open-source. sec.gov

Konkurencja jest intensywna, ponieważ problem użytkownika, który rozwiązuje Request, może być atakowany z kilku kierunków. Tradycyjni dostawcy usług płatniczych dodają rozliczenia w stablecoinach; scentralizowani dostawcy płatności krypto mogą oferować zgodność regulacyjną, politykę chargebacków, wyjścia do fiat oraz panele dla merchantów; portfele i giełdy mogą bezpośrednio dodawać linki płatnicze; a dostawcy korporacyjnej księgowości krypto mogą wbudować uzgadnianie faktur w swoje własne stosy technologiczne. W obrębie Web3 produkty podobne do Safe i Coinbase Commerce, narzędzia do zarządzania skarbcem multisig, platformy płacowe, dostawcy checkoutów w stablecoinach, panele księgowości on-chain i API do routingu międzyłańcuchowego mogą każdy z osobna przejmować fragmenty przepływu pracy Request.

Zagrożenie ekonomiczne polega na tym, że opłata Request w wysokości 5 punktów bazowych oraz powiązanie z burnem REQ mogą zostać „wypchnięte” konkurencją, jeśli routing płatności i uzgadnianie staną się skomodytyzowanymi funkcjami API. Obrona pozycji Request zależy od tego, czy deweloperzy potraktują obiekt faktury Request, standard referencji płatności i narzędzia do uzgadniania jako trwałą warstwę integracyjną, a nie wymienialną nakładkę-ułatwiacz. docs.request.network

Jakie są perspektywy rozwoju Request?

Krótkoterminowa mapa drogowa Request wydaje się skoncentrowana na pogłębianiu produktu, a nie na reinwencji warstwy konsensusu. Zweryfikowana dokumentacja z 2025 r. i początku 2026 r. wskazuje na migrację do API V2, płatności stablecoinami cross-chain, płatności zbiorcze (batch), płatności częściowe, przepływy krypto–fiat, płatności cykliczne, dostosowywanie opłat, ulepszenia w przełączaniu portfeli i sieci, szersze śledzenie płatności oraz obsługę ponad 25 łańcuchów poprzez powierzchnię API. Płatności cross-chain są szczególnie istotne, ponieważ adresują realny problem operacyjny: płatnicy mogą trzymać USDT na Optimism, podczas gdy faktury wymagają USDC na Base, a zespoły finansowe nie chcą ręcznie zarządzać mostami, swapami, tokenami na gas i uzgadnianiem.

Dokumentacja Request podaje, że płatności cross-chain obsługują USDC (USDC), USDT (USDT) i DAI (DAI) w sieciach Ethereum (ETH), Arbitrum One (ARB), Base oraz OP Mainnet (OP), przy czym trasy są rangowane według opłat transakcyjnych i szybkości przetwarzania; publiczna strona produktu cross-chain stwierdza, że Request korzysta z routingu LI.FI, zachowując jednolitą logikę wykrywania płatności i webhooków. request.network

Strukturalną przeszkodą jest gęstość adopcji. Request nie musi pokonać w szerokim sensie Ethereum, Visy, Stripe ani każdego procesora stablecoinów; potrzebuje wystarczającej liczby aplikacji biznesowych, produktów księgowych, PSP oraz natywnych dla krypto zespołów finansowych, aby ustandaryzowały się wokół jego warstwy „request-and-reconciliation”. Niedźwiedzi scenariusz zakłada, że płatności w stablecoinach zostaną bezpośrednio wbudowane w portfele, banki i API giełd, pozostawiając Request jako małe narzędzie deweloperskie z ograniczonym przechwytywaniem wartości przez token.

Byczy scenariusz jest bardziej powściągliwy niż narracja cenowa: jeśli rozliczenia w stablecoinach będą się dalej rozszerzać, a zespoły finansowe będą potrzebowały audytowalnych, niepowierniczych, wielołańcuchowych zapisów płatności, to kombinacja podpisanych żądań, referencji płatności, webhooków, przepływów batch, płatności cyklicznych i routingu cross-chain w Request może pozostać infrastrukturą o trwałej wartości.

Przyszłość projektu zależy więc mniej od spekulacyjnego popytu na REQ, a bardziej od tego, czy Request zdoła przekuć swoją długą historię działania w trwałe integracje, przejrzyste metryki wykorzystania oraz model tokena, którego powiązanie ekonomiczne z realnymi płatnościami będzie na tyle klarowne, aby instytucjonalni użytkownicy i posiadacze tokena mogli je świadomie „underwrite’ować”.