CoinClear

Request Network

6.0/10

Decentralized invoicing and payment requests — a niche but real use case for crypto-native businesses and DAOs.

Updated: February 16, 2026AI Model: claude-4-opusVersion 1

Overview

Request Network launched in 2017 with the vision of becoming a decentralized protocol for payment requests — essentially the web3 equivalent of an invoice system. Rather than building another payment rail, Request focused on the financial document layer: creating, storing, and tracking payment requests in a decentralized, verifiable manner.

The protocol allows anyone to create a payment request (specifying payer, amount, currency, and terms) that is stored on a decentralized network (using IPFS and Ethereum for anchoring). The payer can then fulfill the request by making the specified payment, which is automatically detected and the request is marked as paid. This creates an immutable, auditable record of financial transactions — useful for accounting, tax compliance, and payment tracking.

Request has found product-market fit within the crypto-native economy: DAOs paying contributors, freelancers invoicing crypto companies, and crypto businesses managing accounts payable/receivable. It's not a mass-market product, but within its niche, Request provides genuine utility that no other protocol specifically addresses.

Technology

Protocol Architecture

Request Network stores payment requests on a decentralized data layer. Each request is a structured data object containing payer, payee, amount, currency, due date, and other metadata. Requests are stored on IPFS with content hashes anchored to Ethereum (or other supported chains) for immutability and timestamping. The protocol supports multi-currency requests (ETH, ERC-20 tokens, BTC, fiat-denominated with crypto settlement) and complex payment conditions (installments, escrow, streaming).

Request Finance (dApp)

Request Finance is the primary user-facing application built on the protocol. It provides a familiar invoicing interface: create invoices, send them to clients, track payments, and export data for accounting. The product integrates with major wallets (MetaMask, Safe, WalletConnect) and supports batch payments for DAOs managing multiple contributor payments. The UX is designed to be accessible to non-technical users — a significant achievement for a crypto product.

Accounting Integration

Request exports payment data in formats compatible with traditional accounting software (QuickBooks, Xero). This bridges the gap between on-chain payments and off-chain accounting requirements — a real pain point for crypto businesses that need to maintain compliant financial records. On-chain payment detection provides automatic reconciliation, reducing manual accounting work.

Security

Data Integrity

Payment requests stored on IPFS with Ethereum anchoring are immutable and tamper-proof. Once a request is created, it cannot be altered — only its status (pending, paid, cancelled) can be updated. This provides an auditable financial record that is resistant to manipulation, which is valuable for accounting and dispute resolution.

Payment Security

Request doesn't custody funds — it creates and tracks payment requests, while actual payments flow directly between wallets through standard on-chain transfers or through escrow contracts. This non-custodial model limits the attack surface — a Request Network compromise would not result in fund loss (though it could affect payment tracking and records).

Contract Audits

Request's smart contracts have been audited by firms including Certik. The relatively narrow scope of functionality (payment request management, not DeFi trading) limits complexity and attack surface. No major exploits have been reported.

Decentralization

Data Layer

Payment request data is stored on IPFS (decentralized) with hash anchoring on Ethereum (decentralized). The data layer is genuinely decentralized — no central server stores the payment requests.

Application Layer

The Request Finance application is a centralized web application maintained by the Request Foundation. While the underlying data is decentralized, the primary user interface is centralized. Alternative front-ends could be built on the protocol, but in practice, Request Finance is the dominant access point.

Governance

The Request Foundation manages protocol development. REQ token holders do not have formal on-chain governance. The protocol's development direction is determined by the foundation team, with community input through forums and discussions.

Adoption

Crypto-Native Businesses

Request has found genuine traction among crypto-native organizations. DAOs use Request Finance for contributor payments (batch pay 50+ contributors with proper invoicing records). Crypto companies use it for vendor payments and accounts receivable. The product solves a real operational pain point for organizations operating primarily in crypto.

Transaction Volume

Request has processed billions of dollars in cumulative payment requests. Monthly active users and invoice counts have grown steadily, with particular strength in DAO and crypto company use cases. The growth is modest but organic — driven by genuine utility rather than token incentives.

Competitive Landscape

Request's direct competition comes from centralized crypto invoicing tools (Coinshift, Utopia Labs, Parcel) and traditional invoicing software that is adding crypto support. Request's advantage is the decentralized data layer and protocol-level composability; its disadvantage is the UX gap versus purely centralized solutions.

Tokenomics

Token Overview

REQ has a total supply of approximately 1 billion tokens. The token was originally designed with a burn mechanism — a portion of fees paid on the network is used to buy and burn REQ, creating deflationary pressure proportional to network usage.

Fee and Burn Model

Network fees (charged on payment request creation and processing) are partially used to buy and burn REQ tokens. This creates a direct link between protocol usage and token deflation. The burn rate depends on transaction volume — higher adoption means more burning. However, current burn volumes are modest relative to total supply.

Value Capture

The burn mechanism provides clearer value capture than many infrastructure tokens — there is a direct, quantifiable relationship between protocol revenue and token supply reduction. The limitation is that the absolute fee revenue (and therefore burn) is small given current adoption levels.

Risk Factors

  • Niche market: Crypto invoicing is a narrow addressable market compared to broader infrastructure plays.
  • Centralized competition: Traditional invoicing tools adding crypto support could capture the same market with better UX.
  • Adoption ceiling: The addressable market is limited to crypto-native businesses and DAOs — mainstream businesses use existing invoicing solutions.
  • Token necessity: The burn mechanism provides value capture but the REQ token is not strictly necessary for the invoicing functionality.
  • Foundation dependency: Protocol development depends on the foundation's continued funding and commitment.
  • Bear market sensitivity: Crypto business activity (and therefore invoicing demand) correlates with market cycles.

Conclusion

Request Network occupies a small but genuine niche in the crypto infrastructure landscape. Decentralized invoicing and payment tracking for crypto-native organizations is a real use case, and Request has built a functional product with steady adoption. The accounting integration — bridging on-chain payments with traditional bookkeeping — solves an underappreciated pain point.

The 6.0 score reflects a project that does what it claims, has real users, and provides genuine utility — but operates in a niche market with limited growth ceiling. Request is not going to become the next Chainlink or ENS, but it may sustain a viable protocol serving the crypto-native business economy. For the market it serves, Request is a useful and well-executed tool.

Sources