Money Streams: Programmable Per-Second Crypto Payroll

A money stream is an agreement, funded up front, that releases value continuously over a set duration rather than at a single date. The receiving side sees a balance that increases every second the stream runs. It can withdraw whatever has accrued at any point, without waiting for the stream to finish. There is no missed date to chase, because there is no single date the whole payment depends on.

This is the same underlying pattern used by dedicated streaming-payment protocols. Sablier, one of the earliest and most established, describes its purpose as continuous token distribution that treats the passage of time itself as the mechanism that builds trust between sender and recipient, rather than a scheduled transfer that requires both sides to show up on the right day ^[3]. The specific implementation differs across products, but the underlying shift is the same one: from a payment event to a payment rate.

A recurring payment normally needs one of two things. Either the payer submits a new transaction every cycle, or the payer hands the recipient standing custody over funds sitting in an intermediary account. Both have real costs. The first requires constant manual action. The second requires trusting a third party with money that is not moving yet.

The Ethereum standard EIP-2612 offers a narrower alternative for token approvals. It is a signed message, verified using the EIP-712 typed-data standard, that authorizes a specific spender to move a specific token amount, with its own nonce and expiry built in for replay protection ^[2]. The token holder signs once. Anyone, including a relayer, can then submit that signed authorization on-chain, and the contract enforces exactly what was signed and nothing more.

That pattern, one signature setting a scoped and revocable allowance rather than handing over custody, is the same shape SpendTheBits uses for both autopay and money streams.

In the app, creating a money stream funds an allowance and a rate. It does not fund a running balance sitting idle in a wallet the recipient does not control. The not-yet-paid portion is parked in an Earn vault. Each claim just-in-time unwinds only the slice that has actually vested, so the float keeps working right up until the second it is claimed rather than sitting flat for the whole pay period.

The recipient can check the pay screen at any point and see exactly what has accrued so far, with nothing to request and nothing pending approval. Everything signs and settles on the device. Private keys never leave it, the same non-custodial model that runs the rest of the wallet.

Money streams and SpendTheBits' autopay solve related but different problems. Autopay is built for a fixed recurring amount, like a subscription or a rent payment. One standing-allowance signature at setup caps the total, and each occurrence afterward is a plain transfer against that cap, revocable at any time without a new signature.

A money stream is built for accrual, where value builds up continuously rather than in fixed installments. Salary, vesting and rent are the obvious cases. A job performed continuously deserves a payment that accrues continuously, rather than one artificially chunked into a biweekly date because that is how a legacy payroll system happens to batch its runs.

A stream cannot pay out money the sender has not funded. If the paying account's balance runs out mid-stream, accrual stops at whatever has already vested. The recipient is not exposed to a missed payment, only to the sender's own shortfall, which is a smaller problem than a payment that never arrives at all.

A stream also does not replace the compliance work around payroll. Tax withholding, contractor classification and reporting still sit outside it. For the recipient's own tax records, CFO Books turns the on-chain history into FIFO or HIFO cost-basis lots and an exportable ledger. None of this is a criticism of the model, only a boundary. A stream fixes the timing problem, not the funding problem or the paperwork problem, and it is worth being precise about which one it actually solves.

The clearest case is anyone paid for continuous work rather than a single deliverable: a remote contractor on a monthly retainer, an employee on salary, an investor receiving a vesting grant. In each case the underlying work or vesting schedule is already continuous. A stream just makes the payment match it, instead of forcing it into a calendar date that has nothing to do with when the value was actually created. The freelancers and remote workers page walks through the setup end to end.

It matters less for one-off payments. There is nothing continuous to match, and a single transfer is already the right shape there. Buying a single item, settling a one-time invoice, or paying a flat fixed price for a deliverable all fit the lump-sum model well, because the value itself was created all at once, not gradually. The point of a money stream is not that streaming beats a lump sum in every case. It is that a lump sum is the wrong shape for a payment that was earned gradually, and until now the gradual case has mostly been forced into the wrong shape anyway, simply because that was the only tool payroll systems had.