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.

I received a grant to develop a multiplatform Stellar SDK for Kotlin (https://github.com/rahimklaber/stellar_kt).

I have done the following:

• Created wrappers around the accounts, transactions and operations Horizon endpoints.
• Created classes to represent the Stellar XDR definitions. I did this by hand to make the classes easier and more pleasant to use.
• Implemented the functionality of signing transactions.
• Partially implemented the functionality of creating transactions.

I am currently working on allowing users to create and submit transactions. Afterward, I am planning on adding Soroban support.

Some Technical Information

The project will consist of 3 smart contracts, a Stream contract, Stream split contract and an Exchange contract.

The Stream contract will contain the streaming logic.

The Stream split contract will contain the logic of splitting streams. A stream can be split to have multiple recipients. The recipients can be either Stellar accounts or other contracts. Contracts will have to adhere to an interface to be compatible. Therefore integrations with other contracts will go through an "adapter" contract.

The Exchange contract will be a wrapper around a dex so that it can be used with the split contract.

There will be a Backend service that keeps track of streams, their recipients and creators so that you don't need to know the ID of a stream to look up its details. This service will continuously listen to contract events and keep track of the streams in a database. Most likely I will use TypeScript as its Stellar libraries are the most reliable in terms of Soroban support.

There will also be a Keeper that is responsible for periodically claiming and exchanging tokens. The Keeper will listen to contract events and build a queue of tasks to execute. Currently, I'm aiming to have the Keeper exchange tokens every 30 to 60 minutes. Initially, the Keeper will not be as robust as I like and it may skip tasks. I will likely make another submission in the future To make a more robust Keeper, which could be useful for other projects as well. The Keeper will also be written in TypeScript.

Revenue Model

The core application will be free and open source. However, I will build apps on top that will charge a fee. For example, converting a portion of the stream to another token or lending out the stream funds.

Marketing

I will attempt to gain users by posting in the Stellar Discords.

I will also attempt to piggyback off other projects' popularity by integrating SStream with those projects. The first integration will be either with Soroswap or Comet to support the token exchange feature.

The first deliverable consisted of a streaming payments smart contract and a basic user interface.

The smart contract and UI have the following features:

• Creating streams - Streams can be created with a specific amount, flow rate, recipient, and end date.
• Withdrawing from streams - The recipient of a stream can withdraw the current withdrawable amount.
• Canceling streams - A cancellable stream can be created that is cancellable by the creator. When canceling,  the current claimable amount will be sent to the recipient.

I have created and tested the contract and the UI.

How can a reviewer check you completed your first deliverable?

The code is publically available at https://github.com/rahimklaber/SStream. The UI is accessible at https://s-stream.vercel.app/.

The contract code and test are in the src folder and the UI is in the ui folder.

The README contains instructions about how to use the UI. One important thing to remember is to make sure that your freighter wallet is on the futurenet and that it is funded.

To quickly try out the UI without setting up a second wallet, you can create a stream from and to yourself.

‍

‍