QUIVER

Reference

Fees

There is exactly one fee: a flat amount of ETH at creation. Withdrawing is free, cancelling is free, transferring is free, and a fee change can never reach a stream that already exists.

The whole fee schedule

Creating a stream
A flat fee in ETH, passed as msg.value, plus gas. Read the current value from creationFee().
Withdrawing
Free, forever. Gas only.
Cancelling
Free. Gas only.
Transferring or selling a stream
Free. Gas only, and it is a plain ERC-721 transfer.
A cut of the streamed tokens
None. The protocol never takes a share of what you stream.

The fee is charged per stream, not per recipient and not per token. Streaming to twenty contributors is twenty creations, so twenty fees.

Read it, do not hardcode it

The fee is settable by the protocol owner under a hard cap, so any integration should read it rather than assume it. The app does exactly this: the number in the create form is fetched live from the contract.

bash · the current fee and the cap
RPC=https://rpc.mainnet.chain.robinhood.com
QUIVER=0x2866D49f364a70383591a958354A89F6BDf050f2

# what a stream costs right now, in wei
cast call $QUIVER "creationFee()(uint256)" --rpc-url $RPC

# the ceiling, written into the contract as a constant
cast call $QUIVER "MAX_CREATION_FEE()(uint256)" --rpc-url $RPC

Overpaying is safe. createStream keeps exactly the current fee and refunds the rest of your msg.value in the same transaction, so a fee that drops between your simulation and your broadcast costs you nothing. Underpaying reverts with InsufficientFee, so you never accidentally create a stream at the wrong price.

The cap is the point

MAX_CREATION_FEE is a constant, 0.01 ETH. Not a storage variable with an owner-only setter, a constant compiled into the bytecode. It cannot be raised by the owner, by a vote, or by an upgrade, because there is no upgrade path.

setCreationFee reverts with FeeTooHigh above the cap, and so does the constructor. This is the guarantee that matters: whatever happens to this project, nobody can turn it into a toll booth after you have built on it. The worst case is bounded, in advance, in code you can read.

A fee change is never retroactive

The fee is read once, at creation, and never stored on the stream. There is no recurring charge and no settlement later. A stream created today is unaffected by any fee the owner sets tomorrow, because nothing in the withdrawal path consults the fee at all.

What it costs in gas

Measured on real transactions on Robinhood Chain, not estimated:

createStream
325,148 gas. Heavier than a transfer because the contract writes the stream, mints the NFT, and indexes the stream on both the holder side and the funder side.
withdrawMax
56,433 gas. Roughly a token transfer plus a storage write.

Creation buys something with that gas. Because both sides are indexed on-chain, this site needs no backend and no indexer, and the protocol stays fully usable from a block explorer if our frontend disappears tomorrow. On a chain where gas is cheap, that trade is worth making.

Where the fees go

Fees accumulate in the contract as accruedFees and are sent to the treasury address by sweepFees(). That function is permissionless: anyone can trigger the sweep, but the destination is the treasury the owner set, so triggering it does not let you divert anything.

  • accruedFees counts ETH from creation fees only. It is a separate accounting line from the ERC-20s held in escrow for streams.
  • sweepFees only ever moves accruedFees. There is no path in it, or anywhere else, that touches escrowed stream tokens.
  • The owner's entire financial reach is the fee, under the cap, and the treasury address. See Security and limits.