Request Finance is the invoicing and payables layer of a DAO treasury: the place where a contributor's claim on the treasury becomes a document – an invoice, an expense, a payroll run – that somebody approves before any money moves. It sits above the multisig rather than replacing it. Custody stays in the Safe; what Request Finance adds is the paperwork, the approval trail, and the export that turns a wall of token transfers into something an accountant can read.
That is a real gap. A DAO can vote a budget on-chain and hold it in a multisig, but paying the people who do the work still means collecting invoices, checking them, converting some of them to fiat, and reconciling the lot at the end of the quarter. Most DAO tooling addresses the authorization problem. Very little of it addresses the bookkeeping.
Request splits into a protocol and a business built on it, and the distinction matters when you are assessing how much of the stack you actually depend on.
Request Network is the protocol: an open-source, non-custodial payment-request standard where, in its own words, funds are never held. Its TypeScript monorepo is MIT-licensed, and request data is stored on Ethereum and IPFS (with a TheGraph indexing path as an alternative), so an invoice is a shared on-chain artifact rather than a row in one vendor's database. The network reaches the major EVM chains – Ethereum, BNB Chain, Base, Polygon, Arbitrum, Optimism – and Tron, and the foundation describes the contracts and SDK as public goods that integrators can keep operating regardless of what happens to the foundation itself.
Request Finance is the product: a business account with corporate cards, accounts payable, accrual accounting, and stablecoin-plus-bank settlement, sold to finance teams. Its developer documentation describes it as an accounts-payable and receivable API sitting on Request Network, so an integrator can issue invoices and track their status without querying a chain directly. Its front page still reports 1,500+ finance teams and $1B+ processed, unchanged when re-read on 7 October 2026.
That split is no longer as clean as it was. Read on 7 October 2026, request.network fronts a priced commercial service – 0.9 % flat fee per transaction, capped at $500 per payment, and a claimed 95 % stablecoin-supply coverage, though the $2B+ volume processed figure it carried on 26 August 2026 is no longer on the page – and the protocol documentation now describes three products, a Dashboard, a Secure Payment Page and an API, benchmarked against “Stripe, PayPal & crypto payment tools.” The contracts and SDK remain MIT-licensed and non-custodial, so the escape hatch is real; but a DAO reading “protocol” and picturing a neutral standard should note that both halves of the name are now sold as products, and only the repository is a public good.
The working pattern is unglamorous and it is the point:
Nothing here changes who controls the money. The signers on the Safe still control it. What changes is that the DAO can answer “what did we pay, to whom, for what, and under which budget” without an archaeologist.
Request Invoicing found its first real market among DAOs and token-treasury companies, precisely because they had money and no back office. By November 2021, reporting named The Sandbox, Aave, MakerDAO and Chainstack among its users, with roughly $144M in crypto invoices processed across 900+ corporate clients – The Sandbox's COO put the saving at a 90% reduction in monthly payment time. Support then spanned 40+ digital currencies, 9+ fiat currencies and 10+ chains.
The trajectory since is worth reading honestly. The company's own marketing now leads with enterprise stablecoin payments and CFO tooling – corporate cards, accrual accounting, bank rails – not with DAO payables. That is the same drift seen elsewhere in DAO tooling: the crypto-native niche proves the product, and then the addressable market pulls it toward companies with a CFO. A DAO evaluating it today is buying enterprise finance software that happens to settle on-chain, rather than a DAO-first tool.
Treasury tooling divides by the question it answers, and Request Finance answers only one of them.
A mature treasury operation usually runs several of these at once: streams for core contributors, invoices for everyone else, and a multisig underneath all of it.
The honest caveats are structural rather than incidental.
A caper has no invoicing layer, and a caper paying real-world contractors would still need one – the bookkeeping problem does not vanish because the ledger is public. What a caper moves on-chain is the authorization, not the paperwork.
Treasury money leaves a caper only through a payout proposal, and the recipient account, the currency and the amount are frozen into the option members actually voted on. Execution reads that stored recipient rather than accepting one from whoever submits the transaction, so the person who triggers the payment cannot redirect it, and the step is once-only. The transfer is delivered through an account locker, so a recipient's deposit rules cannot strand it, and the payment leaves two events behind: the treasury's own Transfer event, naming the recipient, the currency and the amount actually moved after rounding to the currency's divisibility, and a ProposalExecuted event carrying the same three facts against the proposal's id (execute_proposal_payout in contracts/logic, transfer in contracts/core/src/dao_treasury.rs).
Which is to say the control Request Finance implements as an approval workflow, a caper implements as the shape of the proposal: there is no separate approval stage to bypass, because the vote and the payment instruction are the same object. Everything a finance team would call reconciliation – invoices, expense categories, statutory books – stays outside, where a tool like Request Finance is still the right answer.