FAQ

No. There is no admin withdraw in the contract, and no upgrade path to add one. The owner can set the creation fee, under a cap written into the code, the treasury address, and the card renderer. That is the entire surface. See Security and limits.

An attacker could set the fee to the cap, point the treasury at themselves, and break the artwork. They could not touch a single escrowed token, cancel a stream, or pause anything. Your streams would keep paying out on schedule.

No. It has unit tests, fuzz invariants, and fork tests against real tokens on Robinhood Chain. That is evidence, not a substitute for an audit. It holds real funds, so treat it accordingly and read the code before committing size.

Nothing to your stream. The schedule and the funds are in the contract. Both dashboards here are rebuilt from plain eth_call, so anyone can read, withdraw, cancel or transfer with a block explorer and no frontend at all.

No. There is no deadline anywhere in the contract. Withdraw every day for four years or once at the end, it makes no difference to what you receive. Nothing expires, and no withdrawal is needed to keep a stream alive.

No, and that is deliberate. The vested part stays owed to the recipient and they can still withdraw it afterwards. Only the unvested remainder returns to you. Cancelling is a stop, not a clawback. See Cancel and renounce.

Only if you kept the right. Create the stream irrevocable, or call renounceCancel later, and cancelling reverts forever. There is no undo and no admin override. That is the entire point of it.

No. Only the sender, the address that funded the stream, can cancel. A recipient who wants out sells the NFT instead.

Because the vested part is still owed to the holder until they withdraw it. Cancelling stops accrual and refunds the unvested part, it does not empty the stream.

Because cancel clears the cancelable flag on its way out, and that check runs first. AlreadyCanceled exists in the ABI but no call path currently reaches it. Worth knowing if you decode revert selectors.

So the claim is transferable with no custom code. ownerOf(id) is the only address that can withdraw, so an ordinary ERC-721 transfer is a transfer of the future income. It also means your vesting shows up in any wallet and composes as collateral anywhere. See Tradable streams.

No. The buyer becomes the recipient the moment the transfer lands, and collects everything from then on, including tokens that vested before the sale and were never withdrawn. Withdraw first if you want the vested part.

Only if cancelable == false. Otherwise the sender can cancel and take the unvested part back, including in the block right after your purchase. Also check withdrawn: a seller can legitimately empty the vested part right before selling.

A renderer contract builds it on-chain, at read time, from the contract's own state. No server, no IPFS pin to lapse. The owner can swap the renderer, which changes how a stream looks and never what it pays.

It lets them withdraw its tokens to any address they choose, and transfer the NFT. That is standard ERC-721 behaviour, and setApprovalForAll grants it over every stream you hold, now and later. Approve carefully.

It gates the withdrawal, it does not pause the accrual. Value builds behind it the whole time, so on a 4 year stream with a 1 year cliff, the day the cliff lands, 25% unlocks at once. It does not restart the clock.

Yes. The stream is then already partly vested at creation, and if start is far enough back, immediately withdrawable. Useful for backdating an agreement to the day it was actually made.

Pass cliff == start. There is no separate flag, because a gate that opens at the start gates nothing. In the app, set the cliff to 0 days.

No. A stream is immutable once created. To change terms, cancel if you can and create a new one. To add tokens, create a second stream. This is why verifying before renounceCancel matters.

No. A withdrawal only increments withdrawn. It never touches the schedule, the end date, or the rate. Withdrawing is purely about when you want the tokens in hand.

A flat fee in ETH at creation, plus gas. Withdrawing, cancelling and transferring are free beyond gas, and the protocol never takes a cut of the streamed tokens. Read the current fee from creationFee() rather than hardcoding it. See Fees.

No. The fee is read once at creation and never stored on the stream. Nothing in the withdrawal path consults it, so a fee change cannot reach a stream that already exists. And the fee can never exceed 0.01 ETH, which is a compile-time constant, not a setting.

The excess is refunded in the same transaction. Underpaying reverts with InsufficientFee, so you never create a stream at the wrong price.

Any ERC-20 on Robinhood Chain. The dropdown is a shortcut for tokens that actually trade there, not a permission list. Paste any address to stream it.

Handled. The deposit is measured by the balance actually received, so the stream is created for the net amount and only ever promises what the contract really holds.

Not recommended. deposited is fixed at creation, so if balances change underneath the contract, the accounting will not follow. Streaming a rebasing token is a good way to be unpleasantly surprised.

Yes, as long as the contract implements onERC721Received. If it does not, creation reverts on purpose: such an address could never withdraw or transfer, and the tokens would be stranded forever. The form checks this before you sign.

Yes, and it is the whole team vesting pattern. Stream your own allocation to yourself, renounce the right to cancel, and you have proven on-chain that you cannot pull it early.

Almost always because nothing is withdrawable yet, and withdrawing zero is rejected with ZeroAmount. That happens during a cliff, or straight after another withdrawal. Check withdrawableOf(id) first.

No, and that is deliberate. Every action is a direct contract call. See Integration for working cast, viem and Solidity examples.

Yes. The holder picks the destination on every withdrawal. The tokens do not have to land on the address holding the stream.

streamsOfHolder(you) for what you collect, and streamsBySender(you) for what you funded. Both are plain views. The streams page is built from exactly those two calls.

The mathsis real, the ticking is a local mirror of the contract's formula so a counter can animate between reads. The chain is the source of truth at the moment of withdrawal, and the displayed value can be a few seconds off, because the contract reads block.timestamp rather than your clock.