Request

Was ist Request?

Request ist ein Open-Source-Protokoll für Krypto-Zahlungsanforderungen und Abstimmung, mit dem ein Unternehmen oder Nutzer eine signierte, rechnungsähnliche Zahlungsanforderung erstellen, die Anfragedaten in einer dezentralen Infrastruktur speichern und nachfolgende On-Chain-Zahlungen mit dieser Anforderung abgleichen kann, ohne die Verwahrung von Geldern an einen Zahlungsdienstleister abzugeben. Das Kernproblem ist nicht das abstrakte „Verschieben von Tokens“, was viele Wallets und Zahlungs-Gateways bereits leisten, sondern die Schaffung eines verifizierbaren buchhalterischen Objekts rund um die Zahlung: wer sie angefordert hat, welcher Betrag fällig war, welche Währung oder Rechnungseinheit verwendet wurde, wo die Abwicklung stattfand und ob die Zahlung automatisch erkannt und abgestimmt werden kann.

Der praktische Burggraben des Protokolls ist daher die Workflow-Integration und nicht der Konsens auf der Basisschicht: Request kombiniert signierte Zahlungsanforderungen, IPFS-Speicherung, On-Chain-CID-Verankerung, Payment-Reference-Events, Webhooks, API-Tools und Multi-Chain-Zahlungsrouting zu einem Finanz-Backoffice-Primitive, wie in der Dokumentation von Request Network und in der Protokollübersicht beschrieben. docs.request.network

Request ist weder eine dominante Layer-1-Chain, noch ein Rollup oder ein großer DeFi-Geldmarkt; es ist eine spezialisierte Anwendungsschicht für Zahlungen und Entwickler-Tools, die rund um Krypto-Rechnungsstellung, Zahlungserkennung und Abstimmung aufgebaut ist.

Ende Mai 2026 ordneten Marktdatenanbieter REQ im Small- bis Mid-Cap-Token-Universum ein und nicht unter den systemrelevanten Krypto-Assets: CoinMarketCap zeigte Request in der Nähe von Rang #384, während CoinGecko und DeFiLlama Marktkapitalisierungswerte meldeten, die sich aufgrund unterschiedlicher Methoden und Zeitpunkte zur Berechnung des zirkulierenden Angebots materiell unterschieden. Für diese Art von Protokoll ist TVL nur eine begrenzt aussagekräftige Kennzahl: DeFiLlamas Request Network page weist Treasury- und Tokenmarktdaten aus statt einer konventionellen Lending-/AMM-TVL-Kennzahl, was mit der Rolle von Request als Zahlungsinfrastruktur statt als Pool von Nutzereinlagen übereinstimmt. Relevantere Größenordnungen sind Zahlungsvolumen und verarbeitete Geschäftsaktivität; die Website der Stiftung gibt mehr als 2 Milliarden US-Dollar an verarbeitetem Volumen und eine breite Stablecoin-Abdeckung an, während das Community-geführte Request Activity Dashboard tägliche Zahlungen und Zahlungsvolumina nachverfolgt, aber keinen sauberen DAU/MAU-Nutzerkohortenvergleich zu Consumer-Wallets oder Börsen liefert. (coinmarketcap.com)

Wer hat Request wann gegründet?

Request wurde 2017 von Christophe Lassuyt und Etienne Tatur gegründet, die beide mit dem früheren Fintech-Projekt MONEYTIS verbunden waren; Y Combinator listet Request Network als Winter-2017-Unternehmen mit Sitz in Paris, mit Lassuyt als Gründer/CFO und Tatur als Gründer/CTO. Der Launch-Kontext ist wichtig: REQ entstand während des ICO-Zyklus 2017, als viele Projekte versuchten, Ethereum über einfache Token-Transfers hinaus in Richtung Buchhaltung, Handel und Geschäftsautomatisierung zu verallgemeinern. Historische ICO-Datenbanken verorten den Tokenverkauf im Oktober 2017, mit einem anfänglichen Token-Angebot von rund einer Milliarde REQ, wobei das aktuelle Angebot nach Burns und Änderungen in der Token-Buchführung niedriger ist. Dieser Jahrgang ist zugleich Vorteil und Bürde: Request hat mehrere Marktzyklen überstanden und funktionierende Software beibehalten, trägt aber auch den Reputationsballast vieler Utility-Token-Projekte aus dem Jahr 2017, deren frühe Narrative die kurzfristige Adoption oft überstiegen. (ycombinator.com)

Die Erzählung des Projekts hat sich im Laufe der Zeit verengt.

Die ursprüngliche Rahmung war ein breites dezentrales Zahlungsnetzwerk für Rechnungen, Prüfpfade, Einhaltung von Handelsrecht und globale Zahlungsanforderungen; der aktuelle Produktschwerpunkt ist operativer und weniger ideologisch ausgerichtet, mit Fokus auf API-basierte Krypto-Zahlungen, On-Chain-Rechnungsstellung, Zahlungserkennung, Cross-Chain-Routing, Sammelzahlungen, wiederkehrende Zahlungen und Abstimmung.

Diese Entwicklung zeigt sich in den Updates der Stiftung im Jahr 2025: Request veröffentlichte API V2, Teilzahlungen, verbesserte Webhooks, Krypto-zu-Fiat-Workflows, Sammelzahlungen und Cross-Chain-Zahlungsfunktionen, statt zu versuchen, eine neue General-Purpose-Blockchain zu werden. Institutionell betrachtet vollzieht sich der Pivot weg von „PayPal auf der Blockchain“ hin zu Middleware für Finanzabteilungen, Zahlungsdienstleister und krypto-native Unternehmen, die strukturierte Zahlungsdatensätze über mehrere Chains hinweg benötigen. request.network

Wie funktioniert das Request Network?

Request verfügt weder über einen eigenen Proof-of-Work-, Proof-of-Stake- oder DAG-Konsens, noch über ein Validator-Set, einen Sequencer oder ein Rollup. Es handelt sich um ein hybrides Off-Chain/On-Chain-Protokoll, das den Großteil der Anforderungsinhalte auf IPFS persistiert, die IPFS-Content-ID On-Chain verankert und Zahlungen über Smart Contracts auf unterstützten Settlement-Chains abwickelt.

Die Dokumentation gibt an, dass Anforderungen durch das Speichern von CIDs auf der Gnosis Chain erstellt werden, während Zahlungen auf mehr als 20 unterstützten EVM-kompatiblen Chains oder NEAR erfolgen können; der Anforderungs-Saldo wird dann berechnet, indem On-Chain-Zahlungsereignisse indexiert werden, die mit einer abgeleiteten Payment Reference verknüpft sind. Technisch ist Request ein Protokoll auf Anwendungsebene und eine Entwickler-API, die Liveness und Finalität von externen Netzwerken wie Gnosis, Ethereum, Base, Arbitrum, Optimism, Polygon und anderen erbt, statt ein eigenes Sicherheitsbudget auf der Basisschicht bereitzustellen. docs.request.network

Der charakteristische Mechanismus des Protokolls ist die Payment Reference. Im empfohlenen, referenzbasierten Modell verknüpft ein aus den Anfragedaten abgeleiteter eindeutiger Identifikator eine Blockchain-Zahlung mit der zugrundeliegenden Rechnung oder Zahlungsanforderung; Proxy-Verträge leiten die Gelder an den Empfänger weiter und emittieren Events, die Zahlungsbetrag und Referenz enthalten, während Subgraphs diese Events für eine spätere Abstimmung indexieren.

Das System verwendet weder Sharding noch ZK-Rollups als native Skalierungsprimitive, und sein Verifizierungsmodell ähnelt eher einem durch Events indexierten Settlement plus signierten Anforderungsmetadaten als der Verifikation kryptografischer Rollup-Proofs. Request Nodes stellen ein Gateway über IPFS, Smart Contracts und The Graph bereit; die Stiftung betreibt Nodes aus Gründen der Entwicklerfreundlichkeit, rät Produktivnutzern jedoch, einen eigenen Node zu betreiben, was wichtig ist, da die Abhängigkeit von stiftungsbetriebenen Gateways und APIs einen Zentralisierungsvektor darstellt – selbst wenn die zugrundeliegenden Anfragedaten und Verträge Open Source sind.

Private Anforderungen fügen asymmetrische Verschlüsselung und AES-Verschlüsselung hinzu: Die Inhalte der Anforderung werden mit einem AES-Schlüssel verschlüsselt, und dieser Schlüssel wird für den öffentlichen Schlüssel jedes Beteiligten verschlüsselt, bevor er auf IPFS gespeichert wird. docs.request.network

Wie sind die Tokenomics von REQ?

REQ ist ein ERC-20-Token, das ursprünglich mit etwa einer Milliarde Einheiten gestartet wurde; sein Angebotsprofil lässt sich am besten als überwiegend fix mit einem moderaten Burn-Mechanismus verstehen und nicht als inflationsgetriebener Emissions-Token. Ende Mai 2026 listete Etherscan den ERC-20-Tokenvertrag unter 0x8f8221afbb33998d8584a2b05749ba73c37a938a mit einem maximalen Gesamtangebot von etwa 999,416 Millionen REQ, während CoinMarketCap ein zirkulierendes Angebot von rund 796,7 Millionen REQ meldete und CoinGecko einen abweichenden Wert für das zirkulierende Angebot auswies – ein Hinweis darauf, dass das „zirkulierende“ Angebot davon abhängt, wie Reserven, Bridges und inaktive Bestände klassifiziert werden.

Das Community-Dashboard meldete etwa 583.000 verbrannte REQ, einen kleinen Bruchteil des ursprünglichen Angebots, sodass der deflationäre Effekt zwar existiert, aber allein nicht groß genug ist, um die zentrale Investment-These zu bilden. (etherscan.io)

Der Wertzuwachs von REQ ist indirekt und sollte vorsichtig beurteilt werden.

Die Dokumentation weist auf REQ-Token- und Burn-Mechanismus-Verträge hin, die REQ sperren, bridgen und verbrennen können, wenn Anforderungen gespeichert werden, während die API-Dokumentation eine Protokollgebühr von 5 Basispunkten auf Zahlungen beschreibt, die über die API verarbeitet werden, gedeckelt bei etwa 25 $ oder 25 € für große USD- und EUR-gestützte Stablecoins.

Dies entspricht nicht einer konventionellen PoS-Staking-Rendite, und Request wird nicht durch REQ-Staking gesichert, wie Ethereum durch ETH-Validatoren gesichert wird. Einige Drittbeschreibungen charakterisieren den Nutzen von REQ in Begriffen wie Anti-Spam, Governance, Staking, Rabatten und Unabhängigkeit, aber die aktuelle offizielle technische Dokumentation stellt keinen großen liquiden Staking-Markt, keinen Validator-Belohnungsplan und kein wiederkehrendes Emissionsprogramm für REQ-Inhaber dar.

Die am besten vertretbare Interpretation der Tokenomics ist daher, dass REQ ein Utility-/Governance-Token alten Zuschnitts mit gedeckeltem Angebot und nutzungsbezogenen Burn-Elementen ist, während sich ein Großteil der kurzfristigen Protokollnutzung eher direkt in der Produktebene und bei den von der Stiftung betriebenen API-Services niederschlagen dürfte als automatisch bei passiven Token-Inhabern. docs.request.network

Wer nutzt Request?

Der Unterschied zwischen spekulativem REQ-Handel und tatsächlichem Nutzen des Request Network ist erheblich. Das Token-Volumen an Börsen spiegelt Marktliquidität und Investorenrotation wider, während die Protokollnutzung besser über erstellte Anforderungen, erkannte Zahlungen, Zahlungsvolumen, API-Adoption und die Integration in Finanz-Workflows gemessen wird.

Request selbst hat in seinem Ökosystem-Update vom Mai 2025 den Berichtsfokus explizit von generischen Transaktionszahlen auf die „Anzahl der Zahlungen“ verlagert, da Rechnungserstellung, Genehmigungen, Ablehnungen und andere Aktionen Transaktionsmetriken aufblähen können, ohne reale Settlement-Aktivität widerzuspiegeln.

Das Community-Dashboard berichtet ebenfalls über Zahlungsvolumen und Zahlungsanzahl über die unterstützten Chains, doch dies sind volatile Tagesindikatoren und sollten nicht als stabile Zahlen aktiver Nutzer interpretiert werden. Sektorübergreifend sitzt Request an der Schnittstelle von Krypto-Zahlungen, Stablecoin-Settlement, Rechnungsstellung, Gehaltsabrechnung, Buchhaltung und Treasury-Operations – und weniger im Bereich DeFi-Liquidität, Gaming oder NFT-Spekulation. request.network

Der stärkste Adoptionsnachweis sind Integrationen mit identifizierbaren Finanz- oder Krypto-Operations-Produkten und nicht anonyme Wallet-Zählungen. Request’s 2025-Aktualisierungen im Ökosystem nannten aktive Builder wie Animal Social Club, intrXn, 0 Finance, Allora und Request Finance, während frühere Updates auch Huma Finance, BSOS, Joba Network und andere Ökosystemteilnehmer erwähnten.

Im Oktober 2025 kündigte Kryptos an, dass es die Request Network API integriert habe, um die Rechnungsstellung innerhalb von Kryptos Enterprise zu ermöglichen, wobei Request die Rechnungserstellung, On-Chain-Abwicklung, Event-Webhooks und Abstimmung bereitstellt. Diese Ankündigung verwies außerdem auf Kryptos’ eigenen Adoptionsstatus mit mehr als 200.000 registrierten Nutzern, mehr als 50 Web3-Unternehmen, die in frühen Phasen an Bord geholt wurden, und Tausenden von Integrationen mit Wallets, CEXs, DeFi-Protokollen und Chains. Diese Zahlen sollten als Partner-Plattform-Skalierung und nicht als direkte REQ-Holder-Adoption gelesen werden, sind aber dennoch substanzieller als unbelegte Partnerrgerüchte. request.network

What Are the Risks and Challenges for Request?

Das regulatorische Risiko für Request ist subtiler als für eine Börse, ein Lending-Protokoll oder einen Privacy-Mixer, aber nicht gleich null. Öffentliche Recherchen und der über die Suchergebnisse zugängliche SEC-Beschwerdetext zeigen REQ nicht als benannten Token in den großen SEC-Klagen gegen Coinbase oder Binance im Jahr 2023, und es gibt bis Ende Mai 2026 keine weithin berichtete aktive SEC-Klage speziell gegen Request Network.

Das stellt jedoch keinen regulatorischen Schutzraum dar. REQ wurde in der ICO-Ära 2017 verkauft, wird auf Sekundärmärkten gehandelt, und US-Regulierer haben in der Vergangenheit Token besonders geprüft, die zur Finanzierung der Protokollentwicklung ausgegeben wurden.

Das Zahlungs-Geschäft des Protokolls berührt außerdem Fragen zu Geldwäscheprävention (AML), Sanktions-Screening, KYC, Stablecoin-Regulierung, Geldübertragung und Steuerberichterstattung – insbesondere dort, wo Request Krypto-zu-Fiat-Abwicklung, Wallet-Screening und Geschäftsrechnungsstellung unterstützt. Das Zentralisierungsrisiko ist zudem praktisch statt theoretisch: Die von der Stiftung betriebene API, das Dashboard, die sichere Zahlungsseite, Request Nodes und die Infrastruktur zur Zahlungserkennung können operative Abhängigkeiten schaffen, selbst wenn die Smart Contracts, das SDK und das Datenmodell weiterhin Open Source bleiben. sec.gov

Der Wettbewerb ist intensiv, weil Requests nutzerseitiges Problem aus mehreren Richtungen angegangen werden kann. Traditionelle Zahlungsdienstleister fügen Stablecoin-Abwicklung hinzu; zentralisierte Krypto-Zahlungsprozessoren können Compliance, Rückbuchungsrichtlinien, Fiat-Off-Ramps und Händler-Dashboards anbieten; Wallets und Börsen können Zahlungslinks direkt integrieren; und Enterprise-Krypto-Accounting-Anbieter können Rechnungsabstimmung in ihre eigenen Stacks einbauen. Innerhalb von Web3 können Safe, Coinbase-Commerce-ähnliche Produkte, Multisig-Treasury-Tools, Payroll-Plattformen, Stablecoin-Checkout-Anbieter, On-Chain-Accounting-Dashboards und Cross-Chain-Routing-APIs jeweils Teile von Requests Workflow absorbieren.

Die wirtschaftliche Bedrohung besteht darin, dass Requests Gebühr von 5 Basispunkten und die Kopplung an das REQ-Burn-Modell unter Wettbewerb geraten könnten, falls Zahlungsrouting und Abstimmung zu commoditisierten API-Funktionen werden. Die Verteidigungsfähigkeit hängt davon ab, ob Entwickler das Rechnungsobjekt von Request, den Payment-Reference-Standard und die Abstimmungstools als dauerhafte Integrationsschicht behandeln – statt als austauschbare Convenience-Hülle. docs.request.network

What Is the Future Outlook for Request?

Requests kurzfristige Roadmap scheint auf Produkttiefe statt auf eine Neuerfindung der Konsensschicht ausgerichtet zu sein. Verifizierte Dokumentation aus 2025 und Anfang 2026 verweist auf die Migration zu API V2, Cross-Chain-Stablecoin-Zahlungen, Sammelzahlungen (Batch Payments), Teilzahlungen, Krypto-zu-Fiat-Workflows, wiederkehrende Zahlungen, Gebührenanpassung, Verbesserungen beim Wallet- und Netzwerkwechsel, breitere Zahlungsnachverfolgung und Unterstützung von mehr als 25 Chains über die API-Oberfläche. Cross-Chain-Zahlungen sind besonders wichtig, weil sie einen realen operativen Pain Point adressieren: Zahlende Parteien können USDT auf Optimism halten, während Rechnungen USDC auf Base verlangen, und Finanzteams wollen Bridges, Swaps, Gas-Token und Abstimmung nicht manuell verwalten.

Die Dokumentation von Request besagt, dass Cross-Chain-Zahlungen USDC (USDC), USDT (USDT) und DAI (DAI) über Ethereum (ETH), Arbitrum One (ARB), Base und OP Mainnet (OP) unterstützen, wobei Routen nach Transaktionsgebühren und Verarbeitungsgeschwindigkeit gerankt werden; die öffentliche Cross-Chain-Produktseite gibt an, dass Request LI.FI-Routing verwendet, während ein einheitliches System für Zahlungserkennung und Webhook-Logik beibehalten wird. request.network

Die strukturelle Hürde ist die Adoptionsdichte. Request muss nicht Ethereum, Visa, Stripe oder jeden Stablecoin-Prozessor im weiteren Sinn schlagen; es braucht genügend Business-Anwendungen, Accounting-Produkte, PSPs und krypto-native Finanzteams, die sich auf seine Request-und-Reconciliation-Schicht standardisieren. Das Bären-Szenario ist, dass Stablecoin-Zahlungen direkt in Wallets, Banken und Exchange-APIs eingebettet werden und Request als kleines Entwickler-Tool mit begrenzter Tokenerfassung zurückbleibt.

Das Bullen-Szenario ist zurückhaltender als eine reine Preisstory: Wenn sich Stablecoin-Abwicklung weiter ausbreitet und Finanzteams prüfbare, nicht-kustodiale, Multi-Chain-Zahlungsaufzeichnungen benötigen, könnte Requests Kombination aus signierten Requests, Zahlungsreferenzen, Webhooks, Batch-Flows, wiederkehrenden Zahlungen und Cross-Chain-Routing als Infrastruktur weiterhin tragfähig bleiben.

Die Zukunft des Projekts hängt daher weniger von spekulativer REQ-Nachfrage ab und mehr davon, ob Request seine lange Betriebshistorie in dauerhafte Integrationen, transparente Nutzungsmetriken und ein Token-Modell umwandeln kann, dessen wirtschaftliche Kopplung an reale Zahlungen für institutionelle Nutzer und Tokenholder klar genug ist, um sie zu überzeugen.