Rhada is pioneering 'Event Driven Payments'. We are building a service for DApp developers to link payment streams to real world events.
The Rhada app is an implementation/Proof of concept of the Rhada Protocol. Our aim was to solve the problem of tying a stream of real world events to a stream of payments. At the moment, transaction fees on almost all blockchains remove any potential for microtransactions, and it is somewhat cumbersome for developers to set up any sort of recurring payment system due to smart contracts being unable to self-execute. Our application is a first attempt at trying to address this problem for small, repeated events that should trigger small, repeated payments. We have written an example story illustrating our app use case below: The Times 03/Jan/2029 Chancellor on brink of fifteenth bailout for banks. History never repeats itself, but it does often rhyme. The year is 2029, the financial aftermath of the COVID-19 pandemic led to a steady decline in government backed currency, loans and economy. Money is now almost entirely digital, with the exception of grandfathering old currency. Entrepreneurs must now look to their peers, or Decentralized Autonomous Organizations, to generate funds for their startup. However, principal capital isn’t always so easy to come by. Sometimes an initial investment might include a service such as developing a product; where the return on said investment is a portion of future revenue. This system has thrived to fill the void the financial system has lost, and coined the name ‘Event Driven Payments’ in the process. Here is how it works - In this story are four roles: The Buyer, Mark, is someone with a great startup idea but lacks the capital to pay the developer upfront. The Seller, Carey, is a professional Web3 Developer and doesn’t mind making risky investments that can pay off big if their work is good enough. The Protocol is the tried and tested Event Driven Payments protocol that acts as the base-line logic for a plethora of decentralized applications. The App is a popular decentralized finance site that provides the interface for the Event Driven Payments protocol. Mark came up with an idea to revolutionize the NFT market and bring together all types of NFTs into a reactive gallery that is not confined by a geographical border. However, he had one problem; he doesn’t know the art of computer programming, and doesn’t have enough money to pay someone to build it. This startup does not catch the eye of big player venture capitalists and going through the new financial institutions would just be too cumbersome. Hearing about a recent explosion in event driven payments, Mark decided to give RhadaPay a try. This is an event driven payments protocol in which two parties sign a ‘smart contract’ to act as an escrow, guaranteeing the buyer gets their asset (in this case a website), and the seller receives payments based on the revenue that asset generates (in this case visits to Marks website). The funneling of the payments is done in the smart contract by connecting a payment stream to Superfluid, a payment stream protocol, and then logging the event information to IPFS with Textile. All Mark has to do is stake an initial amount to show he is a legit buyer, then create his job and wait for others to apply! Using RhadaPay, Mark can begin creating his job. This requires him to enter the following fields into the application: Initial Amount of funding that will need to be staked Refresh Rate: Number of events before triggering a payment refresh Event Stream: Connects a job to an event stream Percentage: Percentage increase after each payment refresh But before going any further, Mark needs to create an event stream with a description of what particular events will increase the amount of money the developer who built his project is paid. For his event stream, Mark can give the description: ‘NFT Gallery event stream for website visits.’ Now that Mark has his event stream setup, he just needs to define the refresh rate of the number of events and the percentage increase after each payment refresh. For these numbers he determines that every 10,000 visits he will increase the payments 1.00%. Perfect, now he is all set to find a seller and begin his journey with this new idea. He submits the form and the smart contracts fire, triggering the start of future event driven payments. Carey, an enthusiastic Web3 Developer, has been looking for ways she can generate new forms of passive income. Like Mark, she’s heard of the expanding event driven payments technology and has been intrigued by the concept. Loading up the RhadaPay application, Carey is able to view a list of posted jobs. With a history in NFTs, she’s able to find a very interesting and potentially lucrative job with the name “Digital NFT Gallery”. She selects it and formally applies, and waits to see if she is selected. Mark, seeing Carey’s strong trust factor and proven history, decides that she is the right partner to work with and selects her as a seller. They both connect their digital wallet and use it to sign off on the terms of the contract.With both parties signed off, Carey can begin to develop the application for Mark. Based on the terms of the contract, Carey has a deadline to present her work to Mark and submit the CID to be reviewed. A couple of months go by and Carey creates an outstanding product for Mark. She goes back to the RhadaPay application and submits her work. Mark, who has been patiently waiting, gets a notification that Carey has submitted her work and can go to view what she has done. “Wow!”, says Mark, “I can’t believe she was able to do this so quickly and do such a fantastic job!” Pleased with the product, Mark does a final sign to complete Carey’s work. With the final signing now approved, the protocol connects to Superfluid to set up a payment stream. Within the protocol, an autonomous Ethereum wallet is set up to receive and split the revenue for Mark's new application. Mark will get billed for the amount negotiated between Carey and himself, and the amount will go to the protocol address, where it is then sent to Carey. Mark’s application has a slow start and only sees < 5,000 users in the first two months. However, in his third month he signs a deal to display some big game NFTs and his traffic goes up tenfold. With now 50,000 visits in his third month, the payment to Carey has increased 5% and has reflected in the payments she receives. Now, over time, Carey sees her revenue stream continue to come in. She’s now successfully built a product and sold it for passive income using events driven payments! Not only that, but Mark now has a thriving business and was able to launch his startup without paying a large amount up front
How it's made
For the following question, the buyer will be defined as a job creator looking to hire a developer, and the seller will be defined as a developer seeking work. The RhadaPay dapp we built is a combination of a client-side Typescript application, interacting with various decentralised networks and an event handler. The client-side app is a VueJS application which is authenticated using a user’s metamask wallet. The frontend primarily interacts with the Rhada protocol via a series of transactions and calls to a set of smart contracts which handle the data storage, logic, and payment mechanisms that define RhadaPay. Thes contracts allow for a buyer to create a job with various information, such as a title, description, due date, payment information, events to be tracked, and other data that clearly communicate the terms of the work set out to potential sellers. The contract communicates this information with the frontend via emitted contract events, which will then in turn list the job information on the RhadaPay DApp. Sellers can apply for jobs, and the buyer can choose one of these sellers that applied to complete the buyer’s job. Upon selecting a final seller, the buyer can no longer modify the terms of the job, as dictated by an enum describing the states of the RhadaPay job process. The buyer and the seller will then sign off on the final terms before work can officially be started. Once the work is done, the final seller can submit the work, which will then be reviewed by the buyer before the buyer either approves of or rejects the work with a final sign. Behind the scenes, a second set of smart contracts provide the interface between Rhada and Superfluid for payments. Superfluid solves for us the ability to stream real time payments with minimal transaction fees. If the final submission is approved, a Superfluid flow will be created. While this flow is normally mutable by the stream creator (in this case the buyer), the Rhada Protocol locks this flow by using an autonomous and decentralized intermediary contract. This intermediary contract is complemented by a staking mechanism in the PaymentFactory.sol contract in which the buyer stakes matic into the PaymentFactory.sol contract, which will in turn be used to fuel the payment flow. This prevents the seller from modifying the payment flow while also giving a trustless source control over the payout, incrementing and decrementing the contract solely as defined by the Rhada Protocol - based on the agreed stream of events. The RhadaPay frontend uses the graph to query data from Superfluid payment streams created in each job. This allows for both sellers and buyers to visualize their pay-in and pay-out, respectively, both in a graph and text format without having to search for addresses and Superfluid data in order to see one’s pay, all while remaining on the RhadaPay website. Events are stored as JSON objects within IPFS, using Textile’s ThreadDB as an ORM. For this hackathon, we setup a simple ExpressJS application that handles incoming events, and logs them to IPFS using ThreadDB. It also has some simple logic to check if the number of events matches the trigger condition stored in the smart contract, and if so, has a signed ethereum wallet that is authorised to make changes to payment flows accordingly. We chose IPFS to keep the data truly decentralised, and therefore auditable by anyone - to build trust in the protocol, and we chose Textile because of the ease of use of their existing DB application built on top of IPFS. Finally, the RhadaPay dapp and all of its contracts are to be deployed on the Polygon network to allow for cheaper gas fees with all the benefits of the Ethereum mainnet.Technologies used