Reflow
Transact once, update forever.
About
The problem it solves **Disclaimer** -- Money streaming in it's current phase is working on the logic of constant flow agreements. While these agreements in themselves are quite beneficiary, they could be improved upon further by adding updates + automating them. 👀 > **So, what Reflow does?** -- It helps in creating reward flows which *stream + update* themselves in real-time. 🌊 **Ummm**, what the heck does that mean anyway? 🙄 > *Let's suppose, A (Employer) wants to give salary to B (Employee), but on 2 conditions:* 1. B will receive 100 tokens **per second**, instead of all at once. 2. After each month, salary will be **doubled** -- loyalty bonus. **Therefore**, the scenario would look something like: - 1st Month, B receives *100 tokens/sec* - 2nd Month, B receives *200 tokens/sec* - 3rd Month, B receives *400 tokens/sec* and so on. > **Wait a minute**, is that even possible? 🤔 Well, that's exactly what **Reflow does** -- you can *send money stream* (like Netflix) to anyone; which will be *automagically updated* after a fixed time interval. Plus, you have to **transact only once**, and everything else will be automated -- pretty cool, right? 🙂 > **Under the hood**, this is how it all works: - Money is *streamed* in real-time using **Superfluid**. - Stream is *updated* after specific intervals using **Chainlink**. - Off-chain *notifications* to on-chain updates are sent using **Push Protocol**. > **Moreover**, the 2 major problems which Reflow solves are: - Lack of loyalty based streaming. - Non-availability of real-time updates.
How it's made
Challenges we ran into The main issue was finding a way about how to link Chainlink's smart contract to Reflow's contract such that transactions happen only when there needs to be an update. This needed to be ensured because if transactions keep on running, they would eventually lead to gas loss. Thus, the solution I found was to embed that specific condition in the contract itself as even if Chainlink tries to make an update, the transaction would be automatically reverted without making a state change. Moreover, in order to confirm that it worked, I also added push notifications which could send an update if streaming hadn't stopped + the same could be verified via Superfluid console too.