The problem BlockOverflow solves

BlockOverflow allows users to get their rewards in real-time. It is used to drive its users to show work and contributions as they go and participate on the platform with a new concept of winning. The payments are done in streams in real-time according to the event rules programmed to generate dynamic leaderboards. Leaderboards are generated based on such rules and stream endpoints change throughout the event with it.

For any such events BlockOverflow is different from others as it doesn’t put a full stop to your chance of winning or improvement, its dynamic nature allows constant improvement. This can be applied to virtual and IRL events where a leaderboard is maintained. Some examples are team projects in private orgs, open-source work, hackathons, games, etc.

Problem Solves

• Creates a trustworthy system for events which mitigates the bias judge factor of determining who is worthy of the rewards.
• Sending and receiving of streams happening in real-time based on agreed rules, reduces the conflict of interests between parties when it comes to asset value appreciation or depreciation due to delays.
• Provides a new way of determining a winner of any event by replacing the traditional one-stop way of crossing the finish line.
• Introduces a more efficient way of payments using automated programmed streams based on agreed rules and acts as an escrow for the parties preserving the status-quo
• Can give a new way of rewarding members in communities via integrating the project with discord bots, DAOs, team projects, private orgs, etc managed by the concerned authority.
• There are no closed room meetings or secret talk about deciding the worthy. You show progress in real-time, you earn rewards in real-time.
• Implementation of this in team projects/community projects, each person’s contribution can be tracked and rewarded/credited with real-time streams. This removes the negative intangible factors from a person as an individual’s credits are not diluted.

Challenges I ran into

Faced some challenges with developing logic for updating and creating streams to give rewards in streams. Dealing with bugs on Superfluid stream transactions and tokens. There was a bug due to which the contract was not able to determine the gas amount and the transactions failed. These issues were resolved by getting in touch with the Superfluid team on their discord server.
The project uses the looping streams logic to initially start and maintain the streams. This is an issue as streams were looping for a long time unless some events trigger them to switch endpoints. In the new feature, from the Superfluid docs, we can make an Access Control List which allows an account to initiate streams for some other account. This was discussed with the team and is helpful.