Supporting Money Streams
Supporting Streams in Your Application
Last updated
Was this helpful?
Supporting Streams in Your Application
Last updated
Was this helpful?
When an account opens a money stream using the constant flow agreement, they need to define the receiver, the super token being streamed, and the flow rate of that stream. For example, in our sdk, it looks like this:
When this stream is opened, 4 hours worth of that stream is held in escrow by the protocol. This is known as the streamβs buffer. The buffer is a mechanism to help keep Superfluid secure. With Superfluid streams, you donβt need to lock up the entire stream amount up front. You can learn more about why this works the way that it does , but itβs worth keeping that buffer amount in mind.
For example, as long as I have at least 4 hours worth of the stream in my balance, I can open the above stream at 1000/month. Having all 1k tokens in my wallet is unnecessary: I can keep them working in Aave or Compound, and then periodically top up my wallet balance.
An account can be sending and receiving an arbitrary number of streams at any given point in time. However, the thing that will likely matter for your integration is going to be an accountβs net flow rate.
The netFlowRate
is the total number of tokens being sent or received each second. Accounts will have different net flow rates for each token depending on their streaming activity. As weβll see in the next section, this will be relevant for displaying a balance that is changing in real time. You can get the netFlowRate
in three different ways:
1) Using the :
2) Using the Superfluid , using an entity such as accountTokenSnapshot
Note that you can experiment with your own queries in the subgraph playground in the .
3) You can also get netFlowRate
data in solidity by calling getNetFlow
on the