Streamfi aims to be a one-stop solution for token streaming - made to unleash the extent of what can be accomplished by streaming tokens.

Why Streamfi?

When I first came across Superfluid, I grew an immediate curiosity and a need to build on the protocol. This led to me researching possible use cases and finally being selected for the Fellowship helped me shape that into reality.

https://www.streamfi.fun/

https://devfolio.co/projects/streamfi-c856

The current state of Streamfi

With the fellowship nearing its end, I am sure I will continue developing Streamfi, adding more novel features that cater better to users.

This week was spent the week running feedback loops with a closed beta group as well as researching better smart contract practices.

This led to some improvement that brought down the gas amount significantly.

Also fixed some outstanding tasks that I had left out in the front end, like fixing the UI for the DCA tab.

Next steps

The scope of the project defined in the beginning has been loosely met, with iterations for the vision happening continuously. With the help of the fellowship, I have gained vantage on how to build dApps as well as gained a cohort for future collaborations. I plan to build the project forward, focusing on only more novel additions.

Conclusion

Building Streamfi has helped me hone my skills as a smart contract developer as well as integrate those smart contracts with a frontend. With that said, there is still a lot more to learn and I will build Streamfi further as well as build many more projects that help further the cause of web3, bring in novel use-cases and bring in user adoption.

Smart contracts do not internally have the ability to automate themselves. They require automation to be set up outside that can call them on a regular basis. Gelato is one such service that allows this - basically acting as a server that executes a cron job periodically, with the cron job being a smart contract call.

Slippage & Token Volatility

Slippage refers to the difference between the expected price of a trade and the price at which the trade is executed. Slippage can occur at any time but is most prevalent during periods of higher volatility when market orders are used. And as we all know, cryptocurrencies have this nasty habit of being volatile - even the stable ones 🥲

This becomes an incredibly necessary thing to consider when working with user funds and automation.

Current State of Streamfi

Tasks accomplished:

1. Set up smart contract automation using gelato, currently, the contract has been called every day for a week, with 0 bugs, with swaps happening in the correct quantities and ratios with respect to multiple users.

2. Added a slippage check to the swap function which checks if the price of the token is above a certain threshold before swapping funds. Currently, a check of 80% of the initial value has been added i.e. swaps will stop happening once the value of WETH drops below 80% of its value at the time of setting up the task.

PS: The gas fee required for this currently is a little high because of the app being on goerli testnet.

Conclusion

With the fellowship nearing its end, I will start applying the finishing touches to the UI and backend, fixing outstanding bugs and issues. The project will also undergo beta testing this week and a final feedback loop will be run. This has really been a surreal process to build this website among my peers and I would love to see where it goes from now 🚀

Smart contracts require a certain amount of detail and precision over regular code. They require gas optimisations and multiple security checks so that assets are neither wasted nor stolen or locked in the contract.

Some interesting reads:

https://medium.com/beaver-smartcontract-security/defi-security-lecture-7-price-oracle-manipulation-d716cdeaaf77

https://consensys.github.io/smart-contract-best-practices/attacks/oracle-manipulation/

Current State of Streamfi

Tasks accomplished:

1. Fixed some outstanding bugs with the DCA feature, made it more multi-user compatible and added more metrics for users to track like last swap time.

2. Researched how to set slippage checks with Uniswap, getting rates from the SDK about current market conditions and setting up smart contract automation using gelato.

Next Steps

Next week will be focused on implementing the slippage checks in the UI, setting up the automation script and performing checks on further improvements.

Conclusion

After last week’s accomplishments, this week was mostly spent on research about writing better smart contracts and different factors to be kept in mind while operating with DCA - getting data through oracles and public auctions.

Dollar Cost Averaging is an investing technique that reduces user exposure towards the volatility of assets, by buying along an asset’s “average” curve.

This week was spent diving deep into the well of DCA and figuring out how to integrate it with streaming.

How to do DCA?

DCA will be implemented by a contract that receives a stream of tokens from the user, and accumulates this stream till the time the swap function is called. The swap function will be called through a cron job or gelato periodically to swap tokens by all users.

The flow of events:

1. The user gives permission to the contract for the flow of the given tokens.

2. The user actually starts the flow, while the contract logs the flow and starts calculating the amount of tokens accumulated by the user.

3. Whenever the swap or manual swap function is called, the contract calculates the amount of fDAIx tokens sent by the user, unwraps to fDAI, swaps those tokens to WETH and finally sends the tokens to the user itself.

Current Work Done

1. Figured out how to achieve a basic DCA MVP using streams and Uniswap on goerli which swaps fDAIx for WETH - including the contract and UI implementation. Currently, the swap of a user’s tokens happens when the user clicks manual swap, but a function to swap all tokens provided by all users has been written, which needs to be called by a cron job periodically.

2. Planning out further steps that can serve as USP as well as provide users with more freedom on streams:

   1. Allow users to set custom slippage amounts on token swaps

   2. Allowing users to pause the DCA if they want and also manually swap if they like the market conditions

   3. Notifications on streams and every time tokens are swapped (kind of like logs of DCA)

Check out the Demo Video!

Conclusion

This week was very exciting in terms of figuring out the tech behind DCA and streaming, managing permissions and tokens themselves. Learnt a lot about how tokens are swapped using Uniswap, and actually implementing it using a contract.

“A proxy contract is a contract which delegates calls to another contract. To interact with the actual contract you have to go through the proxy, and the proxy knows which contract to delegate the call to (the target).”

As per last week’s update, the real-time balances were supposed to be calculated from timestamps and stream details pulled from the Superfluid subgraph.

But as a matter of chance, I happened to log the contract details of each token and spotted a function: RealtimeBalanceOfNow - which returns the current token balance, without the need for calculations.

However, there was a twist presented in the form of the contract being deployed in the form of a proxy contract by Superfluid.

What Proxy contracts essentially change is how and where the data is stored and fetched. The current way of calling the contract is creating the contract object using the ABI of the underlying contract the Proxy contract calls and the address of the proxy contract itself.

This provided a really convenient and elegant solution to the fetching balances issue discussed last week.

Current State of StreamFi

Tasks accomplished this week:

1. Fixed and finalised the dashboard, adding real-time updated token balances. The balances are being pulled now directly from proxy contracts, which took a lot of research and diving into the contract structure.

2. Added multiple token support - fDAIx, fTUSDx, fUSDCx

3. Planned out the infrastructure of building the savings feature and researched the backend service to be used. Currently tested out redis to build this.

4. An MVP has been deployed on https://streamfi.fun/ 🚀 Would love to get some feedback on the look and feel of the project. NOTE: Only works on Goerli

Conclusion

The app has started to shape up really nicely, having structure and functioning. I have learned a lot especially about writing better code, researching protocols and creating UX flows. Deploying the website and domain never gets old 🛐

Dashboards form an essential part of any project. When it comes to Defi, dashboards become portfolios. Portfolios that need to be as updated and robust as possible, while keeping the UI intuitive for users.

For Streamfi, I started out by building a standard dashboard that tracks the user’s streams (incoming and outgoing) and displays necessary information related to that stream. There were a couple of roadblocks along the way, majorly in the form of how to access stream information.

Superfluid provides its Subgraph, which you can use to pull information for each account, token, stream, etc. The subgraph, however, does not give you exact token balances (since they are being streamed on a per-second basis). This needs to be calculated on the client side of the app in real-time (yet to be implemented).

Current State of StreamFi

For this week, I focused on 2 major components of the app - finalising the Create Stream functionality and making the dashboard. Users are now able to create streams to other users in a more cleaner and functioning UI, along with viewing their created and incoming streams in the dashboard. The balances of each token are not being displayed currently and is the next feature I would work upon.

The next step after the dashboard is completed is adding a savings tab that users can use to keep track of their personal expenses and stream into their accounts.

Snapshots of the current version (feedback appreciated)

Conclusion

This week was filled with understanding what good UX looks like as well as evaluating the project’s further vision. I had a lot of fun tinkering with the Superfluid Subgraph and have some plans to even build on top of it 👀

Token streaming is a relatively new concept in the web3 space and has been gaining traction, with innovative use cases popping up. The team at Superfluid, a token streaming framework I will be using to build my project has been continuously adding newer features, like token vesting which they added earlier this week.

I have been researching use cases, taking user feedback and trying to find ways to make the dApp as useful as possible. Ideas like notifications, interest-bearing streams and streaming markets are some possible functionalities I researched this week for the scope of this project.

This week’s PoW

Tasks accomplished this week:

1. Made the code base for creating and managing streams more robust, with added UI changes in the website.

2. Got user feedback on the created MVP and implemented some UX changes.

3. Made the Dashboard front-end and gained vantage on how to gain stream details from the SDK.

What’s Next?

The next week will be spent connecting the Dashboard frontend to the data pulled from the SDK, while finding ways to make the code even more optimised and robust and getting ready for starting the next feature’s development, i.e. custom set Savings accounts.

Conclusion

This week was the first time I got user feedback, resulting in some realisations regarding the direction of the product as well as some things that needed to be improved.

As a part of the ETHIndia fellowship 3.0, I will be building StreamFi: a One-stop personal Defi Streaming Application for novice as well as advanced users built on top of Superfluid, a token streaming platform which facilitates token transfer in continuous streams rather than transfer in discrete blocks.

Project Plan

To develop this project, the plan is to build functionalities one at a time, keeping code quality and UI in check. The functionalities should build upon each other and form the app by the end of the timeline.

The dApp will undergo continuous feedback loops with mentors and alpha testing during development itself to ensure a meaningful and seamless application.

This week’s PoW

This week accomplished the following tasks:

1. Technical research on how the project would be implemented and going through the Superfluid docs to find the necessary modules that would be necessary to create the project.

2. Started work on the website and completed functionality of creating a stream and deletion of the created stream. The current POC can be found here

3. This has been done for the DAIx token, further token support will be added next.

The only roadblock encountered was understanding the infrastructure at Superfluid, with token streaming being a fairly new concept, setting up the SDK and figuring out how it interacted with the front end.

Next Steps

The next step is to make the code quality better via modularity, making the code less vulnerable to edge cases and adding more token support.

After that, the development process for the dashboard feature will begin where the users will be able to view and keep track of their created streams.

Conclusion

The first week of the fellowship has already proven to be a productive and rewarding experience, featuring intellectual conversations with other members of the cohort, sharing resources with each other and looking at the innovations in the ecosystem.