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.
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.
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.
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.
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.
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.
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 future inflation left to the DAO.
The community “will receive and be responsible for” 60% of supply, but the announcement splits that number in two: 35% forms the DAO Treasury managed directly by the DAO, and the other 25% forms the Foundation treasury. The development team and early backers take 25% and 15% respectively, both under a three-year lockup stream with a one-year cliff, and the token was not transferable at launch. Holders participate through Superfluid DAO, making Superfluid both a piece of DAO tooling and a DAO in its own right.
The DAO is not a dormant token wrapper. Its ballot is a Snapshot space on Base that has run 22 proposals since February 2025, and the space configuration says as much as the votes do. Proposing is restricted to the space’s admins rather than open to any holder, which is why the register is numbered SIPs and carries none of the airdrop spam that fills permissionless spaces; votes are weighted and run for seven days.
The weighting is the part worth borrowing. Voting power does not come from a wallet’s SUP balance. The space’s strategies read a custom fountainhead strategy over SUP committed to a Locker contract, plus the vSUP token at 0x3DF8A6558073e973f4c3979138Cca836C993E285 on Base, whose on-chain symbol is literally lockedSUP, plus delegation over both. Superfluid therefore runs a locked-stake variant of token-weighted voting: holding SUP is not enough, it has to be committed. Read keylessly by eth_call at Base block 51,923,862 on 28 September 2026, lockedSUP supply stood at roughly 191.7 million, down from 198.8 million on 10 September (block 51,121,005) and close to the 192.7 million read three weeks before that.
The register also shows what a protocol’s own governance looks like once the token exists. SIP #12 stood up a DAO Treasury Committee and operational wallets, two Security Council elections ran nominee-selection votes in December 2025 and July 2026, and seasonal ecosystem campaigns (SIP #11, #14 and #17) allocate the streaming rewards by vote. Turnout does not fall with the DAO’s age so much as with how directly a ballot hands the voter money. Read from the closed register on 10 September 2026, the three largest votes Superfluid has ever run are all reward business – Season 2’s campaign selection at 1,607 voters, SIP #7 on SUP transferability at 1,338, and Season 3 at 1,157 – while the thinnest ballots of 2026 are the ones that allocate nothing to the voter: 83 for the second Security Council nominee selection in July, 171 and 183 for the two yield-backend continuations in May.
The campaign-selection series does slope down across that pattern – Season 5 drew 1,020 voters in February 2026, Season 6 drew 505 in May, Season 7 closed at 391 on 25 August – which is a softening reward vote rather than the collapse in participation this page once recorded. That earlier figure is worth naming: this page previously reported 77 voters for Season 7, a number read on 20 August while the ballot was still open. It ran to 25 August and finished at 391. A tally read mid-window is not a result, and on a seven-day vote it understated this one fivefold.
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 (in contracts/core/src/caper_dao.rs, execute_payout makes one treasury_vault.transfer(recipient, currency, amount) call to the stored recipient, and bind_action refuses a proposal that has already executed).
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.