Request

The historical whitepaper begins before REQ. Etienne Tatur and Christophe Lassuyt worked from 2014 on Moneytis, a Bitcoin-based international-transfer aggregator. Interviews with companies and freelancers exposed a broader problem: moving value was only one step; the request, commercial terms and accounting trail remained scattered.

During Y Combinator Winter 2017, the team recast that lesson as Request Network. Its proposed Ethereum layer would let Bob request a payment from Alice, attach invoice logic and update a shared ledger when payment arrived. The document reached far beyond a checkout tool, promising tax routing, escrow, factoring, audit and even machine-to-machine commerce.

The 2017 sale contracts created all one billion REQ in the constructor. The archived repository says 50% went to the sale, 15% to team vesting, 15% to a foundation multisig and 20% to early investors. The current token page groups the same genesis differently—49.97% ICO, 20.01% early contributors, 18.01% team and advisers, 12.01% foundation. The discrepancy is not explained, so neither table should be treated as a uniquely audited allocation.

The token contract is simpler than the whitepaper economy. It allows holders to transfer or burn their own REQ, and an approved spender can use burnFrom. The owner-only emergency call accepts an arbitrary ERC-20 contract and transfers a balance held by the REQ contract to the owner; it cannot reach into holder wallets. There is no later mint, pause, freeze or upgrade function. The 2026-09-05 chain reading was 999,416,740.934708517074687027 REQ, about 583,259 below genesis. That proves supply was destroyed, but not why each burn occurred.

The Foundation’s own token history now calls the next phase a hard lesson: businesses used invoicing, yet invoicing without payment volume did not make the network grow. This retrospective matters because the original whitepaper treated the invoice ledger as a base for an enormous application ecosystem.

A practical business application did emerge, but it became Request Finance, a separate French company. The protocol FAQ says the two teams have spun apart and that the Foundation cannot grant access to encrypted Request Finance invoices. A customer relationship with that commercial application is therefore not ownership of the protocol, and REQ is not equity in either organization.

Today a request is signed data. Most contents sit in the dedicated Request IPFS network, while a CID is anchored on Gnosis Chain. The signer that creates the record need not be the wallet that receives funds. Payment references let software match transfers on Ethereum, Base and other supported chains back to the request.

That separation is useful, but it limits what the record proves. A request can state that an amount is due and report what was paid; it does not certify that the invoice is legally valid, guarantee collection or turn a fiat denomination into a claim on the Foundation. The Foundation’s terms say it does not verify transaction correctness, custody funds or promise third-party execution.

On June 1, 2026, the Foundation announced stablecoin collection, crosschain payment routes and wallet screening before transfer. Its release claimed reach across seven chains; the current implementation guide describes the narrower crosschain API path for USDC and USDT on five EVM chains, with LiFi routes restricted to Across. The protocol FAQ is explicit: crosschain payment is available through the API only, not through the base request protocol.

This boundary puts operational choices in hosted services. The Foundation operates the API while its terms say third-party providers maintain parts of it; credentials, supported routes, screening and fee quotation can therefore change outside the REQ contract. The open protocol remains available to integrators, but the convenience and availability of the hosted payment flow do not follow from owning REQ.

The current REQ page says a portion of REQ is burned when a request is stored and that holders can participate in decisions about the protocol and Foundation. The contract and lower total supply show that burns have occurred. They do not identify those burns as request-storage charges. In the public materials reviewed here, we did not identify a per-request burn formula, a rule converting API fees into REQ purchases and burns, or an onchain governor that binds the Swiss foundation.

This leaves REQ between two eras. It is a fixed-genesis token with a measurable burn history, while the live payment product charges service fees disclosed through API responses. Holders can join discussions described as governance; they should not infer a redemption claim, protocol revenue share or ownership of the Foundation from that invitation.