Description

Superfluid, we all know with the concept of streaming money by creating flows among users has opened doors for lot of applications and use cases. But, streams on superfluid are constant flow agreements, which can't be changed once the streams is started. This restricts the use cases and flexibility for the end users. Cuperfluid is a customised version of the constant streams. It provides a checkpoint based proof of work verification mechanism for the end users. Cuperfluid is applicable in all those places where the sender is interested in modifying the payment streams based on the work done by the receiver. It can act as a generalised solution for streaming payments for any verifiable proof of work. The creator of stream provides a checkpoint interval and an endpoint to the contract while creating a stream (along with other details) and the contract acts as a middleware and verifies the proof of work done by the receiver using the endpoint provided by the server. The contract is now responsible for alterations in the streams with the receiver. This mechanism abstracts the logic and makes it super easy and convenient for end users. Although, the model currently is semi-centralised due to the fact that the endpoint for verification is centralised, the goal is to make it fully decentralised in the near future. The current motive behind this model is to perform off-chain verification.

Cuperfluid showcase

How it's made

We developed a middleware contract on top of the superfluid protocol. The contract uses chainlink's network to query the external api's and bring the the proof of work. The querying for proof is handled by a backend and is completely abstracted for the end user. It uses Biconomy's Gasless Meta Transactions for registering a stream with the contract. Hence, this makes the stream creation on cuperfluid completely free for the sender. Moreover, All the contracts are deployed on Polygon (testnet) for fast and cheap transactions. The whole execution flow of backend is written in form of simulation. The schema is as follows: - A contract which handles the streams, chainlink querying - A backend which communicates and listens to the contract and performs calls on each checkpoint for each active stream. Based on the proof of work result, it updates the streams