Superfluid (superfluid.org) is a real-time asset-streaming protocol: instead of sending a payment as a one-off transaction, an account opens a stream that moves tokens to a recipient continuously, every second, at a set flow rate — and keeps flowing, with no further transactions, until someone cancels it or the sender runs out of balance. It is the reference primitive for treating money as a live flow rather than a sequence of discrete transfers, and DAOs reach for it for exactly the payments that never really stop: contributor salaries, grants, subscriptions, and streaming reward programs. It sits alongside Sablier as the other pole of on-chain streaming — where Sablier escrows a fixed pot and releases it over a set vesting schedule, Superfluid locks up no capital and simply nets every inflow and outflow in real time.
Super Tokens: money as a flow
Everything in Superfluid is built on the Super Token, which the docs describe as “an extension to the ERC-20 standard enabling the transfer of value in completely novel ways.” Any ERC-20 can be wrapped into its Super Token form (USDC becomes USDCx), and the protocol also supports natively-built Pure Super Tokens. The critical property is that a Super Token balance changes with the passage of time: rather than being updated only when a transaction lands, it is computed live from the account’s net flow rate, so a salary recipient’s balance visibly climbs each second while the payer’s falls. Because “no capital is locked up, and all inflows and outflows are netted in real-time,” a treasury that pays ten contributors and earns fees from a product nets all eleven flows into a single continuously-updating balance without a transaction per period.
Money streaming: the Constant Flow Agreement
The streaming behaviour itself is one of Superfluid’s agreements. The ConstantFlowAgreement (CFA) governs a per-second flow: an account sets a flow rate (denominated in wei per second) to a recipient, and from that moment value moves continuously with no further action. As Superfluid puts it, “Money Streaming allows for continuous, per-second token transfers between accounts”, and a stream continues until it is cancelled by the sender or the sender’s balance depletes. This is the difference from a vesting stream: a CFA stream has no built-in end date and no escrowed pot behind it — it runs open-endedly as long as the sender keeps enough Super Token balance to sustain it, which makes it a natural fit for salaries and subscriptions that should simply keep paying.
Distributions: one-to-many pools
Paying many recipients at once uses a different agreement. The GeneralDistributionAgreement (GDA) lets a pool admin create a Superfluid Pool and assign each member a number of units; a distribution — whether an instant lump or an ongoing stream into the pool — is then split across members in proportion to their units, in a single scalable operation rather than one transfer per recipient. The GDA supersedes the earlier InstantDistributionAgreement (IDA), now deprecated. For a DAO this is the machinery behind proportional reward programs, revenue sharing, and gas-cheap airdrops: adjust a member’s units and their share of every future distribution changes automatically.
Keeping streams solvent
An open-ended stream that carries no escrow raises an obvious question: what happens when the sender’s balance finally runs dry? Superfluid’s answer is a small buffer — when a stream is opened the sender locks a modest deposit, sized to a short slice of the flow, rather than the whole future value. If the sender’s balance is exhausted while the stream is still open, the stream becomes liquidatable: anyone can close it, and the buffer is forfeited to cover the shortfall and reward the liquidator for cleaning up an insolvent stream. This keeps the system honest without escrowing capital — the buffer is the sender’s incentive to top up or cancel before running out, and the reason recipients can trust a live balance they never had to lock. The whole protocol is coordinated by a central Host contract that routes calls between the Super Token contracts and the CFA/GDA agreements.
Why DAOs use it
Streaming reframes a recurring-payments problem that DAOs hit constantly. A treasury that votes a contributor a monthly salary does not want to run a governance transaction — or a manual multisig payout — every single month; a stream lets the DAO open the flow once and let it run, cancelling it with a single action if the engagement ends. The same shape covers contributor compensation, retroactive and ongoing grants, product subscriptions billed per-second, and reward campaigns that pay continuously rather than in a lump. Because Super Tokens net all flows live, a DAO can watch its runway change in real time instead of reconciling it after each disbursement — a different emphasis from Sablier’s escrowed vesting schedules, and a complement to active-management approaches like karpatkey in the broader picture of DAO treasury management.
From protocol to DAO: the SUP token
Superfluid is now governed by the tool it helped popularise. In February 2025 the Superfluid Foundation introduced SUP, the governance token of the protocol, distributed under a model it calls Streaming Programmatic Rewards — fittingly, the token is itself streamed to ecosystem users over time rather than dropped all at once. One billion SUP were minted at genesis, with 60% allocated to the community (rewards, staking, and governance) and the team and early backers receiving 25% and 15% respectively under multi-year lockup streams with a one-year cliff. Holders participate through Superfluid DAO, making Superfluid both a piece of DAO tooling and a DAO in its own right.
How Caper approaches this
Superfluid answers “let this payment run continuously on its own.” Caper deliberately does the opposite: a caper’s treasury moves only in discrete, governed lumps. Every disbursement is a typed proposal — a PAYOUT that must win a vote and then executes a single on-chain transfer of a fixed amount, not an open-ended flow (verified in caper_dao.rs: execute_proposal_payout calls treasury_vault.transfer(recipient, currency, amount) once). There is no streaming primitive in the contract, and that is intentional — the point is that spending the treasury is always a decision on the record, not a standing drip. The two are complementary rather than competing: a caper could vote a grant and, if it wanted continuous settlement, fund a Superfluid stream out of a single approved payout. Where Caper puts the funding decision and the vote on-chain and auditable, Superfluid puts the schedule on-chain — and a treasury can use both.
References
- Superfluid, “What is Superfluid” (docs) · Protocol Architecture
- Superfluid, Money Streaming overview · Distribution Pools
- Superfluid, “Introducing SUP: The Superfluid Token” · Superfluid DAO claim & governance
- The Block, “Superfluid raises $9 million in seed funding”