
Streaming payments allow users to send funds to a recipient, such that a portion of the amount sent is claimable every `x` seconds/hours/days. This type of protocol is useful in many situations, such as a DAO giving out grants. In this case, the DAO can give the grant out as a streaming payment and can cancel the stream when the recipients are not making progress. The protocol will be composable and allow others or me to easily add extra functionality. For example, I am planning to make it possible to use a portion of the stream to invest in other tokens periodically.
Features I am currently planning these features: - Basic functionality: Users can create streams and recipients can withdraw from streams by using a web app. - Top-up streams: The creator of a stream can add additional funds to the stream. - Transferrable streams: Streams will be represented as tokens, which will allow the recipient of a stream to transfer a portion of the stream to someone else. Representing the stream as tokens could also be useful in other ways, such as allowing wallets to notify a user when a stream was canceled. - Infinite Streams: Streams can have no end date. This allows for some interesting applications, such as streaming funds to a DEX where the funds are then exchanged. - Partial conversion to other tokens: Recipients will be able to invest a portion of their stream into other tokens. Funds will periodically be withdrawn and invested. This feature will charge a fee.
Use cases: - Grants: Organizations can use SStream to pay out grants. A cancellable stream can be created per grant. The organization can cancel the stream if the grant recipient is not fulfilling their obligations. - Salaries: Imagine receiving a portion of your salary every second. - Subscriptions: Imagine subscribing to a service where you pay per second and can cancel at any time. - Daily cost average buys: SStream can be used to DCA by creating a stream that periodically converts funds into other tokens.
Challenges: I want the system to be composable. However, this means that the system has to work in many different scenarios and that I will have to consider many different factors. For example, someone can send some of their stream tokens to another user and the other user can keep claiming before the first user is able to. In this way, they are doing a sort of denial of service attack. I will offer services that will rely on keepers. I need to determine the frequency that the keeper calls the contract, such that it is frequent enough to be useful but keeps costs low. I may have to rethink some parts of the system depending on how high the gas fees end up being.
Architecture: The system will consist of a core contract that handles the stream behaviors and another contract that handles integrations with other contracts. A backend will keep track of users' streams and a Keeper will be responsible for periodic token exchange. The diagram gives a nice view of the architecture.
$36.0K

No other submissions.