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.

Two things with one name

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. The company reports 1,500+ finance leaders processing over $1B in payments.

How a DAO actually uses it

The working pattern is unglamorous and it is the point:

• Contributors invoice the DAO. Each contributor or vendor issues an invoice denominated in a stablecoin or token, which becomes a request on the protocol rather than a PDF in someone's inbox.
• An approver clears the queue. Operations staff review and approve bills, which is where budget discipline actually lands — long after the proposal that authorized the budget in the first place.
• The multisig pays in a batch. Approved bills are paid from the connected wallet — Safe, MetaMask or Ledger are the listed integrations — so signers approve one transaction covering many invoices instead of signing each transfer by hand.
• Accounting exports out. Xero, QuickBooks and SAP integrations carry the result into ordinary books, and bank rails (ACH, Wire, SEPA, SWIFT, SPEI, Faster Payments) cover the contributors who need fiat.

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.

Adoption

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.

Where it sits in the stack

Treasury tooling divides by the question it answers, and Request Finance answers only one of them.

• Custody — Safe and Squads hold the assets and decide who can move them.
• Asset management — karpatkey and Enzyme decide what the assets do while they sit there.
• Continuous pay — Sablier and Superfluid stream salaries and vesting by the second, replacing the invoice entirely for recurring roles.
• Allocation — Coordinape decides who deserves what, before anyone bills for it.
• Payables and books — Request Finance, for the one-off, the vendor, the contractor and the tax authority.

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.

Limits

The honest caveats are structural rather than incidental.

• The record of obligation is off-chain. The payment settles on-chain, but the approval workflow, the budget, and the audit trail live in a hosted application. If the vendor disappears, the transfers survive and the institutional memory of why they happened may not — though the protocol's public-goods contracts and MIT SDK give an integrator a path to keep operating.
• Fiat means KYC. The bank rails that make the product useful come with identity requirements a pseudonymous DAO may not want to meet, which pushes the DAO toward a legal wrapper to sign for them.
• It does not constrain spending. Approval workflows are a control only if the signers respect them; nothing in the tool stops a multisig from paying an unapproved address directly. The enforcement, if you want any, has to live in the treasury contract itself.

How Caper approaches this

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 it emits a transfer event against the treasury's opening and closing balance.

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.

References

• Request Network, protocol site · protocol documentation · RequestNetwork/requestNetwork (MIT)
• Request Finance, product site · AP/AR API documentation
• Y Combinator, Request Network company profile (W17)
• crypto.news, “The Sandbox, AAVE & major ICOs all use Request Invoicing” (23 Nov 2021)